Validation Requirements Document for Credentials Validation

Abstract

The present disclosure is directed to a method, associated apparatus, and computer-readable medium for credential validation using a Verification Requirements Document (VRD). The VRD credential validation ecosystem includes, but is not limited to, a VRD management system, a first credential management system, a second credential management system, a VRD issuing device, a verifier device, a distributed VRD transaction agreement network, and the distributed credential management transaction agreement network with necessary communications therebetween. The distributed VRD transaction agreement network maintains a distributed VRD ledger that records VRDs. Credential validation using a VRD is primarily performed by the first credential management system associated with the verifier and the second credential management system associated with the credential owner. The first credential management system retrieves the VRD from the distributed VRD transaction agreement network and transmits the VRD to the second credential management system. The second credential management system generates a proof through the distributed credential management transaction agreement network to verify the requirements specified in the VRD.

Description

[Technical field]

[0001] The present invention relates to a credential validation method and system, and more particularly to a method and system for managing a distributed verification requirement document (VRD) trading agreement network, and a method and system for requesting credential validation of a credential holder using a VRD stored on a distributed VRD trading agreement network. [Background technology]

[0002] Due to the popularity of blockchain technology, it seems that sooner or later digital credentials will become the overwhelming trend instead of traditional credentials when credential validation is required, possibly in most situations. With regard to digital credentials, traditional blockchain technology provides tools, libraries, and reusable components that support decentralized digital identities routed on a blockchain or other distributed system for validation of digital credentials.

[0003] While conventional credential management blockchains built for digital credential validation are available, such blockchains are not flexible enough for more customized validation requirements for verifiers. In view of the ubiquity of telecommunication carriers and globally recognized carrier services, a VRD credential validation ecosystem, ideally chosen to provide trusted credential validation with carrier-level parties, provides services for digital credentials through the telecommunication carriers. However, such a VRD credential validation ecosystem also has characteristics not available in conventional blockchains for digital credential management services. Summary of the Invention [Means for solving the problem]

[0004] The present invention is directed to a method and related apparatus, and computer-readable medium, for credential validation using a validation requirements document (VRD). The VRD credential validation ecosystem may include, but is not limited to, a VRD management system, a first credential management system, a second credential management system, a VRD issuing device, a verifier device, a distributed VRD transaction agreement network, and a distributed credential management transaction agreement network with necessary communication therebetween. The distributed VRD transaction agreement network maintains a distributed VRD ledger that records VRDs. VRD transactions published to the distributed VRD ledger include VRD operator registration transactions, VRD operator cancellation transactions, VRD issuer registration transactions, VRD issuer cancellation transactions, VRD registration transactions, VRD cancellation transactions, and VRD retrieval transactions.

[0005] Credential validation using the VRD is primarily accomplished by a first credential management system associated with the verifier and a second credential management system associated with the credential owner. The first credential management system retrieves the VRD from the distributed VRD transaction agreement system and transmits the VRD to the second credential management system. The second credential management system generates proofs through the distributed credential management transaction agreement network to validate the requirements specified in the VRD.

[0006] The objective of the present disclosure is to create a VRD and record a VRD in a distributed VRD ledger so that a verifier can choose an existing VRD for credential verification. To achieve the above objective, a first credential management system uses a verification requirements document (VRD) stored on a distributed VRD transaction agreement network to request credential verification of a credential holder. The method includes, when receiving a VRD ID and a credential holder identifier of a VRD from a verifier device, the first credential management system sends the VRD ID to the distributed VRD transaction agreement network to obtain a VRD, and sends the VRD and the credential holder identifier to a second credential management system, where the VRD includes at least one attribute, at least one predicate, or both at least one attribute and at least one predicate, together with requirements that define at least one type of credential for verifying each of the at least one attribute and each of the at least one predicate specified in the VRD.

[0007] In one embodiment, the method further includes the steps of the first credential management system receiving a proof from the second credential management system and verifying whether the proof satisfies requirements associated with each of the at least one attribute and at least one predicate specified in the VRD; when each requirement is satisfied, the first credential management system sending the proof and the at least one attribute and at least one predicate specified in the VRD to a distributed credential management transaction agreement network for validation; and upon receiving a validation response from the distributed credential management transaction agreement network, the first credential management system sending a credential validation result to the verifier device.

[0008] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0009] [Figure 1] FIG. 2 is a schematic diagram showing a system architecture related to VRD operation according to the present invention. [Diagram 2] 1 is a table illustrating various VRD transactions related to a distributed VRD transaction agreement network in accordance with the present invention. [Diagram 3] 1 is a table showing a data structure related to a VRD operator registration transaction. [Figure 4] 13 is a table showing a data structure related to a VRD operator cancellation transaction. [Diagram 5] 1 is a table showing data structures associated with a VRD issuer registration transaction. [Figure 6] 1 is a table showing data structures related to a VRD issuer revocation transaction. [Figure 7] 1 is a table showing data structures related to VRD registration transactions. [Figure 8] 8 is a table showing the data structures associated with each attribute and each predicate specified in the VRD registration transaction of FIG. 7. [Figure 9] 1 is a table showing a data structure related to a VRD cancellation transaction. [Figure 10] 2 is a flow chart illustrating a method for a first credential management system to request credential validation of a credential holder using a VRD stored on a distributed VRD transaction agreement network according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] The terminology used in the description presented below is intended to be interpreted in the broadest reasonable manner for that term, even if used in connection with a detailed description of certain specific embodiments in the art. Certain terms may be emphasized below, however, any terminology intended to be interpreted in any restrictive manner is specifically defined as such in this "Description of the Preferred Embodiments" section.

[0011] The embodiments described below may be implemented with programmable circuitry programmed or configured by software and / or firmware, or entirely with special purpose circuitry, or a combination of such forms, where such special purpose circuitry (if any) may take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), etc.

