Verifying digital credentials and digital signatures

Abstract

The disclosure of the present invention includes a method and system for issuing certificate-type credentials and digitally signing documents. Both applications need to verify whether the digital credential of the certifier or signer is authenticated. Authenticating a digital credential requires two-step verification: verifying that the digital credential is valid and verifying that one of at least one issuer linked to the digital credential according to a parent-child relationship is trusted. To verify that a digital credential is valid, the validity, expiration date, and revocation information of the proof associated with the digital credential must all be verified as valid. The two-step verification further strengthens the verification of the digital credential. Non-certificate-type digital credentials and certificate-type digital credentials can be organized into a digital identity hierarchy, allowing one entity implemented using distributed ledger technology to own multiple digital credentials, effectively avoiding a single point of failure.

Description

[Technical Field]

[0001] The present invention relates to a method and system for verifying credentials and signatures, and more particularly to a method and system for verifying digital signatures and digital credentials of signers when signing documents and of verifyers requesting certificate-type digital credentials. [Background technology]

[0002] A certification authority (CA) is an organization that verifies identities and binds them to digital credentials using cryptographic key pairs. In the most commonly adopted Web Public Key Infrastructure (PKI) approach, a CA, the issuing entity is the entity that issues digital credentials that attest to the ownership of a public key by the certificate's designated subject. Typically, a CA hierarchy starts with a root CA at the top. Below the root CA are several intermediate CAs. The root CA issues intermediate CA certificates. The intermediate CAs then issue further CA certificates or sign end-entity certificates.

[0003] A CA acts as a trusted third party that certifies the public keys of a network of entities. Most web services are protected by keys signed by a CA.

[0004] As a result of a monopoly-dominant trusted hierarchy, CA hierarchies have the problem and limitation that the online identity of an entity in the CA hierarchy must be verified by the CA or, in some cases, by an intermediate CA in the CA hierarchy, which may be a private company or government. Another problem is that before issuing a certificate to an entity / organization, the CA must verify the entity / organization's identity to ensure that the entity / organization being certified by the CA is in fact requesting the certificate. Such a step is typically referred to as a know-your-customer (KYC) process. Traditionally, if an entity / organization needs to apply for multiple certificates from different CAs, it must repeat the KYC process for each application to a different CA. Furthermore, such a centralized trust hierarchy is vulnerable to a single point of failure, either at the intermediate CA or the end entity, which, if compromised, can have catastrophic consequences, as demonstrated by the DigiNotar incident. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] PCT / US2020 / 56388 publication Summary of the Invention [Problem to be solved by the invention]

[0006] An object of the present invention is to provide methods and systems for issuing digital credentials and electronically signing documents that can eliminate the KYC process of CA certificates and single points of failure, and enhance security for verifying digital identities. [Means for solving the problem]

[0007] To achieve the above objectives, a method for issuing digital credentials of certificate type comprises: receiving, by a certificate issuing entity, a request for a digital credential of a certificate type from a certificate requesting entity, the request for the digital credential of a certificate type including a public key generated by the certificate requesting entity; a certificate-issuing entity sending a request to a certificate requesting entity for an existing digital credential of the certificate requesting entity; a certificate-issuing entity sending a request to a certificate requesting entity for an existing digital credential of the certificate requesting entity; the certificate-issuing entity verifies whether the existing digital credential is authenticated and whether the certificate requesting entity is authorized to recognize the existing digital credential, and if the existing digital credential is authenticated and the certificate requesting entity is authorized to recognize the existing digital credential, generates a digital credential of a certificate type that includes the public key of the certificate requesting entity; The certificate issuing entity sends a digital credential of the certificate type to the certificate requesting entity.

[0008] In one embodiment, to verify whether the existing digital credential is authenticated and the certificate requesting entity is authorized to accept the existing digital credential, the method further comprises: initializing a current credential and a current credential owner to an existing digital credential and certificate requesting entity, respectively; determining whether the current credentials are valid; If determining that the current credential is valid, determining whether the issuer issuing the current credential is available and trusted in a digital credential hierarchy, wherein the issuer is M tiers below the credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer is the next tier above the current credential owner, and holds a digital credential issued by another issuer that is the next tier above the issuer, and the credential manager is at the top tier of the digital credential hierarchy; if it determines that the issuer is available but not trusted in the digital credential hierarchy, replacing the current credential holder and the current credential with the issuer and the issuer's digital credential, respectively, and restarting the determination of whether the current credential is valid; If the issuer is determined to be available and trusted in the digital credential hierarchy, determining that the existing digital credential is authenticated and performing a determination of whether the certificate requesting entity is authorized to recognize the existing digital credential; determining that the existing digital credential is not authenticated if the results of either determining whether the current credential is valid or determining whether the issuer that issued the current credential is available and trusted in the digital credential hierarchy are negative; If it is determined that the existing digital credential is authenticated, determining whether the certificate requesting entity is authorized to recognize the existing digital credential.

[0009] To achieve the above objectives, the method for electronically signing a document is as follows: the credential verifying entity sending a request to the document signing entity for a proof of the signer digital credential of the document signing entity and receiving a proof of the signer digital credential from the document signing entity, the proof including the signer public key associated with the signer digital credential; the credential verification entity verifies whether the signer digital credential is authenticated, and if the signer digital credential is verified to be valid, sends the document to the document signing entity; The method includes a credential verification entity receiving from the document signing entity a document signed with the signer private key paired with the signer public key and the signer public key, and verifying using the signer public key whether the document is signed by the document signing entity.

[0010] In one embodiment, to verify whether the signer digital credential is authenticated, the method further comprises: initializing the current credential and the current credential owner to a signer digital credential and a document signing entity; determining whether the current credentials are valid; if determining that the current credential is valid, determining whether the issuer issuing the current credential is available and trusted in a digital credential hierarchy, wherein the issuer is M tiers below the credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer is the next tier above the current credential owner, and holds a digital credential issued by another issuer that is the next tier above the issuer, and the credential manager is at the top tier of the digital credential hierarchy; if it determines that the issuer is available but not trusted in the digital credential hierarchy, replacing the current credential holder and the current credential with the issuer and the issuer's digital credential, respectively, and restarting the determination of whether the current credential is valid; determining that the signer digital credential is authenticated if the issuer is determined to be available and trusted in the digital credential hierarchy; and determining that the signer digital credential is not authenticated if the results of either determining whether the current credential is valid or whether the issuer that issued the current credential is available and trusted in the digital credential hierarchy are negative.

[0011] As reflected in the preceding description, each of the methods employs a two-step verification technique: verifying whether a digital credential is valid, regardless of whether it is a certificate-type credential or a non-certificate-type credential, and verifying whether the issuer linked to the digital credential is trusted according to a parent-child issuing relationship. The two-step verification technique can be employed as a prerequisite for applications to issue certificate-type credentials and verify signed documents, thereby eliminating the need for repeated KYC processes for the prover and verifier in applications. Meanwhile, using the two-step verification technique enables digital credentials to be verified in a more secure manner. Furthermore, the flexibility to select certificate-type or non-certificate credentials for verification can reflect the possibility that any entity may possess multiple digital identities that are certificate-type credentials, non-certificate credentials, or both, in a digital credential hierarchy that universally accepts certificate-type and non-certificate credentials.

[0012] To achieve the foregoing objectives, a system for issuing certificate-type digital credentials and electronically signing documents includes a distributed ledger network, a first computing device, a second computing device, at least one issuer device, and a database.

[0013] The distributed ledger network maintains a distributed ledger that stores revocation information associated with issued digital credentials.

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

[0015] The second computing device is communicatively coupled to the first computing device.

[0016] At least one issuer device is provided and linked to a digital credential of a second computing device and, when provided, communicatively connected to a first computing device when a parent-child issuing relationship exists. A parent-child issuing relationship exists when one issuer device of the at least one issuer device issues a digital credential to the second computing device and each of the remaining issuer devices issues another digital credential to another one of the at least one issuer device.

