HK40124108A - Verification of digital credentials and digital signatures - Google Patents

Description

Verification of digital credentials and digital signatures

Technical Field

This invention relates to methods and systems for verifying credentials and signatures, and more specifically, to methods and systems for verifying the digital signatures and digital credentials of signatories when signing documents, as well as the digital signatures and digital credentials of certifiers requesting authentication of digital credentials.

Background Technology

A Certificate Authority (CA) is an organization that verifies identities and binds them to digital certificates using a pair of cryptographic keys. As the most commonly used method of public key infrastructures (PKIs) for networks, any issuing entity within a CA is an entity that issues a digital certificate, which authenticates ownership of the public key through the certificate's named subject. The CA hierarchy begins at the top with the root CA, followed by several intermediate CAs. The root CA issues intermediate CA certificates, which in turn issue certificates to other CAs below that level, or sign end entity certificates.

A Certificate Authority (CA) acts as a trusted third party, authorizing public keys to entities within a network. Most network services are secure thanks to keys signed by a CA.

Because it is a single-dominated trust hierarchy, this CA hierarchy suffers from problems and limitations because the online identities of entities within the CA hierarchy need to be verified by the CA itself or an intermediate CA within the CA hierarchy, sometimes a private company or government. Another issue is that when issuing certifications to entities/organizations, the CA must personally verify the entity/organization's identity to ensure that the entity/organization they are certifying is indeed the entity they claim to be certifying. This step is often referred to as the Know Your Customer (KYC) process. Traditionally, when an entity needs to apply for multiple certifications from different CAs, the KYC process needs to be repeated for each application. Furthermore, this centralized trust hierarchy is vulnerable to a single point of failure occurring at either the intermediate CA or the end entity, and could have catastrophic consequences if compromised, as illustrated by the DigiNotar case.

Summary of the Invention

The purpose of this invention is to provide a method and system for issuing digital certifications and electronically signed documents, which can eliminate the KYC process and single point of failure in CA systems and improve the security of digital identity verification.

To achieve the above objectives, methods for issuing authentication-type digital credentials include:

The authentication issuing entity receives a request for a digital credential of the authentication type from the authentication request entity, wherein the request for the digital credential of the authentication type contains a public key generated by the authentication request entity;

The issuing entity sends a request to the requesting entity for its existing digital credentials.

The issuing entity sends a request to the requesting entity for its existing digital credentials.

The issuing entity verifies whether the existing digital certificate has been verified and whether the requesting entity is authorized to endorse the existing digital certificate. When the existing digital certificate is verified as verified and the requesting entity is authorized to endorse it, the issuing entity generates a digital certificate of that authentication type containing the public key of the requesting entity.

The issuing entity sends the digital credential of that type of authentication to the requesting entity.

In one embodiment, to verify whether the existing digital credential has been verified and whether the authentication requesting entity is authorized to endorse the existing digital credential, the method further includes:

Initialize the current credential and its owner to the existing digital credential and the authentication request entity, respectively.

Determine whether the current credential is valid;

When the current credential is deemed valid, it is determined whether the issuer of the current credential is available and trustworthy in the digital credential hierarchy, wherein the issuer is below the credential manager at level M in the digital identity hierarchy, where M is a positive integer, the issuer is one level above the current credential owner, and has digital credentials issued by another issuer at level one above the issuer, and the credential manager is at the top level in the digital credential hierarchy.

When the issuer is determined to be available but untrusted in the digital certificate hierarchy, the current certificate owner and the current certificate are replaced with the issuer and the issuer's digital certificate, respectively, and the validity of the current certificate is re-evaluated.

When the issuer is deemed available and trustworthy in the digital certificate hierarchy, the existing digital certificate is deemed verified and an assessment is performed to determine whether the entity requesting the authentication is authorized to endorse the existing digital certificate.

The existing digital certificate is deemed unverified if any determination that the existing certificate is valid and that the issuer of the current certificate is useful and trustworthy within the digital certificate hierarchy fails; and

When it is determined that the existing digital certificate has been verified, it is determined whether the entity requesting the authentication has the right to endorse the existing digital certificate.

To achieve the aforementioned objectives, methods for electronically signing documents include:

The credential verification entity sends a request for proof of the signer's digital credential of the document signing entity to the document signing entity, and the document signing entity receives the proof of the signer's digital credential, wherein the proof contains the signer's public key associated with the signer's digital credential;

The credential verification entity verifies whether the signer's digital credential has been verified, and when the signer's digital credential is confirmed to be valid, sends the file to the file signing entity; and

The credential verification entity receives the file signed by the signer's private key, which is paired with the signer's public key, and the signer's public key from the file signing entity, and verifies whether the file was signed by the file signing entity using the signer's public key.

In one embodiment, to verify whether the signer's digital credential has been verified, the method further includes:

Initialize the current credential and its owner to the signer's credential and the document's signing entity;

Determine whether the current credential is valid;

When the current credential is deemed valid, it is determined whether the issuer of the current credential is available and trustworthy in the digital credential hierarchy, wherein the issuer is below the credential manager at level M in the digital credential hierarchy, where M is an integer greater than zero, the issuer is one level above the current credential owner, and has digital credentials issued by another issuer at level one level above the issuer, and the credential manager is at the top level of the digital credential hierarchy.