[0012] The described embodiments relate to one or more methods, systems, devices, and computer-readable media storing processor-executable process steps for validating a credential holder's credentials by using a data structure that records a Verification Requirements Document (VRD) issued by a VRD issuer, a credential type, and requirements. The VRD is stored in a distributed VRD ledger maintained by a distributed VRD transaction agreement network. The distributed VRD ledger may record one or more of the following transactions: VRD operator registration transactions, VRD operator cancellation transactions, VRD issuer registration transactions, VRD issuer cancellation transactions, VRD registration transactions, VRD cancellation transactions, and VRD retrieval transactions. In addition, the distributed credential management transaction agreement network maintains a distributed credential management ledger that provides and verifies proofs of credential requests.

[0013] The aforementioned processing steps are performed by a VRD credential validation ecosystem including a VRD administrator system, a first credential management system, a second credential management system, a verifier device, and a VRD issuing device, which systems and devices are communicatively connected to each other and to a distributed VRD transaction agreement network and a distributed credential management transaction agreement network to form a credential validation network.

[0014] To create a VRD manager, the VRD administrator publishes a VRD manager registration transaction on the distributed VRD ledger to register the VRD manager in the distributed VRD transaction agreement network. The VRD manager may revoke the VRD manager and remove the VRD manager from the distributed VRD transaction agreement network by publishing a VRD manager revocation transaction on the distributed VRD ledger. To create a VRD issuer, the VRD manager publishes a VRD issuer registration transaction on the distributed VRD ledger to register the VRD issuer in the distributed VRD transaction agreement network. The VRD manager may revoke the VRD issuer and remove the VRD issuer from the distributed VRD transaction agreement network by publishing a VRD issuer revocation transaction on the distributed VRD ledger. To create a VRD, a VRD issuer publishes a VRD registration transaction on the distributed VRD ledger. Each VRD includes a VRD ID and at least one attribute, at least one predicate, or both at least one attribute and at least one predicate. Each of the at least one attribute or at least one predicate specified in a VRD specifies a requirement to look for at least one credential for validation.

[0015] The key points of the verification are to obtain a VRD using a VRD ID provided by the verifier device, transfer the VRD and the user identifier from the first credential management system to the second credential management system, identify a set of credentials that satisfy each requirement specified in the VRD, send a handle to a wallet corresponding to the user identifier and a list of at least one attribute and at least one predicate specified in the VRD to the distributed credential management transaction agreement network, obtain a proof received from the distributed credential management transaction agreement network, send the proof to the first credential management system to verify it against the VRD, and after verification, send the proof and a proof request to the distributed credential management transaction agreement network, obtain a verification response from the distributed credential management transaction agreement network, and send the verification result to the verifier device.

[0016] VRDs are used to solve the inflexible credential validation services offered by traditional credential management blockchains. This approach requires a VRD scheme that originates from the VRD credential validation ecosystem to address the drawback of inflexibility. To protect against hacking, the VRD scheme may use a distributed VRD transaction agreement network dedicated to transactions involving VRDs and operations and data structures that handle the interactions between all parties engaged in VRD operations. The decentralized VRD transaction agreement network may be incorporated as part of an existing decentralized credential management transaction agreement network, such as the Hyperledger Indy Blockchain. In one embodiment, the decentralized VRD transaction agreement network may be a blockchain managed by an organization, such as TBCASoft, that can be traced back to a trusted source to ensure a level of authenticity.

[0017] To support VRD operations operating on the distributed VRD transaction agreement network, the VRD credential validation ecosystem includes a VRD administrator system, a number of credential management systems, a number of VRD issuing devices, and a number of verifier devices communicatively connected to each other. The VRD administrator system is provided by a VRD administrator such as TBCASoft. Each of the multiple credential management systems is provided by a credential manager, which may be a corresponding VRD operator registered by the VRD manager, or is a telecommunications operator, a verifier, and a credential owner. Each of the multiple VRD issuing devices is provided by a corresponding VRD issuer. Each of the multiple verifier devices is provided by a corresponding verifier associated with a corresponding credential manager. The collaborative links specified above are non-limiting examples of bilateral or multilateral relationships among all of the parties involved in the VRD credential validation ecosystem.

[0018] In terms of the roles of all the parties in the VRD credential validation ecosystem, a VRD administrator is entitled to register and revoke VRD operators, a VRD operator is entitled to register and revoke VRD issuers associated with it, a VRD issuer is entitled to register and revoke VRDs, a verifier is entitled to request credential validation of a credential holder using a VRD through a credential manager associated with it, and a credential manager associated with a credential holder may play the role of a verifier. As indicated above, a VRD operator in a VRD credential validation ecosystem essentially serves to establish a trust link between the VRD issuers and VRD administrators involved in order to provide a source of authority for verifiers. VRD issuers, in coordination with verifiers, undertake the task of configuring attributes / predicates with requirements that define the attributes / predicates in a VRD to facilitate registration of a VRD in the decentralized VRD transaction agreement network. Only the same VRD issuer that registered a VRD will be able to register subsequent versions of the VRD in the decentralized VRD transaction agreement network. Both VRD issuers and verifiers are intended to be involved in the task of configuring the desired attributes / predicates and requirements for VRDs to be registered in the decentralized VRD transaction agreement network.

[0019] As shown in FIG. 1, the VRD credential validation ecosystem may include, but is not limited to, a VRD management system 10, a first credential management system 20, a second credential management system 30, a VRD issuing device 40, a verifier device 50, a distributed VRD transaction agreement network 60, and a distributed credential management transaction agreement network 70 with necessary communications between these systems and devices, as specifically described below. The VRD administrator system 10 is provided by a VRD administrator to manage the operation of the distributed VRD transaction agreement network. The first credential management system 20 is provided by a first credential manager associated with a verifier. The first credential manager may be a telecommunication operator, a financial institution, a government agency, etc. In this embodiment, the first credential management system 20 includes a first VRD management node 21, a first distributed credential trading node 22, and a first local credential management node 23 that are communicatively connected. The first VRD management node 21 is responsible for all operations related to the distributed VRD transaction agreement network 60. The first distributed credential trading node 22 handles operations related to the distributed credential management transaction agreement network 70. The first local credential management node 23 handles local credential management of the first credential management system 20 and communication with the second credential management system 30. The second credential management system 30 is provided by a second credential manager associated with a credential owner (prover). In another embodiment, the first credential management system 20 includes one or two nodes that may perform all of the functions of the first VRD management node 21, a first distributed credential trading node 22, and a first local credential management node 23.

