Storage and query method and device for verifiable credentials in decentralized identity system and medium

Abstract

An improved method, apparatus, and computer readable medium are presented that allow secure storage of verifiable credential (VC) data objects on different devices and platforms using decentralized identification (DID). Technical solutions are described for securely storing and querying VC data objects published by an issuer for decentralized identity verification or declaration verification between a holder and a verifier. According to the technical scheme, the method comprises the steps that a specially-configured VC database and a certificate index database are maintained to store VC data objects, and after a verification request of a verifier is received, the VC database and the certificate index database are inquired to retrieve the VC data objects and generate a verifiable statement (VP) for the verifier. The VC database and the voucher index database can be stored on a cloud storage service, and can also be stored on a device of a holder as a local browser extension.

Description

Technical Field

[0001] The present invention relates to the fields of computer storage and decentralized identity systems, and in particular to a method, a computer device, and a computer-readable medium for securely storing and querying verifiable credentials in a decentralized identity system. Background Art

[0002] Decentralized identity (DID) is a method for identifying and authenticating users and organizations without a centralized authority. DID systems allow users and organizations to manage and control their identities in a distributed manner, making them more vulnerable to attack by distributing user data across a network. Under a DID system, an attacker would need to compromise multiple locations to access all user data, making it more difficult to compromise. Furthermore, DID systems give users control over their data, allowing them to choose which credentials to share with each service.

[0003] One technical challenge of the DID system is the lack of efficient and feasible solutions for storing and backing up verifiable credentials (VC). Some existing DID solutions do not provide multi-terminal or cross-device verifiable credential backup options. For example, when a user changes their device, although the DID can be regenerated using the private key, the VC obtained from the issuer cannot be restored. Some existing solutions back up the entire verifiable credential database (VC database) to personal storage services (e.g., iCloud, Google Drive, etc.), but these storage services not only face information security issues, but also do not support data merging or version management of VC databases generated by the same DID on different terminals or devices.

[0004] Therefore, there is a need for a system and method that can provide persistent and secure VC storage across different devices and platforms to ensure the privacy and security of user VC. Summary of the Invention

[0005] The present invention proposes an improved technical solution that allows the use of decentralized identities (DIDs) across different devices and platforms to securely store verifiable credential (VC) data objects. The technical solution proposed by the present invention is suitable for docking with storage media to securely store and query VC data objects issued by issuers so that verifiers can verify the decentralized identities or claims held by holders. The technical solution proposed by the present invention includes maintaining a specially configured VC database and credential index database to store VC data objects, and querying the VC database and credential index database to retrieve VC data objects after receiving a verification request from a verifier, thereby generating a verifiable presentation (VP) for the verifier. The VC database can be stored on a cloud storage service or on the local device of the holder. For example, the VC database can be stored on the holder's device in the form of a local browser extension.

[0006] Embodiments of the present invention provide methods, apparatus, and computer-readable media for storing and retrieving VC data across different devices and platforms using two specially configured databases to implement decentralized identity verification. By utilizing two databases (the VC database and the credential index database), users can choose different storage options, such as maintaining one database on a decentralized service and another on a private data service (e.g., iCloud, Firebase), thereby enhancing the security of their VC data.

[0007] Embodiments of the present invention not only enable secure storage and retrieval of VC data across different devices and platforms, but also address data synchronization issues associated with concurrent access. All stored and transmitted data is end-to-end encrypted, enabling the use of decentralized data services. The security of the proposed protocols and services increases with the number of holders (since data association becomes increasingly difficult with the number of users).

[0008] An embodiment of the first aspect of the present invention provides a method suitable for a holder of a verifiable credential data object to securely store and query the verifiable credential data object, for use in performing decentralized identity authentication or claim verification to a verifier based on a claim information data object initially issued by an issuer, the method comprising: the holder encrypts the verifiable credential data object containing the credential metadata object, the claim information data object and the issuer's proof token and uploads it to a verifiable credential database, wherein the encrypted verifiable credential data object uniquely corresponds to each verifiable credential identification token in the verifiable credential database; the holder maintains a credential index database, which contains an encrypted verifiable credential identification token and a hashed credential metadata object; after receiving a verification request from the verifier, the credential metadata object is used to query the credential index database, and the holder receives and decrypts the verifiable credential identification token; the holder uses the verifiable credential identification token to query the verifiable credential database, and the holder receives and decrypts the verifiable credential data object; the holder uses the verifiable credential data object to generate a verifiable claim; the holder transmits the verifiable claim to the verifier, so that the verifier receives the claim information data object and uses the issuer's proof token to verify the claim information data object

[0009] In some embodiments, the credential metadata object includes a credential type and a credential schema that can verify the credential data object, allowing the holder to query the credential index database using the credential type and credential schema.

[0010] In some embodiments, the issuer proof token includes a signature of the issuer, which verifies that the issuer is the author of the verifiable credential data object and that the verifiable credential data object has not been modified since its creation.

[0011] In some embodiments, the issuer's decentralized identifier is hashed with the credential type and credential mode, enabling the holder to query the credential index database using the combination of the credential type, credential mode, and the issuer's decentralized identifier.

[0012] In some embodiments, the holder encrypts a verifiable credential data object in a verifiable credential database using a random symmetric encryption key, and the random symmetric encryption key is further encrypted by the holder's key and stored on the verifiable credential database, so that the random symmetric encryption key can be decrypted using the holder's key, and the verifiable credential data object can be decrypted using the random symmetric encryption key.

[0013] In other embodiments, the verifiable credential database is stored on a cloud storage service. In order to prevent credential metadata objects with the same credential type, credential mode, and issuer decentralized identifier from generating the same hash value, a supplementary randomized token can be further generated and hashed with the credential type, credential mode, and issuer decentralized identifier. In addition, in a cloud storage environment, the present invention can provide holders with independent cloud storage for persistent storage of VCs. In some embodiments, cloud storage is a decentralized storage service. In other embodiments, cloud storage is a private data service to which the holder has access rights, such as an iCloud database, a Firebase real-time database, or a Firebase Firestore database. The present invention provides an improved database table structure for cloud storage and improves the interaction protocol between the holder and the cloud storage.

[0014] In other embodiments, the verifiable credential database is stored locally on the holder's device as a local browser extension. The holder encrypts the verifiable credential data objects in the verifiable credential database, including declaration data objects with numerical values, using an order-preserving encryption algorithm, enabling Boolean queries on the encrypted verifiable credential data objects. This database-based browser extension provides the holder with local VC persistent storage, enabling secure storage and retrieval of the user's VC even when the local storage used by the browser environment itself is not secure.