When the issuer is determined to be available but untrusted in the digital certificate hierarchy, the current certificate owner and the current certificate are replaced with the issuer and the issuer's digital certificate, respectively, and the validity of the current certificate is re-evaluated.

When the issuer is deemed available and trustworthy within the digital credential hierarchy, the signer's digital credential is deemed verified; and

The signer's digital certificate is deemed unverified if any determination of whether the current certificate is valid and whether the issuer of the current certificate is available and trustworthy in the digital hierarchy fails.

To reflect the foregoing, each method employs a dual authentication technique, which includes verifying the validity of the digital credential regardless of whether it is an authenticated or non-authenticated type, and confirming that the issuer linked to the digital credential based on the parent-child issuance relationship is trustworthy. Since dual authentication can be considered a prerequisite for issuing authenticated type credentials and verifying signed documents, it eliminates the redundant KYC process for provers and verifiers in applications. Furthermore, dual authentication allows for more secure verification of digital credentials. In addition, the flexible choice between cert-type and non-cert-type credentials used for verification can reflect that any entity can have multiple digital identities in an identity hierarchy, including cert-type, non-cert-type, or both, and the identity hierarchy can uniformly accommodate both cert-type and non-cert-type credentials.

To achieve the aforementioned objectives, a system for issuing digital credentials and electronically signed documents of the authentication type includes a distributed ledger network, a first computing device, a second computing device, at least one issuer device, and a database.

This distributed ledger network maintains and stores a distributed ledger that stores revocation information related to issued digital certificates.

The first computing device is communicatively connected to the distributed ledger network.

The second computing device is communicatively connected to the first computing device.

When a parent-child issuing relationship exists and when provided for communication connection to the first computing device, the at least one issuing device is provided and connected to the digital certificate of the second computing device, the parent-child issuing relationship exists when the issuing device of the at least one issuing device issues the digital certificate to the second computing device, and when each of the remaining issuing devices issues another digital certificate to the other of the at least one issuing device.

The database communicates with the second computing device and the at least one issuer device, and stores issued digital credentials, which contain the digital credentials of the second computing device and the at least one issuer device, respectively accessible by the second computing device and the at least one issuer device.

Considering the structural features of a first computing device acting as both an authentication issuing entity and an authentication verification entity, a second computing device acting as an authentication request entity and a document signing entity, and at least one issuer device being associated with the digital credential to be verified based on a parent-child issuing relationship, the aforementioned system enables it to perform the application of issuing digital authentication and electronically signing documents as described in the aforementioned method. Therefore, the system also provides the benefit of improved security in KYC processes due to enhanced security of existing credentials and digital identity verification derived from the certifier. As for single points of failure, because this system is implemented on distributed ledger technology, the system damage from any single point of failure can be minimized without further affecting the parts of the system that are not harmed by that failure.

Other objectives, advantages, or novel features of the invention will become clearer from the following description paragraphs and with reference to the corresponding illustrations.

Attached Figure Description

Figure 1 is a schematic diagram illustrating an embodiment of the digital identity hierarchy according to the present invention;

Figure 2 is a schematic diagram illustrating another embodiment of the digital identity hierarchy according to the present invention;

Figure 3 is a flowchart illustrating the verification of the authenticity of digital identity according to the present invention;

Figure 4 is a flowchart illustrating the method for issuing digital certification according to the present invention;

Figure 5 is a flowchart illustrating an embodiment of the method for electronically signing documents according to the present invention;

Figure 6 is a flowchart illustrating another embodiment of the method for electronically signing documents according to the present invention;

Figure 7 is a schematic diagram illustrating the network architecture of a first embodiment of the system for issuing digitally certified and electronically signed documents according to the present invention;

Figure 8 is a schematic diagram illustrating the network architecture of a second embodiment of the system for issuing digitally certified and electronically signed documents according to the present invention; and

Figure 9 is a schematic diagram illustrating the network architecture of a third embodiment of the system for issuing digital certifications and electronically signed documents according to the present invention.

Detailed Implementation

Even when used in conjunction with the detailed description of certain specific embodiments in this art, the terminology used in the following description is intended to be interpreted in its broadest and most reasonable sense. Specific terms may be emphasized below, however any term intended to be interpreted in any limiting manner is defined in this section on implementation.

The embodiments described below can be implemented by a programmable circuit system designed or configured by software and/or firmware, or entirely by a special purpose circuit system, or a combination thereof. Such special purpose circuit systems (if present) may include forms such as one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc. In the following description, the term "digital credential" may refer to a digital credential hereinafter modified to mean a non-authenticated digital credential, or a digital credential hereinafter modified to mean an authenticated digital credential. An entity, such as an authenticator, signer, issuer, verifier, authentication request entity, authentication issuing entity, document signing entity, or credential verification entity, may refer to a computing device, which may be one of a server, desktop computer, laptop computer, smart device, tablet computer, or other similar device.

