Verification of digital credentials and digital signatures

Abstract

Methods and systems including issuing authentication type credentials and electronically signing documents are disclosed. Both applications need to verify whether a certifier or signer of a digital credential is verified. Authorization of the digital certificate requires dual verification where the digital certificate must be verified to be valid and one of the at least one issuer connected to the digital certificate according to the parent-child relationship must be verified to be trustworthy. In order to verify that the digital certificate is valid, the validity of the proof, the expiration date and the revocation information associated with the digital certificate should be verified to be valid. The dual verification is safer in the verification of the digital credentials, and the digital credentials of the non-authentication type and the digital credentials of the authentication type can be managed by a digital identity hierarchy, so that the ownership of a plurality of digital credentials of one entity can be realized in a distributed account book technology to effectively avoid single-point failure.

Description

Technical Field

[0001] The present invention relates to a method and system for verifying credentials and signatures, and more specifically, to a method and system for verifying a digital signature and digital certificate of a signatory when signing a document and a digital signature and digital certificate of a certifier requesting an authentication type digital certificate. Background Art

[0002] A certificate authority (CA) is an organization that verifies identities and binds them to a digital certificate through a pair of cryptographic keys. As the most commonly used method for network public key infrastructures (PKIs), any issuing entity in a CA is an entity that issues digital certificates, where the digital certificate authenticates the ownership of the public key through the named subject of the certificate. The CA hierarchy starts with a root CA at the top level, and there are several intermediate CAs under the root CA. The root CA will issue intermediate CA certificates, which will then issue other CAs one level lower, or sign end entity certificates.

[0003] CA is a trusted third party that authorizes public keys to entities in the network. Most network services are secure through keys signed by CA.

[0004] As a single dominant trust hierarchy, the CA hierarchy has problems and limitations because the network identity of entities in the CA hierarchy needs to be verified by the CA or an intermediate CA in the CA hierarchy, sometimes a private company or government. Another problem is that when issuing a certificate to an entity / organization, the CA must personally perform the identity verification of the entity / organization to ensure that the entity / organization they are certifying is indeed the certified entity it claims to be. This step is usually called the know your customer (KYC) process. Traditionally, when an entity needs to apply for multiple certificates from different CAs, the KYC process needs to be repeated for each application to different CAs. In addition, this centralized trust hierarchy is susceptible to single points of failure occurring in either the intermediate CA or the end entity, and when compromised, catastrophic results may occur, as shown in the case of DigiNotar. Summary of the invention

[0005] The purpose of the present invention is to provide a method and system for issuing digital certificates and electronically signed documents, so as to eliminate the KYC process and single point failure of the CA system and improve the security of digital identity authentication.

[0006] To achieve the above-mentioned purpose, the method for issuing a digital certificate of the authentication type includes:

[0007] The certification issuing entity receives a request for the digital certificate of the certification type from the certification requesting entity, wherein the request for the digital certificate of the certification type includes a public key generated by the certification requesting entity;

[0008] The certification issuing entity sends a request for the certification requesting entity's existing digital certificate to the certification requesting entity;

[0009] The certification issuing entity sends a request for the certification requesting entity's existing digital certificate to the certification requesting entity;

[0010] The certification issuing entity verifies whether the existing digital certificate has been verified and whether the certification requesting entity has the right to endorse the existing digital certificate, and when it is verified that the existing digital certificate is verified and the certification requesting entity has the right to endorse the existing digital certificate, generates the digital certificate of the certification type containing the public key of the certification requesting entity; and

[0011] The certification issuing entity sends the digital certificate of the certification type to the certification requesting entity.

[0012] In one embodiment, in order to verify whether the existing digital certificate is verified and whether the authentication requesting entity has the right to endorse the existing digital certificate, the method further includes:

[0013] Initializing the current credential and the current credential owner to the existing digital credential and the authentication request entity respectively;

[0014] Determine whether the current credential is valid;

[0015] When the current certificate is deemed valid, it is determined whether the issuer of the current certificate is available and trusted in the digital certificate hierarchy, wherein the issuer is below the M-layer of the certificate manager in the digital identity hierarchy, where M is an integer greater than zero, the issuer is one layer above the current certificate owner and has a digital certificate issued by another issuer one layer above the issuer, and the certificate manager is at the topmost layer in the digital certificate hierarchy.

[0016] When the issuer is determined to be usable but untrustworthy in the digital certificate hierarchy, the current certificate owner and the current certificate are replaced with the issuer and the issuer's digital certificate, respectively, and the determination of whether the current certificate is valid is re-executed;

[0017] When the issuer is deemed to be available and trustworthy in the digital certificate hierarchy, the existing digital certificate is deemed to be verified and the verification request entity is determined to be authorized to endorse the existing digital certificate;

[0018] The existing digital certificate is deemed to be unverified when any of the determinations that the existing certificate is valid and that the issuer of the current certificate is valid and trustworthy in the digital certificate hierarchy fails; and

[0019] When it is determined that the existing digital certificate is verified, determine whether the authentication requesting entity has the authority to endorse the existing digital certificate.

[0020] In order to achieve the aforementioned purpose, the method for electronically signing a document includes:

[0021] The certificate verifying entity sends a request for certification of the signer digital certificate of the document signing entity to the document signing entity, and the document signing entity receives the certification of the signer digital certificate, wherein the certification includes the signer public key associated with the signer digital certificate;

[0022] The certificate verification entity verifies whether the signer digital certificate is verified, and when the signer digital certificate is confirmed to be valid, sends the document to the document signing entity; and

[0023] The certificate verification entity receives the file signed by the signer's private key paired with the signer's public key and the signer's public key from the file signing entity, and verifies whether the file is signed by the file signing entity through the signer's public key.

[0024] In one embodiment, in order to verify whether the signer digital certificate is verified, the method further comprises:

[0025] Initialize the current credential and the current credential owner to the signer credential and the document signing entity;

[0026] Determine whether the current credential is valid;

[0027] When the current certificate is determined to be valid, determine whether the issuer that issued the current certificate is available and trusted in the digital certificate hierarchy, wherein the issuer is below the M-layer of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer is one layer above the current certificate owner, and has a digital certificate issued by another issuer one layer above the issuer, and the certificate manager is at the top of the digital certificate hierarchy;

[0028] When the issuer is determined to be usable but untrustworthy in the digital certificate hierarchy, the current certificate owner and the current certificate are replaced with the issuer and the issuer's digital certificate, respectively, and the determination of whether the current certificate is valid is re-executed;

[0029] When the issuer is deemed to be available and trustworthy in the digital certificate hierarchy, the signer digital certificate is deemed to be verified; and

[0030] The signer digital certificate is deemed unverified when any of the determinations of whether the current certificate is valid and whether the issuer of the current certificate is available and trustworthy in the digital hierarchy fails.

[0031] To reflect the foregoing, each method adopts a two-factor authentication technique, which includes that the digital certificate is valid regardless of whether it is a certification type or a non-certification type, and verifies that the issuer connected to the digital certificate based on the parent-child issuance relationship is trustworthy. Since the two-factor authentication technique can be used as a prerequisite for the application of issuing certification type certificates and verifying signed documents, the KYC process that repeatedly troubles the prover and verifier in the application can be eliminated. At the same time, through the two-factor authentication technique, the digital certificate can be more securely verified. In addition, the flexible selection of cert-type certificates and non-cert certificates used for verification can sequentially reflect that any entity can have multiple digital identities in the identity hierarchy, which can have cert-type certificates, non-cert certificates, or both. The identity hierarchy can uniformly accommodate those cert-type certificates and non-cert certificates.

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

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

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

[0035] The second computing device is communicatively connected to the first computing device.