[0020] The second credential management system 30 includes a communicatively connected second VRD management node 31, a second distributed credential trading node 32, and a second local credential management node 33. The second VRD management node 31 is responsible for all operations related to the distributed VRD trading agreement network 60. The second distributed credential trading node 32 handles operations related to the distributed credential management trading agreement network 70. The second local credential management node 33 handles local credential management of the second credential management system 30 and communication with the first credential management system 20, for example through a secure TLS (Transport Layer Security) link. In another embodiment, the second credential management system 30 may include one or two nodes, the second distributed credential trading node 32, and the second local credential management node 33, which may perform all the functions of the second VRD management node 31.

[0021] In one embodiment, the first VRD management node 21 and the second VRD management node 31 may be nodes of a distributed VRD transaction agreement network 60. In another embodiment, the first credential management distributed agreement transaction node 22 and the second credential management distributed agreement transaction node 32 may be nodes of a distributed credential management transaction agreement network 70. The verifier device 50 is provided by a verifier associated with the first credential manager. The credential holder device is provided by a credential holder associated with the second credential manager. The VRD issuing device 40 is provided by a VRD issuer.

[0022] In one embodiment, the first VRD management node 31 may be provided by a first VRD operator separate from the first credential manager. In that situation, the first local credential manager node 23 may communicate with the distributed VRD transaction agreement network to retrieve the VRD. Similarly, the second VRD management node 31 may be provided by a second VRD operator separate from the second credential manager. In that situation, the second local credential management node 33 may communicate with the distributed VRD transaction agreement network to retrieve the VRD. Other VRD operators may provide additional VRD management nodes. After the VRD operator is published on the distributed VRD ledger by the VRD administrator, the VRD operator may publish the VRD issuer on the distributed VRD ledger. The VRD issuer may then publish the VRD on the distributed VRD ledger.

[0023] Figure 1 illustrates the VRD credential validation ecosystem with transactions and data related to the operation of a distributed VRD transaction agreement network, and credential validation using a VRD. Symbols a1, a2, b1, b2, c1, and c2 refer to the VRD operator, VRD issuer, and actions related to registration and revocation of a VRD, respectively. Symbols d1, d2, d3, e1, e2, e3, f1, f2, g1, and g2 refer to various data / information provided during credential validation using a VRD, respectively. The meaning of these symbols is described below. a1: VRD operator registration transaction a2:VRD operator cancellation transaction b1: VRD issuer registration transaction b2: VRD issuer cancellation transaction c1: VRD registered transactions c2: VRD cancellation transaction d1: VRD ID d2: Credential owner identifier d3:VRD e1 and e2: a list of attributes and predicates, and a credential identifier for each of the at least one selected credential e3: handle to the wallet f1: Proof f2:Failure indication g1: Validation response g2: Verification results

[0024] Referring to Figures 1 and 2, a distributed Verification Requirements Document (VRD) transaction agreement network that maintains a distributed VRD ledger includes a VRD management system provided by a VRD administrator, a first VRD management node provided by a first VRD operator, and a second VRD management node provided by a second VRD operator. The VRD management system, the first VRD management node, and the second VRD management are communicatively coupled. Like the distributed transaction agreement network, after the VRD transaction is validated by a predetermined agreement of the distributed VRD transaction agreement network, the VRD transaction is published in the distributed VRD ledger. In one embodiment, there are seven types of VRD transactions: VRD operator registration transaction, VRD operator cancellation transaction, VRD issuer registration transaction, VRD issuer cancellation transaction, VRD registration transaction, VRD cancellation transaction, and VRD removal transaction. The distributed VRD ledger records multiple VRDs, each of which includes a VRD ID, a VRD name, and at least one attribute and at least one predicate.

[0025] A decentralized VRD transaction agreement network begins with an initiation transaction that announces a VRD manager to the network. The VRD manager's DID is a globally unique identifier that identifies the VRD manager who can register the VRD operator identified by the VRD operator's DID on the decentralized VRD transaction agreement network. For example, the VRD manager's DID may be "vrd-admin-01".

[0026] As shown in Figure 2, the first type of VRD transaction is a VRD operator registration transaction. See Figure 3. The data structure of a VRD operator registration transaction includes fields consisting of a transaction type with a value such as 1, the public key and DID (Decentralized ID) of the VRD operator being registered, and the signature and DID of the VRD administrator. As shown by "a1" in FIG. 1, the VRD manager registration transaction created by the VRD manager is submitted from the VRD administrator system to the distributed VRD transaction agreement network. The VRD manager's signature can then be verified by the VRD manager's public key stored in the distributed VRD transaction agreement network. If there is a given agreement, the VRD manager registration transaction is published in the distributed VRD ledger. As a result, the VRD operator can register the VRD issuer. In addition, the VRD operator's public key is stored in the distributed VRD transaction agreement network for verifying the VRD operator's signature. The VRD operator's DID is a "string" data type and is a globally unique identifier that identifies the VRD operator in the distributed VRD transaction agreement network. For example, the VRD issuer's DID can be "vrd-operator-01". The VRD manager's signature is generated by encrypting a hash value that hashes all other fields of the VRD operator registration transaction with the VRD manager's private key.