[0015] In other embodiments, a first version of the verifiable credential database is stored on a cloud storage service, a second version of the verifiable credential database is stored on the holder's device as a local browser extension, and the first and second versions interface and are updated to reconcile any differences between the first and second versions.

[0016] A second aspect of the present invention provides an apparatus for performing decentralized identity verification or claim verification, comprising:

[0017] One or more processors; and one or more computer-readable memories coupled to the one or more processors and having a computer program stored thereon, the computer program being executable by the one or more processors to implement any of the above methods.

[0018] A third aspect of the present invention provides a computer storage medium storing computer instructions, wherein the computer instructions are used to enable a processor to implement any of the above methods when executed.

[0019] Additional features and advantages will be described below. Those skilled in the art will appreciate that the disclosed concepts and specific embodiments may serve as a basis for modifying or designing other structures. Those skilled in the art will also recognize that such equivalent structures do not depart from the spirit and scope of the embodiments described herein. The features of the present invention, both as to its organization and method of operation, as well as further objects and advantages, will be better understood from the description in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings provide further explanation by way of example. The descriptions and diagrams in the accompanying drawings are for illustrative and understanding purposes only and are not intended to be limiting. The embodiments will now be described by way of example with reference to the accompanying drawings, wherein:

[0021] Figure 1 A flow diagram illustrating an example decentralized user authentication system according to some embodiments is shown.

[0022] Figure 2 A diagram illustrating example structural components of a verifiable credential in accordance with some embodiments.

[0023] Figure 3 A flow diagram illustrating an example decentralized user identity authentication system with secure storage of verifiable credentials in accordance with some embodiments.

[0024] Figure 4A -4B is a table illustrating an example composition of a verifiable credential database for storing and querying verifiable credentials, according to some embodiments.

[0025] Figure 5A -5B is a table illustrating an example credential index database composition for storage and query of verifiable credentials, according to some embodiments.

[0026] Figure 6A -6C is an architectural diagram illustrating limitations of an example browser extension storage method, according to some embodiments.

[0027] Figure 7A -7B is an example flow diagram illustrating an issuer issuing a verifiable credential and saving the verifiable credential to a storage medium, according to some embodiments.

[0028] Figure 8A -8B is an example flow chart illustrating a holder obtaining a verifiable credential and generating a verifiable presentation based on the verifiable credential, according to some embodiments.

[0029] Figure 9 is an example computing system diagram illustrating an example computing system for implementing a verifiable credential secure storage system. DETAILED DESCRIPTION

[0030] The DID system faces many technical challenges, such as the lack of efficient and feasible VC storage and backup solutions. Some existing DID solutions do not provide multi-terminal or cross-device verifiable credential backup options. Although the DID can be regenerated using the private key when the user changes the device, the user cannot restore the VC obtained from the issuer. Some existing solutions back up the VC database as a whole to personal storage services (such as iCloud and Google Drive), but these storage services do not support data merging or version management of VC databases generated by the same DID on different terminals or devices.

[0031] For example, when developing a browser extension for a DID system, third-party plug-ins or executable programs in the user's device's desktop operating system could potentially access data stored in the extension without authorization, potentially leaking the user's private data. Browser extensions can only rely on the data storage methods provided by the browser itself, but it's difficult to determine whether the browser environment is secure enough to protect data.

[0032] For example, if a user installs a modified browser and uses a DID plug-in within that browser, the plug-in's code logic will not be able to discern that the browser's data storage method has been modified. The DID plug-in will still write VC data to the compromised interface, resulting in the leakage of the user's private data.

[0033] In another scenario, a DID extension is developed and released for browser A, and uses the secure storage environment provided by browser A to store VC. If a new browser B is introduced and is compatible with browser A's extension, users may install browser A's DID extension on browser B. However, if browser B does not provide a secure storage environment like browser A, this may lead to the leakage of user private data stored in VC.

[0034] Therefore, there is a need for a system and method that can provide persistent and secure VC storage across different devices and cloud platforms to ensure the privacy and security of users' VCs. In the context of browser extensions, there is a need for a system and method that can provide secure storage for users' VCs and protect their VC privacy even if the persistent storage provided by the browser itself is not secure enough.

[0035] The present invention describes an improved method and its related systems, computer devices and computer-readable media, which allow the use of decentralized identities (DIDs) across different devices and platforms to securely store verifiable credential (VC) data objects. The technical solution proposed by the present invention is suitable for docking with storage media to securely store and query VC data objects issued by issuers for decentralized identity or claim verification between holders and verifiers. The proposed method includes maintaining a specially configured VC database and credential index database for storing VC data objects, and after receiving a verification request from a verifier, querying the credential index database and VC database to retrieve VC data objects and generate a verifiable presentation (VP) for the verifier. The VC database can be stored on a cloud storage service or on the holder's local device in the form of a local browser extension.

[0036] The present invention proposes a method for decentralized authentication using two specially configured databases for storing and retrieving VC data across different devices and platforms. By utilizing two databases (the VC database and the credential index database), users can choose a specific storage solution, such as maintaining one (or part of) the database on a decentralized service and another (or part of) the database on a private data service (e.g., iCloud, Firebase). Because the two databases can only communicate to complete VC authentication, maintaining VC data and indexes separately enhances the security of users' VCs.

[0037] "Maintaining" the database can include managing the VC database tables and the credential index database tables, ensuring data integrity, applying randomization techniques, optimizing queries for efficient retrieval, and protecting data using encryption methods such as AES and sequence-preserving symmetric encryption. Whether it's a cloud-based solution or a browser extension, maintenance also involves regular backups, establishing recovery plans, setting up access controls, continuously monitoring for performance issues and security threats, and applying software updates and upgrades to enhance functionality.

[0038] The data stored and transmitted in this invention can be encrypted end-to-end, thus supporting the use of decentralized data services. The security of the protocols and services proposed by this invention increases with the number of holders, because the difficulty of attempting to link data increases with the number of users.

[0039] The technical solution described in this invention can provide independent cloud storage for persistent storage of virtual machines (VCs) within a cloud storage environment. In some embodiments, the cloud storage is a decentralized storage service. In other embodiments, the cloud storage is a private data service to which the holder has access rights, such as an iCloud database, a Firebase Realtime Database, or a Firebase Firestore database. The system described herein provides an improved database table structure for cloud storage and an improved interaction protocol between the holder and the cloud storage.