[0036] The parent-child issuance relationship exists when the parent-child issuance relationship exists and when provided for communication connection to the first computing device, the at least one issuer device is provided and connected to the digital signature of the second computing device, when the issuer device of the at least one issuing device issues the digital certificate to the second computing device, and when each of the remaining issuing devices issues another digital certificate to another device of the at least one issuing device.

[0037] The database is communicatively connected to the second computing device and the at least one issuer device, and stores issued digital certificates, which include the digital certificates of the second computing device and the at least one issuer device and can be accessed by the second computing device and the at least one issuer device, respectively.

[0038] Taking into account the structural features of the first computing device acting as an authentication issuing entity and an authentication verifying entity, the second computing device acting as an authentication requesting entity and a document signing entity, and at least one issuer device satisfying a parent-child issuance relationship and being associated with the digital certificate to be verified, the aforementioned system enables it to execute the application of issuing digital certificates and electronically signing documents as described in the aforementioned method. Therefore, the system can also obtain the benefits of progress in the KYC process achieved by improving the security of the existing certificates and digital identity authentication of the prover. As for single point failure, because this system is implemented on distributed ledger technology, system damage caused by any single point failure can be minimized without further affecting the part of the system that is not harmed by the failure.

[0039] Other objects, advantages or novel features of the invention will become more apparent from the following detailed description with reference to the corresponding drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 is a schematic diagram showing an embodiment of a digital identity hierarchy according to the present invention;

[0041] Figure 2 is a schematic diagram showing another embodiment of the digital identity hierarchy according to the present invention;

[0042] Figure 3 is a flow chart showing the verification of the authenticity of a digital identity according to the present invention;

[0043] Figure 4 is a flow chart showing a method for issuing a digital certificate according to the present invention;

[0044] Figure 5 is a flow chart showing an embodiment of a method for electronically signing a document according to the present invention;

[0045] Figure 6 is a flow chart showing another embodiment of the method for electronically signing a document according to the present invention;

[0046] Figure 7 is a schematic diagram showing the network architecture of a first embodiment of a system for issuing digital certification and electronically signed documents according to the present invention;

[0047] Figure 8is a schematic diagram showing a network architecture of a second embodiment of a system for issuing digital certificates and electronically signed documents according to the present invention; and

[0048] Fig. 9 FIG. 4 is a schematic diagram showing the network architecture of a third embodiment of a system for issuing digital certificates and electronically signed documents according to the present invention. DETAILED DESCRIPTION

[0049] Even if it is used in conjunction with the detailed description of certain specific embodiments of this field, the terms used in the following description are intended to be interpreted in the broadest reasonable manner. Although specific words may be emphasized below, any term intended to be interpreted in any limiting manner will be defined in this implementation section.

[0050] The embodiments described below may be implemented by programmable circuitry programmed or configured by software and / or firmware, or may be implemented entirely by special-purpose circuitry, or may be implemented in a combination of these methods. Such special-purpose circuitry (if any) may include forms such as one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), etc. In the following description, the term digital certificate may be a digital certificate that is later paraphrased as a non-authenticated digital certificate, or may be a digital certificate that is later paraphrased as an authenticated digital certificate, and an entity, such as an authenticator, a signer, an issuer, a verifier, an authentication requesting entity, an authentication issuing entity, a document signing entity, or a certificate verifying 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 computer, or other similar devices.

[0051] The described embodiments are related to one or more methods and systems for verifying the digital signature and digital certificate of a prover when requesting an authentication type digital certificate, and for signing a document, and may focus primarily on a first subject for issuing an authentication type digital certificate to an authentication requesting entity, and a second subject for verifying a document signed by a document signing entity. An entity's authentication type digital certificate is an electronic data structure from another trusted entity that guarantees the validity and authenticity of a public key that binds the entity to its public key. The entity may be an institution, an individual, a computer program, a network address, or other, and is a digital identity identification certificate that confirms that the entity is the entity it claims to be. In order to distinguish it from the authentication type digital certificate traditionally referred to as a digital certificate, all other digital certificates may be referred to as non-authentication type digital certificates. Generally speaking, both authentication type digital certificates and non-authentication type digital certificates are digital certificates, and basically authentication type digital certificates may be regarded as a special type of digital certificate. For simplicity, the word "digital" will be removed from "non-authentication type digital certificate", "authentication type digital certificate" and "digital signature". As a general term for non-authentication type certificates and authentication type certificates, "digital certificate" can also be named in a simpler form as "credential". The terms "certificate" or "credential" in this article can be replaced by the abbreviation "cert" or "cred". This abbreviation can also be used for entities that handle requests or issue cert-type certificates, such as cert-issuing entities or cert-requesting entities. The above naming convention will be adopted hereinafter. In order to issue a cert-type digital certificate to a cert-requesting entity in the first subject, the cert-issuing entity needs to receive a certificate generated based on the existing certificate of the cert-requesting entity and the public key of the cert-requesting entity associated with the existing certificate. The cert-issuing entity must verify that the existing certificate is verified and that the cert-requesting entity endorses the existing certificate as an authentic signer. In the first part of verifying whether the existing credential is verified, the first step needs to check whether the existing credential is valid by verifying that the proof associated with the existing credential is valid and the existing credential has not expired or been revoked. Then the next step can be started to verify whether one of the at least one issuer recursively traced and connected to the existing credential based on the parent-child issuing relationship is trustworthy to complete the verification of the first part.The parent-child issuance relationship defines that one of the at least one issuer issues an existing certificate, and each of the remaining issuers issues another certificate to another of the at least one issuer. This process of tracking the at least one issuer continues until a trusted issuer is found or until no issuer is found at all. After identifying a trusted issuer, the existing certificate is verified in the first part. In the second part for verifying whether the cert-requesting entity is a trusted signer to endorse the existing certificate, the cert-issuing entity needs to verify the signature of the cert-requesting entity through the public key of the cert-requesting entity, and the signature is generated to endorse the existing certificate. When the first part and the second part are correct for the verification of the existing certificate, the cert-issuing entity generates a cert-type certificate including the public key of the cert-requesting entity, and then issues the cert-type certificate to the cert-requesting entity. In order to verify the signed document in the second subject, the cred-verification entity receives the certificate generated based on the signer certificate of the document signing entity from the document signing entity, and verifies whether the signer certificate is verified. After the signer certificate is verified, the cred-verification entity then sends the document to the document signing entity, and the document signing entity receives the signed document and verifies whether the document is signed by the document signing entity. The method of verifying whether the signer certificate is verified is similar to the content discussed above. In an alternative method, the cred-verification entity may transmit the document to the document signing entity before verifying the signer certificate. In this case, the cred-verification entity verifies whether the document is signed by the document signing entity only after verifying that the signer certificate is verified. The system involving the first subject and the second subject includes a prover / signer, an issuer / verifier of the requested certificate, at least one issuer involved in a parent-child issuance relationship, a database, and a distributed ledger network. Each of the prover / signer, the issuer / verifier of the requested certificate, and at least one issuer involved in a parent-child issuance relationship can be a computing device.