[0027] As shown in Figure 2, the second type of VRD transaction is a VRD operator cancel transaction. See Figure 4. The data structure of a VRD operator cancel transaction includes fields consisting of a transaction type with a value such as 2, the DID of the registered VRD operator, and the DID and signature of the VRD administrator. The VRD administrator signature is generated by encrypting a hash value that hashes all of the other fields of the VRD operator cancel transaction with the VRD administrator's private key. As shown by "a2" in Fig. 1, a VRD operator revocation transaction is created by the VRD administrator and submitted from the VRD management system to the distributed VRD transaction agreement network, and the signature of the VRD administrator can be verified by the VRD administrator's public key stored in the distributed VRD transaction agreement network. If there is a given agreement, the VRD operator revocation transaction is published in the distributed VRD ledger. An already registered VRD operator, identified by the VRD operator's DID, is then revoked by the VRD administrator, identified by the DID of the VRD administrator who registered the VRD operator. As a result, the VRD operator can no longer register VRD issuers.

[0028] As shown in Figure 2, a third type of VRD transaction is a VRD issuer registration transaction. See Figure 5. The data structure of a VRD issuer registration transaction includes fields for a transaction type with a value, such as 3, the public key and DID of the VRD issuer being registered, and the signature and DID of the VRD operator registering the VRD issuer. As shown by "b1" in FIG. 1, a VRD issuer registration transaction is created by a VRD operator and then submitted to the distributed VRD transaction agreement network. In one embodiment, the VRD operator may be the first credential manager that provides the VRD management node 21. The signature of the VRD operator can then be verified by the public key of the VRD operator stored in the distributed VRD transaction agreement network. If there is a given agreement, the VRD issuer registration transaction is published in the distributed VRD ledger. As a result, the VRD issuer can register the VRD. In addition, the public key for the VRD issuer is stored in the distributed VRD transaction agreement network to verify the signature of the VRD issuer. The DID of the VRD issuer is a "string" data type and is a globally unique identifier that identifies the VRD issuer. For example, the DID of the VRD issuer may be "vrd-issuer-01". The signature of the VRD operator registering the VRD issuer is generated by encrypting a hash value that hashes all other fields of the VRD issuer registration transaction with the private key of the VRD operator. In this embodiment, the VRD operator who registers the VRD issuer is the first credential manager that provides the first credential management system 20 as shown in Figure 1. A party sensitive to the authenticity of the VRD issuer can use the distributed VRD transaction agreement network 60 to look up the VRD issuer's DID to verify that the VRD issuer is indeed a valid VRD issuer registered by a valid VRD operator.

[0029] As shown in FIG. 2, the fourth type of VRD transaction is a VRD issuer revocation transaction. See FIG. 6. The data structure of the VRD issuer revocation transaction includes fields consisting of a transaction type with a value such as 4, the DID of the registered VRD issuer, and the DID and signature of the VRD operator who registered the VRD issuer. The signature of the VRD operator who registered the VRD issuer is generated by encrypting a hash value that hashes all the other fields of the VRD issuer revocation transaction with the private key of the VRD operator who registered the VRD issuer. In this embodiment, the VRD operator who registered the VRD issuer is the first credential manager. As shown by "b2" in Fig. 1, a VRD issuer revocation transaction is created by the first credential management system and submitted to the distributed VRD transaction agreement network. The VRD manager's signature can then be validated by the first credential manager's public key stored in the distributed VRD transaction agreement network. If there is a given agreement, the VRD issuer revocation transaction is published in the distributed VRD ledger. An already registered VRD issuer, identified by the VRD issuer's DID, is then revoked by the VRD operator who registered the VRD issuer. As a result, the VRD issuer can no longer register VRDs.

[0030] A fifth type of VRD transaction is a VRD registration transaction. See Figure 7. The data structure of each of the at least one VRD registration transaction includes fields consisting of a transaction type with a value, such as 5, a VRD ID, a VRD name, and at least one of the version of the VRD being created, at least one attribute and at least one predicate, the ID of the VRD operator who is registering the VRD issuer in the decentralized VRD transaction agreement network, and the DID and signature of the VRD issuer. The VRD ID is a "string" data type and is a unique identifier, e.g., "vrd-sprint-0000001". The VRD name is a "string" data type and is made meaningful for verification, e.g., "Drinking Age". The VRD version is a "real" data type and represents the version of the VRD, e.g., 1.0 for version 1.0. The VRD operator ID is of a "string" data type. For example, the VRD operator ID may be "Sprint", which in one embodiment is the name of the telecommunications operator that acts as the VRD operator. In one embodiment, the VRD operator ID is used to route the request to the specific VRD operator that registered the VRD issuer. In this situation, the VRD issuer's wallet is stored at the VRD operator's site. As a result, only the VRD operator has access to the VRD issuer's wallet key to sign transactions.

[0031] The VRD issuer's signature on a VRD registration transaction is generated by encrypting a hash value that hashes all other fields of the VRD registration transaction with the VRD issuer's private key. As shown by "c1" in Figure 1, a VRD registration transaction is created by the VRD issuer and then submitted to the distributed VRD transaction agreement network from the VRD issuing device. The VRD issuer's signature can then be verified by the VRD issuer's public key stored in the distributed VRD transaction agreement network. If there is a given agreement, the VRD registration transaction is published in the distributed VRD ledger. As a result, the VRD can be retrieved by a verifier.

[0032] To support self-sovereign identity, in one embodiment, the VRD issuer's private key can be split into multiple shared keys. The multiple shared keys can be stored in a VRD operation device provided by the VRD operator (in this embodiment, a first credential management system provided by the first credential manager) and a VRD issuing device provided by the VRD issuer, respectively. The VRD issuer's private key can be reconstructed by combining the shared keys held by the VRD issuer and the first credential manager according to a secret sharing scheme. In this situation, the VRD issuer's shared key must be combined with the VRD operator's shared key to reconstruct the VRD issuer's private key before creating a VRD issuance transaction. The VRD issuer's signature can be generated using the reconstructed private key at the first credential manager. In one embodiment, the secret sharing scheme is Shamir's secret sharing scheme. After submitting the VRD registration transaction to the distributed VRD transaction agreement network 60, the VRD issuer's signature can be verified by the VRD issuer's public key in the distributed VRD transaction agreement network 60. The registered VRD, represented by the VRD ID, is then published by the VRD issuer to the distributed VRD ledger. The difference between each VRD stored in the distributed VRD transaction agreement network 60 and the VRD registration transaction for that VRD is that the VRD itself does not have a field for the VRD issuer's signature.