[0017] The database is communicatively coupled to the second computing device and the at least one issuer device and stores issued digital credentials including digital credentials of the second computing device and at least one issuer device accessible to the second computing device and the at least one issuer device, respectively. [Effects of the Invention]

[0018] Given the structural features for a first computing device acting as a certificate issuing entity and a credential verifying entity, a second computing device acting as a certificate requesting entity and a document signing entity, and at least one issuer device satisfying a parent-child issuing relationship associated with the digital credential to be verified, as illustrated by the method described above, the system itself can execute applications for issuing digital credentials and electronically signing documents. Accordingly, improvements to the know-your-customer (KYC) process enabled by the certifier's existing credentials and enhanced security in verifying digital identities are also benefits of this system. With regard to single points of failure, because the system is implemented based on distributed ledger technology, damage to the system caused by a single point of failure can be minimized without further impacting portions of the system not compromised by the failure.

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

[0020] [Figure 1] 1 is a schematic diagram illustrating an embodiment of a digital identity hierarchy in accordance with the present invention; [Figure 2] FIG. 2 is a schematic diagram illustrating another embodiment of a digital identity hierarchy in accordance with the present invention. [Figure 3] FIG. 1 is a flow diagram illustrating the verification of the authenticity of a digital identity in accordance with the present invention. [Figure 4] 1 is a flow diagram illustrating a method for issuing digital credentials in accordance with the present invention. [Figure 5] 1 is a flow diagram illustrating an embodiment of a method for digitally signing a document in accordance with the present invention. [Figure 6] FIG. 4 is a flow diagram illustrating another embodiment of a method for digitally signing a document according to the present invention. [Figure 7]1 is a schematic diagram illustrating the network architecture of a first embodiment of a system for issuing digital credentials and electronically signing documents according to the present invention; [Figure 8] FIG. 2 is a schematic diagram illustrating the network architecture of a second embodiment of a system for issuing digital credentials and electronically signing documents according to the present invention. [Figure 9] FIG. 2 is a schematic diagram illustrating the network architecture of a third embodiment of a system for issuing digital credentials and electronically signing documents according to the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0021] The terms used in the following description are intended to be interpreted in the broadest reasonable manner, even when used in conjunction with the detailed description of certain embodiments of the technology. Although certain terms may be emphasized below, terms intended to be interpreted in a limited manner are specifically defined as such in this detailed description section.

[0022] The embodiments presented below may be implemented by programmable circuitry programmed or configured by software and / or firmware, or entirely by dedicated circuitry, or by a combination of such forms. Such dedicated 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. In the following description, the term digital credential may refer to a digital credential, which may later be referred to as a non-certificate digital credential, or a digital credential, which may later be referred to as a certificate-type digital credential, and an entity such as a certifier, signer, issuer, verifier, certificate request entity, certificate-issuing entity, document signing entity, or credential verification entity may refer to a computing device, which may be one of a server, a desktop computer, a laptop computer, a smart device, a tablet PC, etc.

[0023] The described embodiments relate to one or more methods and systems for verifying a certifier's digital signature and digital credential upon requesting a certificate-type digital credential and signing a document, and may primarily focus on a first subject related to the issuance of a certificate-type digital credential to an entity requesting the certificate and a second subject related to verifying a document signed by a document-signing entity. An entity's certificate-type digital credential is an electronic data structure from another trusted entity that vouches for the validity and authenticity of a public key that binds the entity, which may be an institution, person, computer program, web address, etc., to its public key, and is a digital identity proof that confirms that the entity is who it claims to be. To distinguish from certificate-type digital credentials, which are also conventionally referred to as digital credentials, all other digital credentials can be referred to as non-certificate digital credentials. Regardless of whether they are certificate-type digital credentials or non-certificate digital credentials, they are all generally digital credentials. Essentially, certificate-type digital credentials can be treated as a specific type of digital credential. For brevity, the word "digital" is removed from the terms "non-certificate digital credential," "certificate digital credential," and "digital signature." "Digital credentials" is a generic term for both non-certificate credentials and certificate-type credentials, and therefore may also be named in the simpler form of "credentials." Terms appearing with "certificate" or "credentials" may alternatively be named with the abbreviations "cert" or "cred." Such naming abbreviations also apply to entities that handle the request or issuance of certificate-type credentials, such as a cert requesting entity to a certificate requesting entity. The aforementioned naming rules apply as follows: To issue a certificate-type credential to a certificate requesting entity in the first subject, the certificate issuing entity needs to receive a proof generated according to the certificate requesting entity's existing credentials, as well as the certificate requesting entity's signature and public key associated with the existing credentials.The certificate issuing entity must verify whether the existing credential is authenticated and whether the certificate requesting entity is an authorized signer of the existing credential. In the first part of verifying whether the existing credential is authenticated, a first step of checking whether the existing credential is valid requires that the proof associated with the existing credential is verified to be valid and that the existing credential is neither expired nor revoked. The next step then begins, completing the first part of the verification, verifying whether one issuer of at least one issuer recursively traced and linked to the existing credential according to a parent-child issuing relationship is trusted. The parent-child issuing relationship specifies that one issuer of the at least one issuer issues the existing credential, and each of the remaining issuers issues another credential to another one of the at least one issuer. This process of tracing at least one issuer continues until a trusted issuer is found or until no issuer is found at all. After a trusted issuer is identified, the existing credential is authenticated in the first part. In the second part, which is for verifying whether the certificate requesting entity is an authorized signer for approving the existing credential, the certificate issuing entity must verify the certificate requesting entity's signature, generated to approve the existing credential, with the certificate requesting entity's public key. If the verification of the first and second parts of the existing credential is correct, the certificate issuing entity generates a certificate-type credential including the certificate requesting entity's public key and issues the certificate-type credential to the certificate requesting entity. To verify the signed document in the second subject matter, the credential verification entity receives from the document signing entity a proof generated based on the document signing entity's signer credentials and verifies whether the signer credentials are authenticated. After the signer credentials are authenticated, the credential verification entity sends the document to the document signing entity, receives the signed document from the document signing entity, and verifies whether the document is signed by the document signing entity.This is similar to what was previously discussed for verifying whether signer credentials are authenticated. In another approach, the credential verification entity may send the document to the document signing entity before the signer credentials are verified. In that case, the credential verification entity verifies whether the document is signed by the document signing entity only after verifying that the signer credentials are authenticated. The systems involved in the first and second subjects include a certifier / signer, an issuer of the requested credential / verifier, at least one issuer involved in a parent-child issuing relationship, a database, and a distributed ledger network. Each of the certifier / signer, the issuer of the requested credential / verifier, and the at least one issuer involved in the parent-child issuing relationship may be a computing device.