[0052] According to one embodiment depicting a credential hierarchy Figure 1The credential hierarchy includes a root credential 101 owned by a credential manager XYZ, a plurality of issuer credentials 102-105, each of which is owned by an issuer, and a plurality of user credentials 201-207, each of which is owned by a user. A root certificate 101 is located at the top level of the certificate hierarchy, and a certificate manager XYZ issues multiple issuer certificates 102 and 103 that are part of a layer below the root certificate 101 hierarchy. Multiple issuer certificates 102-105 are located in multiple layers respectively below the root certificate 101 hierarchy, and the issuer of each issuer certificate 102-105 issues at least one of the remaining issuer certificates 104, 105 or one of multiple user certificates 201-207, each of the multiple user certificates 201-207 is located at a layer below the corresponding issuer certificate 102-105 hierarchy. For example, issuer certificates 102 and 103 at a layer below the root certificate 101 are owned by corresponding issuers DMV and CA1 and issued by certificate manager XYZ, and issuer certificates 104 and 105 at a layer below the issuer certificate 103 hierarchy are owned by corresponding issuers CA2 and CA3 and issued by issuer CA1 that owns issuer certificate 103. Multiple user credentials 201-207 are located in several layers below the hierarchy of corresponding issuer credentials 102-105. For example, user credentials 201-203 located in a layer below the hierarchy of issuer credential 102 are owned by corresponding users Alice, Bob and Cathy, and are issued by issuer DMV that owns issuer credential 102. User credential 204 located in the next layer below the hierarchy of issuer credential 103 is owned by corresponding user Bob and is owned by issuer CA1 that owns issuer credential 103. User credentials 205, 206 located in a layer below the hierarchy of issuer credential 104 are owned by corresponding users Alice and Cathy, and are owned by issuer CA2 that owns issuer credential 104. User credential 207 located in a layer below the hierarchy of issuer credential 105 is owned by corresponding user Bob and is owned by issuer CA3 that owns issuer credential 105. It can be seen that the issuer in the credential hierarchy is qualified to issue the corresponding issuer credential or user credential, while the user with the user credential in the credential hierarchy is not qualified to issue any credential to anyone. In addition, in the credential hierarchy, multiple credential systems are acceptable, each of which is associated with the issuer credential and the user credential for a specific purpose, such as Figure 1As shown, the credential hierarchy includes but is not limited to a DMV system and a CA system. The DMV system and the CA system include issuer credentials and user credentials for driver's licenses and CA certifications. Generally speaking, the issuer credentials and user credentials of the CA system are cert-type credentials, while those of the DMV system are non-cert-type credentials. Each credential is likely to have issuer credentials in multiple hierarchies of the credential system. In this scenario, visiting from the top level of the credential system downward, any issuer at each level may issue at least one issuer certificate to at least one other issuer, or issue at least one user certificate to at least one user, or may not issue any credentials at all to the next level of the credential system. Figure 2 shows a certificate system with issuer certificates in multiple layers of the certificate system, Figure 2 What is shown is a credential system including an issuer credential 301 issued by a credential manager XYZ to an issuer of a global organization, two issuer credentials 302 and 303 issued by the issuer of the global organization to two issuers of two national organizations A and B, four issuer credentials 304-307, two of which are issued by the issuer of national organization A to two issuers of two local organizations A1 and A2, and the other two are issued by the issuer of national organization B to two issuers of two local organizations B1 and B2, and eight user credentials 308-315, two of which are issued by the issuer of local organization A1 to two users John and Sandra, two of which are issued by the issuer of local organization A2 to two users Eric and Belinda, two of which are issued by the issuer of local organization B1 to two users Peter and Mary, and the remaining two are issued by the issuer of local organization B2 to two users Sam and Zoe. Figure 2 The issuer certificates and user certificates in the drawn certificate hierarchy may be cert-type certificates or non-cert certificates. Issuer certificate 301 owned by the issuer of the global organization is located one layer below the root certificate 101 hierarchy. Issuer certificates 302, 303 owned by the issuers of national organizations A and B are located one layer below the issuer certification 301 hierarchy of the global organization. Issuer certificates 304-307 owned by the issuers of local organizations A1, A2, B1, B2 are located one layer below the issuer certification 302, 303 hierarchy of national organizations A and B. User certificates 308-314 are located one layer below the issuer certification 304-307 hierarchy of local organizations. Basically, in this certificate system, there is only one issuer certificate for the issuer of the global organization. However, the number of issuer certificates for national and local organizations and user certificates for users may be different in different systems.

[0053] The certificate manager is qualified to issue non-cert-type certificates and cert-type certificates. The issuer and user in the certificate hierarchy can serve as the cert-requesting entity in the first subject and one of the cert-verifying entity and document signing entity in the second subject. However, only the issuer of the cert-type certificate issued in the certificate hierarchy can serve as the cert-issuing entity of the first subject, because in the certificate hierarchy, the certificates are owned by a corresponding entity, that is, one of the certificate manager, issuer and user. The certificates and their corresponding entities that correspond to the same identity in the certificate hierarchy can choose to be the same identity. It is worth noting that in Figure 1 The same user Bob may have different issuer certificates 202, 204, 207 in the certificate hierarchy, which are issued by issuer DMV, issuer CA1 and issuer CA3 respectively. In the event that some certificates of any entity are compromised, the entity can still use other uncompromised certificates to prove his / her / its identity.

[0054] Although not identical in all data fields, for purposes of credential verification, cert-type and non-cert-type credentials are considered identical when they have common data fields that are requested for verification and only the remaining data fields differ from each other, such as Figure 1 As shown in FIG. 1 , with reference to cert-type certificates 105, 207 and non-cert certificates 201, the common data fields include the certificate's decentralized identifier (DID), the certificate's expiration date, and the issuer's public key and signature, and in a way explain why the certificate hierarchy can accommodate both cert-type certificates and non-cert certificates. In addition to the common data fields that can be used for cert-type certificates and non-cert certificates, cert-type certificates further include the following remaining data fields:

[0055] type: type is set to "certificate", which is a data field that distinguishes cert-type certificates from non-cert certificates, where non-cert certificates usually have other types other than "certificate".

[0056] dn (Distinguished Name): The distinguished name of the owner of a cert-type certificate, such as a user name, such as "Bob" for a cert-type certificate 207, or a company name. The distinguished name may not be a unique name.

[0057] public_key: The public key of the owner of a cert-type certificate, which is used to verify any information or document signed by the private key of the owner of the cert-type certificate, where the private key is paired with the public key.

[0058] role: role is issuer or user depending on whether the cert-type credential is an issuer credential or a user credential. When the role in the cert-type credential is issuer, the owner of the cert-type credential can be one of the issuer, certifier, and verifier, and when the role in the cert-type credential is user, the owner of the cert-type credential can be one of the certifier and verifier.

[0059] purpose: This shows the purpose of the public key of the owner of the cert-type certificate, usually for digital signature or for data encryption.

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

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

[0062] type: Driver's license. Unlike cert-type credentials, which are specifically "certificate", non-cert credentials may specify their respective type as the type that the non-cert credential is classified as, thereby reflecting the diverse identification purposes of non-cert credentials. Non-limiting examples of type may include digital social security cards, digital passports, digital corporate identity badges, digital degrees, and the like.

[0063] dn: The distinguished name of the non-cert certificate owner. Figure 1 As shown in FIG. 2 , the proper name of Bob's driver's license 202 is “Bob.” The proper name may not be a unique name, for example, there may be multiple driver's licenses with proper names such as “MichaelJordan” or “Brenda Lee.”

[0064] Gender: The gender of the non-cert credential owner, either male (male) or female (female).

[0065] date of birth: Date of birth of the credential holder.

[0066] License number: A multi-digit letter / number sequence that can be used as an ID number in some countries, such as 67892094 on Alice's driver's license 201.

[0067] Since the system involving the first subject may include a distributed ledger network that maintains a distributed ledger, information related to the certificate may be issued off-chain and on-chain. In the off-chain part, a cert-issuing entity in the system issues a cert-type certificate and stores it in a computing device of a cert-requesting entity, an agent or an agent according to different scenarios, and in the on-chain part, revocation information for tracking the revocation status of the certificate in the distributed ledger is published to the distributed ledger, and this revocation information is updated when the private key of any credential owner is found to be vulnerable or compromised, or when the credential owner violates the specification of the credential hierarchy. The credential owner may request the issuer that issued the credential to revoke the owner's credential, and the associated issuer can always revoke the credential and update the related revocation information. The grounds for proving that the revocation of the certificate is reasonable may be one of the following cases, including compromised keys of the credential or the associated issuer, termination or abandonment of the credential owner, reissue of the credential, temporary revocation, retirement of the associated issuer, and the like.

