Verification system and method based on decentralized digital identity

Abstract

A computing system generates a decentralized identifier to represent an immutable string to identify a user. The computing system saves the decentralized identifier in a storage location. The computing system requests a verifiable claim from a trusted issuing system based on the decentralized identifier. The verifiable claim represents a proof of identity of the user by the trusted issuing system. 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 assertion using the verifiable claim based on attributes in the selective disclosure request. The computing system receives a verification confirmation based on the verifiable assertion.

Description

Technical Field

[0001] The embodiments described herein typically relate to a system and method for user authentication using decentralized digital identities. Background Technology

[0002] With the continuous development of Web3.0 technology, the technological revolution of decentralized identity management systems is constantly innovating. Simultaneously, as users become more aware of their own data ownership and management, a technological demand arises: users can use the same digital identity they own and manage to log in and access customer service in independent systems. Most decentralized identities are built on distributed systems, such as blockchain, which not only solves the problem of data silos and provides a platform for data flow, but also provides tamper-proof capabilities for the state of user identity data. Summary of the Invention

[0003] In some embodiments, a method for authentication with a third-party device is provided. A computing system generates a decentralized identifier, which represents an immutable string used to identify a user. The computing system stores the decentralized identifier in a storage location. Based on the decentralized identifier, the computing system requests a verifiable statement from a trusted issuer system, the verifiable statement representing the trusted issuer system's proof of the user's identity. The computing system sends a verification request to the third-party system. The computing system receives a selective disclosure request from the third-party system, the selective disclosure request including attributes required for verification by the third-party system. Based on the attributes in the selective disclosure request, the computing system generates a verifiable claim using the verifiable statement; and based on the verifiable claim, the computing system receives verification confirmation.

[0004] In some embodiments, a non-volatile computer-readable medium is provided. The non-volatile computer-readable medium includes one or more sequences of instructions that, when executed by a processor, cause a computing system to perform operations. The operations include the computing system generating a decentralized identifier representing an immutable string used to identify a user. The operations also include the computing system storing the decentralized identifier in a storage location. Furthermore, the operations include the computing system requesting a verifiable statement from a trusted issuer system based on the decentralized identifier. The verifiable statement represents proof of the user's identity by the trusted issuer system. The operations also include the computing system sending a verification request to a third-party system. The operations further include the computing system receiving a selective disclosure request from the third-party system. The selective disclosure request contains attributes required for verification by the third-party system. The operations also include the computing system generating a verifiable claim using the verifiable statement based on the attributes in the selective disclosure request. Finally, the operations include the computing system receiving verification confirmation based on the verifiable claim.

[0005] In some embodiments, a system is provided. The system includes a processor and a memory. The memory stores programming instructions that, when executed by the processor, cause the system to perform operations. The operations include generating a decentralized identifier. The decentralized identifier represents an immutable string used to identify a user. The operations also 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 representing the trusted issuer system's proof of the user's identity. The operations also include sending a verification request to a third-party system. The operations further include receiving a selective disclosure request from the third-party system, the selective disclosure request including attributes required for verification by the third-party system. The operations also include generating a verifiable claim using the verifiable statement based on the attributes in the selective disclosure request. The operations further include receiving verification confirmation based on the verifiable claim. Attached Figure Description

[0006] To gain a more detailed understanding of the features described in this disclosure, a more specific description of the disclosure (briefly summarized above) can be obtained by referring to some embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the drawings illustrate only typical embodiments of the disclosure and should not be considered as limiting its scope, as the disclosure may also contain other equally effective embodiments.

[0007] Figure 1 This is a block diagram illustrating a computing environment according to some exemplary embodiments.

[0008] Figure 2This is a block diagram illustrating the workflow between a user device and a publisher device, according to some exemplary embodiments.

[0009] Figure 3 This is a block diagram illustrating the workflow between a user device and a third-party system, according to some exemplary embodiments.

[0010] Figure 4 This is a flowchart illustrating a verification method using decentralized digital identity, based on some exemplary embodiments.

[0011] Figure 5A This is a system bus computing system architecture shown according to some exemplary embodiments.

[0012] Figure 5B It is a computer system with a chipset architecture shown according to some exemplary embodiments.

[0013] For ease of understanding, the same reference numerals are used where possible to denote the same elements common in the figures. It is conceivable that elements described in one embodiment may also be advantageously used in other embodiments without special explanation. Detailed Implementation