[0024] 1 , which illustrates an embodiment of a credential hierarchy, the credential hierarchy includes a root credential 101 owned by a credential manager XYZ, multiple issuer credentials 102-105, each owned by an issuer, and multiple user credentials 201-207, each owned by a user. The root credential 101 is at the top of the credential hierarchy, and the credential manager XYZ issues some of the multiple issuer credentials 102, 103 at the next layer below the layer of the root credential 101. The multiple issuer credentials 102-105 are at multiple layers below the layer of the root credential 101, respectively, and the issuer of each issuer credential 102-105 issues at least one of the remaining issuer credentials 104, 105 or at least one of the multiple user credentials 201-207, each at the next layer below the corresponding issuer credential 102-105. For example, issuer credentials 102 and 103, which are the next layer below the layer of root credential 101, are owned by corresponding issuers DMV and CA1 and issued by credential manager XYZ, and issuer credentials 104 and 105, which are the next layer below issuer credential 103, are owned by corresponding issuers CA2 and CA3 and issued by issuer CA1, which owns issuer credential 103. Multiple user credentials 201-207 are multiple layers below the layer of corresponding issuer credentials 102-105. For example, user credentials 201-203 at the next layer below issuer credential 102 are owned by corresponding users Alice, Bob, and Cathy and are issued by issuer DMV, which owns issuer credential 102; user credential 204 at the next layer below issuer credential 103 is owned by corresponding user Bob and issued by issuer CA1, which owns issuer credential 103; user credentials 205 and 206 at the next layer below issuer credential 104 are owned by corresponding users Alice and Cathy and issued by issuer CA2, which owns issuer credential 104; and user credential 207 at the next layer below issuer credential 105 is owned by corresponding user Bob and issued by issuer CA3, which owns issuer credential 105.Ultimately, an issuer in the credential hierarchy has the right to issue a corresponding issuer credential or user credential, but a user who owns a user credential in the credential hierarchy does not have the right to issue certificates to anyone. Furthermore, a credential hierarchy allows for multiple credential systems, each associated with issuer and user credentials for a specific purpose. As shown in FIG. 1 , the credential hierarchy includes, but is not limited to, one DMV system and one CA system. The DMV system and CA system include issuer and user credentials for driver's license and CA certificate purposes. Typically, the issuer and user credentials of the CA system are associated with certificate-type credentials, while the issuer and user credentials of the DMV system are associated with non-certificate credentials. Each credential system may have issuer credentials at multiple tiers in the credential system. In that scenario, moving downward from the top layers of the credential system, issuers at each layer may issue at least one issuer credential to at least one other issuer, or at least one user credential to at least one user, respectively, or none at the next lower layer of the credential system. An embodiment of a credential system with issuer credentials at multiple layers of the credential system is shown in Figure 2.Figure 2 shows issuer credentials 301 issued by credential manager XYZ to an issuer at a global organization; two issuer credentials 302 and 303 issued by the issuer at the global organization to two issuers at two national organizations A and B; and four issuer credentials 304-305, two of which are issued by an issuer at national organization A to two issuers at two local organizations A1 and A2, and two of which are issued by an issuer at national organization B to two issuers at two local organizations B1 and B2, respectively. 7, and eight user credentials 308-315, two of which are issued by an issuer in local organization A1 to two users John and Sandra, two of which are issued by an issuer in local organization A2 to two users Eric and Belinda, two of which are issued by an issuer in local organization B1 to two users Peter and Mary, and the remaining three are issued by an issuer in local organization B2 to Sam and Zoe. The issuer credentials and user credentials in the credential system shown in FIG. 2 are certificate-type credentials or non-certificate credentials. Issuer credential 301, owned by an issuer in a global organization, is the next tier below the root credential 101. Issuer credentials 302 and 303, owned by issuers in national organizations A and B, are the next tier below the issuer credential of global organization 301. Issuer credentials 304-307 owned by issuers of local organizations A1, A2, B1, and B2 are the next layer below the issuer credentials 302 and 303 of national organizations A and B. User credentials 308-314 are the next layer below the issuer credentials 304-307 of local organizations. Essentially, in such a credential system, there is only one issuer credential for an issuer such as a global organization. However, the number of issuer credentials for issuers such as national and local organizations and user credentials for users may vary from credential system to credential system.

[0025] The credential manager is authorized to issue both non-certificate and certificate-type credentials. Issuers and users in the credential hierarchy may play the role of either a certificate requesting entity in a first subject or a credential verifying entity or a document signing entity in a second subject. However, only issuers that issue certificate-type credentials in the credential hierarchy can play the role of a certificate issuing entity in the first subject. Because each certificate in the credential hierarchy is owned by a corresponding entity—a credential manager, an issuer, or a user—credentials and corresponding entities that can equally refer to the same identity in the credential hierarchy can be interchangeably selected for the same identity. Note that the same user Bob in Figure 1 may 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 the credentials of any entity are compromised, the entity can continue to use other uncompromised credentials to prove its identity.

[0026] Although not identical in data fields as far as certificate validation is concerned, certificate-type credentials and non-certificate credentials can be treated the same because they share common data fields required for validation and differ only with respect to the remaining data fields. As shown in Figure 1, the common data fields visible to certificate-type credentials 105, 207 and non-certificate credentials 201 include the credential's distributed identifier (DID), the credential's expiration date, and the issuer's public key and signature, which explains to some extent why a credential hierarchy can accommodate both certificate-type credentials and non-certificate credentials within it. In addition to the common data fields available to certificate-type credentials and non-certificate credentials, each certificate-type credential also includes the following remaining data fields:

[0027] type: The type is set to "credentials". This is a data field that distinguishes between certificate-type credentials and non-certificate credentials that usually have some other type different from "credentials".

[0028] dn: The distinguished name of the certificate type credential owner, which may be, for example, a username such as "Bob" for a certificate type credential 207, or a company name. The distinguished name may not be a unique name.

[0029] public_key: The public key of the certificate type credential holder, which is used to verify any message or document signed by the certificate type credential holder's private key paired with the public key.

[0030] role: this is the role of issuer or user depending on whether the certificate type credential is an issuer credential or a user credential. The certificate type credential holder can be either issuer, certifier, or verifier if the role of the certificate type credential is issuer, or can be either certifier or verifier if the role of the certificate type credential is user.

[0031] purpose: This indicates the purpose of the credential holder's public key for the certificate type, typically for digital signatures or data encryption.

[0032] algorithm: A cryptographic algorithm for digital signatures or data encryption. For digital signatures, RSA and ECDSA are commonly used. For data encryption, RSA is the most widely used.

[0033] The remaining data fields for certificate-type credentials are fixed, whereas the remaining data fields for non-certificate credentials can be flexible to suit various needs for identifying non-certificate credential holders. If the digital driver's licenses issued by the DMV are non-certificate credentials, the remaining data fields of each digital driver's license may include the following data fields:

[0034] type:driver's license. Unlike the type designated as "certificate" for certificate-type credentials, the type of a non-certificate credential designates the respective type into which the non-certificate credential falls to reflect the various identification purposes of the non-certificate credential. Non-limiting examples of types may include digital social security cards, digital passports, digital company identification badges, digital diplomas, etc.

[0035] dn: The distinguished name of the non-certificate credential holder. As illustrated in Figure 1, the distinguished name on Bob 202's driver's license is "Bob." A distinguished name may not be a unique name. For example, there may be multiple driver's licenses with the distinguished name "Michael Jordon" or "Brenda Lee."

[0036] gender: The gender of the non-certificate credential holder, male or female.

[0037] date of birth: The date the certificate holder was born.

[0038] license number: A multi-digit alphanumeric number used as an identification number in some countries, for example, Alice201's driver's license is 67892094.

[0039] A system related to the first subject matter may include a distributed ledger network that maintains a distributed ledger, so that information related to credentials can be issued both off-chain and on-chain. In the off-chain portion, a certificate issuing entity in the system issues certificate-type credentials and stores the credentials on a computing device of a certificate requesting entity, agent, or proxy, depending on various circumstances. In the on-chain portion, revocation information for tracking the revocation status of certificates in the distributed ledger is published to the distributed ledger. Such revocation information is updated when a credential holder's private key is found to be weak or compromised or when the credential holder violates the rules of the credential hierarchy. A credential holder may make a request to the issuer that issued the credential to revoke the holder's credential, and the associated issuer can always revoke the credential and update the associated revocation information. A reason is required to justify the revocation of a certificate, and the reason may be one of several cases including compromise of the credential or associated issuer's key, removal or resignation of the credential holder, reissuance of the credential, temporary revocation, removal of the associated issuer, etc.

[0040] Since the verification of the authenticity of a credential involves the first and second subjects and is also a key technique of the present invention, it has priority to be introduced first. Regarding the verification of a credential owned by a prover, which may be either a certificate requesting entity in the first subject or a document signing entity in the second subject, a verifier, which may be either a certificate issuing entity in the first subject or a credential verifying entity in the second subject, verifies whether the credential is authenticated or not. Figure 3 shows the verification of the authenticity of a credential using the following steps:

[0041] Step S310: Initialize the current credential and the current credential owner to the credential and the verifier, respectively. An issuer tracing process is used to verify whether the verifier's credentials are authenticated. The issuer tracing process requires that at least one issuer at one or more layers above the verifier in the credential hierarchy be recursively traced in the direction from the verifier to issuers at layers below the credential manager according to the parent-child issuing relationship until the credential of one of the tracked issuers is verified as valid or until none of the credentials of the tracked issuers are verified as valid. At the start of the issuer tracing process, the current step serves as the initialization of the issuer tracing process and defines the current credential and the current credential owner as the verifier's certification proof and verifier, respectively.