[0040] The technical solution described in this invention provides the holder with a local VC persistent storage function based on a database in a browser extension, and can still provide secure storage and retrieval for the user's VC even when the local storage used by the browser environment itself is not secure enough.

[0041] Figure 1 is a flow diagram of an example decentralized user authentication system 100 according to some embodiments.

[0042] Participants in system 100 include issuers 106, holders 108, and verifiers 110. For example, in one embodiment, issuer 106 may be a university, holders 108 may be university graduates, and verifiers 110 may be employers seeking employment. References to participants herein extend to the hardware or devices of each participant. For example, issuer 106 may refer to the electronic devices and corresponding computing elements used by the issuer.

[0043] After verifying the identity of holder 108, issuer 106 issues a VC / VC data object 102 to holder 108. This VC 102 includes a proof token from issuer 106, ensuring that VC 102 can be verified as issued by issuer 106 and has not been tampered with. In some embodiments, the issuer proof token is a digital signature. In some embodiments, VC 102 can be provided in a JSON file format. Holder 108 then receives VC 102 and stores it. For example, issuer 106 can be a university that verifies the identity of a graduate (holder) and then issues a degree certificate (VC) to the graduate.

[0044] Verifier 110 can send a verification request to holder 108. Holder 108 uses the stored VC 102 to generate a verifiable presentation (VP) 104, which contains the issuer's proof token. Verifier 110 can use cryptographic techniques to verify the validity of VP 104 and ensure that the information provided in VP 104 is consistent with VC 102. Verifier 110 can specifically verify that: (1) holder 108 owns VC 102 issued by issuer 106; (2) the information disclosed in VP 104 is consistent with the original information in VC 102 and has not been tampered with; and (3) VP 104 is authorized and submitted by holder 108. During the verification process, there is no need for direct communication between verifier 110 and issuer 106. Both parties transfer trust information through a trust data registry 112 (usually using decentralized storage and methods such as blockchain). For example, when graduates (holders) seek jobs, they may need to prove to employers (verifiers) that they own a degree certificate (VC) issued by a university (issuer). In this process, the university, as the issuer, verifies the graduate's identity and issues the corresponding VC, including degree certificate information, to the graduate. When the employer requests verification, the graduate can use the VC to generate the corresponding VP. The employer (verifier) can then use encryption technology to verify the validity of the VP. This process does not involve direct communication with the university, but rather transmits information through a trusted data registry.

[0045] Once generated, VC 102 is stored for a long time. Since VC 102 contains the holder's private data, holder 108 must store VC 102 and ensure that VC 102 is not leaked. VP 104 has a shorter lifespan than VC 102 because VP 104 is only generated in response to a request from verifier 110.

[0046] In some embodiments, VP 104 includes information extracted from multiple VCs 102. In some embodiments, VP 104 does not contain all the information in the VC 102 that generated VP 104. VP 104 supports selective disclosure of information from multiple VCs 102. For example, if a holder 108 needs to provide a work resume VP 104, holder 108 can extract information from VCs 102 issued by multiple issuers 106, such as government-issued ID cards, university-issued degree certificates, or employment certificates issued by previous employers. Multiple VCs 102 can be merged into a single VP 104 and provided to a verifier 110. During this process, holder 108 can choose to hide certain information in VP 104, such as salary information from a VC 102 issued by a previous employer.

[0047] Figure 2FIG. 1 is a diagram illustrating the structural components of an example verifiable credential according to some embodiments. In some embodiments, the verifiable credential data object 102 includes three components: a credential metadata object 202 , a claim information data object 204 , and an issuer proof token 206 .

[0048] The credential metadata object 202 includes a credential ID, type, credential schema, issuer DID, and holder DID. For example, the type of a VC data object 102 might be a graduation certificate, a bank certificate, or the like. The credential schema refers to the content template of the VC data object, describing the content contained in the VC data object 102. For example, a VC data object 102 might be a government-issued ID card or a university-issued diploma. Once the schema is defined, the claim entries within the VC data object 102 are also uniquely identified. In some embodiments, the credential schema is an XML file that describes the content and claims of the VC data object 102. For example, a government-issued ID card VC data object 102 might contain information such as name and date of birth. The issuer DID is a decentralized identifier for the issuer of the VC data object 102. The holder DID is a decentralized identifier for the holder.

[0049] The declaration information data object 204 includes the plain text information of each declaration. For example, the declaration information data object 204 of the government-issued ID card VC data object 102 may include the name, date of birth and ID card number of the ID card holder.

[0050] Issuer proof token 206 includes proof that VC data object 102 has not been tampered with. VC 102 includes issuer proof token 206 to ensure that VC 102 can be proven to be issued by issuer 106 and has not been tampered with by the holder or other parties. In some embodiments, the issuer proof token can be a digital signature or a Merkle tree proof associated with a hash on a decentralized storage blockchain.

[0051] In some embodiments, VC 102 is provided in JSON format.

[0052] Figure 3 is a flow diagram of an example system for decentralized user authentication with secure storage of verifiable credentials, according to some embodiments.

[0053] The embodiments described herein provide an improved VC storage 302 for storing VC data objects 102, as well as an improved storage and retrieval process for holders 108 to store and retrieve VC information from the VC storage 302. The VC storage 302 includes a specially configured VC database table 304 and an index database table 306. The VC storage 302 can be any decentralized storage service or private data service to which the holder 108 has access, such as an iCloud database, a Firebase Realtime Database, or a Firebase Firestore database. The VC storage 302 provides holders 108 with persistent storage functionality for VC data objects 102, but does not serve validators 110 or issuers 106, nor does it alter the interaction between issuers 106, holders 108, and validators 110. Holders 108 interact directly with the VC storage 302, rather than saving and retrieving VC data objects 102 from a local database.

[0054] In some embodiments, one of the VC database table 304 and the credential index database table 306 is maintained on a decentralized service, and the other is maintained on a private data service, so as to reduce the collateral losses caused by the leakage of one party and thereby enhance security.

[0055] Verifier 110 can send a verification request in the form of a query to holder 108. A verification request indicates that verifier 110 is asking holder 108 whether it possesses a VC data object 102 that meets certain conditions. For example, verifier 110 can query holder 108 whether it possesses a VC data object 102 issued by a specific issuer or multiple issuers 106, or verifier 110 can query holder 108 whether it possesses a VC data object 102 with a specific schema, such as a university-issued diploma or a specific type of credential. Verifier 110 can also query holder 108 whether it possesses a VC data object 102 with a specific claim information data object value that satisfies one of the following conditions: "equal to / not equal to a certain value," "in / not in a certain set," "greater than / less than a certain value," and "is any value." For this type of condition acting as a query filter, verifier 110 can receive a Boolean value if the claim information data object value must satisfy a specific operator (e.g., =, <, >, is, is not, is in, is not in, between, etc.). In other cases, the verifier 110 will receive the plain text information of the claim from the claim information data object 204. For a claim information data object 204 with a numeric value, the query can have any of the above conditions. For a claim information data object 204 with a string value, the query can have all conditions except for numeric retrieval.