[0014] Traditionally, most centralized systems use JSON Web Tokens (JWTs) as the authentication technology. Generally, the JWT authentication process relies on a centralized database to establish a relational model for each user's profile. When a user registers, an initial account and user registration information data relationship needs to be established. Then, the user needs to provide at least one piece of associated data, which could be a user-defined alias, an email address, or a mobile phone number. The user also needs to provide a password to unlock account content. After the user provides the associated data and password, the system anonymizes the password and generates a relationship between the associated data and a globally unique identifier in the user profile database. The user registration process is now complete. The user can then use the previously provided associated data and corresponding password to log in through the system's login window.

[0015] As those skilled in the art understand, a drawback of traditional JWT verification techniques is that JWTs can be stolen and tampered with. In some cases, developers may store JWTs locally or in cached files, making them easier for malicious scripts or third-party libraries to steal. JWTs are transmitted over the network, and without HTTPS or other encryption protocols, attackers can obtain them by monitoring network traffic. Because JWTs are generated using keys, if a weak key is used to sign a JWT, attackers can crack the signature using dictionary attacks or brute-force attacks and obtain the information contained within. For websites, if a website has XSS or CSRF vulnerabilities, attackers can inject malicious scripts or trick users into visiting malicious websites to obtain their JWTs.

[0016] JWTs typically consist of three parts: a header, a payload, and a signature. The header and payload are Base64-encoded JSON data, while the signature is obtained by signing the header and payload. Therefore, an attacker can tamper with a JWT by modifying any part of the header, payload, or signature. An attacker can decode the JWT using Base64, modify the header and payload, then Base64 encode them again, and finally regenerate the signature. Attackers can also crack the JWT signature using brute-force or dictionary attacks to obtain the signing key, and then use that key to generate a new signature.

[0017] Furthermore, once a JWT expires, the user must log in again to obtain a new token. For example, setting the expiration time of a JWT too long increases the risk of it being stolen or tampered with. On the other hand, setting the expiration time too short may negatively impact the user experience.

[0018] The technologies described herein enhance traditional authentication techniques by addressing technical issues related to data ownership and privacy. For example, these technologies allow users to independently control access to their own data content through an authentication process in which a trusted issuing system verifies an individual's identity. The user can then use this verification to self-authenticate within one or more third-party systems without having to provide a new set of personally identifiable information to each system.

[0019] Figure 1 This is a block diagram illustrating an exemplary computing environment 100 according to some exemplary embodiments.

[0020] The computing environment 100 may include user equipment 110, issuer system 130, third-party system 140, and a verifiable database registry 150 that communicates via network 105.

[0021] Network 105 can represent any suitable type, including a standalone connection over the Internet, such as a cellular network or a Wi-Fi network. In some embodiments, network 105 can connect terminals, services, and mobile devices via direct connections, such as Radio Frequency Identification (RFID), Near Field Communication (NFC), Bluetooth™, Bluetooth Low Energy™ (BLE), Wi-Fi™, ZigBee™, Ambient Backscatter Communication (ABC) protocol, USB, Wide Area Network (WAN), or Local Area Network (LAN). Because the transmitted information may be personal or confidential, security concerns may require encryption or other security measures for one or more of these types of connections. However, in some embodiments, the transmitted information may be less personalized, and therefore, network connectivity may be chosen for convenience rather than security.

[0022] Network 105 may include any computer network method used for exchanging data. For example, network 105 may represent the Internet, a private data network, a virtual private network using a public network, and / or other suitable connection methods that enable components in computing environment 100 to send and receive information to each other.

[0023] User equipment 110 can be operated by a user. User equipment 110 can be a mobile device, tablet, desktop computer, or any computing system with the functions described herein. User equipment 110 can communicate with one or more of the following via network 105: third-party system 140, issuer system 130, or verifiable database registration system 150.

[0024] User equipment 110 may include management system 112, application 114, and application 116. Each of management system 112, application 114, and application 116 may represent one or more software modules. One or more software modules are collections of code or instructions stored on a medium that represent a series of machine instructions (e.g., program code) that implement one or more algorithmic steps. These machine instructions may be actual computer code that a processor interprets to implement the instructions, or higher-level coded instructions that, after interpretation, yield actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of the example algorithm may be executed by the hardware components (e.g., circuitry) themselves, rather than as a result of instructions.