[0068] Since it involves the first and second subjects and the key technology of the present invention, the verification of the authenticity of the certificate must be introduced first. When it comes to the verification of the certificate owned by the prover, the verifier verifies whether the certificate is verified, wherein the prover can be one of the cert-requesting entity in the first subject and the document signing entity in the second subject, and the verifier can be one of the cert-issuing entity in the first subject and the cred-verifying entity in the second subject, Figure 3 Describes the verification of the authenticity of the credential consists of the following steps.

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

[0070] Step S320: Determine whether the current credential is valid. Three conditions need to be met to verify that the current credential is valid. First, the proof generated based on the current credential needs to be verified to be valid. Second, the current credential should not expire. Third, the current credential has not been revoked. To be recognized as a valid current credential, all three conditions must be met. When any of the three conditions fails, the current credential will be deemed invalid. The proof of the current credential is generated by the current credential owner based on the current credential, the current credential owner's knowledge of the data fields in the current credential, and the verification request document (VRD) from the verifier. For more details about VRD, please refer to patent application PCT / US20 / 56388 entitled "VERIFICATION RQUIREMENT DOCUMENT FOR CREDENTIAL VERIFICATION". The VRD specifies three kinds of data in the current credential, namely, a public part, a challenging part, and a private part, wherein at least one of the public part and the challenging part can be used for verification, and the private part is not used for verification due to privacy considerations, so if both the public part and the challenging part are available, the proof of the current credential for the public part and the challenging part 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 challenging at least one challenging field located in the challenging part according to the VRD. When only the public part is specified in the VRD, only the at least one public field and the at least one signature of the corresponding public field will be presented in the proof. When only the challenge part is specified in the VRD, only the at least one zero-knowledge proof will be presented in the proof. The at least one signature corresponding to the public field is signed by the issuer and can be verified by the public key of the issuer. The method involving generating a signature on a portion of the data field of the credential is called a Camenisch-Lysyanskaya (CL) signature, which enables the current credential owner to generate at least one signature of the corresponding public field of the credential without knowing the issuer's private key as long as the signature used to sign the entire credential data field is available. This CL signature technology enables the verifier to verify the at least one signature of the corresponding public field through the issuer's public key. Each of the at least one zero-knowledge proofs is used to challenge one of the at least one challenge fields, and is calculated by the current credential, the value of the challenge field, and a challenging condition from a VRD. Each challenge condition includes a comparison operator, such as >, <, >=, <=, =, and ≠, which is tested for the corresponding challenge field so that the prover proves whether the challenge condition is met. Each of the at least one zero-knowledge proofs will be verified to be true when the challenge condition of the zero-knowledge proof is met.For the current credential to be verified as valid, at least one signature and at least one zero-knowledge proof corresponding to the public field must be verified as correct, depending on the availability of the public part and the challenge part in the VRD. The following example uses a driver's license as an example to verify the current credential. If the VRD specifies that the public fields of the public part include the dn, gender, and license number in the driver's license, as well as two zero-knowledge proofs, that is, age>18 and not expired before 12 / 31 / 2020 to challenge the challenge fields date of birth and expiration date respectively, the current credential owner will output three signatures of the public fields dn, gender, and license number signed by the issuer, and provide the three public fields, three signatures, the issuer's public key owned by the DMV, and two zero-knowledge proofs challenging the challenge fields date of birth and expiration date to the verifier. If the values ​​of the challenge field, date of birth and expiration date are 08 / 08 / 2000 and 02 / 17 / 2025, the verifier verifies that the proof of the driver's license provided by the current credential owner is valid after verifying that the three signatures of the three public fields dn, gender and license number and the two zero-knowledge proofs are verified to be correct.

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

[0072] When the digital certificate is determined to be valid, step S330 is executed; otherwise, step S360 is executed.

[0073] Step S330: Determine whether the issuer of the current certificate is available and trusted in the certificate hierarchy. The issuer of the current certificate is located below the M-layer of the certificate manager in the certificate hierarchy, where M is an integer greater than zero. The issuer is one layer above the current certificate owner and owns a certificate issued by another issuer one layer higher than the issuer. It is known that the certificate manager is the top layer of the digital certificate hierarchy. In order to verify that the current certificate is verified, not only the current certificate itself needs to be verified as valid, but also the issuer recursively traced back in the certificate hierarchy according to the issuer tracking process needs to be determined to be trusted. When the issuer of the current certificate is not available in the certificate hierarchy, step S360 is executed, which is the case when the issuer of the current certificate cannot be found in the certificate hierarchy. In one embodiment, whether the issuer can be found in the pre-approved list will determine whether the issuer is trustworthy. Step S350 is executed when the issuer is determined to be available and trustworthy in the certificate hierarchy. Step S340 is executed when the issuer is determined to be available but not trustworthy in the certificate hierarchy.

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

[0075] Step S350: Determine that the certifier's credentials are verified and end. After verifying that the current credentials comply with the three conditions and verifying that the trusted issuer is available through the issuer tracking process, the verifier determines that the certifier's credentials are verified and does not continue to execute step S360.

[0076] Step S360: Determine that the certifier's credentials are unverified. The issuer's credentials may be determined to be unverified because any of the three conditions are not met or a trusted issuer is not found in the issuer tracking process.

[0077] The authenticity of the certifier certificate requires that the results of each round of the verification cycle of steps S320-S340 are all positive. When the results of the first round of steps S320-S340 are all positive, it means that the certifier certificate is valid and the issuer of the certifier certificate located one level above the certifier in the credential hierarchy is trusted. However, if the result of step S330 shows that the issuer is available but untrusted in the credential hierarchy, then start executing step S340 and then redo the recursive loop of step S320 to track the next issuer one level above the issuer, and then perform a new round of verification through steps S320-S340 to determine whether the certificate of the next issuer is valid and the next issuer is trustworthy. By default, the issuer at the top level of the credential system in the credential hierarchy, such as Figure 1 The DMV and CA1 in are both reliable. Figure 1 Taking the verification of user credential 207 as an example, assuming that the verification result of the first round is that user credential 207 is valid and issuer CA3 that issued user credential 207 is untrustworthy, if the verification result of the second round is that issuer credential 105 of issuer CA3 is valid and issuer CA1 is trusted by default, the verification result of this example shows that user credential 207 of user Bob is verified as verified within two rounds.

[0078] The first subject and the second subject may be implemented by the aforementioned certificate verification technique, where in addition to the verification of the existing certificate of the cert-requesting entity, the first subject regarding the issuance of a cert-type certificate to the cert-requesting entity needs to further verify something else to additionally endorse the request for issuance of the cert-type certificate, which something else may be the signature of the cert-requesting entity.

[0079] refer to Figure 4 , in order to process a first subject, a method for issuing a cert-type includes the following steps.

[0080] Step S410: The cert-issuing entity receives a request for a cert-type certificate from a cert-requesting entity. The current method involves two participants, one of the two participants is the cert-requesting entity, which initiates the request to receive a cert-type certificate, and the cert-issuing entity is the other participant, which verifies the qualifications of the cert-requesting entity and judges whether the cert-requesting entity is qualified to receive a cert-type certificate issued by the cert-issuing entity. The cert-requesting entity and the cert-issuing entity can both be computing devices that communicate with each other. The request for the cert-type certificate is initiated by the cert-requesting entity, which includes a public key and is sent to the cert-issuing entity. The public key is part of a pair of keys generated by the cert-requesting entity according to public key cryptography and is paired with a private key of the key pair.

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

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