[0056] If the holder 108 does possess a VC data object 102 that meets the query criteria, the holder 108 may generate a VP from the VC data object 102 and submit the VP to the verifier 110 .

[0057] The holder 108 uses the stored VC 102 to generate a VP, which contains the issuer's proof token. During the VP generation process, the holder selectively discloses specific information in the VC, choosing which details to disclose and which details to keep confidential. The holder uses cryptographic techniques to create a VP containing its digital signature, ensuring that the information displayed is consistent with the original VC and has not been tampered with. This VP is then submitted to the verifier. The verifier 110 can use cryptographic techniques to verify the validity of VP 104 and ensure that the information provided in VP 104 is consistent with the VC 102. Among other things, the verifier 110 can verify that: (1) the holder 108 owns the VC 102 issued by the issuer 106; (2) the information disclosed in VP 104 is consistent with the original information in VC 102 and has not been tampered with; and (3) VP 104 is authorized and submitted by the holder 108. During the verification process, there is no need for direct communication between the verifier 110 and the issuer 106. The two parties communicate trust information through a trust data registry (usually using decentralized storage and methods such as blockchain). For example, when graduates (holders) seek employment, they may need to prove to employers (verifiers) that they possess a degree certificate (VC) issued by a university (issuer). Graduates generate a proof of ownership (VP) using their stored university-issued VC and provide it to their employers for verification. Instead of communicating directly with the university, the employer and the university exchange trust information through a trusted data registry. Employers directly use cryptographic techniques to verify the authenticity and accuracy of the proof of ownership (VP) generated from the VC.

[0058] In some embodiments, VC storage 302 is a cloud storage service. The system described herein can provide independent cloud storage for holders 108 to persistently store VC 102. In some embodiments, the cloud storage is a decentralized storage service. In other embodiments, the cloud storage is a private data service to which the holder has access rights, such as an iCloud database, a Firebase Realtime Database, or a Firebase Firestore database. The system described herein provides an improved database table structure for cloud storage and an improved interaction protocol between the holder and the cloud storage.

[0059] In some embodiments, VC storage 302 is located locally on the owner's device in the form of a local browser extension. System 300 can be used within the browser extension to provide secure storage for the user's VC 102. Even in situations where the local storage used by the browser environment itself is not secure enough, the system described herein can provide local persistent storage functionality for the owner. In some embodiments, VC storage 302 encrypts each numeric value in a VC data object 102 using an order-preserving encryption algorithm and encrypts string-type declaration information data object values in a VC data object 102 using a conventional symmetric encryption method (e.g., AES). This allows the owner 108 to search and filter the encrypted data in VC storage 302 based on query filters provided in a verifier 110 query (e.g., "equal to / not equal to a certain value," "is / is not in a certain set," "greater than / less than a certain value," "is any value") without having to decrypt the VC data in VC storage 302. Once the corresponding VC data object 102 is accurately found, the corresponding VP is generated.

[0060] Figure 4A -4B is a table of an example verifiable credential database according to some embodiments, which is used for verifiable credential storage and query.

[0061] Figure 4A An example VC database table 304A for a cloud storage service is shown. The VC database table 304A contains a hash value of a VC ID, encrypted VC content (i.e., a verifiable credential data object), and an encrypted encryption key field. The VC ID (i.e., a verifiable credential identification token) uniquely corresponds to the VC content.

[0062] Figure 4B An example VC database table 304B for local browser extension storage is shown. VC database table 304B contains a hash of the VC ID, encrypted VC metadata, encrypted VC content (a verifiable credential data object), and an encrypted encryption key field. The VC ID uniquely corresponds to the VC content. Compared to VC database table 304A, VC database table 304B additionally contains encrypted VC metadata, allowing users to further query the database table using the VC metadata at a lower cost than cloud-based queries.

[0063] exist Figure 4A and Figure 4BIn the example above, the VCID is hashed, and the encryption key is encrypted again using the holder's 108 key. The holder's key is the private data used by the holder 108 to generate the DID, such as a private key or signature generated using a cryptographic wallet. When the same holder 108 uses the system on different devices, they can recover the same key and thus calculate the same DID. For example, the holder 108 can recover the same key using a mnemonic phrase or a cryptographic wallet signature.

[0064] The encrypted VC content in VC database tables 304A and 304B and the encrypted VC metadata in VC database table 304B are encrypted using a random encryption key. The random encryption key is a randomly generated symmetric key. Each VC data object 102 uses a different random key, which minimizes potential losses in the event of a key leak. This random encryption key is encrypted again using the holder's key and stored in the same database. Therefore, the holder 108 can first decrypt the random encryption key using its own key, and then use the decrypted random encryption key to decrypt the VC content or metadata and the proof token. The encryption method here can be any sufficiently secure symmetric encryption method (e.g., AES).

[0065] Regarding the VC database table 304B, when the holder 108 obtains the ID of a specific VC data object 102, they can query the VC database table 304B to retrieve the credential metadata object 202 and issuer certification token 206 information corresponding to the VC data object 102 required to generate a VP.

[0066] Figure 5A -5B is a table of an example credential index database according to some embodiments, which is used for storage and query of verifiable credentials.

[0067] Figure 5A An example credential index database 306A for a cloud storage service is shown. The credential index database 306A contains fields for a credential metadata hash, a credential metadata and issuer DID hash, an encrypted VC ID, and an encrypted encryption key. In this embodiment, the VC ID is a verifiable credential identification token, and the credential metadata is a credential metadata object.

[0068] The Credential Metadata Hash Value data field is derived by hashing the Credential Type of a VC data object, the Credential Mode of the VC data object, the holder's 108 key, and a supplementary randomization token. The VC data object is a verifiable credential data object. The Credential Type and Credential Mode fields of a Credential Metadata object 202 are often used together in queries to find VC data objects 102 of the same type. Therefore, hashing these two components of the Credential Metadata object 202 together facilitates the holder's 108 using the same calculation method to generate query conditions. In actual applications, the database can adjust the pre-hashed and stored content based on the credential metadata object content and common query conditions.