[0025] The management system 112 can be used to create and manage authentication items for users. For example, the management system 112 can represent a digital wallet used to store sensitive information related to users. In some embodiments, the management system 112 can be used to generate public / private key pairs for users. As shown in the figure, the 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 common command prompt, SSH (Secure Shell) method, or other known encryption methods.

[0026] In some embodiments, the management system 112 can also be used to generate a decentralized identifier 126 for a user. The decentralized identifier 126 can represent a permanent and immutable string that can be used to identify the user. In some embodiments, the decentralized identifier 126 can be associated with a corresponding decentralized identity file stored in a verifiable database registry 150. For example, the decentralized identifier 126 can include a URI indicating the storage location of the corresponding decentralized identity file in the verifiable database registry 150. Once generated, the decentralized identifier 126 can be stored in the management system 112.

[0027] A decentralized identity file can represent a file used to verify a user's identity. In some embodiments, the decentralized identity file may include at least the user's public key. In some embodiments, the decentralized identity file may represent a structured data entity. In some embodiments, the decentralized identity file may be in the form of a JSON document.

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

[0029] Typically, user equipment 110 can access application 114 to request a verifiable statement (VS) from issuer system 130. As further disclosed below, issuer system 130 may represent a trusted third-party institution, such as, but not limited to, government agencies, banks, universities, or other trusted entities. The verifiable statement generated by issuer system 130 can be used by user equipment 110 as a means of verification with one or more third-party systems.

[0030] The issuer system 130 can be used to verify a user's identity based on the user's DID 126. In some embodiments, the issuer system 130 can represent an entity capable of verifying user identity, such as a government, bank, university, or other institution or organization. As shown in the figure, the issuer system 130 may include a web client application server 132 and a management system 134.

[0031] The management system 134 can be used to create and manage authentication items for the issuing system 130. For example, the management system 134 can represent a digital wallet used to store sensitive information related to the issuing system 130. In some embodiments, the management system 134 can be used to generate public / private key pairs for the issuing system 130. As shown, the public / private key pair may include an issuing public key 136 and an issuing private key 138. The issuing public key 136 and issuing private key 138 can be generated using any typical command prompt, SSH method, or other known encryption method.

[0032] In some embodiments, the management system 134 can also be used to generate a decentralized identifier 137 for the issuing system 130. The decentralized identifier 137 can represent a permanent and immutable string that can be used to identify the issuing system 130. In some embodiments, the decentralized identifier 137 can be associated with a corresponding decentralized identity document stored in a verifiable database registry 150. For example, the decentralized identifier 137 can include a URI indicating the storage location of the corresponding decentralized identity document in the verifiable database registry 150. Once generated, the decentralized identifier 137 can be stored in the management system 134.

