WO2025179447A1

WO2025179447A1 - Authentication system and method based on decentralized digital identities

Info

Publication number: WO2025179447A1
Application number: PCT/CN2024/078710
Authority: WO
Inventors: Renyuan TAN; Peng Zhao; Fei PANG; Bing Qu; Junbao DUAN; Tianyu TAN; Ling Zhang; Chengqing JIANG; Tzu-Hsuan Huang
Original assignee: HSBC Software Development Guangdong Ltd
Current assignee: HSBC Software Development Guangdong Ltd
Priority date: 2024-02-27
Filing date: 2024-02-27
Publication date: 2025-09-04
Anticipated expiration: 2026-08-27

Abstract

A computing system generates a decentralized identifier representing an immutable string used to identify a user. The computing system saves the decentralized identifier in a storage location. The computing system requests a verifiable statement from a trusted issuer system based on the decentralized identifier. The verifiable statement represents an attestation from the trusted issuer system of an identity of the user. The computing system sends an authentication request to a third party system. The computing system receives a selective disclosure request from the third party system. The computing system generates a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request. The computing system receives an authentication confirmation based on the verifiable claim.

Description

Authentication System and Method Based on Decentralized Digital Identities

Field of the Disclosure

Embodiments disclosed herein generally relate to a system and method for user authentication using a decentralized digital identity.

Background

With the continuous development of Web3.0 technology, the technological revolution of the decentralized identity management system continues to innovate. At the same time, with the awakening of users'a wareness to ownership management of their own data, here arises the technical need where users use the same digital identity, which they own and manage, to login and obtain customer service among independent systems. Most decentralized identities are built on distributed systems, such as blockchain, which can not only solve the problem of data islands and provide a platform for data flow, but also provide tamper-proof capabilities for the state of user identity data.

Summary

In some embodiments, a method of authenticating with a third party device is disclosed herein. A computing system generates a decentralized identifier representing an immutable string used to identify a user. The computing system stores the decentralized identifier in a storage location. The computing system requests a verifiable statement from a trusted issuer system based on the decentralized identifier. The verifiable statement represents an attestation from the trusted issuer system of an identity of the user. The computing system sends an authentication request to a third party system. The computing system receives a selective disclosure request from the third party system. The selective disclosure request includes attributes required by the third party system for authentication. The computing system generates a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request. The computing system receives an authentication confirmation based on the verifiable claim.

In some embodiments, a non-transitory computer readable medium is disclosed herein. The non-transitory computer readable medium includes one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations. The operations include generating, by the computing system, a decentralized identifier representing an immutable string used to identify a user. The operations further include storing, by the computing system, the decentralized identifier in a storage location. The operations further include requesting, by the computing system, a verifiable statement from a trusted issuer system based on the decentralized identifier. The verifiable statement represents an attestation from the trusted issuer system of an identity of the user. The operations further include sending, by the computing system, an authentication request to a third party system. The operations further include receiving, by the computing system, a selective disclosure request from the third party system. The selective disclosure request includes attributes required by the third party system for authentication. The operations further include generating, by the computing system, averifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request. The operations further include receiving, by the computing system, an authentication confirmation based on the verifiable claim.

In some embodiments, a system is disclosed herein. The system includes a processor and a memory. The has programming instructions stored thereon, which, when executed by the processor, causes the system to perform operations. The operations include generating a decentralized identifier representing an immutable string used to identify a user. The operations further include storing the decentralized identifier in a storage location. The operations further include requesting a verifiable statement from a trusted issuer system based on the decentralized identifier. The verifiable statement represents an attestation from the trusted issuer system of an identity of the user. The operations further include sending an authentication request to a third party system. The operations further include receiving a selective disclosure request from the third party system. The selective disclosure request includes attributes required by the third party system for authentication. The operations further include generating a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request. The operations further include receiving an authentication confirmation based on the verifiable claim.

Brief Description of the Drawings

So that the manner in which the above recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrated only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments.

Figure 1 is a block diagram illustrating a computing environment, according to example embodiments.

Figure 2 is a block diagram illustrating a workflow between a user device and an issuer device, according to example embodiments.

Figure 3 is a block diagram illustrating a workflow between a user device and a third party system, according to example embodiments.

