CN116349198B - Method and system for authenticating credentials - Google Patents

Abstract

An Issuing Authority (IA) can verify a user's identity and issue a digital license to said user. IA can generate an IA public and private key pair and provide the IA public key to the certification authority (CA). IA can sign the digital license with the IA private key and configure the signed digital license on the user device. The IA can request the CA to verify the digital license. The CA can verify the digital license using the IA public key and sign the IA public key with the CA private key, thereby generating a digital certificate associated with the issuing authority linked to the digital license. Relying parties can use the CA public key to verify the digital license. The relying party can retrieve information from the digital license and trust that the retrieved information is legitimate.

Description

Methods and systems for authenticating credentials

Related application cross-references

This application is filed under 35 USC § 119(e) in U.S. Provisional Patent Application No. 63/127,515 titled "Method and System for Authentication Credential" filed on December 18, 2020 and Interests in U.S. Provisional Patent Application No. 63/225,313, entitled "Method and System for Digital License", filed on July 23, 2021, the disclosure content of said U.S. Provisional Patent Application This document is incorporated by reference in its entirety for all purposes.

Background technique

The issuer of the identifying information (e.g., DMV, medical provider, city, state, or federal government agency) provides data about the person (user) used in the transaction. However, the issuer is not necessarily known to the relying party (e.g., the merchant) and therefore cannot be guaranteed to be authentic. Not all transactions occur in locations with stable connections to online authentication services. Furthermore, even if an online authentication service exists, the authenticity of the authentication service must be verified. Current solutions will require other forms of verification, such as providing a physical driver's license, vaccination records, or other types of verification, which can reveal more information about the user than is required for the transaction.

Embodiments are directed to solving these and other problems, individually and collectively.

Contents of the invention

Embodiments allow offline certification of the issuing authority of a digital license. Offline issuer authentication allows maintaining a high level of trust in transactions where the relying party may not be aware of the issuer. The digital certificate generated by the verification authority can be associated with the digital license (eg, integrated or appended to the digital license) and can authenticate the issuing authority of the digital license.

Embodiments provide a method performed by a verification authority computer of a verification authority. The method includes: certifying the issuing authority; receiving the issuing authority's public key from the issuing authority's issuing authority computer; digitally signing the issuing authority's public key using the verification authority's private key; and generating a digital certificate associated with the issuing authority. A digital certificate includes a digitally signed public key of the issuing authority. The method also includes sending a digital certificate to the recipient such that the digital certificate is associated with a digital license generated by the issuing authority and shares the validating authority public key with one or more parties adapted to obtain the digital certificate from the digital certificate. The license holder receives the digital license and associated certificate.

Embodiments also provide a verification authority computer associated with the verification authority, the verification authority including one or more processors and a memory coupled to the one or more processors. The memory stores instructions that, when executed by the one or more processors, cause the one or more processors to: certify an issuer, receive an issuer public key from the issuer; verify the issuer using a verification authority private key digitally sign with the public key; generate a digital certificate associated with the issuing authority; send the digital certificate to the recipient so that the digital certificate is associated with the digital license generated by the issuing authority; and share the verifying authority public key with one or more parties, so The party or parties described above are adapted to receive the digital license and associated certificate from the holder of the digital license. According to various embodiments, the digital certificate includes a digitally signed issuing authority public key.

Embodiments also provide methods performed by a relying party computer associated with the relying party. The method includes receiving a certification authority public key from a certification authority and receiving a digital license issued by an issuing authority from a user device. A digital license consists of a digital certificate signed by a validating authority using the validating authority's private key. The certification authority private key is paired with the certification authority public key. The method also includes validating the certificate using the certification authority public key. The certificate includes the issuing authority's public key. The method also includes verifying the information contained in the digital license using the issuing authority's public key.

Additional details regarding embodiments can be found in the detailed description and drawings.

Description of the drawings

Figure 1 shows a diagram for issuance and verification of digital licenses in accordance with various embodiments.

Figure 2 shows another diagram for issuance and verification of digital licenses in accordance with various embodiments.

Figure 3 illustrates the chain of trust between the relying party, the trusted third party (eg, the verification authority), the issuing authority, and the digital license.

Figure 4A illustrates a Certification Authority Private Key Infrastructure (PKI) model in accordance with various embodiments.

Figure 4B illustrates a master list model in accordance with various embodiments.

Figure 5 illustrates an exemplary use case for digital licensing in accordance with various embodiments.

Figure 6 shows a flowchart of steps according to various embodiments.

Detailed ways

Various embodiments are described in the description below. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without the specific details. Additionally, well-known features may be omitted or simplified so as not to obscure the described embodiments.

Before discussing the embodiments, some terminology may be described in further detail.

A "key" may include a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

A "public key" may include a cryptographic key that is open and publicly shareable. Public keys may be designed to be shared and may be configured such that any information encrypted with the public key can only be decrypted using the private key associated with the public key (ie, a public/private key pair).

A "private key" can include any cryptographic key that can be protected and secure. The private key may be securely stored at the entity and may be used to decrypt any information that has been encrypted with the associated public key of the public/private key pair associated with the private key.

A "public/private key pair" may refer to an associated pair of cryptographic keys generated by an entity. Public keys can be used for public functions, such as encrypting messages to be sent to an entity, or for verifying digital signatures that should be made by the entity. Private keys, on the other hand, can be used for private functions, such as decrypting received messages or applying digital signatures. In some embodiments, a public key may be authorized by a subject called a Certification Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key may typically be maintained in a secure storage medium and will typically be known only to the entity in question. The public and private keys may be in any suitable format, including those based on Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptometry (ECC).

A "digital signature" may include any electronic signature of a message. A digital signature can be a numeric data value, an alphanumeric data value, or any other type of data. In some embodiments, a digital signature may be a unique data value generated from a message (or data packet) and a private key using a cryptographic algorithm. In some embodiments, a verification algorithm using a public key may be used to verify the signature. Digital signatures can be used to demonstrate the authenticity of the authority that issued the credential (eg, digital license) associated with the digital signature.

The term "verification" and its derivatives can refer to the process of using information to determine whether a potential subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure that certain data or information is correct, valid, accurate, legal and/or reputable.