[0069] In some embodiments, the issuer DID can be used as an additional independent query condition, for example, to query the issuer DID value (e.g., a specific value, a value within a set, or any issuer DID) when querying the credential metadata object 202. Therefore, it is necessary to store the issuer DID in a field separate from the hashed credential metadata field. To reduce the risk of generating the same hash data for the same issuer DID (which could be tracked by others for data correlation and subsequent deduction of confidential information), the credential type and credential mode fields of the credential metadata object 202 are still included in the hash function.

[0070] Despite various safeguards in place to ensure unique hash results for different VC data objects, when the same issuer 106 publishes multiple VC data objects 102 with the same schema to the same holder 108, the values of the two hash fields for these VC data objects 102 may still be identical in the credential index database 306A. This can lead to privacy breaches. Specifically, if an issuer publishes n VC data objects with the same credential schema to the same holder 108, detecting that a particular holder has uploaded n pieces of data with the same hash value to the VC storage 302 implies that these pieces of data all belong to that holder 108. To prevent this, the credential index database 306A introduces a supplementary randomization token when generating hash data. This supplementary randomization token ensures that the hash data for different VC data objects 102 from the same issuer 106 are unique.

[0071] In some embodiments, the supplementary randomization token is a random number between 1 and 10. When the holder 108 attempts to query data from the credential index database 306A, the holder 108 must generate 10 query requests (because the holder 108 does not know the specific randomly generated number used when storing the VC data object 102) to retrieve all possible data belonging to the holder 108. After obtaining multiple search results, the holder then further filters them to obtain the VC that was originally intended to be searched.

[0072] Figure 5BAn example claim index database 306B for local browser extension storage is shown. Claim index database 306B contains claim key hash values, encrypted claim values, hashed credential metadata and issuer DID, encrypted VCID, and encrypted encryption key fields. Because local storage and retrieval are less expensive than cloud storage solutions, more combined hashes of values can be pre-calculated and stored for accurate querying. Unlike credential index database 306A, claim index database 306B stores separate claim key and claim value fields. The local browser extension storage creates a record for each claim in the VC data object 102 so that when the verifier 110 initiates a query based on the claim, the holder 108 can accurately retrieve the VC's ID from claim index database 306B.

[0073] The claim key hash value is a value derived by hashing the claim key, credential type, credential mode, and the holder's 108 key. The credential type and credential mode fields of the credential metadata object 202 and the claim key of the claim information data object 204 are often used together in queries to find VC data objects 102 of the same type. Therefore, these fields are hashed together so that the holder 108 can generate query conditions using the same calculation method. For example, the claim key could be "birthday."

[0074] The encrypted claim value is obtained by encrypting the claim value using the key of the holder 108. The verifier 110 can use the claim value of the VC data object as a verification query request. The query filter conditions supported by DID VP include: "equal to / not equal to a certain value", "in / not in a certain set", "greater than / less than a certain value", and "is any value". For example, the claim value corresponding to the "birthday" claim key can be "2020-01-01". Except for the "greater / smaller" filter, other filters can directly use encrypted data for querying without decrypting first. Since string type claim values do not need to support "greater / smaller" filters, string type values can be encrypted using a symmetric encryption method (for example, AES). However, for numeric type claim values, the "greater / smaller" type query filter is supported by the order-preserving encryption algorithm (OPSE). The OPSE method maintains the order of numeric type values after encryption, retains the comparison order before encryption, and provides sufficient security.

[0075] Typically, OPSE encryption is less efficient than common symmetric encryption schemes (e.g., AES). However, when saving VC data objects 102, the OPSE method is executed only once for each numeric type declaration value, and the encrypted data is stored locally. Therefore, the actual operating efficiency of the OPSE method does not affect the overall operation of the local browser plug-in.

[0076] Credential index database 306B stores each claim as a separate record. If VC data object 102 contains hundreds of claims, the amount of stored data could be substantial. However, since local storage is used, no network read / write operations are required, allowing for asynchronous development and optimization. Therefore, storing each claim as a separate record does not significantly impact the user experience.

[0077] In some embodiments, the issuer DID can be used as an additional independent query condition, for example, when querying the credential metadata object 202, the issuer DID value (e.g., a specific value, a value within a set, or any issuer DID) can also be queried. Therefore, it is necessary to store the issuer DID in a field separate from the hash claim key and encrypted claim value fields. To reduce the risk of generating the same hash data for the same issuer DID (which could be tracked by others for data correlation), the credential type and credential mode fields of the credential metadata object 202 are still included in the hash function.

[0078] The design of credential index databases 306A and 306B balances the amount of data that needs to be uploaded to the credential index databases with the amount of VC data that needs to be retrieved / downloaded from the credential index databases each time a VP is generated. Each time a holder 108 obtains a VC data object 102 from an issuer 106, only one record needs to be uploaded to credential index databases 306A / 306B and VC databases 304A / 304B. When a holder 108 generates a VP, the holder 108 only needs to retrieve all VC data objects 102 with the same schema and issuer DID attributes from credential index databases 306A / 306B and VC databases 304A / 304B.

[0079] For example, a holder 108 may have obtained a total of 1,000 VC data objects from different issuers 106. If all VC data objects 102 were retrieved each time a VP was generated, the user experience would be degraded. However, using system 300 as an example, if the desired VC data object 102 is a university diploma, and holder 108 only has five VC data objects that match the "diploma" credential schema, holder 108 only needs to download these five VC data objects and perform local filtering on the claim data to generate the VP. The five downloaded VC data objects can then be deleted.

[0080] In some embodiments, one of the VC database and the credential index database is maintained by a decentralized service, and the other is maintained on a private data service to enhance security.

[0081] Figure 6A -6C is an architectural diagram illustrating limitations of an example browser extension storage method, according to some embodiments.

[0082] There are technical challenges in using a DID system in the context of a browser extension. Figure 6A This article shows an example storage architecture for browser extensions, which includes the process from the operating system to the browser's local persistent storage, and then to the browser extension's persistent storage data. When developing browser extensions for DID systems, the data persisted by the extension plug-in may be illegally accessed by third-party plug-ins or executable programs in the user's device operating system, resulting in the leakage of user private data. Even when the browser extension cannot determine whether the browser environment is secure and has sufficient security to protect persistent data, the extension can only rely on the data storage solution provided by the browser itself.

[0083] For example, Figure 6B As shown, if a user accidentally installs an unsafe browser and uses a DID plug-in in that browser, the plug-in's code logic cannot detect that the browser's data storage method has been modified and will still write VC data to the damaged interface, causing the user's private data to be leaked.