Figure 4 is a flow diagram illustrating an authentication method using a decentralized digital identity, according to example embodiments.

Figure 5A illustrates a system bus computing system architecture, according to example embodiments.

Figure 5B illustrates a computer system having a chipset architecture, according to example embodiments.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.

Detailed Description

Conventionally, most centralized systems use the JSON WEB Token (hereinafter “JWT” ) as an authentication technology. Generally, the authentication process utilizing JWT relies on a centralized database to establish a relational model for each user's profile. When a user registers, a data relation of the initial account and user registration information has to be established. The user is then required to provide at least one type of associated data, which can be an alias defined by the user, an email address or mobile phone number owned by the user. The user also needs to provide a password to unlock the content of the account. When the user provides the associated data and password, the system will desensitize the user password, and generate a relation between the associated data and a globally unique identifier in the user's profile database. The user's registration process is now completed. The user can perform the login process using the previously provided associated data and the corresponding password in the corresponding login window of the system.

As those skilled in the art understand, a downside of conventional JWT authentication technology is that the JWT may be stolen and tampered with. In some cases, developers may store the JWT in local storage or in a cookie, which makes the JWT easy to steal by malicious scripts or third-party libraries. JWTs are transmitted over the network, and if HTTPS or other encrypted protocols are not used, attackers can obtain JWTs by eavesdropping on network traffic. Since JWT is generated based on a key, if a weak key is used to sign the JWT, an attacker can use dictionary attack or brute force cracking to crack the signature of the JWT and obtain the information in it. For the website, if the website has XSS attack vulnerabilities or CSRF attack vulnerabilities, attackers can inject malicious scripts or trick users into visiting malicious websites to obtain the user's JWT.

JWT usually consists of three parts: header (Header) , load (Payload) and signature (Signature) . Among them, the header and payload are Base64-encoded JSON format data, and the signature is obtained by signing the header and payload. Therefore, an attacker can tamper with the JWT by modifying any part of the header, payload, and signature. The attacker can decode the JWT through Base64, modify the content of the header and payload, then perform Base64encoding, and finally regenerate the signature. The attacker can crack typically the signature of the JWT through brute force or dictionary attack, etc., obtain the signature key, and then use the key to generate a new signature.

Furthermore, once the JWT expires, the user must log in again to obtain a new token. If, for example, the expiration time of the JWT is set for too long, there is an increased risk of the JWT being stolen or tampered with. If, on the other hand, the expiration time is set too short, it will likely affect the user experience.

One or more techniques described herein improve upon conventional authentication techniques by improving upon the technical issues related to data ownership and privacy. For example, one or more techniques described herein allow users to retain independent control over access to the content of their own data through an identity verification process during which a trusted issuer system can attest to the identity of an individual. The user may then use this attestation to authenticate him or herself with one or more third party systems, rather than providing each third party system with a new set of personal identification information.

FIG. 1 is a block diagram illustrating an exemplary computing environment 100, according to example embodiments.

Computing environment 100 may include a user device 110, an issuer system 130, a third party system 140, and a verifiable database registry 150 communicating via a network 105.

Network 105 may be representative of any suitable type, including individual connections via the Internet, such as cellular or Wi-Fi networks. In some embodiments, network 105 may connect terminals, services, and mobile devices using direct connections, such as radio frequency identification (RFID) , near-field communication (NFC) , Bluetooth^TM, low-energy Bluetooth^TM (BLE) , Wi-Fi^TM, ZigBee^TM, ambient backscatter communication (ABC) protocols, USB, WAN, or LAN. Because the information transmitted may be personal or confidential, security concerns may dictate one or more of these types of connection be encrypted or otherwise secured. In some embodiments, however, the information being transmitted may be less personal, and therefore, the network connections may be selected for convenience over security.

Network 105 may include any type of computer networking arrangement used to exchange data. For example, network 105 may be representative of the Internet, a private data network, virtual private network using a public network and/or other suitable connection (s) that enables components in computing environment 100 to send and receiving information between the components of computing environment 100.

User device 110 may be operated by a user. User device 110 may be representative of a mobile device, a tablet, a desktop computer, or any computing system having the capabilities described herein. User device 110 may communicate with one or more of the third party system 140, issuer system 130, or the verifiable database registry 150 via the network 105.