[0042] Step S320: Determine whether the current credential is valid. To verify that the current credential is valid, three conditions must be met. First, the proof generated according to the current credential must be verified as valid. Second, the current credential must not have expired. Third, the current credential has not been revoked. To qualify for a valid current credential, all three conditions must be met. If any of the three conditions is not met, the current credential is determined to be invalid. The proof of the current credential is generated by the current credential owner according to the current credential, the current credential owner's knowledge of the data fields of the current credential, and a verification requirements document (VRD) from the verifier. For further details regarding the VRD, reference may be made to Patent Application No. PCT / US2020 / 56388, entitled "VERIFICATION RQUIREMENT DOCUMENT FOR CREDENTIAL VERIFICATION." The VRD specifies three types of data in the current credential: a public portion, an explanation request portion, and a private portion; at least one of the public portion and the explanation request portion is available; and the private portion is not subject to verification due to privacy concerns. Thus, a proof of the current credential focusing on the public portion and the explanation request portion, if both are available, may include at least one public field, at least one signature of the corresponding public field, the public key of the issuer of the current credential, and at least one zero-knowledge proof that explains at least one explanation request field included in the explanation request portion according to the VRD. If the public portion is specified only in the VRD, the proof only contains at least one public field and at least one signature of the corresponding public field. If the explanation request portion is specified only in the VRD, the proof only contains at least one zero-knowledge proof. The at least one signature of the corresponding public field is signed by the issuer and can be verified with the issuer's public key.The technique involved in generating digital signatures for partial data fields of a credential is called Camenisch-Lysyanskaya (CL) signatures, which allow the current credential holder to create a signature for at least one of the corresponding public fields of the credential without knowing the issuer's private key, as long as the issuer's signature for signing all data fields of the credential is available. Such CL signature techniques allow a verifier to verify the signature for at least one of the corresponding public fields of the current credential with the issuer's public key. Each of the at least one zero-knowledge proof is for explaining one of the at least one explanation request fields and is calculated using the current credential, the value of the explanation request field, and an explanation request condition from the VRD. Each explanation request condition includes a comparison operator, such as >, <, >=, <=, =, or ≠, which the prover tests against the corresponding explanation request field to prove whether the explanation request condition is met. If the explanation request condition of the zero-knowledge proof is met, each of the at least one zero-knowledge proof is verified as correct. To verify that the current credential is valid, at least one signature and / or zero-knowledge proof of the corresponding public fields must be verified as correct, depending on the availability of the public and explanation request portions in the VRD. Take the following driver's license as an example of validating a current credential. If the VRD specifies the public fields of the public portion, including the dn, gender, and license number, and two zero-knowledge proofs, namely, age > 18 and not expired before December 31, 2020, with explanation requests in the explanation request fields for the date of birth and expiration, respectively, the current credential owner outputs three signatures of the dn, gender, and license number public fields signed by the issuer, and provides the verifier with the three public fields, the three signatures, the issuer's public key owned by the DMV, and the two zero-knowledge proofs with explanation requests in the explanation request fields for the date of birth and expiration.Description If the requested field values ​​for Date of Birth and Expiration are 08 / 08 / 2000 and 02 / 17 / 2025, then after verifying that the three signatures on the three public fields dn, gender, and license number, and the two zero-knowledge proofs, are correct, the verifier verifies that the driver's license proof provided by the current credential holder is valid.

[0043] The second and third conditions are applicable to credentials regardless of whether the credential is a non-certificate credential or a certificate-type credential. The second condition for verifying whether the credential has expired includes verifying the data field "expiration date" in the credential. Regarding the third condition for verifying the credential, a verifier communicating with the distributed ledger network can access the certificate's revocation information in the distributed ledger and verify whether the credential has expired according to the revocation information.

[0044] If it is determined that the digital credential is valid, then step S330 is executed, otherwise step S360 is executed.

[0045] Step S330: Determine whether the issuer issuing the current credential is available and trusted in the credential hierarchy. The issuer issuing the current credential is M layers below the credential manager in the credential hierarchy, where M is an integer greater than 0. The issuer is the next layer above the current credential owner and owns a credential issued by another issuer that is the next layer above the issuer. The credential manager is known to be at the top layer of the digital credential hierarchy. To verify the current credential to be authenticated, not only should the current credential itself be verified as valid, but it also needs to be traced recursively in the credential hierarchy according to the issuer tracing process to determine that the issuer issuing the current credential is also trusted. If the issuer issuing the current credential is unavailable in the credential hierarchy, execute step S360. This is a situation where the issuer issuing the current credential is not found in the credential hierarchy. To be a trusted or untrusted issuer, in one embodiment, an issuer may or may not be found in a pre-approved list. If it is determined that the issuer is available and trusted in the credential hierarchy, then step S350 is performed. If it is determined that the issuer is available but not trusted in the credential hierarchy, then step S340 is performed.

[0046] Step S340: Replace the current credential owner and the current credential with the issuer and the issuer's certificate, respectively, and restart step S320. The current step repeatedly restarts the aforementioned step S320 to verify whether the current credential is valid after the current credential and the current credential owner are replaced.

[0047] Step S350: Determine that the prover's credentials are authenticated and end. After verifying that the current credentials satisfy the three conditions and the availability of a trusted issuer through the issuer tracking process, the verifier determines that the prover's credentials are authenticated without proceeding to step S360.

[0048] Step S360: Determine that the prover's credentials are not authenticated. The prover's credentials are determined to be not authenticated, possibly because one of the three conditions is not met or because the issuer tracing process does not find a trusted issuer.

[0049] The authenticity of the prover's credentials requires that all results of any round of the verification loop represented by steps S320-S340 be positive. If all verification results of steps S320-S340 are positive in the first verification round, it means that the prover's credentials are valid and the issuer of the prover's credentials at the next layer immediately above the prover in the credential hierarchy is trusted. However, if the result of step S330 indicates that the issuer is available but not trusted in the credential hierarchy, a recursive loop is initiated by performing step S340 and then resuming step S320 to track down the next issuer at the next layer above the issuer, and then performing a new round of verification by steps S320-S340 to determine whether the next issuer's credentials are valid and whether the next issuer is trusted. By default, each issuer at the highest layer of the corresponding credential system in the identity hierarchy, such as DMV or CA1 in FIG. 1, is trusted. 1, for example, assume that the verification in the first round finds that the user credential 207 is valid and that the issuer CA3 that issues the user credential 207 is not trusted. If the verification in the second round finds that the issuer credential 105 of the issuer CA3 is valid and that the issuer CA1 is trusted by default, then the verification result in the example verifies that the user credential 207 of the user Bob should be authenticated in two rounds.

[0050] The first and second subjects can be implemented using techniques introduced for credential validation. In addition to validating the existing credentials of the certificate requesting entity, the first subject involved in issuing a certificate-type credential to the certificate requesting entity needs to verify something else in order to further approve the request for issuance of a certificate-type credential. The something else can be the digital signature of the certificate requesting entity.

[0051] As shown with reference to FIG. 4, to address the first subject, a method for issuing certificate-type credentials includes the following steps.

[0052] Step S410: The certificate issuing entity receives a request for a certificate-type credential from a certificate requesting entity. This method involves two parties. The certificate requesting entity is one of two parties requesting to receive a certificate-type credential. The certificate issuing entity is the other party that verifies the certificate requesting entity's credentials and determines whether the certificate requesting entity is eligible to receive a certificate-type credential issued by the certificate issuing entity. The certificate requesting entity and the certificate issuing entity may both be computing devices that communicate with each other. The request for a certificate-type credential is initiated by the certificate requesting entity, includes a public key, and is forwarded to the certificate issuing entity. The public key is generated by the certificate requesting entity according to public key cryptography and is associated with part of a key pair paired with the private key of the key pair.