[0083] Step S440: The cert-issuing entity verifies whether the existing credential is verified and the cert-requesting entity is authorized to endorse the existing credential. For details on the verification of the existing credential, please refer to steps S310-S360. To verify whether the cert-requesting entity is authorized to endorse the existing credential, the cert-issuing entity uses the public key to verify whether the signature is signed by the cert-requesting entity. When it is verified that the existing credential is verified and the cert-requesting entity is authorized to endorse the existing credential, step S450 is executed, otherwise step S460 is executed.

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

[0085] Step S460: The cert-issuing entity rejects the request for the cert-type certificate.

[0086] The following provides an example of issuing a club member's cert-type certificate. When a club member issuing company's computing device receives a request for a club member's cert-type certificate from an applicant's computing device, wherein the club member issuing company's computing device acts as a cert-issuing entity and is named as a member issuer in this article, and the applicant's computing device acts as a cert-requesting entity and is named as an applicant in this article, the member issuer transmits a request for a digital driver's license to the applicant, and the club member's request also includes a public key of a key pair generated by the applicant, which is paired with a private key of the key pair. In response to the request for a digital driver's license, the applicant generates a certificate for the digital driver's license and transmits the public key of the key pair, a signature, a data fragment, and a certificate to the member issuer. After verifying that the digital driver's license is verified and that the applicant has signed the data fragment through the public key of the key pair, the member issuer generates a club member's cert-type certificate for the applicant, which includes a public key, and transmits the cert-type certificate to the applicant.

[0087] The second subject verifies whether the document is signed by the document signing entity, which is a prerequisite that the signer credential provided by the document signing entity is first verified by the cred-verifying entity to be verified. The first subject and the second subject can be regarded as applications that require both credential and digital signature verification. If the cred-verifying entity in the second subject specifies a cert-type credential, both the first and second subjects may be connected together by verifying the signed document in the second subject using a cert-type credential that is not initially available but can be obtained from the first subject. For example, in the case where the cert-requesting entity in the first subject also serves as the document signing entity in the second subject, before verifying the digital signature of the document used to apply for a loan in the second subject, the CA certificate requested for verification can be learned from an existing credential in the first subject, such as a digital driver's license.

[0088] like Figure 5 As shown, the first embodiment of the method for electronically signing a document includes the following steps.

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

[0090] Step S520: The cred-verification entity verifies whether the signer's credential is verified. Similarly, the details of verifying whether the signer's credential is verified can refer to steps S310-S360. When the signer's credential is verified to be verified, step S530 is executed, otherwise step S570 is executed.

[0091] Step S530: The cred-verifying entity sends the file to the file signing entity. In the current embodiment, the cred-verifying entity sends the file to the file signing entity only after the signer's credentials are verified as verified.

[0092] 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 cred-verifying entity. In one embodiment, the document is signed by the signer private key, which is associated with the signer decentralized identifier (DID) of the document signing entity in one of the data fields of the signer credential when the signer credential is a non-cert credential. In another embodiment, the document is signed by the signer private key, which is paired with the public key in one of the data fields of the signer credential when the signer credential is a cert-type credential.

[0093] Step S550: After receiving the signed document and the signer's public key, the cred-verifying entity verifies whether the document is signed by the document signing entity by signing the document through the signer's public key. When the signer's credential is a non-cert credential, the signer's public key can be connected to the signer's decentralized identifier (DID) of the document signing entity in the signer's credential, or when the signer's credential is a cert-type credential, the signer's public key can be connected to the public key in the signer's credential. When the verification result is positive, step S560 is executed, otherwise step S570 is executed.

[0094] Step S560: The cred-verification entity confirms that the document is signed successfully.

[0095] Step S570: The cred-verification entity determines that the document signing has failed.

[0096] Different from the first embodiment in which the document to be signed is sent only after the signer's credentials have been verified, according to Figure 6 The second embodiment of the method for electronically signing a document comprises the following steps, wherein the document can be selectively sent before the signatory's credentials are verified as verified. To avoid repetition, the description similar to the first embodiment is not repeated in the second embodiment.

[0097] Step S610: the cred-verifying entity sends a request for proof of the signing credential of the document signing entity and the document to the document signing entity. It should be noted that the request for proof of the signatory credential and the document are sent by the cred-verifying entity to the document signing entity at the same time.

[0098] Step S620: The file signing entity signs the file using the signer's private key and sends the file and the proof of the signer's certificate to the cred-verifying entity, where the proof includes the signer's public key paired with the signer's private key. In response to the received request and file, the file signing entity needs to send the signed file and the proof of the signer's certificate to the cred-verifying entity as a response.

[0099] Step S630: The cred-verification entity verifies whether the signer credential is verified. If the signer credential is verified to be verified, step S640 is executed; otherwise, step S660 is executed.

[0100] Step S640: The cred-verification entity verifies whether the file is signed by the file signing entity using the signer's public key paired with the signer's private key. If the verification result is positive, step S650 is executed; otherwise, step S660 is executed.

[0101] Step S650: The cred-verification entity confirms that the document is signed successfully.

[0102] Step S660: The cred-verification entity determines that the document signing has failed.

[0103] refer to Figure 7 , a system applicable to the first and second subjects 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. The system emphasizes the structural description rather than the functions discussed in the aforementioned method. Although the abbreviations between the two issuer devices 704 and between their connections to the first computing device 702 and the database 705 show an embodiment with multiple issuer devices, one of which is trusted, the at least one issuer device 704 may also include other embodiments, such as Figure 8 There is a trusted issuer device as shown, or Fig. 9 There are no issuer devices shown.

[0104] The distributed ledger network 701 maintains a distributed ledger that stores revocation information related to issuer certificates. A first computing device 702 is communicatively connected to the distributed ledger network 701 and can act as a cert-issuing entity in a first subject or a cred-verifying entity in a second subject. The second computing device 703 is communicatively connected to the first computing device 702 and can act as a cert-requesting entity in the first subject or a document signing entity in the second subject. At least one issuer device 704 is a flexible part of the system to some extent. As the parent-child issuing relationship changes, it is communicatively connected to the first computing device 702 and is provided with and connected to the certificate of the second computing device when the parent-child issuing relationship is available. The parent-child issuing relationship defines that one of the at least one issuer device 704 issues the certificate of the second computing device 702, and each of the remaining issuer devices 704 issues another certificate to another device in the at least one issuer device 704. In other words, when the parent-child issuing relationship does not exist, at least one issuer device 704 is not available in the system. The situation where there is no issuer device 704 may result from forged certificates and fake certificates resulting in no issuer device 704 being connected to the fake certificate according to the parent-child issuing relationship. When the parent-child relationship exists, at least one issuer device 704 is connected to the certificate of the second computing device 703, and at least one issuer device 704 and its at least one certificate are located in the certificate hierarchy. When acting as an issuer in the certificate 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 connected to the second computing device 703 and the at least one issuer device 704, and stores issued certificates, which include the certificates of the second computing device 703 and the at least one issuer device 704, and are accessible to the second computing device 703 and the at least one issuer device 704, respectively.

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