The described embodiments relate to one or more methods and systems for verifying a certifier's digital signature and digital credentials when a certified digital credential is requested, and for signing documents. These methods and systems primarily focus on a first subject issuing the certified digital credential to the entity requesting authentication, and a second subject verifying the documents signed by the document signing entity. An entity's certified digital credential is an electronic data structure from another trusted entity that guarantees the validity and authenticity of the entity and the public key bound to it. This entity can be an organization, individual, computer program, network address, or other, and serves as proof of the entity's digital identity as claimed. To distinguish it from certified digital credentials, which are traditionally referred to as digital certifications, all other digital credentials can be called non-certified digital credentials. Generally, both certified and non-certified digital credentials are digital credentials; essentially, certified digital credentials can be considered a special type of digital credential. For simplicity, the term "digital" will be removed from "non-authenticated digital credentials," "authenticated digital credentials," and "digital signature." As a general term for both non-authenticated and authenticated credentials, "digital credential" can also be simply referred to as "credential." The terms "certificate" or "credential" in this document can be replaced with the abbreviation "cert" or "cred." This abbreviation can also be used for entities that process requests for or issue cert-type credentials, such as cert-issuing entity or cert-requesting entity. The above naming convention will be adopted thereafter. In the first entity, to issue a cert-type digital credential to the cert-requesting entity, the cert-issuing entity needs to receive proof based on the existing credential of the cert-requesting entity and the public key of the cert-requesting entity associated with that existing credential. The cert-issuing entity must verify that the existing credential is verified, and the cert-requesting entity endorses the existing credential as a trusted authentic signer. In the first part of verifying whether an existing certificate is verified, the first step is to check whether the existing certificate is valid by verifying that the certificate associated with it is valid and that the existing certificate has not expired or been revoked. Then, the next step can proceed to verify whether one of the at least one issuers recursively traced and connected to the existing certificate according to a parent-child issuing relationship is trustworthy to complete the verification in the first part. A parent-child issuing relationship defines that one of the at least one issuers issued the existing certificate, and each of the remaining issuers issues another certificate to the other issuer among the at least one issuers. This process of tracing at least one issuer continues until a trustworthy issuer is found or until no issuers can be found at all. After a trustworthy issuer is identified, the existing certificate is verified in the first part. In the second part, which verifies whether the cert-requesting entity is a trusted signer endorsing the existing credential, the cert-issuing entity needs to verify the signature of the cert-requesting entity using the public key of the cert-requesting entity. This signature is generated to endorse the existing credential. When the verification of the existing credential in the first and second parts is correct, the cert-issuing entity generates a cert-type credential including the public key of the cert-requesting entity, and then issues the cert-type credential to the cert-requesting entity. In the second entity, to verify the signed document, the cred-verifying entity receives proof generated based on the signer's credentials from the document signing entity and verifies whether the signer's credentials are verified. After the signer's credentials are verified, the cred-verifying entity then sends the document to the document signing entity, which receives the signed document and verifies whether the document was signed by the document signing entity. The method for verifying whether the signer's credentials are verified is similar to that discussed earlier. In an alternative method, the cred-verifying entity may send the document to the document signing entity before verifying the signer's credentials. In this case, the cred-verifying entity only verifies whether the document was signed by the document signing entity after verifying that the signer's credentials are verified. The system involving the first and second entities includes a prover/signer, a requester/verifier of the requested credential, at least one issuer involved in a parent-child issuance relationship, a database, and a distributed ledger network. Each of the prover/signer, the requester/verifier of the requested credential, and at least one issuer involved in a parent-child issuance relationship may be a computing device.

According to Figure 1, which depicts an embodiment of a credential hierarchy, the credential hierarchy includes a root credential 101 owned by a credential administrator XYZ, multiple issuer credentials 102-105, each owned by an issuer, and multiple user credentials 201-207, each owned by a user. Root credential 101 is located at the top of the credential hierarchy, and credential manager XYZ issues multiple issuer credentials 102, 103 in a portion of the layer below root credential 101. Multiple issuer credentials 102-105 are located in multiple layers below root credential 101, and the issuer of each issuer credential 102-105 issues at least one remaining issuer credential 104, 105 or one of multiple user credentials 201-207, each of which is located in the layer below the corresponding issuer credential 102-105. For example, issuer credentials 102, 103 in the layer below root credential 101 are owned by the corresponding issuers DMV, CA1 and issued by credential manager XYZ, and issuer credentials 104, 105 in the layer below issuer credential 103 are owned by the corresponding issuers CA2, CA3 and issued by issuer CA1, which owns issuer credential 103. Multiple user credentials 201-207 are located in several layers below the corresponding issuer credentials 102-105. For example, user credentials 201-203, located one layer below issuer credentials 102, are owned by the corresponding users Alice, Bob, and Cathy, and issued by the issuer DMV, which owns issuer credentials 102. User credential 204, located one layer below issuer credentials 103, is owned by the corresponding user Bob and issued by the issuer CA1, which owns issuer credentials 103. User credentials 205 and 206, located one layer below issuer credentials 104, are owned by the corresponding users Alice and Cathy, and issued by the issuer CA2, which owns issuer credentials 104. User credential 207, located one layer below issuer credentials 105, is owned by the corresponding user Bob and issued by the issuer CA3, which owns issuer credentials 105. Therefore, it is evident that issuers in the credential hierarchy are qualified to issue corresponding issuer credentials or user credentials, while users holding user credentials in the credential hierarchy are not qualified to issue any credentials to anyone. Furthermore, in the credential hierarchy, it is acceptable for each to be associated with multiple credential systems for a specific purpose, such as issuer credentials and user credentials. As shown in Figure 1, the credential hierarchy includes, but is not limited to, a DMV system and a CA system. The DMV system and CA system include issuer credentials and user credentials used for driver's licenses and CA authentication. Generally speaking, issuer credentials and user credentials in the CA system are cert-type credentials, while those in the DMV system are non-cert-type credentials. Each credential may have issuer credentials in multiple tiers of the credential system. In this scenario, traversing from the top level of the credential system downwards, any issuer at each level can issue at least one issuer credential to at least one other issuer, or issue at least one user credential to at least one user, or not issue any credentials to the next level of the credential system. Figure 2 illustrates a credential system with issuer credentials at multiple layers. The system includes issuer credentials 301 issued by credential administrator XYZ to issuers of a global organization; two issuer credentials 302 and 303 issued by the global organization to issuers of two national organizations A and B; four issuer credentials 304-307, two of which are issued by issuers of national organization A to issuers of two local organizations A1 and A2, respectively, and the other two are issued by issuers of national organization B to issuers of two local organizations B1 and B2, respectively; and eight user credentials 308-315, two of which are issued by issuers of local organization A1 to users John and Sandra, two by issuers of local organization A2 to users Eric and Belinda, and the other two by issuers of local organization B1 to users Peter and Mary, respectively. The remaining two are issued by the issuer of local organization B2 to two users, Sam and Zoe, respectively. The issuer credentials and user credentials in the credential hierarchy shown in Figure 2 can be cert-type credentials or non-cert credentials. The issuer credential 301 owned by the issuer of the global organization is located one level below the root credential 101 level. The issuer credentials 302 and 303 owned by the issuers of national organizations A and B are located one level below the issuer authentication 301 level of the global organization. The issuer credentials 304-307 owned by the issuers of local organizations A1, A2, B1, and B2 are located one level below the issuer authentication 302 and 303 levels of national organizations A and B. The user credentials 308-314 are located one level below the issuer authentication 304-307 levels of the local organizations. Basically, there is only one issuer credential for the issuer of the global organization in this credential system. However, the number of issuer credentials for national and local organizations and the number of user credentials for users may vary in different systems.