[0053] Step S420: The certificate issuing entity sends a request for the certificate requesting entity's existing credentials to the certificate requesting entity. In response to the request for certificate-type credentials, the certificate issuing entity sends a request for existing credentials to the certificate requesting entity. The existing credentials may be non-certificate credentials or certificate-type credentials owned by the certificate requesting entity. In one embodiment, if the existing credentials are non-certificate credentials, the non-certificate credentials are any of official ID credentials such as a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card. The type of existing credentials may be specified by the certificate issuing entity in its request.

[0054] Step S430: The certificate requesting entity generates a proof of the existing credential and provides the proof, public key, data, and digital signature to the certificate issuing entity. The proof of the existing credential is provided to verify whether the existing credential is authenticated and includes the aforementioned data for verifying the credential, as described in step S320. The data can be random data generated by the certificate issuing entity individually or by both the certificate issuing entity and the certificate requesting entity, and is signed by the private key of the key pair when the signature is generated. In other words, the data can be generated by the certificate issuing entity individually or by both the certificate issuing entity and the certificate requesting entity. The public key here serves to verify whether the signature was signed by the certificate requesting entity. Therefore, given the signature, public key, data, and proof of the existing credential, approval of the request for issuance of a certificate-type credential can be provided.

[0055] Step S440: The certificate issuing entity verifies whether the existing credentials are authenticated and whether the certificate requesting entity is authorized to recognize the existing credentials. For details regarding the verification of existing credentials, please refer to steps S310 to S360. To verify whether the certificate requesting entity is authorized to recognize the existing credentials, the certificate issuing entity uses a public key to verify whether the signature is signed by the certificate requesting entity. If the existing credentials are authenticated and the certificate requesting entity verifies that it is authorized to recognize the existing credentials, execute step S450. If it does not verify that it is authorized, execute step S460.

[0056] Step S450: The certificate issuing entity generates a certificate-type credential and sends the certificate-type credential to the certificate requesting entity. The certificate-type credential issued to the certificate requesting entity includes the public key of the key pair. According to different applications, the certificate issuing entity may send the certificate-type credential to other locations, such as a proxy or agent computing device, for storage.

[0057] Step S460: The certificate issuing entity denies the request for credentials of the certificate type.

[0058] An example for issuing a club membership certificate type credential is provided below. When a computing device of a club membership issuing company, acting as a certificate issuing entity and hereinafter referred to as the membership issuer, receives a request for a club membership certificate type credential from a computing device of an applicant, acting as a certificate requesting entity and hereinafter referred to as the applicant, the membership issuer sends a request for a digital driver's license to the applicant. The request for club membership also includes a public key of a key pair generated by the applicant and paired with the private key of the key pair. In response to the request for the digital driver's license, the applicant generates a proof of the digital driver's license and sends the public key of the key pair, a signature, the data, and the proof to the membership issuer. After authenticating the digital driver's license and verifying that the applicant signed the data with the public key of the key pair, the membership issuer generates a club membership certificate type credential for the applicant, including the public key, and sends the certificate type credential to the applicant.

[0059] The second subject first verifies whether the document is signed by a document signing entity, assuming that the signer credentials provided by the document signing entity are verified by a credential verification entity to be authentic. The first and second subjects appear to be applications requiring both certificate and digital signature verification. By verifying a signed document in the second subject with initially unavailable certificate-type credentials, both the first and second subjects are potentially linked, and certificate-type credentials can be obtained from the first subject if specified by the credential verification entity in the second subject. For example, in the second subject, a CA certificate required to be verified before verifying a digital signature on a loan application document can be obtained from the first subject using existing credentials such as a digital driver's license, provided that the certificate requesting entity in the first subject also serves as the document signing entity in the second subject.

[0060] As shown in FIG. 5, a first embodiment of a method for digitally signing a document includes the following steps:

[0061] Step S510: The credential verification entity sends a request for a proof of the signer credentials of the document signing entity to the document signing entity and receives the proof of the signer credentials from the document signing entity. The credential verification entity serves to send the request for the proof of the signer credentials to the document signing entity. The credential verification entity serves to receive the proof, verify the signer credentials of the document signing entity, and determine whether the document signing entity is an entitled signer of the document. Both the credential verification entity and the document signing entity may be computing devices that communicate with each other. The proof of the signer credentials is prepared by the document signing entity, and verification of the proof in a subsequent step serves as a condition for proceeding with the document signing. The proof includes the signer public key obtained from the signer credentials. The signer credentials may be credentials other than a certificate or a certificate-type credential owned by the document signing entity. In one embodiment, if the signer credential is a credential other than a certificate, the non-certificate credential is a credential other than an official ID certificate, which may be any of a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card. The type of signer credential may be specified in advance by the credential verification entity to correspond to the type of signed document to be verified. For example, a digital driver's license or a CA certificate is required to verify a digital signature signed on an application for obtaining a medical report.

[0062] Step S520: The credential verification entity verifies whether the signer credential is authenticated. Similarly, for details of verifying whether the signer credential is authenticated, refer to steps S310 to S360. If it is verified that the signer credential should be authenticated, execute step S530. If it is not verified that it is authenticated, execute step S570.

[0063] Step S530: The credential verification entity sends the document to the document signing entity. In this embodiment, the credential verification entity sends the document to the document signing entity only after verifying that the signer credentials should be authenticated.

[0064] Step S540: The document signing entity signs the document using the document signing entity's signer private key paired with the signer public key, and sends the signed document and the signer public key to the credential verifying entity. In one embodiment, if the signer credential is a non-certificate credential, the document is signed by the signer private key associated with the document signing entity's signer distributed identifier (DID) in one of the data fields of the signer credential. In another embodiment, if the signer credential is a certificate-type credential, the document is signed by the signer private key paired with the public key in one of the data fields of the signer credential.

[0065] Step S550: After receiving the signed document and the signer public key, the credential verification entity verifies whether the document is signed by the document signing entity using the signer public key. The signer public key can be linked to the signer distributed identifier (DID) of the document signing entity in the signer credential if the signer credential is a credential other than a certificate, or is linked to the public key in the signer credential if the signer credential is a certificate-type credential. If the verification result is positive, execute step S560. If not, execute step S570.

[0066] Step S560: The authentication verification entity determines that the document signature is successful.

[0067] Step S570: The authentication verification entity determines that the document signature is unsuccessful.

[0068] As shown with reference to Figure 6, unlike the first embodiment described above, which transmits the document to be signed after the signer's credentials have been authenticated, but instead transmits the document before the signer's credentials have been verified to be authenticated, a second embodiment of the method for electronically signing a document includes the following steps: To avoid repetition, descriptions similar to those in the first embodiment will not be repeated in the second embodiment.

[0069] Step S610: The credential verification entity sends the document signing entity a request for a proof of signer credentials of the document signing entity and the document. Note that the request for a proof of signer credentials and the document are sent from the credential verification entity to the document signing entity at the same time.

[0070] Step S620: The document signing entity signs the document using the document signing entity's signer private key and sends the signed document and a proof of signer credentials to the credential verification entity. The proof includes the signer public key paired with the signer private key. The document signing entity needs to send the signed document and the proof of signer credentials to the credential verification entity according to the received request and document.

[0071] Step S630: The credential verification entity verifies whether the signer credential is authenticated. If the signer credential is verified to be authenticated, execute step S640. If the signer credential is not verified to be authenticated, execute step S660.

[0072] Step S640: The credential verification entity verifies whether the document is signed by the document signing entity using the signer public key paired with the signer private key. If the verification result is positive, execute step S650. If not, execute step S660.

[0073] Step S650: The credential verification entity determines that the document signature is successful.

[0074] Step S660: The credential verification entity determines that the document signature is unsuccessful.

[0075] As shown with reference to FIG. 7, a system applicable to the first and second subject matters 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 focuses on a structural description instead of the functionality already discussed in the previous manner. While the dots between the two issuer devices 704 and the links to the first computing device 702 and the database 705 illustrate an embodiment in which one of the multiple issuer devices is trusted, the at least one issuer device 704 may also include other embodiments, such as when one issuer device is trusted, as shown in FIG. 8, or when there are no issuer devices at all, as shown in FIG. 9.