[0033] The issuer system 130 can receive requests for verifiable statements from users (e.g., users of user device 110). In some embodiments, the request may include at least a decentralized identifier 126 and personally identifiable information associated with the user. Exemplary personally identifiable information may include, but is not limited to, name, gender, date of birth, identification number (e.g., passport number, driver's license number), mobile phone number, etc. The issuer system 130 can verify the information provided by the user. In some embodiments, the issuer system 130 can verify the information by comparing the user's personally identifiable information with information in a decentralized identity document associated with the decentralized identifier 126. Once the issuer system 130 can verify the user's identity, it can generate a verifiable statement for the user. In some embodiments, the verifiable statement may include the decentralized identifier 126, the personally identifiable information, and a signature of the issuer system 130, which is issued using the issuer's private key 138. Since the verifiable statement is issued by the issuer system 130, it can be considered a digital certificate verifying the identity of the requesting user. In other words, a verifiable statement can represent a descriptive statement issued by the issuing system 130, proving the legitimacy of attributes related to the user. The issuing system 130 can then return the verifiable statement to the user device 110 for storage.

[0034] In some embodiments, personally identifiable information in a verifiable statement can be encrypted. For example, the issuing system 130 can apply an encryption algorithm (such as a Merkle tree) to the personally identifiable information to generate an encrypted output. This encrypted output can then be provided as a field value in the verifiable statement.

[0035] Returning to user device 110, application 116 may represent an application or webpage associated with third-party system 140. In some embodiments, application 116 may be a standalone application associated with third-party system 140. In some embodiments, application 116 may represent a web browser used to communicate with third-party system 140.

[0036] In some embodiments, when user equipment 110 attempts to obtain services from third-party system 140 using a verifiable statement as the basis for verification, user equipment 110 may access application 116. When user equipment 110 attempts to obtain services from third-party system 140, third-party system 140 may inform or interpret to device 110 the attributes required for verification with third-party system 140. User equipment 110 may use one or more data structures and cryptographic algorithms (e.g., the Merck-Ershu algorithm) to satisfy various disclosure requirements of third-party system 140. The package generated by user equipment 110 to satisfy the disclosure requirements of third-party system 140 may be referred to as a verifiable expression. Typically, the verifiable expression may be based on a verifiable statement. In some embodiments, the verifiable expression may contain a combination of plaintext and ciphertext. For example, in some embodiments, the plaintext in the verifiable expression may contain attributes that third-party system 140 may need to disclose for authentication. In some embodiments, the ciphertext in the verifiable expression may contain additional properties from the verifiable statement that are not required by the third-party system 140; instead, these additional properties may be provided in encrypted ciphertext and can be used to prove computation. In some embodiments, the user equipment 110 may sign the verifiable expression with its private key 172 and may provide the verifiable expression to or connect to the third-party system 140. The verifiable expression may initiate network requests to the interface of the third-party system 140 to obtain various services. In some embodiments, the user equipment 110 may set an expiration period for the verifiable expression according to the requirements of the third-party system 140. This expiration period may be included in the verifiable expression.

[0037] Third-party system 140 can represent any third-party system that a user may need to self-verify. For example, third-party system 140 can represent any third-party system, such as, but not limited to, email service providers, banks, social media platforms, video streaming providers, hotel service providers, etc. Typically, third-party system 140 may operate in a trust relationship with issuing system 130. For example, to allow third-party system 140 to accept the digital signature of issuing system 130, third-party system 140 may have pre-established a relationship with issuing system 130, thereby trusting statements signed by issuing system 130.

[0038] During operation, when a user attempts to perform self-authentication using third-party system 140, third-party system 140 may receive a verifiable expression generated by user device 110. Third-party system 140 can use this verifiable expression for cryptographic verification to determine whether to provide the requested service to user device 110.

[0039] In some embodiments, to verify a verifiable expression, the third-party system 140 may analyze the verifiable expression to determine whether the time period of the verifiable expression is still valid. For example, as described above, in some embodiments, the user equipment 110 may set an expiration date for the verifiable expression. Therefore, the third-party system 140 may check the verifiable expression to determine whether the expression is still valid. In some embodiments, assuming the verifiable expression is still valid (e.g., whether before the expiration date or without an expiration date), the third-party system 140 may analyze the ciphertext of the data disclosed by the user equipment 110 in the verifiable expression and the plaintext. In some embodiments, the third-party system 140 may perform structural and verification derivations to determine whether the data disclosed in the verifiable expression is valid.

[0040] In some embodiments, the third-party system 140 can also be used to verify the signature of the corresponding verifiable statement in the verifiable expression. For example, the third-party system 140 can verify whether the signature conforms to the result of a previous verification derivation, and / or whether the signature comes from a trusted issuing system.

[0041] In some embodiments, the third-party system 140 may also be used to compare the decentralized identifier in the verifiable statement with the decentralized identifier 126 associated with the user equipment 110 to determine whether the two are consistent.

[0042] In some embodiments, the third-party system 140 can also be used to verify the signature of the verifiable expression. For example, the third-party system 140 can determine whether the signature contained in the verifiable expression was issued by or associated with the decentralized identifier 126.

[0043] In some embodiments, the third-party system 140 can also be used to initiate network requests to a registry of verifiable data. For example, the third-party system 140 can query the registry to determine whether the verifiable statement and decentralized identifier are valid.

[0044] In some embodiments, when one or more of the above verification procedures are met, the third-party system 140 can conclude that the holder of the verifiable expression is trustworthy. The third-party system 140 can use the data disclosed in the verifiable expression to provide services to the user device 110. In some embodiments, if the user device 110 continues to access the services of the third-party system 140, the user device 110 may need to re-issue a new verifiable expression to the third-party system 140 for verification before the verifiable statement expires, using the user's private key 172 corresponding to the decentralized identifier 126.

[0045] Figure 2This is a block diagram illustrating a workflow 200 between user equipment 110 and issuing system 130 according to some exemplary embodiments. Workflow 200 generally refers to the process by which user equipment 110 requests a verifiable statement from issuing system 130.

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

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

[0048] In step 206, user equipment 110 may send a registration request to the issuing system 130. In some embodiments, the request may include at least a decentralized identifier 126 and personally identifiable information related to the user. Exemplary personally identifiable 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 phone number, etc.

[0049] In step 208, the issuer system 130 may generate and send a verifiable statement based on the registration request. The issuer system 130 can verify the information by comparing the user's personal identification information with information in a decentralized identity file associated with the decentralized identifier 126. Once the issuer system 130 can verify the user's identity, it can generate a verifiable statement for the user. In some embodiments, the verifiable statement may include the decentralized identifier 126, the personal identification information, and a signature of the issuing system 130 signed using the issuer's private key 138.

[0050] In step 210, user equipment 110 may store the verifiable statement. For example, user equipment 110 may store the verifiable statement in management system 112. User equipment 110 may use the verifiable statement to perform verification with one or more third-party systems.

[0051] Figure 3 This is a block diagram illustrating a workflow 300 between user equipment 110 and third-party system 140 according to a partially exemplary embodiment. Workflow 300 generally refers to the process by which user equipment 110 authenticates itself to third-party system 140 using its verifiable statement.

[0052] In step 302, user equipment 110 may send a verification request to third-party system 140. For example, when user equipment 110 wishes to obtain one or more services from third-party system 140, user equipment 110 may send a verification request to third-party system 140. Examples include, but are not limited to, logging into its account, vehicle registration, loan application, job application, etc.

[0053] In step 304, the third-party system 140 may generate and send a selective disclosure request to the user device 110. For example, when the user device 110 attempts to obtain services from the third-party system 140, the third-party system 140 may notify the user device 110 or explain to the user device 110 the attributes that may be required for authentication. This process is commonly referred to as a selective disclosure request.

[0054] In step 306, user equipment 110 may generate and send a Verifiable Claim (VC) based on a Selective Disclosure Request. User equipment 110 may use one or more data structures and cryptographic algorithms (e.g., the Merck-Ershu algorithm) to generate a verifiable expression that satisfies the Selective Disclosure Request. In some embodiments, the verifiable expression may include a combination of plaintext and ciphertext. For example, in some embodiments, the plaintext in the verifiable expression may include attributes that third-party system 140 requires to be disclosed for authentication. In some embodiments, the ciphertext in the verifiable expression may include other attributes from the verifiable claim that third-party system 140 does not require to be disclosed; instead, these other attributes, which can be provided as encrypted ciphertext, can be used to prove computation. In some embodiments, user equipment 110 may sign the verifiable expression using private key 172 and provide or link the verifiable expression to third-party system 140. The verifiable expression may initiate network requests to the interface of third-party system 140 to obtain various services. In some embodiments, user equipment 110 may set an expiration period for its verifiable expression according to the requirements of third-party system 140, which may be included in the verifiable expression.

[0055] In step 308, the third-party system 140 may review the verifiable statement. To verify the verifiable statement, the third-party system 140 may perform one or more review processes. In some embodiments, the review process may include the third-party system 140 analyzing the verifiable expression to determine if the verifiable expression is still valid at that time. In some embodiments, the review process may include the third-party system 140 analyzing the ciphertext and plaintext of the data disclosed by the user equipment 110 in the verifiable expression. In some embodiments, the review process may include the third-party system 140 performing structural and proof derivations to determine if the data disclosed in the verifiable expression is valid.

[0056] In some embodiments, the third-party system 140 can also be used to verify the signature corresponding to the verifiable statement in the verifiable expression. For example, the third-party system 140 can verify whether the signature conforms to the result of a previous proof derivation and / or whether the signature comes from a trusted issuing system.

[0057] In some embodiments, the third-party system 140 may also be used to compare the decentralized identifier in the verifiable statement with the decentralized identifier 126 associated with the user equipment 110 to determine whether the two are consistent.

[0058] In some embodiments, the third-party system 140 can also be used to verify the signature of the verifiable expression. For example, the third-party system 140 can determine whether the signature contained in the verifiable expression was issued by or associated with the decentralized identifier 126.

[0059] In some embodiments, the third-party system 140 can also be used to initiate network requests to a registry of verifiable data. For example, the third-party system 140 can query the registry to determine whether the verifiable statement and decentralized identifier are valid.

[0060] In step 310, the third-party system 140 may grant the verification request.

[0061] Figure 4 This is a flowchart illustrating a method 400 for performing decentralized verification according to a partially exemplary embodiment. Method 400 may begin at step 402.

[0062] In step 402, user equipment 110 may generate and store a decentralized identifier. For example, user equipment 110 may access management system 112 to generate a decentralized identifier 126. The decentralized identifier 126 may represent a permanent and immutable string that can be used to identify a user. In some embodiments, the decentralized identifier 126 may be associated with a corresponding decentralized identity document stored in a verifiable database registry 150. For example, the decentralized identifier 126 may include a URI indicating the storage location of the corresponding decentralized identity document in the verifiable database registry 150. Once generated, the decentralized identifier 126 may be stored in management system 112.

[0063] In step 404, user equipment 110 may request a verifiable statement from the issuing system. In some embodiments, the request may include at least a decentralized identifier 126 and personally identifiable information related to the user. Exemplary personally identifiable 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 phone number, etc.

[0064] In step 406, user equipment 110 may send a verification request to third-party system 140. For example, when user equipment 110 wishes to obtain one or more services from third-party system 140, it may send a verification request to third-party system 140. Examples may include, but are not limited to, logging into an account, registering a vehicle, applying for a loan, or applying for a job.

[0065] In step 408, user equipment 110 may receive a selective disclosure request from third-party system 140. For example, when user equipment 110 attempts to obtain services from third-party system 140, third-party system 140 may generate and send a selective disclosure request that informs user equipment 110 or explains to user equipment 110 the attributes that may be required for verification with third-party system 140.

[0066] In step 410, user equipment 110 may generate a verifiable statement and send it to third-party system 140. In some embodiments, the verifiable statement may be based on a selective disclosure request. User equipment 110 may use one or more data structures and cryptographic algorithms (e.g., the Merck-Ershu algorithm) to generate a verifiable expression that satisfies the selective disclosure request. In some embodiments, the verifiable expression may include a combination of plaintext and ciphertext. For example, in some embodiments, the plaintext in the verifiable expression may include attributes that third-party system 140 may require to be disclosed for verification. In some embodiments, the ciphertext in the verifiable expression may include other attributes from the verifiable statement that may not be required by third-party system 140; instead, these other attributes that can be provided as encrypted ciphertext may be used to prove computation. In some embodiments, user equipment 110 may sign the verifiable expression with private key 172 and may provide or link the verifiable expression to third-party system 140. The verifiable expression may initiate network requests to the interface of third-party system 140 to obtain various services. In some embodiments, user equipment 110 may set an expiration period for its verifiable expression according to the requirements of third-party system 140. This expiration period may also be included in the verifiable expression.

[0067] In step 412, user equipment 110 may receive verification confirmation based on a verifiable claim. Once user equipment 110 is verified, it can access the requested service. In some embodiments, verification may be time-limited. For example, verification confirmation may have a predefined period of use before user equipment 110 may re-verify itself by generating a new verifiable claim for auditing by a third-party system 140.

[0068] Figure 5AThis is an architecture of a system bus computing system 500 shown according to some exemplary embodiments. One or more components of system 500 can communicate electrically with each other via 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 connecting various system components (including system memory 515, such as read-only memory (ROM) 520 and random access memory (RAM) 525) to processor 510. System 500 may include a cache directly connected to processor 510, or adjacent to processor 510, or integrated as part of processor 510. System 500 can copy data from memory 515 and / or storage device 530 to cache 512 for fast access by processor 510. In this way, cache 512 can improve performance and avoid latency for processor 510 while waiting for data. These and other modules can control or be configured to control processor 510 to perform various operations. System memory 515 may also be available. Memory 515 may include various different types of memory with different performance characteristics. Processor 510 may represent a single processor or multiple processors. Processor 510 may include one or more general-purpose processors, or hardware or software modules, such as services 1 532, service 2 534, and service 5 536 stored in storage device 530, for controlling processor 510, as well as special-purpose processors, where software instructions are incorporated into the actual processor design. Processor 510 can essentially be a fully self-contained computing system, containing multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors can be symmetric or asymmetric.

[0069] To enable user interaction with system 500, input device 545 can be used. This input device can be any number of input mechanisms, such as a microphone for voice, a touchscreen for gesture or graphic input, a keyboard, a mouse, motion input, voice input, etc. Output device 535 (e.g., a display) can also be one of several output mechanisms known to those skilled in the art. In some examples, a multimodal system can allow the user to provide multiple types of input to interact with system 500. Communication interface 540 typically controls and manages user input and system output. Operation is not limited by any specific hardware configuration, therefore the basic functionality described here can be easily replaced with improved hardware or firmware configurations.

[0070] Storage device 530 may be a non-volatile memory, a hard disk or other type of computer-readable medium for storing computer-accessible data, such as magnetic tape, flash memory card, solid-state storage device, digital multifunction disk, tape cassette, random access memory (RAM) 525, read-only memory (ROM) 520, and combinations thereof.

[0071] Storage device 530 may include services 532, 534, and 536 for controlling processor 510, and other hardware or software modules may also be considered. Storage device 530 may be connected to system bus 505. In one aspect, a hardware module performing a specific function may include software components stored in a computer-readable medium, as well as hardware components required to perform that function, such as processor 510, bus 505, output device 535 (such as a display), etc.

[0072] Figure 5B This is a partial exemplary embodiment illustrating a computer system 550 having a chipset architecture. The computer system 550 may be an example of computer hardware, software, and firmware used to implement the disclosed technology. System 550 may include one or more processors 555, representing any number of physically and / or logically distinct resources, capable of executing software, firmware, and configuring hardware to perform specified computations. One or more processors 555 may communicate with a chipset 560, which may control input to and output from one or more processors 555. In this example, chipset 560 outputs information to an output device 565, such as a display, and may read and write information to a storage device 570, such as magnetic and solid-state media. Chipset 560 may also read and write data from storage device 575 (e.g., RAM). A bridge 580 may be provided for interfacing with various user interface components 585 to connect to chipset 560. These user interface components 585 may include a keyboard, microphone, touch detection and processing circuitry, pointing devices (such as a mouse), etc. Generally speaking, the input to System 550 can come from various sources, whether machine-generated or human-generated.

[0073] Chipset 560 can also interface with one or more communication interfaces 590, which may have different physical interfaces. These communication interfaces may include interfaces for wired or wireless local area networks, high-speed wireless networks, and personal area networks. Some applications of the methods disclosed herein for generating, displaying, and using a GUI may include receiving ordered datasets via physical interfaces, or generating them by the machine itself through analysis of data stored in storage devices 570 or 575 by one or more processors 555. Furthermore, the machine can receive user input via user interface component 585 and perform corresponding functions, such as interpreting this input via one or more processors 555 to implement browsing functionality.

[0074] It is understood that example systems 500 and 550 may have more than one processor 510, or example systems 500 and 550 may be part of a group or cluster of network-connected computing devices to provide greater processing power.

[0075] While the above description pertains to the embodiments described herein, other embodiments can be developed without departing from its basic scope. For example, aspects of this disclosure can be implemented in hardware, software, or a combination of hardware and software. One embodiment described herein can be implemented as a program product for use with a computer system. The program product defines the functionality of the embodiment (including the methods described herein) and can be stored on various computer-readable storage media. Exemplary computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory (ROM) devices in a computer, such as CD-ROMs, optical discs readable by CD-ROM drives, flash memory, ROM chips, or any type of solid-state non-volatile memory), where information is permanently stored; and (ii) writable storage media (e.g., floppy disks in floppy disk drives or hard disk drives, or any type of solid-state random access memory), where information is modifiable. When these readable storage media carry computer-readable instructions to instruct the functionality of the disclosed embodiments, they are embodiments of this disclosure.