User device 110 may include management system 112, application 114, and application 116. Each of management system 112, application 114, and application 116 may be representative of one or more software modules. The one or more software modules are collections of code or instructions stored on a media that represent a series of machine instructions (e.g., program code) that implements one or more algorithmic steps. Such machine instructions may be the actual computer code the processor interprets to implement the instructions or, alternatively, may be a higher level of coding of the instructions that are interpreted to obtain the actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of an example algorithm may be performed by the hardware components (e.g., circuitry) itself, rather than as a result of the instructions.

Management system 112 may be configured to create and manage authentication items for the user. For example, management system 112 may be representative of a digital wallet configured to store sensitive information associated with the user. In some embodiments, management system 112 may be configured to generate a public/private key pair for the user. As shown, public/private key pair may include a user public key 170 and a user private key 172. The user public key 170 and user private key 172 can be generated using any typical command prompt, Secure Shell (SSH) method, or other known encryption methods.

In some embodiments, management system 112 may further be configured to generate a decentralized identifier 126 for the user. Decentralized identifier 126 may represent a permanent and immutable string that may be used to identify a user. In some embodiments, decentralized identifier 126 may be associated with a corresponding decentralized identity document stored in verifiable database registry 150. For example, decentralized identifier 126 may include a URI that indicates the storage location of the corresponding decentralized identity document in verifiable database registry 150. Once generated, decentralized identifier 126 may be stored in management system 112.

The decentralized identity document may be representative of a document that may be used to confirm the identity of the user. In some embodiments, the decentralized identity document may include at least user public key 170. In some embodiments, the decentralized identity document may be representative of a structured data entity. In some embodiments, decentralized identity document may take the form of a JSON document.

Application 114 may be representative of an application or webpage associated with issuer system 130. In some embodiments, application 114 may be a standalone application associated with issuer system 130. In some embodiments, application 114 may be representative of a web browser configured to communicate with issuer system 130. In some embodiments, user device 110 may communicate over the network 105 to request a webpage, for example, from an application server 132 of issuer system 130. For example, user device 110 may be configured to execute application 114to access a registration interface of issuer system 130.

Generally, user device 110 may access application 114 to request a verifiable statement from issuer system 130. As further disclosed below, issuer system 130 may be representative of a trusted third party agency, such as, but not limited to a government entity, bank, university, or other trusted institution. The verifiable statement generated by issuer system 130 may be used by user device 110 as a means of authentication with one or more third party systems.

Issuer system 130 may be configured to verify an identity of a user based on user DID 126. In some embodiments, issuer system 130 may be representative of an entity, such as a government, bank, university, other institutions or organizations, which is able to verify an identity of a user. As shown, issuer system 130 may include web client application server 132 and management system 134.

Management system 134 may be configured to create and manage authentication items for issuer system 130. For example, management system 134 may be representative of a digital wallet configured to store sensitive information associated with issuer system 130. In some embodiments, management system 134 may be configured to generate a public/private key pair for issuer system 130. As shown, public/private key pair may include an issuer public key 136 and an issuer private key 138. The issuer public key 136 and issuer private key 138 can be generated using any typical command prompt, SSH method, or other known encryption methods.

In some embodiments, management system 134 may further be configured to generate a decentralized identifier 137 for issuer system 130. Decentralized identifier 137 may represent a permanent and immutable string that may be used to identify issuer system 130. In some embodiments, decentralized identifier 137 may be associated with a corresponding decentralized identity document stored in verifiable database registry 150. For example, decentralized identifier 137 may include a URI that indicates the storage location of the corresponding decentralized identity document in verifiable database registry 150. Once generated, decentralized identifier 137 may be stored in management system 134.