[0106] From the above description, the present invention has advantages in eliminating cumbersome and repetitive KYC procedures, both when requesting the issuance of new cert-type certificates and verifying digital signatures on documents, because the issuance of new cert-type certificates can be received and the signature of the document can be verified through the current certificate, whether the existing certificate is a cert-type certificate or a non-cert certificate type. In addition to not requiring a KYC process, in conjunction with a hierarchical certificate hierarchy with multiple certificate systems, each of which includes cert-type certificates or non-cert certificates, users / issuers can obtain different certificates from multiple certificate systems and therefore have the freedom to choose the type of identity or user / issuer certificate they prefer. Since each issuer in the certificate hierarchy of the present invention can maintain a distributed ledger, the problem of single point errors will only cause a single and unique entity certificate to be compromised and invalid in the certificate hierarchy. For any certificate that is connected to the compromised certificate based on a parent-child issuance relationship, the issuer of the certificate only suffers the loss of the certificate, but can still be identified through other certificates in the certificate hierarchy. Furthermore, to be authenticated as a verified credential, it relies on double verification, wherein the credential must be verified to be valid, and at least one issuer connected to the credential based on a parent-child relationship must be verified to be trustworthy. This double verification ensures that the verification of the credential is more secure.

[0107] Although the various features and advantages of the present invention have been set forth in the foregoing, together with the details of construction and the functions of the invention, this disclosure is for reference only. In detail, particularly in matters of shape, size and arrangement of parts, modifications may be made within the maximum scope of the inventive concept as indicated by the broad general meaning expressed in the appended claims.

Claims

1. A method for issuing a digital certificate of an authentication type, comprising: (a) the certification issuing entity receives a request for the digital certificate of the certification type from the certification requesting entity, wherein the request for the digital certificate of the certification type includes a public key generated by the certification requesting entity; (b) the certification issuing entity sends a request for the certification requesting entity's existing digital certificate to the certification requesting entity; (c) after verifying that the existing digital certificate is authenticated and the certification requesting entity has the right to endorse the existing digital certificate, the certification issuing entity generates the digital certificate of the certification type including the public key of the certification requesting entity; as well as (d) The certification issuing entity sends the digital certificate of the certification type to the certification requesting entity.

2. The method of claim 1, wherein the existing digital certificate is of a non-authentication type or an authentication type.

3. The method as claimed in claim 2, wherein when the existing digital credential belongs to the non-authentication type, the existing digital credential is an official ID digital credential, and the official ID digital credential is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card. The method of claim 1 , wherein the identity credential of the authentication type is associated with a type of document.

5. The method of claim 1, wherein in order to verify whether the existing digital certificate is verified and whether the authentication requesting entity has the right to endorse the existing digital certificate, step (c) comprises: (c1) initializing the current credential and the current credential owner to the existing digital credential and the authentication requesting entity, respectively; (c2) determining whether the current credential is valid; (c3) when determining that the current credential is valid, determining whether the issuer that issued the current credential is available and trusted in the digital credential hierarchy, wherein the issuer is below the M layers of the credential manager in the digital identity hierarchy, where M is an integer greater than zero, the issuer is above the current credential owner and has a digital certificate issued by another issuer above the issuer, and the credential manager is at the top of the digital credential hierarchy; (c4) when it is determined that the issuer is usable but untrustworthy in the digital certificate hierarchy, replacing the current certificate owner and the current certificate with the issuer and a digital certificate of the issuer, respectively, and re-performing step (c2); (c5) when the issuer is determined to be usable and trustworthy in the digital certificate hierarchy, determining that the existing digital certificate is verified and executing step (c7); (c6) when any of the determination results in the determination steps (c2) and (c3) fails, the existing digital certificate is determined to be unverified; and (c7) When it is determined that the existing digital certificate is verified, determine whether the authentication requesting entity has the authority to endorse the existing digital certificate.

6. The method of claim 5, comprising between step (b) and step (c): (e) The authentication requesting entity generates a certificate of the existing digital certificate, and provides the certificate, the public key, a data fragment and a digital signature to the authentication issuing entity, wherein the data fragment is random data generated by the authentication issuing entity individually or by the authentication issuing entity and the authentication requesting entity jointly, and is signed with a private key generated by the authentication requesting entity and paired with the public key to produce the digital signature.

7. The method of claim 6, wherein when the current credential is determined to be valid, step (c2) comprises: (c21) verifying that the proof of the current credential is valid, wherein the proof of the current credential is provided by the current credential owner and includes at least one option according to a verification requirement document from the certification issuing entity, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, and another option includes at least one zero-knowledge proof that challenges at least one challenge field respectively and includes a public key associated with the DID of the issuer of the current credential, and the certification issuing entity determines that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct; and (c22) Verify that the current credential has not expired and has not been revoked.

8. The method of claim 7, wherein in step (c22), the certification issuing entity interacts with a distributed ledger network that maintains a distributed ledger and is communicatively connected to the certification issuing entity to obtain revocation information in the distributed ledger, and verifies that the current certificate has not been revoked based on the revocation information.

9. A method as claimed in claim 6, wherein in step (c7), when it is determined that the certification requesting entity has the authority to endorse the existing digital certificate, the certification issuing entity verifies that the digital signature is signed by the certification requesting entity through the public key generated by the certification requesting entity.

10. The method of claim 6, wherein in step (c3), the certificate issuing entity determines that the issuer is trustworthy when the issuer is determined to be in a pre-approved list or the issuer is the credential manager.

11. A method for electronically signing a document, comprising: (f) the credential verifying entity sends a request for a certificate of the signer digital certificate of the document signing entity to the document signing entity, and receives a certificate of the signer digital certificate from the document signing entity, wherein the certificate includes a signer public key associated with the signer digital certificate; (g) the certificate verification entity verifies whether the signatory digital certificate is verified, and when the signatory digital certificate is confirmed to be valid, sends the document to the document signing entity; and (h) The certificate verification entity receives the document signed by the document signing entity using the signer's private key paired with the signer's public key and the signer's public key, and verifies whether the document is signed by the document signing entity using the signer's public key.

12. The method of claim 13, wherein the signatory digital certificate is of a non-authentication type or an authentication type.

13. The method of claim 14, wherein when the signer digital certificate belongs to the non-authentication type, the signer digital certificate is an official ID digital certificate, and the official ID digital certificate is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

14. A method as claimed in claim 14, wherein in step (h), when the signer digital certificate belongs to the non-authentication type, the certificate verification entity receives the document signed with the signer private key, the signer's private key is associated with the signer's decentralized identifier of the document signing entity in the signer digital certificate, and receives the signer public key paired with the signer private key, and verifies whether the document is signed by the document signing entity through the signer public key.

15. The method as described in claim 14, wherein in step (h), when the signer digital certificate belongs to the authentication type, the certificate verification entity receives the document signed with the signer private key from the document signing entity, the signer private key is paired with the signer public key in the signer digital certificate, and receives the signer public key, and verifies whether the document is signed by the document signing entity through the signer public key.

16. The method of claim 13, wherein in order to verify whether the signer digital certificate is verified, step (g) comprises: (g1) Initializing the current credential and the current credential owner to the signer credential and the document signing entity; (g2) Determine whether the current certificate is valid; (g3) when determining that the current certificate is valid, determining whether the issuer that issued the current certificate is available and trusted in the digital certificate hierarchy, wherein the issuer is below the M-layer of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer is one layer above the current certificate owner and has a digital certificate issued by another issuer one layer above the issuer, and the certificate manager is at the top of the digital certificate hierarchy; (g4) when it is determined that the issuer is usable but untrustworthy in the digital certificate hierarchy, replacing the current certificate owner and the current certificate with the issuer and the issuer's digital certificate, respectively, and re-performing step (g2); (g5) deeming the signer digital certificate to be verified when deeming the issuer to be available and trustworthy in the digital certificate hierarchy; and (g6) When any of the authentication results of authentication steps (g2) and (g3) fails, the signer digital certificate is deemed to be unverified.