[0076] It should be understood by those skilled in the art that the above examples are merely illustrative and not restrictive. The intention is that all permutations, enhancements, equivalents, and modifications, which will be apparent to those skilled in the art upon reading this specification and studying the accompanying drawings, are contained within the true spirit and scope of this disclosure. Therefore, it is intended that the following appended claims cover all such modifications, permutations, and equivalents falling within the true spirit and scope of these teachings.

Claims

1. A method for verifying with a third-party device, comprising: The computing system generates a decentralized identifier, which represents an immutable string used to identify the user; The computing system stores the decentralized identifier in a storage location; Based on the decentralized identifier, the computing system requests a verifiable statement from the trusted issuer system, the verifiable statement representing the trusted issuer system's proof of the user's identity; The computing system sends a verification request to the third-party system; The computing system receives a selective disclosure request from the third-party system, the selective disclosure request including attributes required for verification by the third-party system; Based on the attributes in the selective disclosure request, the computing system uses the verifiable statement to generate a verifiable claim; as well as Based on the verifiable statement, the computing system receives verification confirmation.

2. The method according to claim 1, wherein, Generating decentralized identifiers includes: Generate a decentralized identity document, the decentralized identity document including information used by the trusted issuer system to prove the user's identity; and Generate an identifier corresponding to the second storage location, wherein the decentralized identity document is stored in the second storage location.