Issuer system 130 may receive from a user, such as a user of user device 110, a request for a verifiable statement. In some embodiments, the request may include at least decentralized identifier 126 and personal identification information associated with the user. Exemplary personal identification information may include, but is not limited to, name, gender, date of birth, identification number (e.g., passport number, driver’s license number, etc. ) , mobile telephone number, and the like. Issuer system 130 may verify the information provided by the user. In some embodiments, issuer system 130 may verify the information by comparing the personal identification information of the user to the information in the decentralized identification document linked to decentralized identifier 126. Once issuer system 130 is able to verify the identity of the user, issuer system 130 may generate the verifiable statement for the user. In some embodiments, the verifiable statement may include decentralized identifier 126, the personal identification information, and a signature of issuer system 130 signed using issuer private key 138. Because the verifiable statement is signed by issuer system 130, the verifiable statement may be thought of as a digital certificate that verifies the identity of the requesting user. In other words, verifiable statement may be representative of a descriptive statement, issued by issuer system 130, attesting to the legitimacy of attributes associated with the user. Issuer system 130 may then return the verifiable statement to user device 110 for storage.

In some embodiments, the personal identification information in the verifiable statement may be encrypted. For example, issuer system 130 may apply a cryptographic algorithm (e.g., a Merkle tree) on the personal identification information to generate an encrypted output. The encrypted output may be provided as a field value in the verifiable statement.

Referring back to user device 110, application 116 may be representative of an application or webpage associated with the third party system 140. In some embodiments, application 116 may be a standalone application associated with the third party system 140. In some embodiments, application 116 may be representative of a web browser configured to communicate with the third party system 140.

In some embodiments, user device 110 may access application 116when user device 110 attempts to obtain services from third party system 140 using their verifiable statement as the basis for authentication. When user device 110 attempts to obtain services from third party system 140, third party system 140 may notify or explain to user device 110 the attributes that may be needed for authentication with third party system 140. User device 110 may use one or more data structures and cryptographic algorithms (e.g., Merck Ershu algorithm) to meet the various disclosure requirements of third party system 140. The package that user device 110 generates to satisfy the disclosure requirements of third party system 140 may be referred to as a verifiable expression. Generally, the verifiable expression may be based on the verifiable statement. In some embodiments, the verifiable expression may include a combination of original text and cipher text. For example, in some embodiments, the original text in the verifiable expression may include the attributes that third party system 140 may require to be disclosed for authentication. In some embodiments, the cipher text in the verifiable expression may include other attributes from the verifiable statement that may not be required by third party system 140; instead, the other attributes that may be provided as encrypted ciphertext may be used for proof calculation. In some embodiments, user device 110 may sign the verifiable expression with private key 172 and may provide or link the verifiable expression with third party system 140. The verifiable expression may initiate a network request to an interface of third party system 140 to obtain various services. In some embodiments, user device 110 may set an expiration time for their verifiable expression according to the requirements of third party system 140. Such expiration time may be included in the verifiable expression.

Third party system 140 may be representative of any third party system for which the user may have to authenticate themselves. For example, third party system 140 may be representative of any third party system, such as, but not limited to, an email service provider, bank, social media platform, video playback provider, hotel provider, and the like. Generally, third party system 140 may work in a trusted relationship with issuer system 130. For example, in order for third party system 140 to accept digital signatures from issuer system 130, third party system 140 may have a pre-established relationship with issuer system 130, whereby third party system 140 may trust statement signed by issuer system 130.

In operation, when a user attempts to authenticate themselves with third party system 140, third party system 140 may receive a verifiable expression generated by user device 110. Third party system 140 may be configured to perform cryptographic verification of the verifiable expression to determine whether to provide user device 110 with the requested services.

In some embodiments, to verify the verifiable expression, third party system 140 may analyze the verifiable expression to determine whether the time of the verifiable expression is still valid. For example, as discussed above, in some embodiments, user device 110 may set an expiration for the verifiable expression. Accordingly, third party system 140 may check the verifiable expression to determine whether the verifiable expression is still valid. In some embodiments, assuming the verifiable expression is still valid (e.g., either before expiration or no expiration noted) , third party system 140 may analyze the ciphertext of the data disclosed by user device 110 in the verifiable expression and the plain text. In some embodiments, third party system 140 may perform structure and proof derivation to determine whether the data disclosed in the verifiable expression is valid.

In some embodiments, third party system 140 may further be configured to verify the signature corresponding to the verifiable statement in the verifiable expression. For example, third party system 140 may verify whether the signature conforms to the result of the previous proof derivation and/or whether the signature is from a trusted issuer system.