[0084] Even if we assume that browser A is completely unmodified and can guarantee the security of user data, the DID system still faces security issues. Figure 6C As shown, a DID extension is developed and released for a hypothetical secure browser A, and uses the secure storage environment provided by browser A to store VC. If a user knowingly or unknowingly introduces browser B, and it is compatible with browser A's extension, the user may install browser A's DID extension on browser B. However, if browser B does not provide a similar secure storage environment as browser A, the user's private data stored in VC may be leaked.

[0085] The embodiments described herein provide a solution that ensures the privacy and security of a user's VC through persistent and secure VC storage. In the context of browser extensions, the present invention provides a system and method for providing secure storage and protecting the privacy of a user's VC, even when the browser's native persistent storage is not secure enough. This solution utilizes decentralized identity and the aforementioned separately configured databases 304 and 306.

[0086] Figure 7A -7B is an example flow chart of an issuer issuing a verifiable credential and saving the verifiable credential to a storage medium according to some embodiments.

[0087] Figure 7AAn example process 700A is shown in which an issuer publishes a VC data object and saves the VC data object to a cloud storage service. In step 702A, the holder recovers the key used to encrypt and hash the VC data. If necessary, the holder can use methods such as mnemonics or encrypted wallet signatures. In step 704A, the holder is authenticated and requests the issuer to publish the required VC data object. The authentication process can be internal to the issuer's system. For example, in the case where a university graduate (holder) requests a graduation certificate VC, the university (issuer) can verify the graduate's identity by searching the university's registration database or graduation records for the graduate's identity information.

[0088] In step 706A, the issuer publishes a VC data object (JSON format) to the holder. The VC contains the issuer's digital signature or other information as an issuer verification token, ensuring that the VC can be verified as issued by the issuer and has not been tampered with. When subsequently generating a VP, the issuer's digital signature further verifies the authenticity and accuracy of the information to the verifier.