The credential administrator is qualified to issue both non-cert-type and cert-type credentials. Issuers and users in the credential hierarchy can be either the cert-requesting entity in the first subject or the cert-verifying entity and document-signing entity in the second subject. However, only the issuer of a cert-type credential issued in the credential hierarchy can be the cert-issuing entity in the first subject. This is because in the credential hierarchy, each credential is owned by a corresponding entity, namely the credential administrator, issuer, or user. Credentials with the same identity in the credential hierarchy and their corresponding entities can mutually select the same identity. It is worth noting that in Figure 1, the same user Bob can have different issuer credentials 202, 204, and 207 in the credential hierarchy, issued by issuer DMV, issuer CA1, and issuer CA3 respectively. Even if some of an entity's credentials are compromised, the entity can still use other uncompromised credentials to prove its identity.

Although not all data fields are identical, for the purpose of credential verification, cert-type and non-cert-type credentials can be considered identical when they share common data fields requested for verification and differ only in their remaining data fields, as shown in Figure 1. Referring to cert-type credentials 105 and 207 and non-cert-type credential 201, the common data fields include the credential's decentralized identifier (DID), expiry date, and the issuer's public key and signature. This, in a way, explains why the credential hierarchy can accommodate both cert-type and non-cert-type credentials. In addition to the common data fields available for both cert-type and non-cert-type credentials, cert-type credentials further include the following remaining data fields:

type: type is set to “certificate”, which is a data field that distinguishes cert-type certificates from non-certificate certificates. Non-certificate certificates usually have other types than “certificate”.

DN (Distinguished Name): The distinguished name of the owner of the cert-type credential, such as a username like "Bob" in cert-type credential 207, or a company name. The distinguished name does not have to be a unique name.

public_key: The public key of the owner of a cert-type credential, which is used to verify any information or document signed by the owner of a cert-type credential's private key, which is paired with the public key.

The role (issuer) or user depends on whether the cert-type credential is an issuer credential or a user credential. When the role in the cert-type credential is issuer, the owner of the cert-type credential can be one of the issuer, prover, or verifier. When the role in the cert-type credential is user, the owner of the cert-type credential can be one of the prover or verifier.

Purpose: This indicates the purpose of the public key held by the owner of the cert-type credential, typically for digital signing or data encryption.

Algorithm: An encryption algorithm used for digital signatures or data encryption. RSA and ECDSA are commonly used for digital signatures. For data encryption, RSA is the most widely used.

Compared to the fixed remaining data fields of cert-type certificates, the remaining data fields of non-cert-type certificates can be flexible to adapt to different needs in identifying the owner of the non-cert-type certificate. When a digital driver's license issued by the DMV is a non-cert-type certificate, the remaining data fields of each digital driver's license may include the following data fields:

type: Driver’s license. Unlike cert-type credentials which are specifically “certificate”, the type of non-certificate credentials can specify their respective types as the type to which the non-certificate credential is classified, thereby reflecting the diverse identity verification purposes of the non-certificate credential. Unlimited examples of type can include digital Social Security cards, digital passports, digital corporate identity badges, digital degrees, and the like.

DN: The proprietary name of a non-certificate holder. As illustrated in Figure 1, Bob's license 202 has the proprietary name "Bob". This proprietary name may not be unique; for example, there may be multiple licenses with the proprietary names "Michael Jordan" or "Brenda Lee".