In some embodiments, third party system 140 may further be configured to compare the decentralized identifier in the verifiable statement to decentralized identifier 126 associated with user device 110 to determine if the two are consistent.

In some embodiments, third party system 140 may further be configured to verify the signature of the verifiable expression. For example, third party system 140 may determine whether the signature included in the verifiable expression is issued or otherwise associated with decentralized identifier 126.

In some embodiments, third party system 140 may further be configured to initiate a network request with a registration authority of verifiable data. For example, third party system 140 may query the registration authority to determine whether the verifiable statement and decentralized identifiers are valid.

In some embodiments, when one or more of the above-mentioned verification procedures are satisfied, third party system 140 may conclude that the identity of the holder of the verifiable expression is credible. Third party system 140 may use the data disclosed in the verifiable expression to complete service to user device 110. In some embodiments, if user device 110 continues to access services of third party system 140, user device 110 may need to re-use user private key 172 corresponding to decentralized identifier 126 to issue a new verifiable expression to third party system 140 for authentication before the expiration time of the verifiable statement.

Figure 2 is a block diagram illustrating a workflow 200 between user device 110 and issuer system 130, according to example embodiments. Workflow 200 may generally refer to a process in which user device 110 requests a verifiable statement from issuer system 130.

At step 202, user device 110 may create and save a decentralized identifier. For example, user device 110 may access management system 112 to generate decentralized identifier 126. Decentralized identifier 126 may represent a permanent and immutable string that may be used to identify a user. In some embodiments, decentralized identifier 126 may be associated with a corresponding decentralized identity document stored in verifiable database registry 150. For example, decentralized identifier 126 may include a URI that indicates the storage location of the corresponding decentralized identity document in verifiable database registry 150. Once generated, decentralized identifier 126 may be stored in management system 112.

At step 204, issuer system 130 may create and save a decentralized identifier. For example, issuer system 130 may access management system 134 to generate decentralized identifier 126. Decentralized identifier 126 may represent a permanent and immutable string that may be used to identify the issuer system. In some embodiments, decentralized identifier 126 may be associated with a corresponding decentralized identity document stored in verifiable database registry 150. For example, decentralized identifier 126 may include a URI that indicates the storage location of the corresponding decentralized identity document in verifiable database registry 150. Once generated, decentralized identifier 126 may be stored in management system 112.

At step 206, user device 110 may send a registration request to issuer system 130. In some embodiments, the request may include at least decentralized identifier 126 and personal identification information associated with the user. Exemplary personal identification information may include, but is not limited to, name, gender, date of birth, identification number (e.g., passport number, driver’s license number, etc. ) , mobile telephone number, and the like.

At step 208, issuer system 130 may generate and send a verifiable statement based on the registration request. Issuer system 130 may verify the information by comparing the personal identification information of the user to the information in the decentralized identification document linked to decentralized identifier 126. Once issuer system 130 is able to verify the identity of the user, issuer system 130 may generate the verifiable statement for the user. In some embodiments, the verifiable statement may include decentralized identifier 126, the personal identification information, and a signature of issuer system 130 signed using issuer private key 138.

At step 210, user device 110 may save the verifiable statement. For example, user device 110 may save the verifiable statement in management system 112. Verifiable statement may be used by user device 110 for authentication with one or more third party systems.

Figure 3 is a block diagram illustrating a workflow 300 between user device 110 and third party system 140, according to example embodiments. Workflow 300 may generally refer to a process in which user device 110 uses their verifiable statement to authenticate themselves with third party system 140.

At step 302, user device 110 may send an authentication request to third party system 140. For example, user device 110 may send an authentication request to third party system 140 when wishing to obtain one or more services from third party system 140. Examples may include, but are not limited to, logging into their accounts, vehicle registration, loan applications, job applications, and the like.

At step 304, third party system 140 may generate and send a selective disclosure request to user device 110. For example, when user device 110 attempts to obtain services from third party system 140, third party system 140 may notify or explain to user device 110 the attributes that may be needed for authentication with third party system 140. Such process may generally be referred to as a selective disclosure request.