[0089] In step 708A, the holder encrypts and / or hashes the VC data object and the voucher index item and stores the data. Figure 4A The VC database 304A stores the encrypted and hashed VC data (i.e., Figure 4A The encrypted VC content in the VC database is written into the cloud storage. The encrypted VC content is a verifiable credential data object, and the VC database is a verifiable credential database. Figure 4A The VC content includes a credential metadata object, a declaration information data object, and an issuer certification token (i.e., the digital signature mentioned above). Each VC content is uniquely associated with a VC ID stored in the VC database 304A as a verifiable credential identification token. In step 712A, the holder Figure 5A The credential index database 306A writes the encrypted and hashed credential index data to the cloud storage. The encrypted and hashed credential index data includes an encrypted verifiable credential identification token (encrypted VC ID) and the hashed credential metadata object. Figure 4A and Figure 5A The VC ID is a verifiable credential identification token.

[0090] Figure 7BAn example process 700B is shown in which an issuer publishes a VC data object and saves the VC data object to local browser extension storage. In step 702B, the holder recovers the secret private key used to encrypt and hash the VC data. If necessary, the holder can use methods such as mnemonics or encrypted wallet signatures. In step 704B, the holder is authenticated and requests the issuer to publish the required VC data object. The authentication process can be internal to the issuer's system. For example, in the case where a university graduate (holder) requests a graduation certificate VC, the university (issuer) can verify the identity of the graduate by searching the university's registration database or graduation records for the graduate's identity information.

[0091] In step 706B, the issuer publishes a VC data object (JSON format) to the holder. The VC data object includes the issuer's digital signature or other information as an issuer verification token, ensuring that the VC can be verified as issued by the issuer and has not been tampered with. When subsequently generating a VP, the issuer's digital signature further verifies the authenticity and accuracy of the information to the verifier.

[0092] In step 708B, the holder encrypts and / or hashes the VC data object and the credential index item. The holder stores the VC data and the credential index item. In step 710B, the holder Figure 4B The VC database 304B writes the encrypted and hashed VC data object into local storage (browser extension), wherein the VC data object is a verifiable credential data object, and the VC database 304B is a verifiable credential database. Figure 4B The VC metadata is a credential metadata object. In step 712B, the holder Figure 5B The credential index database 306B writes the encrypted and / or hashed credential index data to local storage. The encrypted and / or hashed credential index data includes an encrypted verifiable credential identification token (here, VC ID) and the hashed credential metadata object. Figure 4B and Figure 5B The VCID is a verifiable credential identification token, the claim key and claim value are claim information data objects, and the issuer DID is an issuer proof token.

[0093] Although the cloud storage-based and browser extension-based embodiments are described in different figures and paragraphs, the two embodiments can coexist and interact in operation. The holder can choose to store part of the VC and its corresponding index data in a cloud storage-based solution, while storing other parts in local storage media. This decision can be based on a wide range of considerations, including the holder's trust in each storage solution, the associated operating costs of each solution due to the size of the VC data, and the holder's access rights to their existing storage forms. The holder can even decide to store the VC index in the cloud, but keep the VC database locally (or vice versa) to balance security and accessibility. In some embodiments, the VC stored in one medium can be an identical copy of the VC stored in another medium. In this case, one version of the VC can serve as a backup of the other version to prevent the loss of the VC due to downtime or data corruption.

[0094] If there are any discrepancies or out-of-sync issues between the cloud and local VC databases, the holder can choose to designate one version as the "official copy" and update the other version accordingly. The holder can also send another request to the issuer to regenerate the VC. Due to the nature of their provenance, these VCs will automatically become the "official copy" and can be used to reconcile the stored records in the database accordingly.

[0095] Figure 8A -8B is an example flow chart of a holder obtaining a verifiable credential and generating a verifiable presentation based on the verifiable credential according to some embodiments.

[0096] Figure 8A An example process 800A is shown in which a holder retrieves a VC data object, which is a verifiable credential data object, and generates a VP based on the VC data object. Example process 800A is used for a cloud storage service. The VC data object is a verifiable credential data object. In step 802A, the verifier queries the holder's VC data object via a verification request. In step 804A, the holder hashes the query index.

[0097] In step 806A, the holder retrieves data from the credential index database 306A of the cloud storage. In step 808A, the holder uses the credential metadata object to query the credential index database 306A and retrieves the encrypted VC data object ID (ie, VCID) as a verifiable credential identification token.

[0098] In step 810A, the holder decrypts the VC data object ID. In step 812A, the holder uses the decrypted VC data object ID to retrieve the encrypted VC data object from VC database 304A and, in step 814A, uses the VC data object to generate a VP. The holder selectively discloses specific information within the VC, deciding which details to disclose and which to keep private. For example, the holder might provide proof of a degree certificate but withhold grade information. The holder then uses cryptographic techniques to create a VP containing their digital signature, ensuring that the displayed information is consistent with the original VC and has not been tampered with. The proof contained in the VP ensures the authenticity and integrity of the information.

[0099] In step 816A, the holder sends the VP to the verifier, completing the verification process. The verifier uses cryptographic tools to verify the authenticity and integrity of the VP, confirming that the holder owns the VC issued by the issuer, that the disclosed information matches the original VC, and that the VP is authorized and submitted by the holder.

[0100] Figure 8B An example process 800B is shown for a holder to retrieve a VC data object and generate a VP based on the VC data object. Example process 800B is used for local browser extension storage. In step 802B, the verifier queries the holder's VC data object via a verification request. In step 804B, the holder hashes the query index.

[0101] In step 806B, the holder queries the VCID from the claims index database 306B stored by the local browser extension. In step 808B, the holder retrieves the encrypted VC data object ID, which serves as a verifiable credential identification token. In step 810B, the holder decrypts the VC data object ID and the claims value and, in step 812B, uses the decrypted VC data object ID to retrieve the VC credential metadata object and issuer proof token (e.g., the digital signature described above) from the VC database 304B.

[0102] In step 814A, the holder decrypts the VC credential metadata object and the issuer proof token. In step 816B, the holder uses the VC credential metadata object, the issuer proof token, and the claim value to generate a VP. The holder selectively discloses specific information within the VC, deciding which details to disclose and which to keep private. The holder then uses cryptographic techniques to create a VP containing their digital signature, ensuring that the displayed information is consistent with the original VC and has not been tampered with. The proof contained in the VP ensures the authenticity and integrity of the information.

[0103] In step 818B, the holder sends the VP to the verifier, completing the verification process. The verifier uses cryptographic tools to verify the authenticity and integrity of the VP, confirming that the holder possesses the VC issued by the issuer, that the disclosed information matches the original VC, and that the VP was authorized and submitted by the holder. Through these steps, the holder can securely generate and submit the VP, ensuring that the verifier can trust the information provided, without requiring direct communication between the verifier and the issuer.

[0104] In a practical application scenario, the verifier could be a multinational financial institution established in countries A and B, and the holder could be a potential overseas customer of one of these financial institutions. The customer's identity information is issued by a government agency in country A. The customer has completed the identity verification or KYC ("Know Your Client / Customer") process in country A and successfully opened an account at a branch of the multinational financial institution in country A. The customer now wishes to open a new account at the same branch of the financial institution in country B. Using traditional methods, the customer can bring all necessary KYC documents or original identity documents to the branch of the financial institution in country B for identity verification. However, this traditional method encounters many issues, such as the fact that the branch in country B may not be able to verify the identity documents issued by the government agency in country A.

[0105] In the solution of the present invention, the branch of a financial institution in Country A acts as the issuer, verifies the documents issued by Country A and issues a VC to the customer. After receiving the VC, the customer encrypts and hashes the information and stores the corresponding information in the cloud-based VC database and VC index.

[0106] When a customer opens an account at a branch in Country B, they download the VC from the cloud, generate a VP according to the requirements of the Country B branch, and submit it for identity verification and KYC. Because the branches of financial institutions in Country A and Country B trust each other, the Country B branch trusts the VC (and subsequently generated VP) issued by the Country A branch. The financial institution in Country B can further verify that the information in the VP complies with its own KYC or other requirements to complete the customer's account opening process in Country B.

[0107] In this process, the actual data is carried and transferred across borders by the client (ownership of the VC belongs to the client, just as if the client were carrying their own ID card across borders), rather than being actively transferred across borders by the financial institution. There is no direct data transfer between branches of financial institutions in countries A and B, thus saving the costs associated with cross-border data transfer.

[0108] Since DID is usually implemented as a VC stored on the user's device (computer / mobile phone), if the device is lost, the user may need to reapply for VC from the branch of National Bank A. The solution of utilizing cloud storage in this invention effectively mitigates this risk and improves the user experience.

[0109] Although many of the steps in the examples are described as being done manually, in practice the process can be automated by an application such that the hashing, encryption, and query steps are automatically performed by the application, which then performs subsequent communication and verification with the verifier on the client's behalf.

[0110] The embodiments described herein eliminate the need for local persistent storage of VC data objects on the device. The proposed system can be used securely and conveniently across various platforms and devices, such as mobile applications, computer executables, browser extensions, and web platforms. If the user confirms that the terminal or platform has a secure storage environment (e.g., a mobile application), local secure storage can be used to cache VC data objects, reducing the amount of VC data that needs to be downloaded when generating a VP.

[0111] The embodiments described herein can be implemented using any client with local storage capabilities. While mobile operating systems provide relatively secure sandbox storage areas for applications, as well as secure storage areas based on biometric authentication technology, users can still use compromised mobile operating systems, leaving the system vulnerable to attacks. Therefore, the system proposed in this invention can provide enhanced security for any user's VC storage.

[0112] In some embodiments, a cloud database service that provides a relational database or NoSQL interface is required. The proposed system uses an end-to-end encryption scheme, making the data in the database publicly accessible to third parties. In some embodiments, one of the VC database and the credential index database is maintained on a decentralized service, while the other database is maintained on a private data service to enhance security. Examples of private database services include iCloud, Firebase Realtime Database, Firebase Firestore Database, etc. Firebase Realtime Database and Firebase Firestore Database provide software development kits (SDKs) for all major operating systems and platforms, while iCloud Database supports use on web platforms and Android operating systems by providing Javascript API / SDK.

[0113] Figure 9900 is a diagram of an example computer device, showing an example computer device based on the same system for implementing a secure storage system for verifiable credentials. As shown in the figure, the computer device 900 includes at least one processor 902, a memory 904, at least one I / O interface 906, and at least one network interface 908. These components can be connected in various ways, including direct coupling, indirect coupling through a network, and distributed in different geographical locations but connected through a network ("cloud computing"). The at least one processor 902 is coupled to the memory 904, and the memory 904 stores computer programs that can be executed by the at least one processor 902. When these computer programs are executed by the at least one processor 902, they can execute the storage and query methods for verifiable credentials in a decentralized identity system described above.

[0114] Figure 9 While only one computer device 900 is shown, the system may include multiple computer devices 900 operable by a user to access remote network resources and exchange data. Multiple computer devices 900 may be of the same or different types. For example, computer device 900 may be a server, a network appliance, a set-top box, an embedded device, a computer expansion module, a personal computer, a laptop computer, a personal data assistant, a cellular phone, a smartphone, a UMPC tablet computer, a video display terminal, a game console, an electronic reading device, a wireless hypermedia device, or any other computing device capable of executing the methods described herein. In some embodiments, the present invention may be implemented as a dedicated server computer or server computing device for securely managing the VC database and index database in a DID system.

[0115] Each processor 902 may be any type of general purpose microprocessor or microcontroller, digital signal processing (DSP) processor, integrated circuit, field programmable gate array (FPGA), reconfigurable processor, programmable read-only memory (PROM), or any combination thereof.

[0116] The memory 904 may include a suitable combination of any type of computer memory, whether located internally or externally, such as random access memory (RAM), read-only memory (ROM), compact disk read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), ferroelectric RAM (FRAM), etc.