A "certificate" or "digital certificate" may include electronic files and/or data files. In some cases, the certificate or digital certificate may be a device certificate. In some embodiments, a digital certificate may use a digital signature to bind a public key with data associated with the identity. Digital certificates can be used to prove ownership of a public key. A certificate may include one or more data fields, such as the identity's legal name, the certificate's serial number, the certificate's start and end validity dates, certificate-related permissions, etc. A certificate may contain a "valid from" date indicating the first date the certificate is valid, and an "valid from" date indicating the last date the certificate is valid. The certificate may also contain a hash of the data included in the certificate's data fields. Certificates can be signed by a verification authority. For example, a validating authority may provide a digital certificate for a digital license provided by the issuing authority. Digital certificates help authenticate the issuing organization.

A "certifying authority" may include an entity that issues a digital certificate. A certification authority can prove its identity using a certification authority certificate, which includes the certification authority's public key. A certification authority certificate can be signed with the private key of another certification authority, or with the private key of the same certification authority. The latter is called a self-signed certificate. A certification authority may maintain a database of all certificates issued by the certification authority. A certification authority may maintain a list of revoked certificates. A verification authority may be operated by an entity such as a processing network entity, issuer, acquirer, central bank, etc.

An "Issuing Authority" may include an entity that issues credentials to users, typically using the issuing entity's computer to issue credentials. Issuing entities can be government agencies, healthcare providers, document repositories, access administrators, etc. The issuing entity may also issue the credential to the user in the form of a digital license stored on the user's device (eg, cell phone, smart card, tablet, or laptop).

"User" may include a person or a computing device. In some embodiments, a user may be associated with one or more personal accounts and/or user devices (eg, mobile devices).

A "user device" may be a device operated by a user. Examples of user devices may include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, vehicles (eg, automobiles), thin client devices, tablet PCs, and the like. Additionally, the user device may be any type of wearable technology device, such as a watch, headphones, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from a variety of data input types, including but not limited to audio data, visual data, or biometric data. User devices may include any electronic device operable by a user that may also provide remote communication capabilities with a network. Examples of remote communication capabilities include the use of mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or may provide access to a network (e.g., the Internet or a private network) any other communication medium.

A "server computer" is usually a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers acting as a unit. In one example, the server computer may be a database server coupled to a network server. A server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the foregoing for servicing requests from one or more client computers. A server computer may include one or more computing devices, and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

A "processor" may include any suitable data computing device or devices. A processor may include one or more microprocessors that work together to achieve desired functionality. The processor may include a CPU including at least one high-speed data processor sufficient to execute program components for executing user and/or system generated requests. The CPU may be a microprocessor, such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium , Xeon and/or XScale; and/or similar processors.

"Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include non-transitory computer-readable media storing instructions executable by a processor to perform the desired method. Examples of memory may include one or more memory chips, disk drives, and the like. Such memory may operate using any suitable electrical, optical and/or magnetic operating modes.

"Machine-readable code" may include any image or symbol that can be read by an electronic device for interpretation and manipulation by a computer. Some examples of machine-readable codes include barcodes, quick response (QR) codes, military-spec UID codes, and any other suitable code.

A "communication channel" may include a medium over which messages may be provided. Communication channels may include physical transmission media (eg, wires, contact interfaces, etc.), over-the-air communication media (eg, using electromagnetic signals, etc.), logical media (eg, application programming interfaces (APIs), etc.), and/or combinations thereof.

A "transaction" can be any interaction or exchange between two or more parties. For example, a transaction may include a first entity requesting resources from a second entity. In this example, the transaction is completed when the resource is provided to the first entity or the transaction is rejected.

"Interaction" may include reciprocal actions or effects involving more than one participant. "Interaction" may include communication, contact or exchange between parties, devices and/or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, the interaction may include the user requesting access to secure data, secure web pages, secure locations, etc.