At step 306, user device 110 may generate and send a verifiable claim based on the selective disclosure request. User device 110 may use one or more data structures and cryptographic algorithms (e.g., Merck Ershu algorithm) to generate a verifiable expression the satisfies the selective disclosure request. In some embodiments, the verifiable expression may include a combination of original text and cipher text. For example, in some embodiments, the original text in the verifiable expression may include the attributes that third party system 140 may require to be disclosed for authentication. In some embodiments, the cipher text in the verifiable expression may include other attributes from the verifiable statement that may not be required by third party system 140; instead, the other attributes that may be provided as encrypted ciphertext may be used for proof calculation. In some embodiments, user device 110 may sign the verifiable expression with private key 172 and may provide or link the verifiable expression with third party system 140. The verifiable expression may initiate a network request to an interface of third party system 140 to obtain various services. In some embodiments, user device 110 may set an expiration time for their verifiable expression according to the requirements of third party system 140. Such expiration time may be included in the verifiable expression.

At step308, third party system 140 may review the verifiable claim. To verify the verifiable claim, third party system 140 may perform one or more review processes. In some embodiments, the review processes may include third party system 140 analyzing the verifiable expression to determine whether the time of the verifiable expression is still valid. In some embodiments, the review processes may include third party system 140 analyzing the ciphertext of the data disclosed by user device 110 in the verifiable expression and the plain text. In some embodiments, the review processes may include third party system 140 performing structure and proof derivation to determine whether the data disclosed in the verifiable expression is valid.

At step310, third party system 140 may grant the authentication request.

Figure 4 is a flow diagram illustrating a method 400 of performing decentralized authentication, according to example embodiments. Method 400 may begin at step 402.

At step 402, user device 110 may generate and save a decentralized identifier. For example, user device 110 may access management system 112 to generate decentralized identifier 126. Decentralized identifier 126 may represent a permanent and immutable string that may be used to identify a user. In some embodiments, decentralized identifier 126 may be associated with a corresponding decentralized identity document stored in verifiable database registry 150. For example, decentralized identifier 126 may include a URI that indicates the storage location of the corresponding decentralized identity document in verifiable database registry 150. Once generated, decentralized identifier 126 may be stored in management system 112.

At step 404, user device 110 may request a verifiable statement from an issuer system. In some embodiments, the request may include at least decentralized identifier 126 and personal identification information associated with the user. Exemplary personal identification information may include, but is not limited to, name, gender, date of birth, identification number (e.g., passport number, driver’s license number, etc. ) , mobile telephone number, and the like.

At step 406, user device 110 may send an authentication request to third party system 140. user device 110 may send an authentication request to third party system 140. For example, user device 110 may send an authentication request to third party system 140when wishing to obtain one or more services from third party system 140. Examples may include, but are not limited to, logging into their accounts, vehicle registration, loan applications, job applications, and the like.

At step 408, user device 110 may receive a selective disclosure request from third party system 140. For example, when user device 110 attempts to obtain services from third party system 140, third party system 140 may generate and send a selective disclosure request that notifies or explains to user device 110 the attributes that may be needed for authentication with third party system 140.

At step 410, user device 110 may generate a verifiable claim and send the verifiable claim to third party system 140. In some embodiments, the verifiable claim may be based on the selective disclosure request. User device 110 may use one or more data structures and cryptographic algorithms (e.g., Merck Ershu algorithm) to generate a verifiable expression the satisfies the selective disclosure request. In some embodiments, the verifiable expression may include a combination of original text and cipher text. For example, in some embodiments, the original text in the verifiable expression may include the attributes that third party system 140 may require to be disclosed for authentication. In some embodiments, the cipher text in the verifiable expression may include other attributes from the verifiable statement that may not be required by third party system 140; instead, the other attributes that may be provided as encrypted ciphertext may be used for proof calculation. In some embodiments, user device 110 may sign the verifiable expression with private key 172and may provide or link the verifiable expression with third party system 140. The verifiable expression may initiate a network request to an interface of third party system 140 to obtain various services. In some embodiments, user device 110 may set an expiration time for their verifiable expression according to the requirements of third party system 140. Such expiration time may be included in the verifiable expression.