17. The method of claim 18, wherein when the current credential is determined to be valid, step (g2) comprises: (g21) verifying that the proof of the current credential is valid, wherein the proof of the current credential is provided by the current credential owner and includes at least one option according to a verification request document (VRD) from the credential verification entity, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, and another option includes at least one zero-knowledge proof respectively challenging at least one challenge field, and includes a public key associated with the DID of the issuer of the current credential, and the certification issuing entity determines that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct; and (g22) Verify that the digital certificate has not expired and has not been revoked.

18. The method of claim 19, wherein in step (g22), the credential verification entity interacts with a distributed ledger network that maintains a distributed network and is communicatively connected to the credential verification entity to access revocation information in the distributed ledger, and verifies that the current credential has not been revoked based on the revocation information.

19. The method of claim 13, wherein the signer digital certificate is assigned by the credential verification entity to be associated with a type of document.

20. The method of claim 18, wherein in step (g3), the credential verification entity determines that the issuer is trustworthy when it is determined that the issuer is in a pre-approved list or that the issuer is the credential manager.

21. A method for electronically signing a document, comprising: (i) the credential verification entity sends a request and a document of a certificate of a signer digital certificate of a document signing entity to the document signing entity, wherein the certificate includes a signer public key associated with the signer digital certificate; (j) the certificate verifying entity receives from the document signing entity the proof of the signer's digital certificate and the document signed with the signer's private key paired with the signer's public key; as well as (k) The certificate verification entity verifies whether the signer digital certificate is verified, and when the signer digital certificate is verified to be verified, verifies through the signer public key that the file is signed by the file signing entity.

22. The method of claim 25, wherein the signer digital certificate is of an authentication type or a non-authentication type.

23. The method of claim 26, wherein when the signatory digital certificate belongs to the non-authentication type, the signatory digital certificate is an official ID digital certificate, which is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

24. A method as claimed in claim 26, wherein in step (j), when the signer digital certificate belongs to the non-authentication type, the certificate verification entity receives the document signed with the signer private key, wherein the signing private key is associated with the signer decentralized identifier of the document signing entity in the signer digital certificate, and verifies whether the document is signed by the document signing entity through the signer public key.

25. A method as claimed in claim 26, wherein in step (j), when the signer digital certificate belongs to the authentication type, the certificate verification entity receives the document signed with the signer private key from the document signing entity, wherein the signing private key is paired with the signer public key in the signer digital certificate, and verifies whether the document is signed by the document signing entity through the signer public key.

26. The method of claim 25, wherein to verify whether the signer digital certificate is verified, step (k) comprises: (k1) Initializing the current credential and the current credential owner to the signer digital credential and the document signing entity; (k2) determining whether the current certificate is valid; (k3) when determining that the current certificate is valid, determining whether the issuer that issued the current certificate is available and trusted in the digital certificate hierarchy, wherein the issuer is located below the M layers of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer is one layer above the current certificate owner and owns a digital certificate issued by another issuer one layer above the issuer, and the certificate manager is located at the top of the digital certificate hierarchy; (k4) when it is determined that the issuer is usable but untrustworthy in the digital certificate hierarchy, updating the current certificate owner and the current certificate to the issuer and the issuer's digital certificate, respectively, and re-performing step (g2); (k5) when the issuer is deemed available and trustworthy, deeming the signer digital certificate to be verified; and (k6) When any of the authentication results of authentication steps (k2) and (k3) fails, the signer digital certificate is deemed to be unverified.

27. The method of claim 30, wherein when the current credential is determined to be valid, step (k2) comprises: (k21) verifying that the proof of the current credential is valid, wherein the proof of the current credential is provided by the current credential owner and, according to a verification request document from the credential verification entity, includes at least one option, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, and another option includes at least one zero-knowledge proof challenging at least one challenge field, and includes a public key associated with the DID of the issuer of the current credential, and the certification issuing entity verifies that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct; (k22) Verify that the current credential has not expired and has not been revoked.

28. The method as described in claim 31, wherein in step (k22), the credential verification entity interacts with a distributed ledger network that maintains a distributed network and is communicatively connected to the credential verification entity to obtain revocation information in the distributed ledger, and verifies that the current credential has not been revoked based on the revocation information.

29. The method of claim 25, wherein the signer digital certificate is assigned by the credential verification entity to be associated with a type of document.

30. The method of claim 30, wherein in step (k3), the credential verification entity determines that the issuer is trustworthy when it is determined that the issuer is in a pre-approved list or that the issuer is the credential manager.

31. A system for issuing a digital certificate of an authentication type and an electronically signed document, comprising: A distributed ledger network that maintains a distributed ledger that stores revocation information associated with issued digital credentials; A first computing device is communicatively connected to the distributed ledger network; a second computing device communicatively connected to the first computing device; at least one issuer device, when a parent-child issuance relationship exists and when provided communicatively connected to the first computing device, is provided with and connected to the digital certificate of the second computing device, wherein the parent-child issuance relationship exists when the at least one issuing device issues the digital certificate to the second computing device, and when each of the remaining issuing devices issues another digital certificate to another of the at least one issuing device; as well as A database is communicatively connected to the second computing device and the at least one issuer device, and stores the issued digital certificate, which includes the digital certificate of the second computing device and the at least one issuer device, and can be accessed by the second computing device and the at least one issuer device respectively.

32. A system as described in claim 37, wherein the first computing device receives a request for the digital certificate of the authentication type from the second computing device, sends a request for an existing digital certificate to the second computing device, verifies whether the existing digital certificate is verified and whether the second computing device has the authority to endorse the existing digital certificate, and when it is verified that the existing digital certificate is verified and the second computing device has the authority to endorse the existing digital certificate, generates the digital certificate of the authentication type and sends the digital certificate of the authentication type to the second computing device, wherein the request for the digital certificate of the authentication type includes a public key generated by the second computing device.

33. The system as claimed in claim 38, wherein the existing digital certificate is of a non-authentication type or an authentication type.

34. The system of claim 39, wherein when the existing digital credential belongs to the non-authentication type, the existing digital credential is an official ID digital credential, which is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

35. The system of claim 38, wherein the digital certificate of the authentication type is associated with a type of document.

36. The system of claim 38, wherein when verifying whether the existing digital certificate is verified and whether the second computing device has the right to endorse the existing digital certificate, the first computing device initializes the current certificate and the current certificate owner to the existing digital certificate and the second computing device, determines whether the current certificate is valid, when determining that the current certificate is valid, determines whether one of at least one issuer device that issued the current digital certificate is available and trusted in the digital certificate hierarchy, when determining that the issuer device is available but untrusted in the digital certificate hierarchy, replaces the current certificate owner and the current certificate with the issuer device and the digital certificate of the issuer device, respectively, and recursively loops to determine whether the current certificate is valid until the issuer device is available and trusted in the digital certificate hierarchy or unavailable in the digital certificate hierarchy, when determining that the issuer device is available and trusted in the digital certificate hierarchy, determines that the existing digital certificate is verified, and when determining that the existing digital certificate is verified, determines whether the second computing device has the right to endorse the existing digital certificate; The issuer device or its digital certificate is below the M layer of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer device or its digital certificate is above the current certificate owner or its digital certificate, the issuer device owns a digital certificate issued by another device among the at least one issuer device above the issuer device, and the certificate manager or its digital certificate is at the top of the digital certificate hierarchy.