gender: The gender of the non-certificate holder, either male or female.

Date of birth: The date of birth of the credential holder.

License number: A multi-digit alphanumeric number that can be used as an ID number in some countries, such as Alice's 201 driver's license number 67892094.

Since the system involving the first entity may include a distributed ledger network that maintains the distributed ledger, information related to credentials can be issued both off-chain and on-chain. Off-chain, the issuing entity in the system issues cert-type credentials and stores them on the computing devices of the requesting entity, agent, or proxy, depending on the context. On-chain, revocation information used to track the revocation status of credentials in the distributed ledger is published to the distributed ledger. This revocation information is updated whenever a credential holder's private key is found to be vulnerable or compromised, or when the credential holder violates the specifications of the credential hierarchy. The credential holder can request the issuer that issued the credential to revoke their credential, and the associated issuer can always revoke the credential and update the related revocation information. Justification for credential revocation is required and can include one of the following: compromised key of the credential or associated issuer; termination or abandonment of the credential holder; reissue of the credential; temporary revocation; retirement of the associated issuer; and so on.

Because it involves the first and second entities and the key technologies of this invention, the verification of credential authenticity must be introduced first. When it comes to the verification of credentials possessed by a certifier, the verifier verifies whether the credential has been verified, wherein the certifier may be one of the cert-requesting entity in the first entity and the document signing entity in the second entity, and the verifier may be one of the cert-issuing entity in the first entity and the cred-verifying entity in the second entity. Figure 3 depicts the steps involved in the verification of credential authenticity.

Step S310: Initialize the current credential and the current credential owner as the credential and the prover, respectively. The issuer-tracing process is used to verify whether the prover's credential has been verified. In the issuer-tracing process, each of at least one issuer in one or more layers above the prover's layer in the credential hierarchy needs to be recursively traced according to parent-child issuing relationships until the credential of one of the traced issuers is verified as valid or none of the traced issuers' credentials are verified as valid. The direction is from the prover to the issuer in the layer below the credential manager. At the beginning of the issuer-tracing process, this current step serves as the initialization of the issuer-tracing process, used to define the current credential and the current credential owner as the prover's credential and prover, respectively.

Step S320: Determine if the current document is valid. Three conditions must be met to verify the validity of the current document. First, the proof derived from the current document must be verified as valid. Second, the current document should not have expired. Third, the current document has not been revoked. All three conditions must be met for the current document to be considered valid; if any one of the three conditions fails, the current document will be deemed invalid. The proof of the current document is generated by the current document owner based on the current document, the current document owner's knowledge of the data fields in the current document, and the Verification Request Document (VRD) from the verifier. More details about the VRD can be found in patent application PCT/US20/56388 entitled "VERIFICATION RQUIREMENT DOCUMENT FOR CREDENTIAL VERIFICATION". The VRD specifies three types of data in the current credential: a public portion, a challenging portion, and a private portion. At least one of the public and challenging portions is available for verification, while the private portion is not used for verification due to privacy concerns. Therefore, if both the public and challenging portions are available, a proof of the current credential based on the VRD for both public and challenging portions may include at least one public field, at least one signature of that corresponding public field, the public key of the current credential issuer, and at least one zero-knowledge proof challenge—at least one challenging field located in the challenging portion according to the VRD. When the VRD only specifies the public portion, only at least one public field and at least one signature of that corresponding public field will be presented in the proof. When the VRD only specifies the challenging portion, only at least one zero-knowledge proof will be presented in the proof. The at least one signature of the corresponding public field is signed by the issuer and can be verified using the issuer's public key. The method involving generating signatures on partial data fields of a credential is called Camenisch-Lysyanskaya (CL) signature. This allows the current credential owner to generate at least one signature for the corresponding public field of the credential without knowing the issuer's private key, provided that the signature used by the issuer to sign the entire credential data field is available. This CL signature technique allows a verifier to verify at least one signature for the corresponding public field using the issuer's public key. In an at least-one zero-knowledge proof, each party challenges one of at least one challenge field, calculated using the current credential, the value of the challenge field, and a challenge condition from the VRD. Each challenge condition includes a comparison operator, such as >, <, >=, <=, =, and ≠, which tests the corresponding challenge field to allow the prover to prove whether the challenge condition is met. In an at least-one zero-knowledge proof, each party is verified as true if the challenge condition of the zero-knowledge proof is met. For a credential to be verified as valid, at least one signature and at least one zero-knowledge proof for the corresponding public fields must be verified as correct, depending on the availability of the public and challenge portions of the VRD. The following example uses a driver's license to verify the credential. If the VRD specifies that the public fields of the public portion include the driver's license's DN, gender, and license number, along with two zero-knowledge proofs (i.e., age > 18 and not expired before 12/31/2020) to challenge the challenge fields "date of birth" and "expiration date"), the credential holder will output three signatures signed by the issuer for the public fields DN, gender, and license number, and provide the verifier with the three public fields, the three signatures, the issuer's public key held by the DMV, and the two zero-knowledge proofs for challenging the challenge fields "date of birth" and "expiration date". If the values of the challenge field, date of birth and expiration date, are 08/08/2000 and 02/17/2025, respectively, after verifying that the three signatures of the three public fields dn, gender, and license number, as well as the two zero-knowledge proofs, are correct, the verifier verifies that the proof of the driver's license provided by the current credential holder is valid.