At step 412, user device 110 may receive an authentication confirmation based on the verifiable claim. Once user device 110 is authenticated, user device 110 may receive access to the requested services. In some embodiments, the authentication may be limited in time. For example, the authentication confirmation may have a predefined duration of use before user device 110 may have to re-authenticate themselves by generating a new verifiable claim for third party system 140 to review.

Figure 5A illustrates an architecture of system bus computing system 500, according to example embodiments. One or more components of system 500 may be in electrical communication with each other using a bus 505. System 500 may include a processor (e.g., one or more CPUs, GPUs or other types of processors) 510 and a system bus 505 that couples various system components including the system memory 515, such as read only memory (ROM) 520 and random access memory (RAM) 525, to processor 510. System 500 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 510. System 500 can copy data from memory 515 and/or storage device 530 to cache 512 for quick access by processor 510. In this way, cache 512 may provide a performance boost that avoids processor 510 delays while waiting for data. These and other modules can control or be configured to control processor 510 to perform various actions. Other system memory 515 may be available for use as well. Memory 515 may include multiple different types of memory with different performance characteristics. Processor 510 may be representative of a single processor or multiple processors. Processor 510 can include one or more of a general purpose processor or a hardware module or software module, such as service 1 532, service 2 534, and service 5 536 stored in storage device 530, configured to control processor 510, as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 510 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the system 500, an input device 545 which can be any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 535 (e.g., a display) can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with system 500. Communications interface 540 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

Storage device 530 may be a non-volatile memory and can be a hard disk or other types of computer readable media that can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 525, read only memory (ROM) 520, and hybrids thereof.

Storage device 530 can include services 532, 534, and 536for controlling the processor 510. Other hardware or software modules are contemplated. Storage device 530 can be connected to system bus 505. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 510, bus 505, output device 535 (e.g., a display) , and so forth, to carry out the function.

Figure 5B illustrates a computer system 550 having a chipset architecture, according to example embodiments. Computer system 550 may be an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System 550 can include one or more processors 555, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. One or more processors 555 can communicate with a chipset 560 that can control input to and output from one or more processors 555. In this example, chipset 560 outputs information to output 565, such as a display, and can read and write information to storage device 570, which can include magnetic media, and solid-state media, for example. Chipset 560 can also read data from and write data to storage device 575 (e.g., RAM) . A bridge 580 for interfacing with a variety of user interface components 585 can be provided for interfacing with chipset 560. Such user interface components 585 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on.In general, inputs to system 550 can come from any of a variety of sources, machine generated and/or human generated.

Chipset 560 can also interface with one or more communication interfaces 590 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by one or more processors 555 analyzing data stored in storage device 570 or 575. Further, the machine can receive inputs from a user through user interface components 585 and execute appropriate functions, such as browsing functions by interpreting these inputs using one or more processors 555.

It can be appreciated that example systems 500 and 550 can have more than one processor 510 or be part of a group or cluster of computing devices networked together to provide greater processing capability.

While the foregoing is directed to embodiments described herein, other and further embodiments may be devised without departing from the basic scope thereof. For example, aspects of the present disclosure may be implemented in hardware or software or a combination of hardware and software. One embodiment described herein may be implemented as a program product for use with a computer system. The program (s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory (ROM) devices within a computer, such as CD-ROM disks readably by a CD-ROM drive, flash memory, ROM chips, or any type of solid-state non-volatile memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid state random-access memory) on which alterable information is stored. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the disclosed embodiments, are embodiments of the present disclosure.

It will be appreciated to those skilled in the art that the preceding examples are exemplary and not limiting. It is intended that all permutations, enhancements, equivalents, and improvements thereto are apparent to those skilled in the art upon a reading of the specification and a study of the drawings are included within the true spirit and scope of the present disclosure. It is therefore intended that the following appended claims include all such modifications, permutations, and equivalents as fall within the true spirit and scope of these teachings.

Claims

A method of authenticating with a third party device, comprising:

generating, by a computing system, a decentralized identifier representing an immutable string used to identify a user;

storing, by the computing system, the decentralized identifier in a storage location;

requesting, by the computing system, a verifiable statement from a trusted issuer system based on the decentralized identifier, the verifiable statement representing an attestation from the trusted issuer system of an identity of the user;

sending, by the computing system, an authentication request to a third party system;