[0076] The distributed ledger network 701 maintains a distributed ledger that stores revocation information associated with issued credentials. A first computing device 702 is communicatively coupled to the distributed ledger network 701 and may act as a certificate issuing entity in a first subject or a credential verifying entity in a second subject. A second computing device 703 is communicatively coupled to the first computing device 702 and may act as a certificate requesting entity in the first subject or a document signing entity in the second subject. At least one issuer device 704, a type of flexible part of the system that varies depending on the parent-child issuing relationship, is communicatively coupled to the first computing device 702 and is provided with and linked to the credentials of the second computing device when a parent-child issuing relationship is available. The parent-child issuing relationship specifies that one of the at least one issuer devices 704 issues a credential to the second computing device 702, and each of the remaining issuer devices 704 issues another credential to another one of the at least one issuer devices 704. In other words, if a parent-child issuing relationship does not exist, at least one issuer device 704 is not available in the system. A situation where an issuer device 704 is missing can arise from credential forgery, where the fake credential results in no issuer device 704 being linked to the fake credential according to the parent-child issuing relationship. If a parent-child relationship exists, at least one issuer device 704 is linked to the credential of the second computing device 703, and the at least one issuer device 704 and its at least one credential are arranged in a credential hierarchy. When an issuer in a credential hierarchy, each of the first computing device 702, the second computing device 703, and the at least one issuer device 704 can maintain a distributed ledger.The database 705 is communicatively coupled to the second computing device 703 and the at least one issuer device 704 and stores issued credentials including credentials of the second computing device 703 and the at least one issuer device 704 accessible to the second computing device 703 and the at least one issuer device 704, respectively.

[0077] 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 trusted, upon receiving a request to verify whether any credential of the at least one issuer device 704 is valid, the issuer device 704 will send a proof to the first computing device 702 according to its credential for verification.

[0078] From the above, the present invention is advantageous in eliminating the tedious and repetitive KYC process each time a new certificate-type credential is requested and a digital signature on a document is verified. This is because the issuance of a new certificate-type credential, regardless of whether it is a certificate-type credential or a non-certificate credential, is permitted and the document signature can be verified using existing credentials. In addition to eliminating the KYC process, a combined hierarchical credential hierarchy has multiple credential systems, each containing either certificate-type or non-certificate credential. Users / issuers can obtain different credentials from various credential systems, allowing them to freely choose their preferred type of identity or user / issuer credential. Each issuer in the credential hierarchy of the present invention can maintain a distributed ledger, so that a single point of failure problem will only invalidate one entity's credential in the credential hierarchy. In the case of a credential related to a compromised credential based on a parent-child issuing relationship, the issuer of the credential only suffers the loss of the credential and is still identifiable by other credentials in the credential hierarchy. Furthermore, to qualify as an authenticated credential, it relies on a two-step verification: the credential is verified to be valid, and one of at least one issuer linked to the credential is verified to be trusted according to a parent-child relationship. Such two-step verification ensures more secure authentication of the credential.

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

Claims

1. 1. A method for issuing digital credentials of certificate type, comprising: (a) receiving, by a certificate issuing entity, a request for the digital credential of the certificate type from a certificate requesting entity, the request for the digital credential of the certificate type including a public key generated by the certificate requesting entity; (b) the certificate issuing entity sending to the certificate requesting entity a request for the certificate requesting entity's existing digital credentials; (c) after the pre-existing digital credential is authenticated and the certificate requesting entity verifies that it is authorized to recognize the pre-existing digital credential, the certificate issuing entity generates the digital credential of the certificate type that includes the public key of the certificate requesting entity; and (d) the certificate issuing entity sending the digital credential of the certificate type to the certificate requesting entity.

2. 2. The method of claim 1, wherein the pre-existing digital credential is of a type other than a certificate or of the certificate type.

3. 3. The method of claim 2, wherein if the existing digital credential is of a type other than the certificate, the existing digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card.

4. 2. The method of claim 1, wherein the digital credential of the certificate type is associated with a document of one type.

5. To verify whether the existing digital credential is authenticated and the certificate requesting entity is authorized to accept the existing digital credential, step (c) further comprises: (c1) initializing a current credential and a current credential holder to said existing digital credential and said certificate requesting entity, respectively; (c2) determining whether the current credentials are valid; and (c3) if determining that the current credential is valid, determining whether the issuer issuing the current credential is available and trusted in a digital credential hierarchy, wherein the issuer is M tiers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer is the next tier above the current credential owner, and holds a digital credential issued by another issuer the next tier above the issuer, and the credential manager is at the top tier of the digital credential hierarchy; (c4) if it determines that the issuer is available but not trusted in the digital credential hierarchy, replacing the current credential holder and the current credential with the issuer and the issuer's digital credential, respectively, and resuming step (c2); (c5) if it determines that the issuer is available and trusted in the digital credential hierarchy, determining that the existing digital credential is authenticated and performing step (c7); (c6) if the determination results of the steps (c2) and (c3) are negative, determining that the existing digital credential is not authenticated; (c7) if determining that the existing digital credential is authenticated, determining whether the certificate requesting entity is authorized to recognize the existing digital credential.

6. Between the step (b) and the step (c), 6. The method of claim 5, further comprising: (e) the certificate requesting entity generating a proof of the existing digital credential and providing the proof, the public key, data, and a digital signature to the certificate issuing entity, wherein the data is random data generated by the certificate issuing entity individually or by both the certificate issuing entity and the certificate requesting entity, and signed with a private key paired with the public key generated by the certificate requesting entity to generate the digital signature.

7. If it is determined that the current credentials are valid, step (c2) comprises: (c21) verifying that a proof of the current credential is valid, the proof of the current credential being provided by the current credential owner and including at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof that explains at least one explained-upon field, and a public key associated with the DID of the issuer of the current credential in accordance with a Verification Requirements Document (VRD) from the certificate issuing entity, wherein the certificate issuing entity determines that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct; 7. The method of claim 6, further comprising: (c22) verifying that the current credentials are not expired or revoked.

8. 8. The method of claim 7, wherein in step (c22), the certificate issuing entity maintains a distributed ledger and interacts with a distributed ledger network communicatively connected to the certificate issuing entity to access revocation information in the distributed ledger and verify that the current credential has not expired according to the revocation information.

9. 7. The method of claim 6, wherein if in step (c7) the certificate requesting entity is determined to be authorized to recognize the existing digital credential, the certificate issuing entity verifies that the digital signature was signed by the certificate requesting entity using the public key generated by the certificate requesting entity.

10. 7. The method of claim 6, wherein in step (c3), if the certificate issuing entity determines that the issuer is in a pre-approved list or that the issuer is the credential manager, the certificate issuing entity determines that the issuer is trusted.

11. 1. A method for electronically signing a document, comprising: (f) the credential verifying entity sending a request to the document signing entity for a proof of the signer digital credential of the document signing entity and receiving the proof of the signer digital credential from the document signing entity, the proof including the signer public key associated with the signer digital credential; (g) the credential verification entity verifies whether the signer digital credential is authenticated, and if the signer digital credential is verified to be valid, sends the document to the document signing entity; (h) the credential verification entity receives from the document signing entity the document signed with the signer public key and a signer private key paired with the signer public key, and verifies whether the document was signed by the document signing entity using the signer public key.

12. 12. The method of claim 11, wherein the signer digital credential is of a type other than a certificate or of a certificate type.

13. 13. The method of claim 12, wherein if the signer digital credential is of a type other than the certificate, the signer digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

14. 13. The method of claim 12, wherein in step (h), the credential verification entity receives the document signed with the signer private key associated with a signer distributed identifier (DID) of the document signing entity in the signer digital credential and the signer public key paired with the signer private key, and if the signer digital credential is of a type other than the certificate, verifies whether the document was signed by the document signing entity using the signer public key.

15. 13. The method of claim 12, wherein in step (h), the credential verification entity receives from the document signing entity the document signed with the signer public key and the signer private key paired with the signer public key in the signer digital credential, and if the signer digital credential is of the certificate type, verifies whether the document was signed by the document signing entity using the signer public key.