Both the second and third conditions apply regardless of whether the credential is a non-certificate or a cert-type credential. The second condition, used to verify whether the credential has expired, involves verifying the "expiration date" data field in the credential. As for the third condition, the verifier communicating with the distributed ledger network can obtain revocation information from the distributed ledger and verify whether the credential has been revoked based on the revocation information.

If the digital credential is deemed valid, proceed to step S330; otherwise, proceed to step S360.

Step S330: Determine whether the issuer of the current credential is available and trustworthy in the credential hierarchy. The issuer of the current credential is located below the credential manager at level M in the credential hierarchy, where M is a positive integer. The issuer is one level above the current credential owner and owns credentials issued by another issuer one level above the current owner. The credential manager is known to be at the top level of the digital credential hierarchy. To verify that the current credential is verified, not only must the current credential itself be verified as valid, but the issuer recursively traced back in the credential hierarchy according to the issuer tracing process must also be deemed trustworthy. When the issuer of the current credential is unavailable in the credential hierarchy, proceed to step S360, which is the case when the issuer of the current credential cannot be found in the credential hierarchy. In one embodiment, whether the issuer can be found in the pre-approved list will determine whether the issuer is trustworthy. When the issuer is deemed available and trustworthy in the credential hierarchy, proceed to step S350. When the issuer is deemed available but untrustworthy in the credential hierarchy, proceed to step S340.

Step S340: Replace the current credential owner and the current credential with the issuer and the credential issuer, and return to step S320. After the current credential and the current credential owner are replaced, the current step recursively returns to the aforementioned step S320 to verify whether the current credential is valid.

Step S350: Determine that the prover's credentials are verified and end. If the current credential meets three conditions and the issuer is verified as usable through the issuer tracking process, the verifier determines that the prover's credentials are verified and does not continue to step S360.

Step S360: Determine that the issuer's credentials are unverified. An issuer's credentials may be deemed unverified because any of the three conditions are not met or because a trustworthy issuer cannot be found in the issuer tracking process.

The authenticity of the prover's credentials requires that the results of each round of the verification loop in steps S320-S340 be positive. If the results of the first round of steps S320-S340 are all positive, it means that the prover's credentials are valid and the issuer of the prover's credentials located one level above the prover in the credential hierarchy is trustworthy. However, if the result of step S330 shows that the issuer is usable but untrustworthy in the credential hierarchy, then step S340 is executed, and the recursive loop of step S320 is repeated to track the next issuer one level above the issuer. Then, a new round of verification is performed through steps S320-S340 to determine whether the next issuer's credentials are valid and the next issuer is trustworthy. By default, the issuers located at the top level of the credential hierarchy, corresponding to the top layer of the credential system, such as DMV and CA1 in Figure 1, are both trustworthy. Taking the verification of user credential 207 in Figure 1 as an example, assuming that the verification result of the first round is that user credential 207 is valid and the issuer CA3 that issued user credential 207 is untrusted, and the verification result of the second round is that the issuer credential 105 of issuer CA3 is valid and issuer CA1 is trusted by default, the verification result of this example shows that user Bob's user credential 207 has been verified in both rounds.

The first and second parties can be implemented using the aforementioned credential verification techniques. In addition to verifying the existing credentials of the cert-requesting entity, the first party issuing the cert-type credential to the cert-requesting entity needs to further verify something else to additionally endorse the request for the issuance of the cert-type credential. This other thing can be the signature of the cert-requesting entity.

Referring to Figure 4, the method for issuing cert-type documents in order to process the first subject includes the following steps.

Step S410: The cert-issuing entity receives a request for a cert-type credential from the cert-requesting entity. The current method involves two participants: one is the cert-requesting entity, which initiates the request to receive a cert-type credential; the other is the cert-issuing entity, which verifies the cert-requesting entity's eligibility and determines whether the cert-requesting entity is qualified to receive a cert-type credential issued by the cert-issuing entity. Both the cert-requesting entity and the cert-issuing entity can be communicating computing devices. The request for a cert-type credential is initiated by the cert-requesting entity, which includes a public key and is sent to the cert-issuing entity. This public key is part of a key pair generated by the cert-requesting entity using public-key cryptography and is paired with the private key of the key pair.

Step S420: The cert-issuing entity transmits a request for an existing credential from the cert-requesting entity to the cert-requesting entity. In response to the request for the cert-type credential, the cert-issuing entity transmits a request for an existing credential to the cert-requesting entity, which may be a non-certificate credential or a cert-type credential owned by the cert-requesting entity. In one embodiment, when the existing credential is a non-certificate credential, it is one of the official ID credentials, such as a digital driver's license, digital passport, digital national ID card, and digital state ID card, and the type of existing credential may be specified by the cert-issuing entity in its request.

Step S430: The cert-requesting entity generates proof of the existing credential and provides this proof, public key, data fragment, and digital signature to the cert-issuing entity. As described in step S320, the proof of the existing credential is provided to verify whether the existing credential has been verified, and includes the aforementioned data used to verify the credential. The data fragment may be a fragment of random data generated by the cert-issuing entity alone or by the cert-issuing entity and the cert-requesting entity together. It is signed by the private key of the key pair to generate a signature. In other words, the data fragment may be generated by the cert-issuing entity individually or by the cert-issuing entity and the cert-requesting entity together. The public key here is used to verify that the signature was signed by the cert-requesting entity. Therefore, in view of the signature, public key, data fragment, and proof of the existing credential, an endorsement for the request to issue a cert-type credential can then be provided.