3. The method according to claim 1, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: Identify portions of the verifiable statement that correspond to the attributes of the selective disclosure request.

4. The method according to claim 1, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: At least a portion of the verifiable claim is encrypted using a private key associated with the user.

5. The method according to claim 1, wherein, The verifiable statement includes an expiration date.

6. The method according to claim 5, further comprising: The computing system determines that the verifiable claim has expired; as well as Based on the determination, the computing system generates a new verifiable statement for re-verification with the third-party system.

7. The method according to claim 1, wherein, The request for the verifiable statement includes personally identifiable information related to the user.

8. A non-volatile computer-readable medium comprising one or more sequences of instructions, which, when executed by a processor, cause a computing system to perform operations including: The computing system generates a decentralized identifier, which represents an immutable string used to identify the user; The computing system stores the decentralized identifier in a storage location; The computing system requests a verifiable statement from the trusted issuer system based on the decentralized identifier, the verifiable statement representing the trusted issuer system's proof of the user's identity; The computing system sends a verification request to the third-party system; The computing system receives a selective disclosure request from the third-party system, the selective disclosure request containing attributes required for verification by the third-party system; Based on the attributes in the selective disclosure request, the computing system uses the verifiable statement to generate a verifiable claim; as well as Based on the verifiable statement, the computing system receives verification confirmation.