receiving, by the computing system, a selective disclosure request from the third party system, the selective disclosure request comprising attributes required by the third party system for authentication;

generating, by the computing system, a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request; and

receiving, by the computing system, an authentication confirmation based on the verifiable claim.
The method of claim 1, wherein generating the decentralized identifier comprises:

generating a decentralized identity document comprising information used by the trusted issuer system for attesting to the identity of the user; and

generating an identifier corresponding to a second storage location where the decentralized identity document is stored.
The method of claim 1, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

identifying portions of the verifiable statement that corresponds to the attributes of the selective disclosure request.
The method of claim 1, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

encrypting at least a portion of the verifiable claim using a private key associated with the user.
The method of claim 1, wherein the verifiable claim comprises an expiration time.
The method of claim 5, further comprising:

determining, by the computing system, that the verifiable claim has expired; and

based on the determining, generating, by the computing system, a new verifiable claim to re-authenticate with the third party system.
The method of claim 1, wherein the request for the verifiable statement comprises personal identification information associated with the user.
A non-transitory computer readable medium comprising one or more sequences of instructions, which, when executed by a processor, causes a computing system to perform operations comprising:

generating, by the computing system, a decentralized identifier representing an immutable string used to identify a user;

storing, by the computing system, the decentralized identifier in a storage location;

requesting, by the computing system, a verifiable statement from a trusted issuer system based on the decentralized identifier, the verifiable statement representing an attestation from the trusted issuer system of an identity of the user;

sending, by the computing system, an authentication request to a third party system;

receiving, by the computing system, a selective disclosure request from the third party system, the selective disclosure request comprising attributes required by the third party system for authentication;

generating, by the computing system, a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request; and

receiving, by the computing system, an authentication confirmation based on the verifiable claim.
The non-transitory computer readable medium of claim 8, wherein generating the decentralized identifier comprises:

generating a decentralized identity document comprising information used by the trusted issuer system for attesting to the identity of the user; and

generating an identifier corresponding to a second storage location where the decentralized identity document is stored.
The non-transitory computer readable medium of claim 8, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

identifying portions of the verifiable statement that corresponds to the attributes of the selective disclosure request.
The non-transitory computer readable medium of claim 8, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

encrypting at least a portion of the verifiable claim using a private key associated with the user.
The non-transitory computer readable medium of claim 8, wherein the verifiable claim comprises an expiration time.
The non-transitory computer readable medium of claim 12, further comprising:

determining, by the computing system, that the verifiable claim has expired; and

based on the determining, generating, by the computing system, a new verifiable claim to re-authenticate with the third party system.
The non-transitory computer readable medium of claim 8, wherein the request for the verifiable statement comprises personal identification information associated with the user.
A system, comprising:

a processor; and

a memory having programming instructions stored thereon, which, when executed by the processor, causes the system to perform operations comprising:

generating a decentralized identifier representing an immutable string used to identify a user;

storing the decentralized identifier in a storage location;

requesting a verifiable statement from a trusted issuer system based on the decentralized identifier, the verifiable statement representing an attestation from the trusted issuer system of an identity of the user;

sending an authentication request to a third party system;

receiving a selective disclosure request from the third party system, the selective disclosure request comprising attributes required by the third party system for authentication;

generating a verifiable claim using the verifiable statement in accordance with the attributes in the selective disclosure request; and

receiving an authentication confirmation based on the verifiable claim.
The system of claim 15, wherein generating the decentralized identifier comprises:

generating a decentralized identity document comprising information used by the trusted issuer system for attesting to the identity of the user; and

generating an identifier corresponding to a second storage location where the decentralized identity document is stored.
The system of claim 15, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

identifying portions of the verifiable statement that corresponds to the attributes of the selective disclosure request.
The system of claim 15, wherein generating the verifiable claim using the verifiable statement in accordance with the attributes of the selective disclosure request comprises:

encrypting at least a portion of the verifiable claim using a private key associated with the user.
The system of claim 15, wherein the verifiable claim comprises an expiration time.
The system of claim 19, wherein the operations further comprise:

determining that the verifiable claim has expired; and

based on the determining, generating a new verifiable claim to re-authenticate with the third party system.