[0033] The following description may be accompanied by examples of attributes, predicates, and attribute and predicate-related requirements that are provided for illustrative purposes only: Each VRD registration transaction or each VRD may be configured to have only at least one attribute, only at least one predicate, or both at least one attribute and at least one predicate simultaneously. See Figure 8. Each of the at least one attribute specifies an attribute of the at least one identified credential of the credential owner and includes subfields consisting of requirements, an attribute name, and a publishing option.

[0034] An attribute requirement describes at least one search condition that identifies at least one credential that contains the attribute. In one embodiment, at least multiple conditions of an attribute requirement may be combined with at least one Boolean operator. Each search condition of a requirement is intended to specify a credential type by a specific type of schema ID, such as {schema_id=1}, or a specific type of credential ID, such as {credential_definition_id=7}, or a credential issued by a specific credential issuer, such as {issuer id=5}. When a VRD has one search condition, for example an attribute, such as "first name", with {schema id=1} that specifies a US driver's license regardless of state, the VRD requires verification of the first name (attribute) of the credential holder's US driver's license (credential with specific schema id). When an attribute requirement has only one search condition, no Boolean operator is required. However, when an attribute requirement, e.g., “date of birth” has multiple search criteria, e.g., {credential_definition_id=1}, {credential_definition_id=2}, and {issuer_id=3}, the VRD requires validation of the date of birth (attribute) of credentials that meet all three search criteria. Multiple search conditions may be combined with one or more Boolean operators, such as "AND" and "OR", according to the need for validation. As an example of multiple search conditions combined with Boolean operators, {credential_definition_id=1 OR [credential_definition_id=2 AND issuer_id=3]} is interpreted as requiring the date of birth of a credential where credential_definition_id is equal to 1, which is a California driver's license, or the date of birth of a credential where credential_definition_id is equal to 2 and issuer_id is equal to 3, which is a New York driver's license issued by the New York DMV (Department of Motor Vehicles), for validation. That is, the VRD requires the validation of the date of birth from the credential holder's California driver's license or New York driver's license issued by the New York DMV. In this example, either one of these two credentials satisfies the three search conditions combined by the two Boolean operators, and the date of birth from either credential can be used for validation.

[0035] An attribute name with a "string" data type specifies a particular type of attribute, such as name, date of birth, social security number, passport number, employer, etc. A reveal option associated with an attribute name is a Boolean value, TRUE or FALSE, configured to allow or disallow revealing the value or contents of the attribute. In one embodiment, the default value of the reveal option is FALSE. For example, if the attribute name is "date of birth" and the reveal option is TRUE, then the date of birth contents of the identified credential will be revealed in the attestation.

[0036] Each predicate in the VRD requires verification that a predicate character derived from or associated with an attribute of the identified credential satisfies a validation condition. A validation condition is the nature of a comparison relationship to a given value. For example, a predicate (age >= 21) should require verification of an age (predicate character) derived from a date of birth (predicate attribute) on a driver's license (identified credential) to be 21 or greater (validation condition). Validation conditions further include the nature of a comparison relationship (predicate value) such as greater than ">", equal to "=", less than "<", greater than or equal to "≥", and less than or equal to "≤", as well as a predicate value that is a given numeric value (predicate value). Other predicates include "age < 65", where "< 65" is a validation condition, and "education degree >= 3", where "≥ 3" is a validation condition requiring verification of a minimum master's degree denoted by 3.

[0037] Further referring to FIG. 8 , each of the at least one predicate includes subfields consisting of requirement, predicate name, predicate character, predicate value, and predicate type. In one embodiment, each predicate further includes a subfield of predicate attribute from which the value of the predicate character is derived. The requirements on the predicate are similar to the requirements on the attributes, and therefore will not be repeated here. The attribute name is of “string” data type and is created to convey the meaning of the predicate, for example “age verification”. The predicate character in the predicate is of “string” data type and specifies a character derived from or related to an attribute of at least one credential identified by the requirement. For example, the predicate character “age” in the predicate “age<65” can be derived from the predicate attribute “date of birth”. The predicate value is of “integer” data type and specifies a value to be compared with the value of the predicate character derived from the attribute, such as 65 in the predicate above. The predicate type is a "string" data type that specifies the nature of the comparison relationship between the value of the predicate character and the predicate value derived from the attributes of the identified credential, such as the less than "<" in the predicate above.

[0038] Predicate requirements function substantially the same as attribute requirements. When a predicate requirement has one search condition that identifies at least one credential that encompasses the attribute used to derive the value of the predicate string. For example, a requirement for the predicate "age < 65" has one search condition "schema_id=1" that is a state-independent U.S. driver's license. The date of birth on the credential holder's U.S. driver's license is used to derive the value of age compared to 65. Such a predicate in the VRD requires that the credential holder's validation derived from the credential holder's U.S. driver's license is less than 65. When a predicate requirement has multiple search conditions, such as {credential_definition_id=1 OR [credential_definition_id=2 AND issuer_id=3]}, the VRD requires validation of the age (predicate string) derived from the date of birth (attribute) of the credential that meets all three search conditions. Multiple search criteria may be combined with one or more Boolean operators, such as "AND" and "OR", depending on the need for validation. As an example of multiple search criteria combined with Boolean operators, {credential_definition_id=1 OR [credential_definition_id=2 AND issuer_id=3]} is interpreted as requiring, for age validation, the date of birth of the credential where credential_definition_id is equal to 1, which is a California driver's license, or the date of birth of the credential where credential_definition_id is equal to 2 and issuer_id is equal to 3, which is a New York driver's license issued by the New York DMV. That is, the VRD should use the date of birth from the credential holder's California driver's license or New York driver's license issued by the New York DMV for validation of the age predicate.