An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a coordinating computer, communications network or any other suitable system. The access device may generally be located at any suitable location, such as at the location of the relying party. The access device may take any suitable form. Some examples of access devices include POS or point-of-sale devices (eg, POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, handheld specialty readers, set-top boxes, electronic cash registers (ECR), automated teller machine (ATM), virtual cash register (VCR), information service kiosk (kiosk), security system, access system, barcode reader, QR code reader, etc. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. The access device may use any suitable contact or contactless mode of operation to send or receive data to or associate with the user device. For example, the access device may have a card reader, which may include electrical contacts, a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with the user device.

An "access request" may include a request to access a resource. A resource may be a physical location (eg, a concert venue, an apartment building, an office space), a physical resource (eg, a building), a digital resource (eg, electronic files, electronic data, etc.), or a service. In some cases, an access request may be submitted by sending an access request message that includes the access request data. Typically, a device associated with the requesting party may send an access request message to a device associated with the relying party responsible for granting the requested access.

"Access Credentials" may include any suitable data that can be used to access a resource or create data that can access a resource. The credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used as confirmation. In other embodiments, access data may include data that may be used to access location or access security data. Such information can be driver's licenses, vaccination records, national passports, medical prescriptions, recreational licenses, entertainment permits, voter registration confirmations, identification documents to enter buildings, ticket information for events, data to enter buildings, transit ticket information , passwords, biometrics or other credentials to access secure data. According to various embodiments, access credentials may be provided in the form of a digital license configured on the user's device. For example, a digital license may be configured on a user device by an issuing authority that issues the digital license. In some embodiments, the digital license may be configured on the user device by a certification issuing authority and/or a certifying authority for the digital license.

The details of some embodiments will now be described in greater detail.

Embodiments associate digital certificates with digital licenses configured on the user device. The digital license is generated by the issuing authority (IA) and signed using the issuing authority's private key (IA private key). The issuing organization can share the issuing organization's public key (IA public key) with the verification authority. A digital certificate including the IA public key can then be generated by a Certification Authority (CA) and associated with the digital license. Verifying authorities may include globally trusted authorities.

As part of the interaction with the relying party, the user may present a digital license to the relying party. For example, a user may wish to gain access to a location (e.g., concert venue, foreign country, secure building) managed by a relying party that requires a specific set of credentials (e.g., tickets, vaccination records, passport, identification card). In other embodiments, the user may present a digital license as proof of authorization (eg, driver's license, fishing license). The relying party may receive the certification authority's public key (CA public key) from the certification authority. After receiving the digital license associated with the digital certificate, the relying party can use the CA public key to decrypt the digital certificate to obtain the information contained therein. For example, the issuing authority public key (IA public key) can be embedded in the digital certificate. The relying party can retrieve the IA public key, use the IA public key to decrypt the digital license, and obtain the information in the digital license. The relying party can trust the authenticity and accuracy of the information retrieved from the digital license because the relying party trusts the verification authority. Digital certificates issued by a verification authority in turn vouch for the identity of the issuing authority. Therefore, the relying party can trust the authenticity and accuracy of the information retrieved from the digital license.

Figure 1 shows a diagram for issuance and verification of digital licenses in accordance with various embodiments. According to various embodiments, digital permissions may include one or more of a driver's license, vaccination passport, regular passport, medical prescription, recreational license, entertainment permit, voter registration confirmation, identification document to enter a building, etc.

According to various embodiments, digital license 105 may be issued to a user as a digital license by an issuing authority (eg, issuing entity) 100 . The digital license 105 may be signed using the issuing authority's private key (the IA public key of the IA public and private key pair). In some embodiments, the digital license 105 may be configured by the issuing authority 100 on the user device 104 . The issuing authority 100 may share the issuing authority's public key (the IA public key of the IA public and private key pair) with the verification authority 102 .

The verification authority 102 may certify the issuing authority 100. In some embodiments, the verification authority 102 may receive a request from the issuing authority 100 to certify the issuing authority 100 . As part of certification issuer 100 , verification authority 102 may then interact with issuer 100 to collect and verify information about issuer 100 . For example, the verification authority 102 may receive information from the issuing authority 100 that is associated with the identity of the issuing authority 100 . As part of the certification issuer 100, the verification authority 102 can verify information associated with the identity of the issuing authority. After identifying (and verifying) the identity of the issuing authority, verification authority 102 may determine a set of authentication steps based on the identity of issuing authority 100. According to various embodiments, the verification authority 102 may perform a first set of authentication steps for authenticating the first issuing authority 100 and may perform a second set of authentication steps that is different from the first set of authentication steps for authenticating the second issuing authority. For example, a state Department of Motor Vehicles (DMV) that issues driver's licenses to users may be associated with a different set of authentication steps than a medical provider that issues vaccination records. This set of authentication steps may be based on the identity of the issuing authority 100 or the type of certificate issued by the issuing authority 100 . The verification authority 102 may authenticate the issuing authority 100 based on a set of authentication steps associated with the issuing authority 100 .

After authenticating the issuing authority 100, the verification authority 102 may generate a digital certificate 115 associated with the digital license 105 issued by the issuing authority 100. According to various embodiments, the verification authority 102 may certify the issuing authority 100 before or after receiving a request to issue a digital certificate.

According to various embodiments, the verification authority 102 may generate a CA public-private key pair having a CA public key 110 and a corresponding CA private key 111 . The verification authority 102 may store the CA public and private key pair at the storage device. The verification authority 102 may digitally sign (e.g., include additional data, hashes) the IA public key component using the CA private key 111 of the CA public and private key pair, thereby generating a digital certificate 115 including the IA public key signed with the CA private key 111 . In some embodiments, the verification authority 102 may return the digital certificate 115 to the issuing authority 100 so that the issuing authority 100 associates the digital certificate 115 with the digital license 105 issued by the issuing authority 100 . In other embodiments, the verification authority 102 may associate the digital certificate 115 with the digital license 105 on the user device 104 .

The verification authority 102 may share the CA public key 110 of the CA public and private key pair with one or more relying parties that may need to verify the digital certificate issued by the issuing authority 100 . The relying party (eg, verifier) 108 may be able to verify or certify the issuing authority 100 and/or the digital license 105 using the CA public key 110 of the CA public-private key pair. That is, the relying party may verify or certify the content of the issuing authority 100 and/or the digital license 105 based on the identity of the verification authority 102 . For example, a digital license 105 issued to a user (eg, the holder of the digital license) may include an identification card. Relying parties such as employers, airline operators, or security personnel at stadium entrances can confirm the validity of the digital ID card, as described in this article. Thus, embodiments enable digitization of physical licenses in a safe and reliable manner. Additionally, embodiments prevent the use and dissemination of fraudulent licenses.

According to various embodiments, two separate entities (eg, relying party and issuing authority) can authenticate each other. For example, in the United States, driver's licenses are issued by state Departments of Motor Vehicles (DMV). While each state in the United States may recognize each other's DMV, a foreign entity may not recognize a state DMV or even the state itself. When a person obtains a driver's license from, for example, the Wyoming DMV in the United States, the relying party in Japan has no means of confirming said information or even treating the Wyoming DMV of the United States as a reliable source. Embodiments provide a public key infrastructure (PKI) model in which a verification authority receives data from an issuing authority and verifies that the issuing authority and the received data are legitimate. Trusted verification agencies around the world underwrite the information provided by the issuer. A verification authority acts as a trusted intermediary capable of transferring trust or a chain of trust, thereby securely verifying whether information was received from or queried by a legitimate entity (e.g., an issuing authority).

According to various embodiments, the verification authority 102 performs a review of the issuing authority 100 (eg, a healthcare provider, a government agency that provides a driver's license, a national passport, etc.) before generating any digital certificate. The requirement to review an issuer 100 may depend on the type of permission provided by the issuer 100 or on the identity (eg, type) of the issuer 100 . For example, an entity that verifies identity information provided by a government agency as the issuing authority may have a different set of requirements than an entity that verifies medical information provided by a healthcare provider (e.g., hospital, doctor's office, pharmacy).

The verification authority 102 generates a CA private-public key pair. While the verification authority 102 keeps the CA private key 111 secret for signing the issuing authority's public key (eg, the IA public key), the verification authority 102 provides the CA public key 110 to anyone who needs to access and/or use the information on the digital license 105 Relying Party 108. Through the process of verifying the information on the digital license 105, the relying party 108 is able to trust the IA public key as a legitimately issued public key, and therefore the relying party 108 is able to verify that a piece of information retrieved from the digital license 105 was provided by a legitimate source.

According to various embodiments, the issuing authority 100 may request the verification authority 102 to issue a digital certificate 115 for the issuing authority. Verification authority 102 may verify issuing authority 100 using one or more authentication and verification processes. The exemplary authentication and verification process may include a set of steps that need to be performed by the verification authority 102 and/or the issuing authority 100 , and may depend on the type or identity of the issuing authority 100 , or the type of digital license issued by the issuing authority 100 .

The issuing authority 100 may then issue the digital license 105 to the user. Before issuing the digital license 105, the issuing authority 100 can verify the user's identity. The issuing authority 100 may generate an IA public and private key pair and provide the IA public key to the verification authority 102. The issuing authority 100 may sign the digital license 105 with the IA private key and configure the signed digital license 105 on the user device 104 (eg, on an electronic wallet of the user device).

The verification authority 102 uses the verification authority's own private key (for example, the CA private key 111) to sign the IA public key, thereby generating a digital certificate 115 to verify that the issuing authority 100 is a legitimate source. The verification authority 102 may provide the digital certificate 115 to the issuing authority 100 , which may configure the digital certificate 115 on the digital wallet of the user device 104 to be associated with the digital license 105 . When presented to the verifier/relying party 108, the relying party 108 can use the CA public key 110 to verify the digital certificate 115 signed with the CA private key 111. The relying party 108 can then retrieve the IA public key from the digital certificate 115 . The relying party 108 can trust that the IA public key is trusted based on the IA public key signed using the CA private key 111 (eg, the verification authority 102 is a globally trusted entity, or the verification authority 102 is an entity that the relying party 108 trusts). The relying party 108 can then retrieve the information from the digital license 105 and trust that the issuing authority 100 that issued the information is legitimate.

Figure 1 also shows a series of steps for generating and verifying a digital license. In step 1, the verification agency 102 verifies the legitimacy of one or more issuing agencies 100 and establishes a trustworthy relationship with each issuing agency 100. The verification authority 102 may generate a CA public and private key pair and use the CA private key 111 to sign digital certificate requests from the trusted issuing authority 100 . According to various embodiments, the issuing authority 100 may include one or more of the following: a medical service provider; a government entity that issues forms of identification such as driver's licenses, passports, national identity cards, etc.; issues such as public transportation tickets, airline tickets, or entry tickets. The organization of event tickets (for example, concert tickets or building passes). The issuing authority 100 may share the IA public key with the verification authority 102 and perform the authentication steps required by the verification authority 102 to authenticate itself to the verification authority 102 .

In step 2, the issuing authority 100 may generate a digital license 105 signed with the IA private key. According to various embodiments, the issuing authority 100 may configure the digital license 105 on the electronic wallet of the user device 104 (eg, the user's mobile device). Digital licenses 105 may be provided remotely and may be renewed by the issuing authority 100 as needed (eg, upon expiration, when information is changed or updated, etc.). Users may be able to request modifications to the information associated with the digital license 105 to add or remove temporary or permanent information, such as disability status, temporary address, etc. According to various embodiments, communications between user device 104 and issuing authority 100 may use new communications standards (eg, ISO/IE CTS 23220-3).

In step 3, the verification authority 102 may digitally sign the IA public key with the CA private key 111 to generate a digital certificate 115 for the issuing authority 100. For example, digital certificate 115 may prove the legitimacy or authenticity of issuing authority 100 . In some embodiments, the verification authority 102 may directly update the digital license 105 on the user device 104 to be associated with the digital certificate 115 that is digitally signed (eg, "locked") using the CA private key 111 , thereby establishing Legality of the issuing agency 100. Digital certificate 115 may include an IA public key digitally signed with CA private key 111 . For example, the verification authority 102 may receive a request from the user device 104 to verify a digital license 105 configured on the user device 104 . The verification authority 102 may send the digital certificate 115 to the user device 104 to link to the digital license 105 on the user device 104 .

In other embodiments, the verification authority 102 may return the digital certificate 115 to the issuing authority 100 so that the issuing authority 100 links the digital certificate 115 with the digital license 105 . Issuing authority 100 may receive digital certificate 115 before or during generation of digital license 105 . Issuing authority 100 may associate (eg, link) digital certificate 115 with digital license 105 .

At step 4, the verification authority 102 may provide the CA public key 110 to one or more relying parties 108 adapted to receive the digital license 105 from the user (e.g., the holder of the digital license) and Associated digital certificate 115. One or more relying parties 108 may interoperate with all trusted issuers worldwide. The verification authority 102 may support offline and online digital authentication of dependent entities. For example, the verification authority 102 may send the CA public key 110 to the relying party 108, and the relying party 108 may store the CA public key 110 in a secure location. Alternatively, the verification authority 102 may store the CA public key 110 in a storage device accessible to the relying party 108 (eg, a cloud storage device). The verification authority 102 may notify the relying party 108 how to retrieve the CA public key 110 from the cloud or remote storage. For example, the verification authority 102 may send access credentials to the storage device to the relying party 108 . In some embodiments, the verification authority 102 may provide the CA public key 110 to the relying party 108 at the request of the relying party 108 .

According to various embodiments, the involvement of the verification authority 102 may reduce counterfeit ID fraud and reduce reliance on manual inspections that require specialized and localized knowledge. The verification authority 102 can ensure the legitimacy of the issuing authority 100 that issued the digital license 105 .

At step 5, the user presents the digital license 105 associated with the digital certificate 115 to the relying party 108. The relying party 108 may retrieve the CA public key 110 to retrieve and/or verify the authenticity of the IA public key. The relying party 108 can then retrieve the information contained in the digital license 105 using the IA public key. According to various embodiments, the user may provide the digital license 105 to the relying party 108 via any suitable means, including but not limited to communication via Bluetooth, NFC, Wi-Fi, or using a machine-readable code (eg, a QR code). The relying party 108 may receive and verify data from the user/user device using a dedicated mobile application installed on the terminal or a dedicated terminal (eg, access device). The data transfer between the user device 104 and the relying party terminal may be an offline data transfer.

According to various embodiments, the user may select all information or a subset of the information on the digital license 105 to provide to the relying party 108 . For example, the information provided may comply with the ISO 18013-5 standard. The relying party computer may have detected (eg, through an identifier on the user device 104 ) that the digital license 105 is associated with the digital certificate 115 issued by the verification authority 102 . The relying party 108 can then retrieve the CA public key 110 and decrypt the digital certificate 115 to obtain the IA public key, and then decrypt the digital license 105 to obtain the information contained therein. If the series of decryptions and/or verifications are successful, the relying party 108 can now trust that the issuing authority 100 is legitimate because it is associated with the trusted verification authority 102 . In some cases, the relying party computer may also contact the verification authority 102 to determine whether the details of the digital certificate 115 are still valid. Relying parties 108 may rely on a single trusted entity (eg, verification authority 102) to reliably authenticate IDs from all participating jurisdictions around the world.

As described above, the verification authority 102 verifies the authenticity of the issuing authority 100 using the verification authority's 102 public and private key infrastructure. According to various embodiments, the verification authority 102 does not authenticate the user who presented the digital license 105 to the relying party 108 . It is the issuing authority 100 that authenticates the user before issuing the digital license 105 to the user. The verification authority 102 certifies the issuing authority 100 .

According to various embodiments, the verification authority 102 may provide a mobile application (eg, a software application, an "app") on the user device 104. Digital licenses 105 and digital certificates 115 can be configured on the mobile application rather than on the e-wallet. Alternatively, as described above, the digital license 105 and digital certificate 115 may be configured on the electronic wallet of the user device 104. However, in some embodiments, the digital license 105 may be configured on the electronic wallet and the digital certificate 115 may be configured on the verification authority application on the user device 104 .

Figure 2 shows another diagram for issuance and verification of digital licenses in accordance with various embodiments. Issuing authority 202 may be audited (eg, certified, verified) by verification authority 206 . According to an exemplary embodiment, the digital license may be a mobile driving license (mDL). Accordingly, FIG. 2 may illustrate a method of generating and/or validating the user's mDL data provided by the user and/or the mDL to the relying party 216 . Use previously configured data held by the mDL and relying party 216 (eg, IA certificate, mDL certificate, CA public key) in order to perform offline verification of the user's personal data. One of ordinary skill in the art will understand that the use of mDL is for illustrative purposes only and should not be construed as limiting. The process 200 shown in Figure 2 can be applied to other digital permissions, including but not limited to vaccination passports, ordinary passports, medical prescriptions, entertainment licenses, entertainment licenses, voter registration confirmations, and identification documents to enter buildings.

In step 1, the issuing authority 202 under review may generate an IA public and private key pair. At step 2, the issuing authority 202 may send a certificate request 204 to the verification authority 206, requesting the verification authority 206 to generate a certificate (eg, a digital certificate) for the digital license issued by the issuing authority 202. Certificate request 204 may include the IA public key. At step 3, the verification authority 206 may review the certificate request 204 received from the issuing authority 202, confirm that the issuing authority is vetted/certified, and digitally sign the provided information (e.g., IA public key) using the CA private key , thereby generating a digital certificate 208. For example, elliptic curve cryptography can be used to generate a CA public and private key pair. The verification authority 206 may store the CA public and private key pairs (or at least the CA private keys) in a secure database managed by the verification authority 206 . The verification authority 206 provides a copy of the CA's public key to the relying party 216 . For example, the verification authority 206 may configure the CA public key on the relying party 216's computer so that the relying party 216 securely stores the CA public key. Alternatively, the verification authority 206 may store the CA public key at a cloud storage device accessible by the relying party 216 .

Verifying authority 206 may return digital certificate 208 to issuing authority 202. At step 4, issuing authority 202 receives digital certificate 208 from verification authority 206. In step 5, the issuing authority 202 generates a digital license 210 (or retrieves a previously generated digital license) and personalizes the digital license 210 with a digital certificate 208. For example, the issuing authority 202 associates the digital certificate 208 received from the verification authority 206 with the digital license 210 generated by the issuing authority 202 . Issuing authority 202 then configures digital license 210 and digital certificate 208 on user device 212. According to various embodiments, the user device may be a mobile phone or a smart device (eg, smart card, smartphone, etc.). At step 6, the user presents the digital license 210 and the digital certificate 208 to the relying party's 216 terminal via the user device 212. The relying party 216 retrieves the CA public key to decrypt the digital certificate 208 and retrieve the IA public key, thereby authenticating the issuing authority 202 . The relying party 216 can then retrieve the data in the digital license 210 using the IA public key. Therefore, the relying party 216 can trust the authenticity of the digital license 210 issued by the issuing authority 202.

For example, relying party 216 may be a merchant that needs to check a user's age before providing goods or services to the user. When the user presents the user device to the relying party's terminal, the mobile driver's license sends a digital certificate (generated by the verification authority 206 and including the digitally signed IA public key) to the relying party computer. The digital certificate may have any suitable format, such as the X.509 format, which includes, inter alia, the certificate version number, serial number, issuer name, validity period, owner public key information and signature.

The relying party computer can detect (eg, via an identifier on the card) that the mobile driver's license is associated with the verification authority 206 and retrieve the CA public key. The relying party computer can use the CA public key to verify that the IA public key was signed by the CA private key. The relying party computer then extracts the IA public key from the digital certificate and can verify that the digital license was signed with the IA's private key. If the verification is successful, the relying party computer can now trust that the issuing authority 202 is legitimate because it has been certified by the trusted verification authority 206 . In some cases, the relying party computer may also contact the verification authority 206 to determine whether the details of the digital certificate are still valid.

In some embodiments, the user device or an application on the user device may use mDL data (e.g., name, expiration date, IA signature information), which may be through industry standard means (e.g., ISO 18013-5), such as through The user credentials are encrypted with the private key to create a dynamic signature if required for the transaction (for example, using the mDL private key) and send the signature to the relying party. Dynamic signatures are signatures that are only valid for a single certificate to protect users from data cloning.

Figure 3 shows the chain of trust between the parties described in Figures 1 and 2. Public key algorithms can be used to authenticate messages between different parties. Relying party 300 (eg, merchant, transit terminal operator) trusts verification authority 302 (eg, third party) and stores or otherwise has access to the CA verification public key that will be retrieved later during the transaction. Therefore, the verifying authority 302 and the relying party 300 of the chain of trust trust the issuing authority 304 (eg, healthcare provider, government entity that issued the identity). According to various embodiments, the verification authority 302 may review the issuing authority 304 to ensure that the issuing authority 304 is legitimate. The issuing authority 304 trusts the digital license 306 because it is its issuer, and therefore the relying party 300 can trust the digital license 306 . This chain of trust allows the relying party 300 to trust that the data provided via the digital license 306 is legitimate. Therefore, the relying party 300 can trust the digital license 306 by following the process described herein with respect to at least FIGS. 1 and 2 without requiring an online connection to the issuing authority 304 .

The certification authority may certify and vouch for the issuing institution in any appropriate manner. For example, the verification authority may use the private key infrastructure (PKI) model shown in Figure 4A. In some embodiments, the verification authority may use a master list model as shown in Figure 4B.

Figure 4A illustrates a certification authority private key infrastructure (PKI) model 400 in accordance with various embodiments. There are a large number of issuing agencies 402, 404, 406 around the world (e.g., state DMVs; national, state, or local governments; national or local health care providers, etc.). Without the benefits provided by the embodiments described herein, the relying party 414 would have to maintain a continuously up-to-date list of all legitimate issuers 402, 404, 406 and their public keys IA1, IA2, IA3, while keeping illegal keys on the list. Additionally, this is an expensive and difficult task. Using a PKI solution, the relying party 414 will only need to maintain an updated connection to a single global trusted verification authority 410 rather than all issuing authorities.

The global trusted verification authority 410 has a private and public key pair. Verification authorities interact with legitimate issuers and verify/certify their legitimacy. The verification authority may then receive the certified issuing authority's IA public key and sign the IA public key with the CA private key, thereby generating a digital certificate 408 for the issuing authority. The verification authority 410 may send the digital certificate 408 to the corresponding issuing authority 402, 404, 406, which then associates the digital certificate 408 with the digital license generated by the corresponding issuing authority 402, 404, 406. For example, when a car rental agent in Japan (as the example relying party 414) wishes to verify the authenticity of a digital driver's license issued by the state of Missouri in the United States, the car rental agent will use a globally trusted CA shared with the car rental agent by the verification authority 410 The public key 412 verifies the digital certificate associated with the digital driver's license, allowing the car rental agent to trust the issuing authority 402, 404, 406 in a cryptographically secure manner.

The Global Trusted Verification Authority 410 uses a PKI scheme to verify that the issuing authority 402, 404, 406 is legitimate, increasing domestic and global reach and trust, and allowing relying parties 414 to trust the legitimacy of the issuing authority 402, 404, 406 based on the digital license. In the event that the issuing authority is not properly vetted (eg, fraudulent issuing authority 416), the validating authority 410 may refuse to sign the IA public key and generate a digital certificate for the uncertified issuing authority 416. The relying party 414 must only maintain a connection to a central verification authority 410 rather than hundreds of issuing authorities 402, 404, 406. Issuing institutions 402, 404, 406 benefit from reduced fraud and increased acceptance of digital licenses issued by them. In contrast to localized systems, users can use their digital licenses in a wide variety of regions.

Figure 4B illustrates a master list model 450 in accordance with various embodiments. In the master list model 450, all issuing authorities 452, 454, 456 store their public keys 462, 464, 466 on a master list 460, which may be stored on a remote server (eg, on the cloud). The master list distributor (eg, verification authority 470) may then sign the master list (rather than each individual IA public key 462, 464, 466) using the master list distributor private key. The relying party 480 then checks whether the master list 460 is authentic using the master list distributor public key, and retrieves the relevant IA public keys 462, 464, 466 from the master list 460. According to the master list model, digital certificates are not related to digital licenses. Instead, the master list distributor certifies the master list 460 of IA public keys. The master list model may be applicable where the issuing authority does not allow third parties, such as the verification authority 470, to modify or verify the digital license. According to various embodiments, global coverage may require multiple master list distributors. Master list distributors must implement strong, consistent, and scalable controls and governance to verify the legitimacy of each self-signing issuer and prevent key spoofing (e.g., to prevent fraudulent issuers 474 from inserting fraud into the master list 460 IA public key 472).

Figure 5 illustrates an exemplary use case for digital licensing in accordance with various embodiments. According to an exemplary use case, the digital license may include a mobile vaccination card 502 (eg, a digital vaccination passport) configured on the user device 500 by an issuing authority (eg, a local healthcare provider). The local healthcare provider can verify the user's identity, administer the required vaccinations, and issue a mobile vaccination card 502 (mVC) to the user's user device 500. mVC 502 may include a variety of information, including, but not limited to, user identification information (e.g., user name, user date of birth, user photo), vaccine identification information (e.g., manufacturer, lot number, serial number, date of administration, dose number, ingredients ). Local healthcare providers can sign the mVC 502 using the IA private key. Authentication authorities can authenticate and establish secure communications with local healthcare providers. The verification authority can then authenticate the local healthcare provider and can use the CA private key to sign the local healthcare provider's IA public key. The verification authority may generate a digital certificate and provide the digital certificate to the local healthcare provider for configuration on user device 500 as associated with mVC 502 . Alternatively, the verification authority may update the mVC 502 configured on the user device 500 with the digital certificate generated by the verification authority. According to various embodiments, the verification authority may provide a digitally licensed mobile application. In some embodiments, the digital license (and associated digital certificate issued by the verification authority) may be configured on the user's device's digital wallet.

The certification authority can share the CA public key with the relying party. Verification authorities may also provide mobile verification applications to relying parties upon request. When a user presents their mVC to the relying party, the relying party can use the CA public key to authenticate the local healthcare provider by retrieving the IA public key, and can then use the IA public key to retrieve and verify the information stored on the mVC 502 . Relying parties can use the same mobile verification application to verify mVC for multiple users.

As shown in Figure 5, users can select the type, level and content of information that will be shared with relying parties. For example, the user may choose whether to publish all data 504 or a subset of the data 506 with the relying party. Users can decide what information is shared based on the identity of the relying party. For example, sharing all data at a customs checkpoint may be appropriate, but publishing only minimal data as a condition of entry to a restaurant may be sufficient. The relying party's mobile application 510 may receive information from the user device (eg, by reading the machine-readable code 512 ).

Figure 6 shows a flowchart of steps according to various embodiments. In step S608, the verification authority 600 may share the CA public key with the relying party 606. As explained above, the verification authority 600 can send the CA public key directly to the relying party 606. Otherwise, the verification authority 600 may store the CA public key at a cloud storage device accessible by the relying party 606.

The issuing authority may request a certificate from the certification authority 600. The request may include the IA public key. As part of a certification issuer, the verification authority 600 can interact with the issuer to collect and verify information about the issuer. For example, the verification authority 600 may use a set of certification steps to certify the issuing authority. In some embodiments, the verification authority 600 may first identify the issuing authority. Verification authority 600 may then determine a set of authentication steps based on the identity of the issuing authority or the type of verification issued by the issuing authority. Verification authority 600 may authenticate an issuing authority based on a set of authentication steps associated with the issuing authority. According to various embodiments, a first set of authentication steps may be performed to authenticate a first issuing authority (e.g., a government entity), and a second set of authentication steps, different from the first set of authentication steps, may be performed to authenticate a second issuing authority (e.g., local healthcare provider).

The verification authority 600 may generate a digital certificate associated with the issuing authority and send the digital certificate to the recipient to associate the digital certificate with the digital license generated by the issuing authority. The recipient can be the issuing institution. A digital certificate includes a digitally signed IA public key digitally signed using the CA private key. For example, the verification authority 600 may embed the digitally signed IA public key into the digital certificate.

The issuing authority associates the digital certificate with the digital license generated by the issuing authority. The issuing authority configures (or otherwise sends) the digital license associated with the digital certificate to the user device 604.

At optional step S615, prior to sharing the digital license with a third party (e.g., relying party 606), user device 604 (via a software application stored on user device 604) may use the private key (e.g., digital license application) to key) to sign digital licenses and digital certificates. That is, user device 604 can generate dynamic signatures.

At step S616, the user device 604 may send the digital license together with the digital certificate to the relying party 606. A digital license is associated with (eg, includes the digital certificate) a digital certificate signed by a verification authority using a CA private key, which is paired with a CA public key. As discussed above, the relying party 606 may have received (or otherwise retrieved) the CA public key.

At step S618, the relying party 606 may verify (eg, decrypt) the digital certificate using the CA public key and retrieve the IA public key from the decrypted digital certificate.

At optional step S620, the relying party 606 may extract the digital license using the digital license application public key.

At step S622, the relying party 606 may retrieve and verify the information contained in the digital license using the IA public key. Relying parties can verify the issuing authority's signature and the information contained in the digital license at the verification authority. According to various embodiments, the level of detail of the information contained in the digital license may depend on the identity of the relying party 606.

As mentioned above, digital certificates and digital licenses are stored or installed on the mobile device. In some embodiments, a mobile device may allow a user to gain access to location or security data. An example mobile device may include computer-readable media that may be present within the body of the mobile device. Computer-readable media may be in the form of memory that stores data. In some cases, the memory may also store information such as digital licenses associated with digital certificates. Generally, any of this information may be transmitted from a mobile device to another device using any suitable method, including the use of antennas or contactless elements. The body may take the form of a plastic substrate, housing or other structure.

In some embodiments, the mobile device may also include a contactless element, typically implemented in the form of a semiconductor chip (or other data storage element), with associated wireless transmission (eg, data transmission) elements, such as an antenna. The contactless element may be coupled to (eg, embedded in) the mobile device, and data or control instructions sent via the cellular network may be applied to the contactless element via a contactless element interface (not shown). Contactless elements may be able to transmit and receive data using short-range wireless communication capabilities. Mobile devices may include components for receiving and sending data. Thus, a mobile device may be able to communicate and send data or control instructions via a cellular network (or any other suitable wireless network—eg, the Internet or other data network) and short-range communications.

The mobile device may also include a processor (eg, a microprocessor) for processing the functionality of the mobile device and a display that allows the consumer to see the phone number and other information and messages. The mobile device may also include input elements that allow the user to enter information into the device, speakers that allow the user to hear voice communications, music, etc., a microphone that allows the user to send his or her voice through the mobile device, and for taking photos or scanning machine-readable codes camera. Mobile devices may also include antennas for wireless data transmission (eg, data transmission).

Memory may be in the form of one or more memory devices (eg, RAM, EEPROM, ROM chips) using any suitable data storage mode. In some embodiments, memory in the mobile device may also include a secure storage area for storing sensitive data, such as digital licenses associated with digital certificates. For example, the memory may be part of the secure element or may contain the secure element.

A computer (eg, a verification authority computer) according to various embodiments includes a processor and memory. A network interface and non-transitory computer-readable media may be coupled to the processor.

A processor may be implemented as one or more integrated circuits (eg, one or more single or multi-core microprocessors and/or microcontrollers). The processor may execute various programs in response to program code or computer-readable code stored in a computer-readable medium. A processor may include functionality to maintain multiple concurrently executing programs or processes. The memory may store multiple application programs executable by the processor, as well as public/private key pairs generated by the computer.

A network interface may be configured to connect to one or more communications networks to allow the computer to communicate with other entities (eg, external computers, issuing authority computers, relying party computers, user devices). Some examples of network interfaces may include modems, physical network interfaces such as Ethernet cards or other network interface cards (NICs), virtual network interfaces, communication ports, Personal Computer Memory Card International Association (PCMCIA) slots and cards, and the like. Wireless protocols enabled by the network interface may include Wi-Fi ^™ . Data transmitted via a network interface may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals capable of being received by an external communications interface (collectively, "electronic signals" or "electronic messages") . These electronic messages, which may include data or instructions, may be provided between the network interface and other devices via a communication path or channel. As noted above, any suitable communications path or channel may be used, such as wire or cable, fiber optics, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

Computer-readable media may include one or more non-transitory media for storage and/or transmission. Suitable media include, for example, random access memory (RAM); read only memory (ROM); magnetic media, such as a hard drive; or optical media, such as a CD (Compact Disc) or DVD (Digital Versatile Disc); flash memory, etc. Computer-readable media can be any combination of such storage or transmission devices. Computer-readable media may be embodied by any number of non-volatile memory (eg, flash memory) and volatile memory (eg, DRAM, SRAM), or any other non-transitory storage medium or combination of media.

According to various embodiments, a computer-readable medium may store instructions that, when executed by a processor, cause the processor to: certify an issuing authority; receive an issuing authority public key from the issuing authority; use the certifying authority's private key to authenticate an issuing authority digitally signing with the authority's public key; generating a digital certificate associated with the issuing authority, wherein the digital certificate includes the digitally signed issuing authority's public key; sending the digital certificate to the recipient such that the digital certificate is identical to the one issued by the issuing authority associating the generated digital license; and sharing the certification authority public key with one or more parties adapted to receive the digital license and associated digital certificate from the holder of the digital license.

Embodiments provide various advantages. According to various embodiments, digital permissions configured on the user device may also be used during mobile wallet configuration. Digital permissions can be used to match account holder and device holder data during account provisioning on the user's device, thus limiting the potential for tokens and fraudulent information to be provisioned on the user's device. In some embodiments, digital permissions can be used to authenticate accounts or loan applications and link them to the submitter, thereby reducing the opportunity for fraud using stolen identities. In other embodiments, digital licensing and merchant authentication processes allow age verification to be automated and reduce the number of illicit/illicit purchases and activities, e.g., activities related to purchasing alcohol and tobacco; entering bars, clubs, casinos; vehicle rentals, etc. Digital permissions can also be used in the airline industry to link device owners with boarding documents on their mobile devices, as well as simplify the traditional ID verification process and reduce the use of fraudulent IDs during travel. It is the Notary's responsibility to ensure the identity of each signatory and failure to do so may result in civil or criminal liability. Digital licensing provides the opportunity to authenticate documents and link them more closely to their holders, thereby eliminating notarization risks and reducing the notarization of fraudulent information. Other use cases include secure building access, traffic stops, job eligibility verification, prescription and medication procurement, voter registration, government programs, recreational licenses and permits.

Any software component or function described in this application may be implemented using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented Technology Software code executed by a processor. Software code may be stored as a sequence of instructions or commands on a computer-readable medium for storage and/or transmission. Suitable media include random access memory (RAM), read only memory (ROM), magnetic media (such as a hard drive or floppy disk), or optical media (such as a compact disk (CD) or digital versatile disk (DVD)), flash memory, etc. The computer-readable medium can be any combination of such storage devices or transmission devices.

Such programs may also be encoded and sent using carrier signals suitable for transmission over wired, optical and/or wireless networks conforming to various protocols, including the Internet. Thus, computer-readable media according to embodiments may be produced using data signals encoded by such programs. Computer-readable media encoded with program code may be packaged with a compatible device or provided separately from other devices (eg, via download over the Internet). Any such computer-readable medium may reside on or within a single computer product (eg, a hard drive, a CD, or an entire computer system), and may exist on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display for providing the user with any of the results mentioned herein.

The above description is illustrative and not restrictive. Those skilled in the art will appreciate many variations of the embodiments upon reading this disclosure. The scope, therefore, should be determined not with reference to the above description, but rather with reference to the appended claims, along with their full scope or equivalents.

One or more features from any embodiment may be combined with one or more features from any other embodiment without departing from the scope of the embodiments.

As used herein, use of "a" or "the" is intended to mean "at least one" unless expressly indicated to the contrary.

Claims (20)

1. A method including: Certification of the issuing organization by the certification authority's certification authority computer; receiving, by the verification authority computer, an issuing authority public key from an issuing authority computer of the issuing authority; The verification authority computer uses the verification authority private key to digitally sign the issuing authority public key; Generate, by the verification authority computer, a digital certificate associated with the issuing authority, wherein the digital certificate includes a digitally signed issuing authority public key; sending the digital certificate to a recipient by the verification authority computer so that the digital certificate is associated with the digital license generated by the issuing authority; and The certification authority public key is shared by the certification authority computer with one or more parties adapted to receive the digital license and associated digital certificate from the holder of the digital license. 2. The method of claim 1, wherein the recipient is the issuing authority, and the issuing authority associates the digital certificate with the digital license generated by the issuing authority. 3. The method of claim 1, wherein the recipient is a user device on which the digital license is configured, and the method further comprising: receiving, by the verification authority computer, a request from the user device to verify the digital license configured on the user device; and The digital certificate is sent to the user device by the verification authority computer to be linked to the digital license on the user device. 4. The method of claim 1, further comprising: The digitally signed issuing authority public key is embedded in the digital certificate by the verification authority computer. 5. The method of claim 1, wherein the digital license includes one or more of the following: driver's license, vaccination passport, ordinary passport, medical prescription, entertainment license, entertainment permit, voter registration Confirmation of identification to enter the building. 6. The method of claim 1, wherein the digital license is configured on a user device by the issuing authority. 7. The method of claim 1, further comprising: Identifying, by the verification authority computer, the identity of the issuing authority; determining, by the certification authority computer, a set of certification steps based on the identity of the issuing authority or the type of certification issued by the issuing authority; and The issuing authority is certified by the certification authority computer based on the set of certification steps associated with the issuing authority. 8. The method of claim 7, wherein a first set of authentication steps is performed for authenticating a first issuing authority, and a second set of authentication steps different from the first set of authentication steps is performed for authenticating Secondary issuing agency. 9. The method of claim 1, further comprising: receiving, by the certification authority computer, a request from the issuing authority to certify the issuing authority; and As part of authenticating the issuing authority, the verifying authority computer interacts with the issuing authority to collect and verify information about the issuing authority. 10. A verification authority computer associated with a verification authority, the verification authority computer comprising: one or more processors; and A memory coupled to the one or more processors and storing instructions that, when executed by the one or more processors, cause the one or more processors to: Certification issuing agency; receiving an issuing authority public key from the issuing authority; Digitally sign the issuing authority's public key using the verification authority's private key; generating a digital certificate associated with the issuing authority, wherein the digital certificate includes a digitally signed issuing authority public key; sending the digital certificate to a recipient to associate the digital certificate with the digital license generated by the issuing authority; and The certification authority public key is shared with one or more parties adapted to receive the digital license and associated digital certificate from the holder of the digital license. 11. The verification authority computer of claim 10, wherein sending the digital certificate to the recipient includes sending the digital certificate to the issuing authority, the issuing authority aligning the digital certificate with the associated with the digital license generated by the issuing authority. 12. The verification authority computer of claim 10, wherein the instructions, when executed by the one or more processors, cause the one or more processors to: Send said certification authority public key to said party or parties; or The certification authority public key is stored at a storage device and access credentials to the storage device are sent to the party or parties. 13. The verification authority computer of claim 10, wherein the digital license includes one or more of the following: a driver's license, a vaccination passport, an ordinary passport configured on the user device by the issuing authority , medical prescriptions, entertainment licenses, entertainment permits, voter registration confirmation, identification to enter buildings. 14. The certification authority computer of claim 10, wherein instructions to certify the issuing authority further comprise instructions for: Identifying, by the verification authority computer, the identity of the issuing authority; determining, by the certification authority computer, a set of certification steps based on the identity of the issuing authority or the type of certification issued by the issuing authority, wherein a first set of certification steps are performed for authenticating a first issuing authority, and A second set of authentication steps, different from the first set of authentication steps, is performed for authenticating the second issuing authority; and The issuing authority is certified by the certification authority computer based on the set of certification steps associated with the issuing authority. 15. The certification authority computer of claim 10, wherein instructions to certify the issuing authority further comprise instructions for: Generate the verification authority private key and the verification authority public key; and Store the public and private key pairs of the certification authority in the database. 16. The certification authority computer of claim 10, wherein instructions to certify the issuing authority further comprise instructions for: Receive information from the issuer associated with the identity of the issuer; and As part of authenticating said issuing authority, verifying said identity associated with said issuing authority 231692 1PWCN linked information. 17. A method comprising: The relying party computer receives the certification authority public key from the certification authority; A digital license issued by an issuing authority is received by the relying party computer from a user device, wherein the digital license includes a digital certificate signed by the certification authority using a certification authority private key, wherein the certification authority private key is identical to the certification authority private key. Verification authority public key pairing; Verify the digital certificate by the relying party computer using a verification authority public key, wherein the digital certificate includes an issuing authority public key; and The information contained in the digital license is verified by the relying party computer using the issuing authority public key. 18. The method of claim 17, further comprising: Decrypting, by the relying party computer, the digital certificate using the verification authority public key; Retrieve, by the relying party computer, the issuing authority public key from the decrypted digital certificate; and The information contained in the digital license is retrieved by the relying party computer using the issuing authority public key. 19. The method of claim 17, wherein the digital license includes one or more of the following: driver's license, vaccination passport, ordinary passport, medical prescription, entertainment license, entertainment license, voter registration Confirmation of identification to enter the building. 20. The method of claim 17, wherein the level of detail of the information contained in the digital license depends on the identity of the relying party associated with the relying party computer.