37. A system as described in claim 42, wherein after the first computing device sends the request for the existing digital certificate and the public key to the second computing device, the second computing device generates a certificate of the existing digital certificate, and provides the certificate of the existing digital certificate, the public key, a data fragment, and a digital signature to the first computing device, wherein the data fragment is random data generated by the first computing device individually or by the first computing device and the second computing device jointly, and is 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. The system of claim 43, wherein when the current credential is determined to be valid, the first computing device verifies that the proof of the current credential is valid and then verifies that the current credential has not expired and has not been revoked; The proof of the current credential is provided by the owner of the current credential and includes at least one option based on a verification request file from the first computing device, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, and another option includes at least one zero-knowledge proof that challenges at least one challenge field respectively, and includes a public key associated with the DID of the issuer of the current credential, and the first computing device verifies that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct.

39. The system of claim 44, wherein the first computing device interacts with the distributed ledger network to obtain revocation information in the distributed ledger, and verifies that the current credential to be verified has not been revoked based on the revocation information.

40. The system of claim 43, wherein when the second computing device is deemed to be authorized to endorse the existing digital certificate, the first computing device verifies that the digital certificate is signed by the second computing device using the public key generated by the second computing device.

41. The system of claim 42, wherein when deeming the issuer device to be trusted, the first computing device deems the issuer device to be in a pre-approved list or the issuer device to be the credential manager.

42. A system as described in claim 37, wherein the first computing device sends the request for the proof of the signer digital certificate of the second computing device to the second computing device, the second computing device receives the proof of the signer digital certificate, verifies whether the signer digital certificate is verified, and when the signer digital certificate is verified to be verified, sends a file to the second computing device, receives the file signed with the signer private key and the signer public key from the second computing device, wherein the signer private key is paired with the signer public key included in the proof and is associated with the signer digital certificate, and verifies through the signer public key that the file is signed by the second computing device.

43. The system of claim 50, wherein the signer digital certificate is of the non-authentication type or the authentication type.

44. The system of claim 51, wherein the signatory digital credential is an official ID digital credential, which is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

45. A system as described in claim 51, wherein when the signer digital certificate belongs to the non-authentication type, the first computing device receives the file signed with the signer private key and the signer public key paired with the signer private key, wherein the signer private key is associated with the signer decentralized identifier of the second computing device in the signer digital certificate, and verifies whether the file is signed by the second computing device through the signer public key.

46. ​​A system as described in claim 51, wherein when the signer digital identity is of an authentication type, the first computing device receives the document signed with the signer private key and the signer public key from the second computing device, wherein the signer private key is paired with the signer public key in the signer digital certificate, and verifies whether the document is signed by the second computing device through the signer public key.

47. The system of claim 51, wherein when the signer digital certificate belongs to the authentication type and the first computing device determines that the signer digital certificate is verified, the first computing device initializes the current certificate and the current certificate owner to the signer digital certificate and the second computing device, determines whether the current certificate is valid, and when the current certificate is determined to be valid, determines whether one of at least one issuer device that issued the current identity is available and trusted in the digital certificate hierarchy, and when the issuer device is determined to be available but untrustworthy in the digital certificate hierarchy, replaces the current certificate owner and the current certificate with the issuer device and the digital certificate of the issuer device, respectively, and recursively loops to determine whether the current certificate is valid until the issuer device is available and trusted in the digital certificate hierarchy or is unavailable in the digital certificate hierarchy, and when the issuer device is determined to be available and trusted in the digital certificate hierarchy, determines that the signer digital certificate is verified; The issuer device or its digital certificate is below the M layer of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer device or its digital certificate is above the current certificate owner or its digital certificate, the issuer device owns a digital certificate issued by another device among the at least one issuer device in the layer above the issuer device, and the certificate manager or its digital certificate is at the topmost layer in the digital certificate hierarchy.

48. The system of claim 55, wherein when the current credential is deemed to be verified, the first computing device verifies that the proof of the current credential is valid, and then verifies that the current credential has not expired and has not been revoked; The proof of the current credential is provided by the owner of the current credential and includes at least one option based on a verification request file from the first computing device, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, and another option includes at least one zero-knowledge proof that challenges at least one challenge field respectively, and includes a public key associated with the DID of the issuer device of the current credential, and the first computing device verifies that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct.

49. The system of claim 56, wherein the first computing device interacts with the distributed ledger network to obtain revocation information in the distributed ledger, and verifies through the revocation information that the current credential to be verified has not been revoked.

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

51. The system of claim 55, wherein when deeming the issuer device to be trusted, the first computing device deems the issuer device to be in a pre-approved list or the issuer device to be the credential manager.

52. A system as described in claim 37, wherein the first computing device sends a request for proof of the signer digital certificate and a file to the second computing device, receives the proof of the issuer digital certificate and the file signed with the issuer's private key from the second computing device, wherein the issuer's private key is paired with the issuer's public key included in the proof, verifies whether the signer digital certificate is verified, and when the signer digital certificate is verified to be verified, verifies whether the file is signed by the second computing device through the signer's public key.

53. The system of claim 62, wherein the signer digital certificate is of the non-authentication type or the authentication type.

54. The system of claim 63, wherein the signatory digital credential is an official ID digital credential, which is one of a digital driver's license, a digital passport, a digital national ID card, and a digital state ID card.

55. A system as described in claim 63, wherein when the signer digital certificate belongs to the non-authentication type, the first computing device receives the file signed with the signer private key and the signer public key paired with the signer private key, wherein the signer private key is associated with the signer decentralized identifier of the second computing device in the signer digital certificate, and verifies whether the file is signed by the second computing device through the signer public key.

56. A system as described in claim 63, wherein when the signer digital certificate belongs to the authentication type, the first computing device receives the file signed with the signer private key and the signer public key from the second computing device, wherein the signer private key is paired with the signer public key in the signer digital certificate, and verifies whether the file is signed by the second computing device through the signer public key.

57. The system of claim 63, wherein when the first computing device determines that the signer digital identity is verified, the first computing device initializes the current credential and the current credential owner to the signer digital certificate and the second computing device, determines whether the current credential is valid, and when the current credential is determined to be valid, determines that one of the at least one issuer that issued the current credential is available and trustworthy in the digital credential hierarchy, and when the issuer device is determined to be available but untrustworthy, replaces the current credential owner and the current credential with the issuer device and the digital credential of the issuer device, respectively, and loops back to determine whether the current credential is valid until the issuer device is available and trustworthy in the digital credential hierarchy or unavailable in the digital credential hierarchy, and when the issuer device is determined to be available and trustworthy in the digital credential hierarchy, determines that the signer digital certificate is verified; The issuer device or its digital identity is below the M layer of the certificate manager in the digital certificate hierarchy, where M is an integer greater than zero, the issuer device or its digital certificate is one layer above the current certificate owner or its digital certificate, the issuer device owns a digital certificate issued by another device in at least one issuer device one layer above the current issuer device, and the certificate manager or its digital certificate is at the topmost layer of the digital certificate hierarchy.

58. The system of claim 67, wherein when the current credential is determined to be valid, the first computing device verifies that the proof of the current credential is valid and then verifies that the current credential has not expired and has not been revoked; The proof of the current credential is provided by the owner of the current credential, and includes at least one option according to a verification requirement file from the first computing device, wherein one option includes at least one public field and at least one digital signature of the corresponding public field, another option includes at least one zero-knowledge proof respectively challenging at least one challenge field, and includes a public key associated with the DID of the issuer device of the current credential, and the first computing device verifies that the current credential is valid by verifying that the at least one digital signature of the at least one public field and the at least one option of the at least one zero-knowledge proof are correct.

59. The system of claim 68, wherein the first computing device interacts with the distributed ledger network to obtain revocation information in the distributed ledger, and verifies based on the revocation information that the current credential to be verified has not been revoked.

60. The system of claim 62, wherein the first computing device specifies that the signer digital certificate is associated with a type of document.

61. The system of claim 67, wherein when any of the at least one issuer device is deemed trustworthy, 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