[0039] One advantage of the present invention is that it provides a more flexible and efficient approach to setting attribute or predicate related requirements for credential validation, since multiple search criteria can be combined using both AND and OR Boolean operators.

[0040] A sixth type of VRD transaction is a VRDCancel transaction. See Figure 9. The data structure of each VRDCancel transaction includes fields consisting of a transaction type with a value such as 6, the VRD issuer's DID and signature, and the ID of the VRD being cancelled. The VRD issuer's signature on a VRDCancel transaction is generated by encrypting a hash value that hashes all of the other fields of the VRDCancel transaction with the VRD issuer's private key. As indicated by "c2" in Fig. 1, a VRD cancellation transaction is created by the VRD issuer and submitted from the VRD issuing device to the distributed VRD transaction agreement network 60. The VRD issuer's signature can then be verified in the distributed VRD transaction agreement network 60 by the VRD issuer's public key. If there is a given agreement, the VRD cancellation transaction is published in the distributed VRD ledger. The VRD identified by the ID of the VRD to be cancelled is then removed from the distributed VRD transaction agreement network 60 by the VRD issuer identified by the VRD issuer's DID. As a result, the cancelled VRD can no longer be used by the verifier.

[0041] A seventh type of VRD transaction is a VRD retrieval transaction. The data structure of each VRD retrieval transaction includes fields consisting of a transaction type with a value, such as 7, and a VRD ID. As shown in FIG. 1 by "d1", a VRD retrieval transaction is submitted to the distributed VRD transaction agreement network from a first credential management system 20 provided by a first credential manager associated with the verifier. As a result, the VRD is returned from the distributed VRD transaction agreement network 60 to the first credential management system 20 by "d2" shown in FIG. 1.

[0042] After the distributed VRD transaction agreement network is formed and the VRD is recorded therein, the method of using the VRD to verify credentials will be discussed in detail below. A first credential management system associated with a verifier communicates with the distributed VRD transaction agreement network and the distributed credential management transaction agreement network to interact with a second credential management system associated with a credential owner (prover) to verify the credential of the credential owner. 1 and 10, a method is provided for a first credential management system to request credential verification of a credential holder using a VRD stored on a distributed VRD transaction agreement network, the method including the following steps:

[0043] Step S310: Upon receiving the VRD ID and credential owner identifier marked by d1 and d2, respectively, from the verifier device 50, the first credential management system 20 transmits the VRD ID included in the VRD retrieval transaction to the distributed VRD transaction agreement network 60 to obtain a VRD shown as d3, and then transmits the VRD and credential manager identifier to the second credential management system 30, as shown in FIG. 1. The VRD includes at least one attribute, at least one predicate, or both at least one attribute and at least one predicate. Each attribute and each predicate has its own requirements that define at least one type of credential to verify such attribute and predicate specified in the VRD.

[0044] Specifically, when a credential holder approaches the verifier with a verifier device 50, the verifier device 50 receives a credential holder identifier from the credential holder and provides a VRD ID and a credential holder identifier to the first credential management system 20. Each verifier device 50 may use a dedicated VRD ID for a credential holder, or may use multiple VRD IDs for different groups of credential holders and / or for different verification purposes, respectively. When using a dedicated VRD ID, the verifier device 50 always transmits the same VRD ID. When using multiple VRD IDs, the verifier device 50 provides the corresponding VRD ID to the first credential management system 20 based on the group of credential holders and / or the verification purpose. In one embodiment, the verifier device 50 further provides the version of the VRD. As shown in FIG. 1, the first credential management system 20 then sends the VRD ID to the distributed VRD transaction agreement network 60, retrieves the VRD (d3) from the distributed VRD transaction agreement network 60 using the VRD ID, and sends the VRD (d3) and the credential owner identifier (d2) to the second credential management system 30. The credential owner identifier includes the credential owner ID and the identifier of the second credential management system 30 associated with the credential owner. As a result, the first credential management system 20 can identify the second credential management system 30 based on the credential owner identifier, and then sends the VRD and the credential owner identifier to the second credential management system 30. In one embodiment, the first credential management system 20 further sends a certification request to the second credential management system 30 based on the attributes and predicates defined in the VRD. The certification request specifies which attributes must be included in the certification and demonstrates the existence of credentials that each contain the specified attributes. However, the certification request does not place any requirements on the credentials that can be used in the certification request.

[0045] As previously indicated, each VRD may be configured to include at least one attribute, at least one predicate, or both at least one attribute and at least one predicate. Each of the at least one attribute includes an attribute name and a requirement identifying at least one predicate of the credential holder that encompasses the attribute. Each of the at least one predicate in the VRD includes a predicate attribute (an attribute from which a predicate character can be derived) and a requirement identifying at least one credential of the credential holder that encompasses the predicate attribute to determine whether a validation condition of the predicate is satisfied.

[0046] Step S320: The first credential management system 20 receives a proof from the second credential management system 30, and then checks whether the proof satisfies the requirements associated with each of the at least one attribute and at least one predicate specified in the VRD.

[0047] Specifically, after receiving the VRD ID from the first credential management system 20, the second credential management system 30 generates a list of attributes and predicates, including an attribute name for each of the at least one attribute and a predicate attribute for each of the at least one predicate specified in the VRD. The second credential management system 30 determines the credential owner from the credential owner identifier, including the credential owner ID, and then searches the credential owner's wallet for credentials that satisfy the requirements corresponding to each attribute and each predicate. The credential owner's credentials are encrypted and stored in a local database in a concept known as a wallet. In another embodiment, the credential owner's wallet can be managed by a third party or by the credential owner himself. The second credential owner management system searches through the credential owner's wallet by accessing a local database to locate at least one credential that satisfies the requirements specified in the VRD.