Step S440: The cert-issuing entity verifies whether the existing credential has been verified and whether the cert-requesting entity is authorized to endorse it. For details regarding the verification of the existing credential, please refer to steps S310-S360. To verify whether the cert-requesting entity is authorized to endorse the existing credential, the cert-issuing entity uses its public key to verify whether the signature was signed by the cert-requesting entity. If the existing credential is verified and the cert-requesting entity is authorized to endorse it, proceed to step S450; otherwise, proceed to step S460.

Step S450: The issuing entity generates a cert-type credential and sends it to the requesting entity. The cert-type credential issued to the requesting entity includes the public key of the key pair. Depending on the application, the issuing entity may send the cert-type credential to another location for storage, such as a computing device belonging to an agent or proxy.

Step S460: The issuing entity of cert-rejects the request for a cert-type certificate.

The following provides an example of issuing a cert-type credential for club membership. When the computing device of the club membership issuing company receives a request for a cert-type credential for club membership from the computing device of the applicant, where the computing device of the club membership issuing company is the cert-issuing entity and is named the membership issuer herein, and the computing device of the applicant is the cert-requesting entity and is named the applicant herein, the membership issuer transmits a request for a digital license to the applicant. This club membership request also includes the public key of a key pair generated by the applicant, which is paired with the private key of the key pair. In response to the request for a digital license, the applicant generates proof of the digital license and transmits the public key of the key pair, a signature, a data fragment, and proof to the membership issuer. After verifying that the digital license is verified and that the applicant has signed the data fragment using the public key of the key pair, the membership issuer generates a cert-type credential for club membership for the applicant, which includes the public key, and transmits the cert-type credential to the applicant.

The prerequisite for a second entity to verify whether a document was signed by a document signing entity is that the signer credentials provided by the document signing entity are first verified by the cred-verification entity to confirm their authenticity. The first and second entities can be viewed as applications requiring both credentials and digital signatures for verification. If the cred-verification entity in the second entity specifies a cert-type credential, both the first and second entities can potentially be linked together by using a cert-type credential that is initially unavailable but can be obtained from the first entity to verify the document signed in the second entity. For example, if the cert-requesting entity in the first entity also acts as the document signing entity in the second entity, the CA certificate requested for verification can be obtained from existing credentials in the first entity, such as a digital driver's license, before verifying the digital signature on a document used for a loan application in the second entity.

As shown in Figure 5, a first embodiment of the method for electronically signing documents includes the following steps.

Step S510: The credential verification entity transmits a request for proof of the signer's credentials of the document signing entity to the document signing entity, and receives the proof of the signer's credentials from the document signing entity. The cred-verification entity is used to transmit the request for proof of the signer's credentials to the document signing entity, and is used to receive the proof, verify the signer's credentials of the document signing entity, and determine whether the document signing entity is a qualified signer of the document. Both the cred-verification entity and the document signing entity can be computing devices that communicate with each other. The proof of the signer's credentials is prepared by the document signing entity, and the verification of the proof in subsequent steps is a condition for continuing to perform the document signing. The proof includes the signer's public key learned from the signer's credentials, which can be a non-cert credential or a cert-type credential owned by the document signing entity. In one embodiment, when the signer's credentials are non-cert credentials, the non-cert credential is an official ID non-cert credential, which is one of a digital driver's license, digital passport, digital national ID card, and digital state ID card. The type of signer's credentials can be specified in advance by the cred-verification entity to correspond to a document with a signature that needs to be verified, such as a digital driver's license or CA certificate requested to verify a digital signature on an application form for obtaining a medical report.

Step S520: The cred-verifying entity verifies whether the signer's credentials have been verified. Similarly, details on verifying whether the signer's credentials have been verified can be found in steps S310-S360. If the signer's credentials have been verified, proceed to step S530; otherwise, proceed to step S570.

Step S530: The cred-verification entity sends the file to the document signing entity. In the current embodiment, the cred-verification entity only sends the file to the document signing entity after the signer's credentials have been verified as verified.

Step S540: The document signing entity signs the document using its own private key, which is paired with the signer's public key, and sends the signed document and the signer's public key to the cred-verification entity. In one embodiment, the document is signed by the signer's private key, which, when the signer's credential is not a cert credential, is associated with the signer's Distributed Identifier (DID) of the document signing entity in one of the data fields of the signer's credential. In another embodiment, the document is signed by the signer's private key, which, when the signer's credential is a cert-type credential, is paired with the public key in one of the data fields of the signer's credential.

Step S550: After receiving the signed document and the signer's public key, the cred-verification entity verifies whether the document was signed by the document signing entity using the signer's public key. When the signer's credential is not a cert credential, the signer's public key can be linked to the signer's Distributed Identifier (DID) of the document signing entity in the signer's credential; or when the signer's credential is a cert-type credential, the signer's public key can be linked to the public key in the signer's credential. If the verification result is positive, proceed to step S560; otherwise, proceed to step S570.

Step S560: cred - Verify that the entity certification document has been successfully signed.