9. The non-volatile computer-readable medium according to claim 8, wherein, Generating the decentralized identifier includes: Generate a decentralized identity document, the decentralized identity document including information used by the trusted issuer system to prove the user's identity; and Generate an identifier corresponding to the second storage location, wherein the decentralized identity document is stored in the second storage location.

10. The non-volatile computer-readable medium according to claim 8, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: Identify portions of the verifiable statement that correspond to the attributes of the selective disclosure request.

11. The non-volatile computer-readable medium according to claim 8, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: At least a portion of the verifiable claim is encrypted using a private key associated with the user.

12. The non-volatile computer-readable medium according to claim 8, wherein, The verifiable statement includes an expiration date.

13. The non-volatile computer-readable medium of claim 12, further comprising: The computing system determines that the verifiable claim has expired; as well as Based on the determination, the computing system generates a new verifiable statement for re-verification with the third-party system.

14. The non-volatile computer-readable medium according to claim 8, wherein, The request for the verifiable statement includes personally identifiable information related to the user.

15. A system comprising: processor; as well as The memory stores programming instructions that, when executed by the processor, cause the system to perform the following operations: Generate a decentralized identifier, wherein the decentralized identifier represents an immutable string used to identify the user; The decentralized identifier is stored in the storage location; Based on the decentralized identifier, a verifiable statement is requested from the trusted issuer system, the verifiable statement representing the trusted issuer system's proof of the user's identity; Send a verification request to a third-party system; Receive a selective disclosure request from the third-party system, the selective disclosure request including attributes required for verification by the third-party system; Based on the attributes in the selective disclosure request, a verifiable statement is generated using the verifiable statement; as well as Based on the verifiable statement, receive verification confirmation.

16. The system according to claim 15, wherein, Generating decentralized identifiers includes: Generate a decentralized identity document, the decentralized identity document including information used by the trusted issuer system to prove the user's identity; and Generate an identifier corresponding to the second storage location, wherein the decentralized identity document is stored in the second storage location.

17. The system according to claim 15, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: Identify portions of the verifiable statement that correspond to the attributes of the selective disclosure request.

18. The system according to claim 15, wherein, Generating the verifiable statement using the verifiable statement, based on the attributes in the selective disclosure request, includes: At least a portion of the verifiable claim is encrypted using a private key associated with the user.

19. The system according to claim 15, wherein, The verifiable statement includes an expiration date.

20. The system according to claim 19, wherein, The operation also includes: It was determined that the verifiable claim had expired; and Based on the determination, a new verifiable statement is generated for re-verification with the third-party system.

Images