[0048] The second credential management system 30 then creates a proof based on the proof request and those credentials selected through the distributed credential management transaction agreement network 70. As shown in FIG. 1, the second credential management system 30 sends the proof request, the attribute and predicate list (e1???), the credential identifier (e2???) of each of the at least one selected credential, and the handle to the credential owner's wallet to the distributed credential management transaction agreement network 70. The handle to the credential owner's wallet can be used to access the credential owner's credential. Along with the attributes and values, the credential includes the credential owner, the issuer, and a "link secret" that is a mathematical value derived from the credential owner's and credential issuer's public keys stored on the distributed credential management ledger for the schema and credential definition. The second credential management system 30 then receives the proof (f1) returned from the distributed credential management transaction agreement network 70.

[0049] In one embodiment, the Hyperledger Indy SDK is used to construct a proof that uses both the link secret stored in the local credential and the public keys of the credential owner and credential issuer found in the distributed credential management ledger to construct a zero-knowledge proof.

[0050] In one embodiment, a zero knowledge proof (ZKP) is created for each requested attribute and predicate specified in the VRD. These ZKPs can be verified by looking up the credential owner's and credential issuer's public keys found in the distributed credential ledger. Each ZKP proves that the credential owner's credential is valid and has not been revoked. In addition to the zero knowledge proof, the proof includes the plaintext and / or value of each attribute requested to be revealed by the reveal option in the VRD. For example, if "Name" (attribute) is requested to be revealed, "John Doe" (the plaintext of the attribute) is included in the proof. The plaintext and / or value of each attribute is obtained directly from the credential.

[0051] Besides the at least one zero-knowledge proof, the proof further includes a credential identifier for each selected credential. If no credential of the credential owner can be identified that satisfies the requirements of each of the at least one attribute and at least one predicate specified in the VRD, the second credential management system 30 simply sends a failure indication (f2) to the first credential management system 20 without performing any processing related to the proof. Otherwise, the second credential management system 30 sends the proof to the first credential management system 20.

[0052] The first credential management system 20 receives a certificate from the second credential management system 30. The certificate includes at least one credential identifier that identifies at least one selected credential that contains an attribute or predicate attribute specified in the VRD. The first credential management system 20 checks to see if the at least one credential indicated by the at least one credential identifier in the certificate satisfies the requirements of each of the at least one attribute and at least one predicate specified in the VRD. Such a check is performed solely by the first credential management system 20. However, the first credential management system 20 does not check whether the credential owner actually possesses at least one selected credential that is valid and not revoked.

[0053] Step S330: Upon satisfying each requirement, the first credential management system 20 sends the proof and at least one of the at least one attribute and at least one predicate specified in the VRD to the distributed credential management transaction agreement network for validation.

[0054] Specifically, when each requirement is satisfied, the first credential management system 20 sends the proof (f1) and the attribute name of each of the at least one attribute and the predicate attribute of each of the at least one predicate specified in the VRD that is identical to the list of attributes and predicates (e1) generated in the second credential management system 30 to the distributed credential management transaction agreement network 70 for validation.

[0055] Upon receiving an indication of failure, the first credential management system 20 sends a verification result of failure to the verifier device 50 indicating that the credential holder does not have any credentials that satisfy the requirements of at least one attribute and at least one predicate specified in the VRD, and terminates the remaining steps of the method.

[0056] Step S340: Upon receiving the verification response from the distributed credential management transaction agreement network, the first credential management system 20 sends the credential verification result to the verification device 50.

[0057] Specifically, upon receiving the verification response (g1) from the distributed credential management transaction agreement network 70, the first credential management system 20 transmits a verification result (g2) to the verification device 50. Being mathematical values, each of the at least one zero-knowledge proof for the corresponding attribute name and the corresponding predicate attribute in the proof can be validated against the credential owner and the credential issuer public keys stored on the distributed credential management transaction agreement network 70 with respect to the credential owner, the credential issuer, and the schema and certificate definitions associated with the at least one credential in the proof. Validation of each zero-knowledge proof produces a Boolean value TRUE or FALSE, indicating that the at least one credential containing the attribute of the corresponding attribute or the attribute of the corresponding predicate is valid and has not been revoked. The verification response includes a Boolean value indicating the validation result of each zero-knowledge proof. For example, if the VRD includes an attribute name of an attribute, e.g., "First Name", and a credential identified by the attribute requirement, e.g., {schema_id=1}, which is a US driver's license, a TRUE value of the corresponding zero-knowledge proof validation means that the credential owner owns a US driver's license credential that includes a valid and not revoked first name. Moreover, if the predicate is "Age<65", and a credential identified by the predicate requirement, e.g., {schema_id=1}, which is a US driver's license, a FALSE value of the corresponding zero-knowledge proof validation means that the US driver's license credential is not valid or has been revoked. Based on the verification response, the verification result is then sent from the first credential management system 20. The verification result can also be a Boolean value, i.e., TRUE for passing the verification, and FALSE for failing the verification specified in the VRD. In another embodiment, the verification result can be a customized report with the verification response modified according to the verifier's request.

[0058] Although numerous features and advantages of the present invention have been set forth in the foregoing description, together with details of the structure and function of the invention, the disclosure is merely illustrative, and changes may be made in details, particularly with regard to shape, size, and arrangement of parts, within the scope of the principles of the invention to the fullest extent indicated by the broad general meaning of the terms as expressed in the appended claims.

Claims

1. 1. A method for a first credential management system to request credential verification of a credential holder using a distributed verification requirement document (VRD) stored on a transaction agreement network, the method comprising: (a) upon receiving a VRD ID and a credential owner identifier of the VRD from a verifier device, the first credential management system retrieves the VRD by sending the VRD ID to the distributed VRD transaction agreement network, and sends the VRD and the credential owner identifier to a second credential management system, the VRD includes at least one attribute, at least one predicate, or both at least one attribute and at least one predicate, together with requirements defining at least one type of credential for verifying each of the at least one attribute and each of the at least one predicate specified in the VRD, method.