16. To verify whether the signer digital credential is authenticated, step (g) comprises: (g1) initializing a current credential and a current credential owner to said signer digital credential and said document signing entity; (g2) determining whether the current credentials are valid; and (g3) if determining that the current credential is valid, determining whether an issuer issuing the current credential is available in a digital credential hierarchy, wherein the issuer is M tiers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer is the next tier above the current credential owner, and holds a digital credential issued by another issuer the next tier above the issuer, and the credential manager is at the top tier of the digital credential hierarchy; (g4) if it determines that the issuer is available but not trusted in the digital credential hierarchy, replacing the current credential holder and the current credential with the issuer and the issuer's digital credential, respectively, and resuming step (g2); (g5) determining that the signer digital credential is authenticated if the issuer is determined to be available and trusted in the digital credential hierarchy; and (g6) determining that the signer digital credential is not authenticated if the determination results of either step (g2) or step (g3) are negative.

17. If it is determined that the current credentials are valid, step (g2) (g21) verifying that a proof of the current credential is valid, the proof of the current credential being provided by the current credential owner and including at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof that explains at least one explained-upon field, and a public key associated with the DID of the issuer of the current credential according to a Verification Requirements Document (VRD) from the credential verifying entity, the certificate issuing entity determining that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct; 17. The method of claim 16, further comprising: (g22) verifying that the digital credential is not expired or revoked.

18. 18. The method of claim 17, wherein in step (g22), the credential verification entity maintains a distributed network and interacts with a distributed ledger network communicatively connected to the credential verification entity to access revocation information in the distributed ledger and verify that the current credential has not expired according to the revocation information.

19. 12. The method of claim 11, wherein the signer digital credentials are designated by the credential verification entity to be associated with the document type.

20. 17. The method of claim 16, wherein if in step (g3) the issuer is determined to be in a pre-approved list or the issuer is the credential manager, the credential verification entity determines that the issuer is trusted.

21. 1. A method for electronically signing a document, comprising: (i) a credential verifying entity sending a document to a document signing entity a request for a proof of the document signing entity's signer digital credential, the proof including a signer public key associated with the signer digital credential; (j) the credential verifying entity receiving from the document signing entity the proof of the signer digital credential and the document signed with the signer private key paired with the signer public key; (k) the credential verification entity verifying whether the signer digital credential is authenticated, and if the signer digital credential is authenticated, verifying that the document was signed by the document signing entity using the signer public key.

22. 22. The method of claim 21, wherein the signer digital credential is of a certificate type or a non-certificate type.

23. 23. The method of claim 22, wherein if the signer digital credential is of a type other than the certificate, the signer digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

24. 23. The method of claim 22, wherein in step (j), the credential verifying entity receives the document signed with the signer private key associated with a signer distributed identifier (DID) of the document signing entity in the signer digital credential and the signer public key paired with the signer private key, and if the signer digital credential is of a type other than the certificate, verifies whether the document was signed by the document signing entity using the signer public key.

25. 23. The method of claim 22, wherein in step (j), the credential verification entity receives from the document signing entity the document signed with the signer public key and the signer private key paired with the signer public key in the signer digital credential, and if the signer digital credential is of the certificate type, verifies whether the document was signed by the document signing entity using the signer public key.

26. To verify whether the signer digital credential is authenticated, step (k) comprises: (k1) initializing a current credential and a current credential owner to said signer digital credential and said document signing entity; (k2) determining whether the current credentials are valid; and (k3) if determining that the current credential is valid, determining whether an issuer issuing the current credential is available in a digital credential hierarchy, wherein the issuer is M tiers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer is the next tier above the current credential owner, and holds a digital credential issued by another issuer the next tier above the issuer, and the credential manager is at the top tier of the digital credential hierarchy; (k4) if it determines that the issuer is available but not trusted in the digital credential hierarchy, updating the current credential holder and the current credential with the issuer and the issuer's digital credential, respectively, and resuming step (g2); (k5) determining that the signer digital credential is authenticated if the issuer is determined to be available and trusted; 22. The method of claim 21, further comprising: (k6) determining that the signer digital credential is not authenticated if the determination results of either step (k2) or step (k3) are negative.

27. If it is determined that the current credentials are valid, step (k2) (k21) verifying that a proof of the current credential is valid, the proof of the current credential being provided by the current credential owner and including at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof that explains at least one explained-upon field, and a public key associated with the DID of the issuer of the current credential according to a Verification Requirements Document (VRD) from the credential verifying entity, the certificate issuing entity determining that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct; 27. The method of claim 26, further comprising: (k22) verifying that the current credentials are not expired or revoked.

28. 28. The method of claim 27, wherein in step (k22), the credential verification entity maintains a distributed network and interacts with a distributed ledger network communicatively connected to the credential verification entity to access revocation information in the distributed ledger and verify that the current credential has not expired according to the revocation information.

29. 22. The method of claim 21, wherein the signer digital credentials are designated by the credential verification entity to be associated with the document type.

30. 27. The method of claim 26, wherein if in step (k3) the issuer is determined to be in a pre-approved list or the issuer is the credential manager, the credential verification entity determines that the issuer is trusted.

31. 1. A system for issuing certificate-type digital credentials and electronically signing documents, comprising: a distributed ledger network that maintains a distributed ledger that stores revocation information associated with issued digital credentials; a first computing device communicatively coupled to the distributed ledger network; a second computing device communicatively coupled to the first computing device; at least one issuer device communicatively coupled to the first computing device that is provided and linked to a digital credential of the second computing device when a parent-child issuing relationship exists, the parent-child issuing relationship existing when one issuer device of the at least one issuer device issues the digital credential to the second computing device and each of the remaining issuer devices issues another digital credential to another one of the at least one issuer device; a database communicatively connected to the second computing device and the at least one issuer device, the database storing issued digital credentials including the digital credentials of the second computing device and the at least one issuer device accessible to the second computing device and the at least one issuer device, respectively.

32. 32. The system of claim 31 , wherein the first computing device receives a request for the digital credential of the certificate type from the second computing device, sends a request for an existing digital credential to the second computing device, verifies whether the existing digital credential is authenticated and the second computing device is authorized to recognize the existing digital credential, and if the existing digital credential is authenticated and the second computing device is authorized to recognize the existing digital credential, generates the digital credential of the certificate type and sends the digital credential of the certificate type to the second computing device, wherein the request for the digital credential of the certificate type includes a public key generated by the second computing device.

33. 33. The system of claim 32, wherein the pre-existing digital credential is of a type other than a certificate or of the certificate type.

34. 34. The system of claim 33, wherein if the existing digital credential is of a type other than the certificate, the existing digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card.

35. 33. The system of claim 32, wherein the digital credential of the certificate type is associated with a document of one type.

36. If the existing digital credential is authenticated and the second computing device verifies whether it is authorized to recognize the existing digital identity, the first computing device initializes a current credential and a current credential owner to the existing digital credential and the second computing device, determines whether the current credential is valid, and if it determines that the current credential is valid, determines whether an issuer device of the at least one issuer device that issues the current credential is available and trusted in a digital credential hierarchy, and determines that the issuer device is available but not trusted in the digital credential hierarchy. if so, replace the current credential holder and the current credential with a digital credential of the issuer device and the issuer device, respectively, and recursively loop back to determine whether the current credential is valid until the issuer device is available and trusted in the digital credential hierarchy or is no longer available in the digital credential hierarchy; if it determines that the issuer device is available and trusted in the digital credential hierarchy, determine that the existing digital credential is authenticated; and if it determines that the existing digital credential is authenticated, determine whether the second computing device is authorized to accept the existing digital credential; 33. The system of claim 32, wherein the issuer device or its digital credential is M layers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer device or its digital credential is at the next layer above the current credential owner or its digital credential, the issuer device owns the digital credential issued by another one of the at least one issuer devices that is at the next layer above the issuer device, and the credential manager or its digital credential is at the top layer of the digital credential hierarchy.