Step S570: cred - Verification of entity certification document signing failed.

Unlike the first embodiment, which sends the document to be signed only after the signer's credentials have been verified, according to FIG6, the second embodiment of the method for electronically signing documents includes the following steps, wherein the document may be selectively sent before the signer's credentials have been verified. To avoid repetition, descriptions similar to those in the first embodiment will not be repeated in the second embodiment.

Step S610: The cred-verification entity sends a request for proof of the signing credentials of the document signing entity and the document to the document signing entity. Note that the request for proof of the signer's credentials and the document are simultaneously sent by the cred-verification entity to the document signing entity.

Step S620: The document signing entity signs the document using the signer's private key and sends proof of the document and signer's credentials to the cred-verification entity. The proof includes the signer's public key, which is paired with the signer's private key. In response to the received request and document, the document signing entity needs to send proof of the signed document and signer's credentials to the cred-verification entity as a response.

Step S630: The cred-verifying entity verifies whether the signer's credentials have been verified. If the signer's credentials have been verified, proceed to step S640; otherwise, proceed to step S660.

Step S640: The cred-verifying entity verifies whether the document was signed by the document signing entity using the signer's public key, which is paired with the signer's private key. If the verification result is positive, proceed to step S650; otherwise, proceed to step S660.

Step S650: cred - Verify that the entity certification document has been successfully signed.

Step S660: cred - Verification of entity authentication document signing failed.

Referring to Figure 7, the system applicable to the first and second principals includes a distributed ledger network 701, a first computing device 702, a second computing device 703, at least one issuer device 704, and a database 705. This system emphasizes structural description rather than the functionality already discussed in the foregoing methods. While ellipses between the two issuer devices 704 and between their connections to the first computing device 702 and the database 705 show an embodiment with multiple issuer devices, where one of the multiple issuer devices is trusted, the at least one issuer device 704 may also include other embodiments, such as having one trusted issuer device as shown in Figure 8, or having no issuer devices as shown in Figure 9.

Distributed ledger network 701 maintains a distributed ledger that stores revocation information related to issuer credentials. First computing device 702 is communicatively connected to distributed ledger network 701 and can act as either the cert-issuing entity in a first entity or the cred-verifying entity in a second entity. The second computing device 703 is communicatively connected to the first computing device 702 and can act as a cert-request entity in the first subject or a document signing entity in the second subject. At least one issuer device 704 is a flexible part of the system that changes with the parent-child issuance relationship. Its communication connection to the first computing device 702 is maintained, and when the parent-child issuance relationship is available, it provides and connects to the second computing device with credentials. The parent-child issuance relationship defines that one of the at least one issuer device 704 issues credentials to the second computing device 702, and each of the remaining issuer devices 704 issues another credential to the other of the at least one issuer device 704. In other words, when the parent-child issuance relationship does not exist, at least one issuer device 704 is unavailable in the system. The absence of an issuer device 704 may stem from forged or fake credentials, causing the absence of an issuer device 704 to connect to fake credentials based on the parent-child issuance relationship. When the parent-child relationship exists, at least one issuer device 704 connects to the credentials of the second computing device 703, and at least one issuer device 704 and its at least one credential reside in the credential hierarchy. When acting as an issuer in the credential hierarchy, each of the first computing device 702, the second computing device 703, and at least one issuer device 704 can maintain a distributed ledger. A database 705 is communicatively connected to the second computing device 703 and the at least one issuer device 704, and stores issued credentials, which contain credentials of the second computing device 703 and the at least one issuer device 704, respectively, and is accessible to both the second computing device 703 and the at least one issuer device 704.

It is worth mentioning that if at least one issuer device 704 is available, when the first computing device 702 verifies whether the issuer device 704 is trustworthy, after receiving a request to verify whether the credentials of any of the at least one issuer device 704 are valid, the issuer device 704 immediately sends a proof based on its credentials to the first computing device 702 for verification.

From the above description, this invention offers advantages in eliminating cumbersome and repetitive KYC processes when requesting the issuance of new cert-type certificates and verifying digital signatures on documents. This is because the issuance of new cert-type certificates can be accepted and document signatures can be verified using the existing certificates, regardless of whether the existing certificates are cert-type or non-cert-type. Besides eliminating the need for KYC processes, the hierarchical certificate hierarchy offers multiple certificate systems, each including cert-type or non-cert-type certificates. Users/issuers can obtain different certificates from multiple systems and thus have the freedom to choose their preferred type of identity or user/issuer certificate. Since each issuer in the certificate hierarchy of this invention can maintain a distributed ledger, the problem of a single point of failure only results in a single, unique entity certificate being compromised and invalidated within the certificate hierarchy. For any certificate linked to the compromised certificate based on a parent-child issuance relationship, the issuer of the certificate only suffers the loss of that certificate but can still be identified through other certificates in the certificate hierarchy. In addition, in order to be certified as a verified credential, it relies on dual verification, in which the credential must be verified as valid and at least one issuer linked to the credential based on parentage must be verified as trustworthy. This dual verification ensures that the verification of the credential is more secure.

While various features and advantages of the invention have been set forth in the foregoing, together with structural details and the functionality of the invention, this disclosure is for reference only. Modifications may be made, in particular, to the extent indicated by the broad general meaning set forth in the appended claims, to the maximum extent of the principles of the invention.