[0117] Each I / O interface 906 enables the computing device 900 to be interconnected with one or more input devices (such as a keyboard, a mouse, a camera, a touch screen, and a microphone) or one or more output devices (such as a display screen and speakers).

[0118] Each network interface 908 enables the computer device 900 to communicate with other components, exchange data with other components, access and connect to network resources, provide services for applications, and execute other computing applications by connecting to a network (or multiple networks) capable of carrying data, including the Internet, Ethernet, plain old telephone service (POTS) lines, public switched telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optic, satellite, mobile, wireless (e.g., Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, etc., or any combination of these.

[0119] Computer device 900 can be used to register and authenticate users (e.g., using a login name, unique identifier, and password) before providing access to applications, local networks, network resources, other network and network security devices. Computer device 900 can serve one user or multiple users.

[0120] Embodiments of the present invention further provide a computer-readable medium storing computer program instructions that, when executed by a processor, can perform the above-described method for storing and querying verifiable credentials in a decentralized identity system. The specific method steps are not repeated here.

[0121] Applicants note that the described embodiments and examples are illustrative and non-restrictive. Actual implementations of features may incorporate combinations of some or all aspects, and the features described herein should not be considered indicative of future or existing product plans. Applicants engage in both fundamental and applied research, and in some cases, the features described have been developed on an exploratory basis.

[0122] Each of the processes, methods, and algorithms described above can be embodied in a code module executed by one or more computer systems or computer processors comprising computer hardware and implemented fully or partially automatically therewith. The processes and algorithms can be implemented partially or entirely in dedicated circuitry. The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and the blocks or states associated therewith may be performed in other appropriate orders. For example, the blocks or states described may be performed in an order different from that specifically disclosed, or multiple blocks or states may be combined in a single block or state. Examples of blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed embodiments. The examples of the systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged compared to the disclosed embodiments. Various changes, substitutions, and modifications to the embodiments do not depart from the scope.

[0123] The above discussion provides many example embodiments. Although each embodiment represents a single combination of inventive elements, other examples may include all possible combinations of the disclosed elements. Thus, if one embodiment includes elements A, B, and C, and a second embodiment includes elements B and D, then any remaining combination of A, B, C, or D may also be used.

[0124] The terms "connected" or "coupled to" may include direct coupling (where two coupled elements are in contact with each other) and indirect coupling (where at least one additional element is positioned between the two elements).

[0125] Those skilled in the art will appreciate that the present disclosure may utilize processes, machines, manufacture, compositions of matter, apparatus, methods, or steps, now known or later developed, that perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. The appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, apparatus, methods, or steps.

Claims

1. A method for decentralized identity verification or claim verification, comprising: The holder of the verifiable credential data object encrypts and uploads the verifiable credential data object including the credential metadata object, the claim information data object and the issuer certification token to a verifiable credential database, wherein the encrypted verifiable credential data object uniquely corresponds to a verifiable credential identification token in the verifiable credential database; The holder maintains a credential index database, the credential index database containing the encrypted verifiable credential identification token and the hashed credential metadata object; After receiving the verification request from the verifier, querying the credential index database using the credential metadata object to receive the verifiable credential identification token, the holder decrypting the verifiable credential identification token; The holder queries the verifiable credential database using the verifiable credential identification token to receive the verifiable credential data object, and the holder decrypts the verifiable credential data object; The holder generates a verifiable claim using the verifiable credential data object; The holder transmits the verifiable claim to the verifier, causing the verifier to receive the claim information data object and verify the claim information data object using the issuer certification token.

2. The method according to claim 1, wherein The credential metadata object includes a credential type and a credential mode that can verify the credential data object, and using the credential metadata object to query the credential index database includes the holder being able to query the credential index database using the credential type and the credential mode.

3. The method according to claim 1, wherein The issuer proof token includes a signature of the issuer, and verifying the claim information data object using the inventor proof token includes verifying, based on the signature, that the issuer is the author of the verifiable credential data object and that the verifiable credential data object has not been tampered with since issuance.

4. The method according to claim 2, wherein The hashed credential metadata object is obtained by hashing the issuer's decentralized identifier, credential type and credential mode, and the use of the credential metadata object to query the credential index database includes the holder querying the credential index database using a combination of the issuer's decentralized identifier, the credential type and the credential mode.

5. The method according to claim 1, wherein The verifiable credential data object in the verifiable credential database is further encrypted by a random symmetric encryption key, which is further encrypted by the holder's secret key and stored in the verifiable credential database.

6. The method according to claim 1, wherein The credential index database is stored in a cloud storage service.

7. The method according to claim 6, wherein The hashed credential metadata object is derived by hashing the issuer's decentralized identifier, credential type, credential mode, and a supplemental randomization token.

8. The method according to claim 1, wherein The credential index database is stored on the holder's device in the form of a local browser extension.

9. The method according to claim 8, wherein Further comprising encrypting the declaration data object containing the numerical value using an order-preserving encryption algorithm.

10. The method of claim 2, wherein: The first version of the verifiable credential database is stored on a cloud storage service, and the second version of the verifiable credential database is stored on the holder's device in the form of a local browser extension. The first version of the verifiable credential database and the second version of the verifiable credential database interface and update each other to reconcile any differences between the first version of the verifiable credential database and the second version of the verifiable credential database.

11. A computer device for performing decentralized identity verification or claim verification, the device comprising: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having a computer program stored thereon, the computer program being executable by the one or more processors to perform the method of any one of claims 1 to 10.

12. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: The computer program instructions, when executed by a processor, implement the method of any one of claims 1 to 10.

Images