37. 37. The system of claim 36, wherein after the first computing device sends the request for the existing digital credential and the public key to the second computing device, the second computing device generates a proof of the existing digital credential and provides the proof of the existing digital credential, the public key, data, and a digital signature to the first computing device, the data being random data generated by the first computing device individually or by both the first computing device and the second computing device, and signed by the second computing device with a private key generated by the second computing device and paired with the public key to generate the digital signature.

38. If the first computing device determines that the current credentials are valid, it verifies that a proof of the current credentials is valid, and then verifies that the current credentials are not expired or revoked; 38. The system of claim 37, wherein the proof of the current credential is provided by the current credential owner and includes at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof each accounting for at least one accountable field, and a public key associated with the DID of the issuer of the current credential in accordance with a Verification Requirements Document (VRD) from the first computing device, and wherein the first computing device determines that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct.

39. 39. The system of claim 38, wherein the first computing device interacts with the distributed ledger network to access revocation information in the distributed ledger and verify that the current credential to be verified has not expired according to the revocation information.

40. 38. The system of claim 37, wherein if the second computing device determines that the existing digital credential is legitimate to be recognized, the first computing device verifies that the digital signature was signed by the second computing device using the public key generated by the second computing device.

41. 37. The system of claim 36, wherein if the first computing device determines that the issuer device is trusted, the first computing device determines that the issuer device is in a pre-approved list or that the issuer device is the credential manager.

42. 32. The system of claim 31 , wherein the first computing device sends the request for a proof of the signer digital credential of the second computing device to the second computing device, receives the proof of the signer digital credential from the second computing device, verifies whether the signer digital credential is authenticated, and if the first computing device verifies that the signer digital credential is authenticated, sends a document to the second computing device, receives from the second computing device the document included in the proof and signed with a signer private key paired with a signer public key associated with the signer digital credential and the signer public key, and verifies whether the document was signed by the second computing device using the signer public key.

43. 43. The system of claim 42, wherein the signer digital credential is of a type other than the certificate or of the certificate type.

44. 44. The system of claim 43, wherein the signer digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card.

45. 44. The system of claim 43, wherein the first computing device receives the document signed with the signer private key associated with a signer distributed identifier (DID) of the second computing device in the signer digital credential and the signer public key paired with the signer private key, and if the signer digital credential is of a type other than the certificate, verifies whether the document was signed by the second computing device using the signer public key.

46. 44. The system of claim 43, wherein the first computing device receives from the second computing device the document signed with the signer public key and the signer private key paired with the signer public key in the signer digital credential, and if the signer digital identity is of the certificate type, verifies whether the document was signed by the second computing device using the signer public key.

47. and if the first computing device determines that the signer digital credential is of the certificate type and the first computing device determines that the signer digital credential is authenticated, the first computing device initializes a current credential and a current credential owner to the signer digital credential and the second computing device, determines whether the current credential is valid, and if the first computing device determines that the current credential is valid, determines whether an issuer device of the at least one issuer device that issues the current identity is available and trusted in a digital credential hierarchy, and if the first computing device determines that the issuer device is available but not trusted in the digital credential hierarchy, replaces the current credential owner and the current credential with the issuer device and the issuer device's digital credential, respectively, and recursively loops back to determine whether the current credential is valid until the issuer device is available and trusted in the digital credential hierarchy or is no longer available in the digital credential hierarchy, and if the first computing device determines that the issuer device is available and trusted in the digital credential hierarchy, determines that the signer digital credential is authenticated.

44. The system of claim 43, wherein the issuer device or its digital credential is M layers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer device or its digital credential is at the next layer above the current credential owner or its digital credential, the issuer device is issued by another one of the at least one issuer devices that is at the next layer above the issuer device, and the credential manager or its digital credential is at the top layer of the digital credential hierarchy.

48. If the first computing device determines that the current credentials are authenticated, it verifies that a proof of the current credentials is valid, and then verifies that the current credentials are not expired or revoked; 48. The system of claim 47, wherein the proof of the current credential is provided by the current credential owner and includes at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof each accounting for at least one accountable field, and a public key associated with the DID of the issuer device of the current credential in accordance with a Verification Requirements Document (VRD) from the first computing device, and wherein the first computing device determines that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct.

49. 49. The system of claim 48, wherein the first computing device interacts with the distributed ledger network to access revocation information in the distributed ledger and verify that the current credential to be verified has not expired according to the revocation information.

50. 43. The system of claim 42, wherein the first computing device specifies that the signer digital credential is associated with the document type.

51. 48. The system of claim 47, wherein if the first computing device determines that the issuer device is trusted, the first computing device determines that the issuer device is in a pre-approved list or that the issuer device is the credential manager.

52. 32. The system of claim 31 , wherein the first computing device sends a request for a proof of a signer digital credential and a document to the second computing device, receives the proof of the signer digital credential and the document included in the proof and signed by a signer private key paired with a signer public key from the second computing device, verifies whether the signer digital credential is authenticated, and if it verifies that the signer digital credential is authenticated, verifies whether the document was signed by the second computing device using the signer public key.

53. 53. The system of claim 52, wherein the signer digital credential is of a type other than the certificate or of the certificate type.

54. 54. The system of claim 53, wherein the signer digital credential is an official ID digital credential that is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state-issued ID card.

55. 54. The system of claim 53, wherein the first computing device receives the document signed with the signer private key associated with a signer distributed identifier (DID) of the second computing device in the signer digital credential and the signer public key paired with the signer private key, and if the signer digital credential is of a type other than the certificate, verifies whether the document was signed by the second computing device using the signer public key.

56. 54. The system of claim 53, wherein the first computing device receives from the second computing device the document signed with the signer public key and the signer private key paired with the signer public key in the signer digital credential, and if the signer digital credential is of the certificate type, verifies whether the document was signed by the second computing device using the signer public key.

57. If the first computing device determines that the signer digital identity is authenticated, the first computing device initializes a current credential and a current credential owner to the signer digital credential and the second computing device, determines whether the current credential is valid, and if it determines that the current credential is valid, determines whether an issuer device of the at least one issuer device that issues the current credential is available and trusted in a digital credential hierarchy, and if it determines that the issuer device is available but not trusted, replaces the current credential owner and the current credential with the issuer device and the issuer device's digital credential, respectively, and recursively loops back to determine whether the current credential is valid until the issuer device is available and trusted in the digital credential hierarchy or is no longer available in the digital credential hierarchy, and if it determines that the issuer device is available and trusted in the digital credential hierarchy, determines that the signer digital credential is authenticated; 54. The system of claim 53, wherein the issuer device or its digital identity is M layers below a credential manager in the digital credential hierarchy, where M is an integer greater than 0, the issuer device or its digital credential is at the next layer above the current credential owner or its digital credential, the issuer device owns the digital credential issued by another issuer device of the at least one issuer device that is at the next layer above the issuer device, and the credential manager or its digital credential is at the top layer of the digital credential hierarchy.

58. If it determines that the current credentials are valid, the first computing device verifies that a proof of the current credentials is valid, and then verifies that the current credentials are not expired or revoked; 58. The system of claim 57, wherein the proof of the current credential is provided by the current credential owner and includes at least one of an option including at least one public field and at least one digital signature for each of the public fields, and another option including at least one zero-knowledge proof each claiming an explanation for at least one claimed field, and a public key associated with the DID of the issuer device of the current credential in accordance with a Verification Requirements Document (VRD) from the first computing device, and wherein the first computing device determines that the current credential is valid by verifying that at least one option of the at least one digital signature for the at least one public field and the at least one zero-knowledge proof is correct.

59. 59. The system of claim 58, wherein the first computing device interacts with the distributed ledger network to access revocation information in the distributed ledger and verify that the current credential to be verified has not expired according to the revocation information.

60. 53. The system of claim 52, wherein the first computing device specifies that the signer digital credential is associated with the document type.

61. 58. The system of claim 57, wherein if the first computing device determines that any of the at least one issuer device is trusted, the first computing device determines that the issuer device is in a pre-approved list or that the issuer device is the credential manager.

Images