2. 2. The method of claim 1, further comprising: (b) the first credential management system receiving a proof from the second credential management system and verifying whether the proof satisfies requirements associated with each of the at least one attribute and the at least one predicate specified in the VRD; (c) upon satisfying each of the requirements, the first credential management system sending the proof and at least one of the at least one attribute and the at least one predicate specified in the VRD to a distributed credential management transaction agreement network for validation; and (d) upon receiving a validation response from the distributed credential management transaction agreement network, the first credential management system sending a credential validation result to the verifier device.

3. 3. The method of claim 2, further comprising the steps of: the second credential management system selecting at least one credential of the credential holder that satisfies the requirements of each of the at least one attribute and the at least one predicate specified in the VRD; transmitting the at least one attribute and each of the at least one predicate specified in the VRD and a credential identifier of each of the at least one selected credential to the distributed credential management transaction agreement network; and transmitting the proof received from the distributed credential management transaction agreement network to the first credential management system.

4. 2. The method of claim 1, wherein the credential holder identifier comprises a credential holder ID and an identifier of the second credential management system associated with the credential holder.

5. 3. The method of claim 2, wherein the VRD has fields consisting of the VRD ID, a VRD name, at least one of the at least one attribute and the at least one predicate, and a DID of a VRD issuer.

6. 6. The method of claim 5, wherein each of the at least one attribute includes a corresponding requirement, an attribute name, and a publishing option, the corresponding requirement defining at least one type of credential of the credential holder and including at least one search condition.

7. 7. The method of claim 6, wherein the at least one search criterion comprises multiple search criteria joined by an OR Boolean operator.

8. 3. The method of claim 2, wherein each of the at least one predicate specified in the VRD includes a corresponding requirement, a predicate name, a predicate character, a predicate attribute, a predicate value, and a predicate type, the corresponding requirement defining the at least one type of credential of the credential holder, and including at least one search condition.

9. 9. The method of claim 8, wherein the at least one search criterion comprises multiple search criteria joined by an OR Boolean operator.

10. 3. The method of claim 2, wherein the proof includes a zero-knowledge proof corresponding to each of the at least one attribute and the at least one predicate specified in the VRD for verifying that the selected credentials are valid and have not been revoked.

11. 7. The method of claim 6, wherein when the disclosure option for any one of the at least one attribute specified in the VRD allows the specified attribute to be revealed, the attestation includes a value or content of the specified attribute.

12. 7. The method of claim 6, wherein when the publishing option of any one of the at least one attribute specified in the VRD allows the specified attribute to be revealed, the credential validation result includes a value or content of the specified attribute.

13. The method of claim 2 , wherein the distributed VRD transaction agreement network and the distributed credential management transaction agreement network are blockchains.

14. 3. The method of claim 2, wherein the distributed VRD transaction agreement network and the distributed credential management transaction agreement network are separate networks.

15. 3. The method of claim 2, wherein the distributed VRD transaction agreement network is integrated into the distributed credential management transaction agreement network.

16. 1. A distributed Verification Requirements Document (VRD) transaction agreement network that maintains a distributed VRD ledger, comprising: A VRD management system provided by a VRD manager; a first VRD management node provided by a first VRD operator; A distributed VRD transaction agreement network comprising: a second VRD management node provided by a second VRD operator; the VRD management system, the first VRD management node, and the second VRD management node are communicatively connected; After the validity of the VRD transaction is confirmed by a predetermined consensus of the distributed VRD transaction consensus network, the VRD transaction is published in the distributed VRD ledger; The VRD transaction is one of a VRD operator registration transaction, a VRD operator cancellation transaction, a VRD issuer registration transaction, a VRD issuer cancellation transaction, a VRD registration transaction, a VRD cancellation transaction, and a VRD withdrawal transaction; The distributed VRD ledger records a number of VRDs; Each VRD has fields consisting of a VRD ID, a VRD name, at least one of at least one attribute and at least one predicate, and a DID of a VRD issuer. Decentralized VRD transaction consensus network.

17. 17. The network of claim 16, wherein the VRD operator registration transaction comprises a public key and DID of the VRD operator, and a DID and signature of a VRD administrator announcing the VRD operator.

18. 17. The network of claim 16, wherein the VRD operator cancellation transaction comprises a DID of a VRD operator and a DID and signature of a VRD administrator who registered the VRD operator and is canceling the VRD operator.

19. 17. The network of claim 16, wherein the VRD issuer registration transaction comprises a public key and DID of a VRD issuer, and a DID and signature of a VRD operator announcing the VRD issuer.

20. 17. The network of claim 16, wherein the VRD issuer revocation transaction includes a DID of the VRD issuer and a DID and signature of a VRD operator who registered the VRD issuer and is revoking the VRD issuer.

21. 17. The network of claim 16, wherein the VRD registration transaction has fields consisting of a VRD ID, a VRD name, at least one of at least one attribute and at least one predicate, and a VRD issuer's DID and signature.

22. 17. The network of claim 16, wherein the VRD cancellation transaction has fields consisting of the signature and DID of the VRD issuer who registered the VRD, and the ID of the registered VRD.

23. 22. The network of claim 21, wherein each of the at least one attribute specified in the VRD registration transaction includes a corresponding requirement, an attribute name, and a publication option, the corresponding requirement defining at least one type of credential of a credential holder and including at least one search criterion.

24. 24. The network of claim 23, wherein the at least one search criterion comprises multiple search criteria joined by an OR Boolean operator.

25. 22. The network of claim 21, wherein each of the at least one predicate specified in the VRD registration transaction includes a corresponding requirement, a predicate name, a predicate character, a predicate attribute, a predicate value, and a predicate type, the corresponding requirement defining at least one type of credential of a credential holder and including at least one search condition.

26. 26. The network of claim 25, wherein the at least one search criterion comprises multiple search criteria joined by an OR Boolean operator.

27. The network of claim 16, wherein the distributed VRD transaction agreement network is a blockchain.

Images