CN116349198B

CN116349198B - Method and system for authenticating credentials

Info

Publication number: CN116349198B
Application number: CN202180067717.6A
Authority: CN
Inventors: A·阿艾拜; C·麦克米兰; A·克拉克; C·阿艾拜; S·赫里
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2021-07-23
Filing date: 2021-12-16
Publication date: 2023-12-22
Anticipated expiration: 2041-12-16
Also published as: CN116349198A; CN117614631A

Abstract

An Issuer (IA) may verify the identity of a user and issue digital licenses to the user. The IA may generate an IA public-private key pair and provide the IA public key to a verification authority (CA). The IA may sign the digital license with the IA private key and configure the signed digital license on the user device. The IA may request the CA to verify the digital license. The CA may 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 issuer that is linked to the digital license. The relying party may use the CA public key to verify the digital license. The relying party may retrieve information from the digital license and trust that the retrieved information is legitimate.

Description

Method and system for authenticating credentials

Cross reference to related applications

The present application claims the benefit of U.S. provisional patent application No. 63/127,515 entitled "method and System for authenticating credentials (Method and System for Authentication Credential)" filed on month 12 and 18 of 2020 and U.S. provisional patent application No. 63/225,313 entitled "method and System for digital licensing (Method and System for Digital License)" filed on month 7 and 23 of 2021, the disclosures of which are incorporated herein by reference in their entirety for all purposes.

Background

The issuer of the identification information (e.g., DMV, healthcare provider, city, state, or federal government agency) provides data regarding the person (user) used in the transaction. However, the issuer is not necessarily known to the relying party (e.g., merchant), and thus cannot be guaranteed to be authentic. Not all transactions occur at locations with a stable connection to the online authentication service. 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 record, or other types of verification, which may reveal more information about the user than is required for the transaction.

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

Disclosure of Invention

Embodiments allow for offline authentication of digital license issuers. Offline issuer authentication allows for 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 validation authority may be associated with (e.g., integrated into or attached to) the digital license, and the issuer of the digital license may be authenticated.

Embodiments provide a method performed by a validation authority computer of a validation authority. The method comprises the following steps: authenticating the issuing authority; receiving an issuer public key from an issuer computer of an issuer; digitally signing the issuer public key using the private key of the verifier; and generating a digital certificate associated with the issuer. The digital certificate includes a digitally signed issuer public key. The method further includes sending the digital certificate to a recipient to associate the digital certificate with the digital license generated by the issuer and to share a verification authority public key with one or more parties adapted to receive the digital license and the associated certificate from a holder of the digital license.

Embodiments also provide a validation authority computer associated with a validation authority that includes one or more processors and memory coupled to the one or more processors. A memory stores instructions that, when executed by the one or more processors, cause the one or more processors to: authenticating the issuer, receiving an issuer public key from the issuer; digitally signing the issuer public key using the verifier private key; generating a digital certificate associated with an issuer; transmitting the digital certificate to the recipient to associate the digital certificate with the digital license generated by the issuer; and sharing the certificate authority public key with one or more parties 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 issuer public key.

Embodiments also provide methods performed by a relying party computer associated with a relying party. The method includes receiving a verification authority public key from a verification authority and receiving a digital license issued by an issuer from a user device. The digital license includes a digital certificate signed by the validation authority using a validation authority private key. The verification authority private key is paired with the verification authority public key. The method also includes verifying the certificate using the certificate authority public key. The certificate includes an issuer public key. The method also includes verifying information contained in the digital license using the issuer public key.

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

Drawings

FIG. 1 illustrates a diagram for issuing and verifying digital licenses in accordance with various embodiments.

FIG. 2 illustrates another diagram for issuing and verifying digital licenses in accordance with various embodiments.

Fig. 3 illustrates a chain of trust between a relying party, a trusted third party (e.g., a validation authority), an issuer, and a digital license.

Fig. 4A illustrates a certificate authority Private Key Infrastructure (PKI) model in accordance with various embodiments.

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

FIG. 5 illustrates an exemplary use case of digital licenses in accordance with various embodiments.

Fig. 6 shows a flow chart of steps according to various embodiments.

Detailed Description

Various embodiments will be described in the following description. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the described embodiments.

Some terms may be described in further detail before discussing the embodiments.

The "key" may comprise a piece of information used in a cryptographic algorithm to transform input data into another representation. The cryptographic algorithm may be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms the 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), and so forth.

The "public key" may include cryptographic keys that may be shared openly and publicly. The public key may be designed to be shared and may be configured such that any information encrypted with the public key may only be decrypted using the private key associated with the public key (i.e., the public/private key pair).

The "private key" may include any cryptographic key that may 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 a pair of associated cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to be sent to an entity, or for verifying a digital signature that should be made by an entity. On the other hand, the private key may be used for private functions such as decrypting received messages or applying digital signatures. In some embodiments, the public key may be authorized by a principal called a verification authority (CA), which stores the public key in a database and distributes it to any other entity requesting it. The private key may typically be maintained in a secure storage medium and will typically be known only to the entity. The public and private keys may be in any suitable format, including formats based on Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptography (ECC).

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

The term "verify" and its derivatives may refer to the process of utilizing information to determine whether a potential principal is valid for a given set of circumstances. Verification may include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and/or reputable.

A "certificate" or "digital certificate" may include an electronic file and/or a data file. In some cases, the certificate or digital certificate may be a device certificate. In some embodiments, the digital certificate may use a digital signature to bind the public key with data associated with the identity. Digital certificates may be used to prove ownership of public keys. The certificate may include one or more data fields such as a legal name for the identity, a serial number for the certificate, a start and end expiration date for the certificate, a certificate-related license, etc. The certificate may contain a "start valid" date indicating the first date the certificate is valid, and a "end valid" date indicating the last date the certificate is valid. The certificate may also contain a hash of the data in the certificate including the data field. The certificate may be signed by a validation authority. For example, the validation authority may provide digital certificates for digital licenses provided by the issuing authority. Digital certificates may help authenticate an issuer.

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

An "issuer" may include an entity that issues credentials to a user, typically using an issuing entity computer to issue credentials. The issuing entity may be a government agency, medical service provider, file repository, access administrator, or the like. The issuing entity may also issue the credentials to the user in the form of a digital license stored on a user device (e.g., a cellular telephone, smart card, tablet computer, or laptop computer).

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

The "user device" may be a device operated by a user. Examples of user devices may include mobile phones, smart phones, cards, personal Digital Assistants (PDAs), laptop computers, desktop computers, server computers, vehicles (e.g., automobiles), thin client devices, tablet PCs, and the like. Furthermore, 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, such as accelerometers, cameras, microphones, etc., that are capable of detecting user input. The user input obtained by the input sensor may come from a variety of data input types including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device operable by a user, which may also provide remote communication capabilities with the network. Examples of telecommunications capabilities include using a mobile telephone (wireless) network, a wireless data network (e.g., 3G, 4G, or the like), wi-Fi, wi-Max, or any other communication medium that can provide access to a network (e.g., the internet or a private network).

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

A "processor" may include any suitable data computing device or devices. A processor may include one or more microprocessors that work together to achieve a desired function. The processor may include a CPU that includes 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 Athlon, duron, and/or Opteron; powerPC of IBM and/or Motorola; cell processors of IBM and Sony (Sony); celeron, itanium, pentium, xeon and/or XScale from Intel (Intel); and/or the like.

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

A "machine readable code" may comprise 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 bar codes, quick Response (QR) codes, military specification UID codes, and any other suitable codes.

A "communication channel" may include a medium via which messages may be provided. Communication channels may include physical transmission media (e.g., wire, contact interface, etc.), over-the-air communication media (e.g., using electromagnetic signals, etc.), logical media (e.g., application Programming Interface (API), etc.), and/or combinations thereof.

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

An "interaction" may include a peer-to-peer action or effect involving more than one participant. "interaction" may include communication, association, or exchange between parties, devices, and/or entities. Example interactions include transactions between two parties and data exchanges between two devices. In some embodiments, the interaction may include a user requesting access to secure data, a secure web page, a secure location, and the like.

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, a communications network, or any other suitable system. The access means may generally be located at any suitable location, for example at the location of the relying party. The access means may take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular telephones, personal Digital Assistants (PDAs), personal Computers (PCs), tablet PCs, handheld dedicated readers, set top boxes, electronic Cash Registers (ECRs), automated Teller Machines (ATM), virtual Cash Registers (VCRs), information kiosks (kiosks), security systems, access systems, bar code readers, QR code readers, and the like. In some embodiments, the 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 from the user device or to be associated with the user device. For example, the access device may have a card reader that may include an electrical contact, a Radio Frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with the user device.

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

An "access credential" may include any suitable data that may be used to access a resource or create data that may access a resource. The credential may be a string of numbers, letters, or any other suitable character, as well as any object or file that may be used as a confirmation. In other embodiments, the access data may include data that may be used to access a location or to access security data. Such information may be a driver's license, vaccination record, national passport, medical prescription, entertainment license, resident registration confirmation, identification document entered into a building, ticket information for an event, data entered into a building, transit ticket information, password, biometric or other credentials to access secure data, etc. According to various embodiments, the access credentials may be provided in the form of a digital license configured on the user device. For example, the digital license may be configured on the user device by an issuer that issues the digital license. In some embodiments, the digital license may be configured on the user device by a certificate issuer and/or a certificate authority of the digital license.

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

Embodiments associate a digital certificate with a digital license configured on a user device. The digital license is generated by an Issuer (IA) and signed using the issuer's private key (IA private key). The issuer may share the issuer's public key (IA public key) with the validation authority. A digital certificate including the IA public key may then be generated by a Certificate Authority (CA) and associated with the digital license. The validation authority may comprise a global trusted authority.

As part of interacting with the relying party, the user may present the digital license to the relying party. For example, a user may wish to gain access to locations (e.g., concert venues, foreign countries, security buildings) managed by a relying party that require a particular set of credentials (e.g., ticket, vaccination record, passport, identification card). In other embodiments, the user may present the digital license as a proof of authorization (e.g., driver's license, fishing license). The relying party may receive the public key of the validation authority (CA public key) from the validation authority. Upon receiving the digital license associated with the digital certificate, the relying party may decrypt the digital certificate using the CA public key to obtain the information contained therein. For example, an issuer public key (IA public key) may be embedded in a digital certificate. The relying party may retrieve the IA public key, decrypt the digital license using the IA public key, and obtain the information in the digital license. The relying party may trust the authenticity and accuracy of the information retrieved from the digital license because the relying party trusts the validation authority. The digital certificate issued by the verification authority may in turn provide a guarantee for the identity of the issuing authority. Thus, the relying party may trust the authenticity and accuracy of the information retrieved from the digital license.

FIG. 1 illustrates a diagram for issuing and verifying digital licenses in accordance with various embodiments. According to various embodiments, the digital license may include one or more of a driver's license, a vaccination passport, a general passport, a medical prescription, an entertainment license, a selection registration confirmation, an identity document entering a building, and the like.

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

The verification authority 102 may authenticate the issuing authority 100. In some embodiments, the verification authority 102 may receive a request from the issuer 100 to authenticate the issuer 100. As part of authenticating the issuer 100, the verification authority 102 may then interact with the issuer 100 to collect and verify information about the issuer 100. For example, the verification authority 102 may receive information associated with the identity of the issuer 100 from the issuer 100. As part of authenticating the issuer 100, the verification authority 102 may verify information associated with the identity of the issuer. After identifying (and verifying) the identity of the issuer, the verification authority 102 may determine a set of authentication steps based on the identity of the issuer 100. According to various embodiments, the verification authority 102 may perform a first set of authentication steps for authenticating the first issuer 100 and may perform a second set of authentication steps different from the first set of authentication steps for authenticating the second issuer. For example, a state motor vehicle Department (DMV) issuing a driver's license to a user may be associated with a different set of authentication steps than the set of authentication steps of the healthcare provider issuing the vaccination record. The set of authentication steps may be based on the identity of the issuer 100 or the type of certificate issued by the issuer 100. The verification authority 102 may authenticate the issuer 100 based on a set of authentication steps associated with the issuer 100.

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

According to various embodiments, 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 validation authority 102 may store the CA public-private key pair at the storage device. The validation 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-private key pair, thereby generating a digital certificate 115 that includes the IA public key signed with the CA private key 111. In some embodiments, the validation authority 102 may return the digital certificate 115 to the issuer 100 such that the issuer 100 associates the digital certificate 115 with the digital license 105 issued by the issuer 100. In other embodiments, verification authority 102 may associate digital certificate 115 with digital license 105 on user device 104.

The validation authority 102 may share the CA public key 110 of the CA public-private key pair with one or more relying parties that may need to validate digital certificates issued by the issuer 100. Relying party (e.g., verifier) 108 may be able to verify or authenticate issuer 100 and/or digital license 105 using CA public key 110 of the CA public-private key pair. That is, the relying party may verify or authenticate the content of issuer 100 and/or digital license 105 based on the identity of verification authority 102. For example, digital license 105 issued to a user (e.g., a holder of the digital license) may include an identification card. The relying party, such as an employer, airline operator, or security personnel at the stadium entrance, may confirm the validity of the digital identification card, as described herein. Thus, embodiments enable digitization of physical permissions in a secure and reliable manner. In addition, embodiments prevent the use and propagation of fraudulent permissions.

According to various embodiments, two separate entities (e.g., a relying party and an issuer) may authenticate each other. For example, in the united states, driver's licenses are issued by the state motor vehicle Department (DMV). While each state in the united states may acknowledge each other's DMV, foreign entities may not acknowledge a state DMV or even the state itself. When a person obtains a driver's license from, for example, a wyoming DMV in united states, the japanese relying party does not have any means to confirm the information, or even any means to consider the wyoming DMV as a reliable source. Embodiments provide a Public Key Infrastructure (PKI) model in which a validation authority receives data from an issuer, verifies that the issuer and the received data are legitimate. The globally trusted validation authority underwrites the information provided by the issuer. The validation authority acts as a trusted intermediary that can transfer trust or a chain of trust, thereby being able to securely verify whether information is received from or queried by a legitimate entity (e.g., an issuer).

According to various embodiments, the validation authority 102 performs a review of the issuing authority 100 (e.g., a healthcare provider, a government agency providing a driver's license, a national passport, etc.) prior to generating any digital certificates. The requirements of the auditing issuer 100 may depend on the type of permissions provided by the issuer 100 or on the identity (e.g., type) of the issuer 100. For example, verifying that an entity that provides identity information by a government agency is an issuer may have a different set of requirements than verifying that an entity that provides medical information by a medical service provider (e.g., hospital, doctor's office, pharmacy).

Authentication mechanism 102 generates a CA private-public key pair. While verification authority 102 keeps CA private key 111 secret to sign the public key of the issuer (e.g., IA public key), verification authority 102 provides CA public key 110 to relying party 108 that needs to access and/or use information on digital license 105. By the process of verifying information on digital license 105, relying party 108 can trust the IA public key as a legitimately issued public key, and thus relying party 108 can verify that one piece of information retrieved from digital license 105 is provided by a legitimate source.

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

Issuer 100 may then issue digital license 105 to the user. Prior to issuing digital license 105, issuer 100 may verify the identity of the user. The issuer 100 may generate an IA public-private key pair and provide the IA public key to the verification authority 102. The issuer 100 may sign the digital license 105 with the IA private key and configure the signed digital license 105 on the user device 104 (e.g., on an electronic wallet of the user device).

The certification authority 102 signs the IA public key with the certification authority's own private key (e.g., CA private key 111) to generate a digital certificate 115, verifying that the issuer 100 is a legitimate source. The validation authority 102 may provide the digital certificate 115 to the issuer 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 verifier/relying party 108, relying party 108 can use CA public key 110 to verify digital certificate 115 signed with CA private key 111. Relying party 108 can then retrieve the IA public key from digital certificate 115. Relying party 108 can trust that the IA public key is trusted (e.g., authentication mechanism 102 is a globally trusted entity, or authentication mechanism 102 is an entity that relying party 108 trusts) based on the IA public key signed using CA private key 111. Relying party 108 can then retrieve the information from digital license 105 and trust that issuer 100 that issued the information is legitimate.

FIG. 1 also shows a series of steps for generating and verifying a digital license. At step 1, the verification authority 102 verifies the legitimacy of one or more of the issuing authorities 100 and establishes a trusted relationship with each of the issuing authorities 100. The certificate authority 102 may generate a CA public-private key pair and sign the digital certificate request from the trusted issuer 100 using the CA private key 111. According to various embodiments, the issuer 100 may include one or more of the following: a medical service provider; a government entity issuing an identification form such as a driver's license, passport, national identification card, or the like; a mechanism for issuing, for example, public transportation tickets, air tickets, or admission tickets (e.g., concert admission tickets or building admission certificates). The issuer 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.

At step 2, issuer 100 may generate digital license 105 signed with the IA private key. According to various embodiments, issuer 100 may configure digital license 105 on an electronic wallet of user device 104 (e.g., a user mobile device). Digital license 105 may be provided remotely and may be updated by issuer 100 as needed (e.g., upon expiration, when information is altered or updated, etc.). The user may be able to request modification of information associated with digital license 105 to add or delete temporary or permanent information, such as disability status, temporary address, etc. According to various embodiments, the communication between the user device 104 and the issuer 100 may use a new communication standard (e.g., ISO/IE CTS 23220-3).

At step 3, the validation authority 102 may digitally sign the IA public key with the CA private key 111 to generate a digital certificate 115 for the issuer 100. For example, the digital certificate 115 may prove the legitimacy or authenticity of the issuer 100. In some embodiments, verification authority 102 may update digital license 105 directly on user device 104 to be associated with digital certificate 115, which is digitally signed (e.g., "locked") using CA private key 111, thereby establishing legitimacy of issuer 100. Digital certificate 115 may include an IA public key digitally signed with CA private key 111. For example, verification mechanism 102 may receive a request from user device 104 to verify digital license 105 configured on user device 104. The validation 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, verification authority 102 may return digital certificate 115 to issuer 100 so that issuer 100 links digital certificate 115 with digital license 105. The issuer 100 may receive the digital certificate 115 prior to or during the generation of the digital license 105. Issuer 100 may associate (e.g., link) digital certificate 115 with digital license 105.

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

According to various embodiments, participation by the verification authority 102 may reduce counterfeit ID fraud and reduce reliance on manual inspection requiring specialized and localized knowledge. Verification authority 102 may ensure the legitimacy of issuing authority 100 that issued digital license 105.

In step 5, the user presents digital license 105 associated with digital certificate 115 to relying party 108. Relying party 108 can retrieve CA public key 110 to retrieve and/or verify the authenticity of the IA public key. Relying party 108 can then use the IA public key to retrieve the information contained in digital license 105. According to various embodiments, a user may provide digital license 105 to relying party 108 via any suitable means, including but not limited to communication via bluetooth, NFC, wi-Fi, or using a machine-readable code (e.g., QR code). Relying party 108 can receive and verify data from a user/user device using a dedicated mobile application installed on the terminal or a dedicated terminal (e.g., 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, a user may select all or a subset of information on digital license 105 to provide to relying party 108. For example, the information provided may conform to the ISO 18013-5 standard. The relying party computer may have detected (e.g., by an identifier on user device 104) that digital license 105 is associated with digital certificate 115 issued by verification authority 102. Relying party 108 can then retrieve CA public key 110 and decrypt digital certificate 115 to obtain the IA public key and then decrypt digital license 105 to obtain the information contained therein. If a series of decryption and/or verification is successful, relying party 108 can now trust that issuer 100 is legitimate because it is associated with trusted verification authority 102. In some cases, the relying party computer may also contact the validation authority 102 to determine whether the detailed information of the digital certificate 115 is still valid. Relying party 108 can rely on a single trusted entity (e.g., verification authority 102) to reliably authenticate IDs from all participating jurisdictions worldwide.

As described above, the verification authority 102 verifies the authenticity of the issuer 100 using the public-private key infrastructure of the verification authority 102. According to various embodiments, validation mechanism 102 does not authenticate a user that presents digital license 105 to relying party 108. It is issuer 100 that authenticates the user prior to issuing digital license 105 to the user. The verification authority 102 authenticates the issuing authority 100.

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

FIG. 2 illustrates another diagram for issuing and verifying digital licenses in accordance with various embodiments. The issuer 202 may be reviewed (e.g., authenticated, verified) by the verification authority 206. According to an exemplary embodiment, the digital license may be a mobile driver license (mDL). Accordingly, fig. 2 may illustrate a method of generating and/or verifying mDL data provided by a user and/or mDL to a user of relying party 216. Previously configured data held by mDL and relying party 216 (e.g., IA certificates, mDL certificates, CA public keys) are used in order to perform offline verification of user personal data. Those of ordinary skill in the art will appreciate that the use of mDL is for illustrative purposes only and should not be construed as limiting. The process 200 shown in fig. 2 may be applied to other digital licenses including, but not limited to, vaccination passports, ordinary passports, medical prescriptions, entertainment licenses, registration confirmation of a selection of people, identification documents entered into a building.

At step 1, the censored issuer 202 may generate an IA public-private key pair. At step 2, issuer 202 may send certificate request 204 to certificate authority 206 requesting that certificate authority 206 generate a certificate (e.g., a digital certificate) for the digital license issued by issuer 202. Certificate request 204 may include an IA public key. At step 3, the validation authority 206 may review the certificate request 204 received from the issuer 202, confirm that the issuer is reviewed/authenticated, 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 may be used to generate a CA public-private key pair. The validation authority 206 may store the CA public-private key pair (or at least the CA private key) in a secure database managed by the validation authority 206. Verification mechanism 206 provides a copy of the CA public key to relying party 216. For example, validation authority 206 may configure the CA public key on the computer of relying party 216 so that relying party 216 securely stores the CA public key. Alternatively, validation authority 206 may store the CA public key at cloud storage accessible by relying party 216.

The validation authority 206 may return the digital certificate 208 to the issuer 202. In step 4, issuer 202 receives digital certificate 208 from verification authority 206. At step 5, issuer 202 generates digital license 210 (or retrieves the previously generated digital license), personalizing digital license 210 with digital certificate 208. For example, issuer 202 associates digital certificate 208 received from verification authority 206 with digital license 210 generated by issuer 202. Issuer 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 (e.g., a smart card, a smart phone, etc.). At step 6, the user presents digital license 210 and digital certificate 208 to the terminal of relying party 216 via user device 212. Relying party 216 retrieves the CA public key to decrypt digital certificate 208 and the IA public key to authenticate issuer 202. Relying party 216 can then use the IA public key to retrieve the data in digital license 210. Thus, relying party 216 can trust the authenticity of digital license 210 issued by issuer 202.

For example, relying party 216 may be a merchant that needs to check the age of the user 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 mechanism 206 and including the digitally signed IA public key) to the relying party computer. The digital certificate may have any suitable format, such as an x.509 format, including, among other things, a certificate version number, a serial number, an issuer name, a validity period, generic public key information, and a signature.

The relying party computer may detect that the mobile driver's license is associated with the verification mechanism 206 (e.g., by an identifier on the card) and retrieve the CA public key. The relying party computer may use the CA public key to verify that the IA public key has been 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 has been signed using the IA private key. If the verification is successful, the relying party computer can now trust that the issuer 202 is legitimate because it has been authenticated by the trusted verification authority 206. In some cases, the relying party computer may also contact the validation authority 206 to determine if the detailed information of the digital certificate is 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 encrypted by industry standard means (e.g., ISO 18013-5), such as by a user credential private key, to create a dynamic signature (e.g., using mDL private key) and send the signature to the relying party if required for the transaction. Dynamic signatures are signatures that are valid for only a single authentication to protect users from data cloning.

Fig. 3 shows the trust chain between the parties described in fig. 1 and 2. Public key algorithms may be used to verify information between different parties. Relying party 300 (e.g., merchant, transit terminal operator) trusts authentication mechanism 302 (e.g., third party) and stores or otherwise accesses the CA authentication public key to be retrieved during a later transaction. Thus, the validation authority 302 and relying party 300 of the trust chain trust the issuing authority 304 (e.g., medical service provider, government entity issuing the identification). According to various embodiments, the validation authority 302 may audit the issuer 304 to ensure that the issuer 304 is legitimate. Because it is its issuer, issuer 304 believes digital license 306 and, therefore, relying party 300 is able to trust digital license 306. This chain of trust allows relying party 300 to trust that the data provided by digital license 306 is legitimate. Thus, relying party 300 can trust digital license 306 by following the processes described herein with respect to at least fig. 1 and 2 without having to connect online to issuer 304.

The validation authority may authenticate the issuer and provide vouching to the issuer in any suitable manner. For example, the validation authority may use a Private Key Infrastructure (PKI) model as shown in fig. 4A. In some embodiments, the validation authority may use a master list model as shown in FIG. 4B.

Fig. 4A illustrates a certificate authority Private Key Infrastructure (PKI) model 400 in accordance with various embodiments. There are a large number of issuers 402, 404, 406 worldwide (e.g., state DMV; state, state or local government; state or local medical service provider, etc.). Without the benefits provided by the embodiments described herein, 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 the illegitimate keys out of the list, an expensive and difficult task. Using the PKI solution, relying party 414 would only need to maintain updated connections with a single global trusted verification authority 410, not all issuers.

The global trusted authority 410 has a private public key pair. The verification authority interacts with the legitimate issuer and verifies/authenticates its legitimacy. The certification authority may then receive the IA public key of the authenticated issuer and sign the IA public key with the CA private key, thereby generating a digital certificate 408 for the issuer. The validation authority 410 may send the digital certificate 408 to the corresponding issuer 402, 404, 406, which then associates the digital certificate 408 with the digital license generated by the corresponding issuer 402, 404, 406. For example, when a japanese car rental agency (as an example relying party 414) wishes to verify the authenticity of a digital driver's license issued by missouri, U.S. the car rental agency will verify the digital certificate associated with the digital driver's license using the global trusted CA public key 412 shared by the verification authority 410 with the car rental agency, thereby allowing the car rental agency to trust the issuing authorities 402, 404, 406 in an cryptographically secure manner.

The global trust verifier 410 verifies that the issuers 402, 404, 406 are legitimate using the PKI program, increasing national and global scope and trust, and allowing the relying party 414 to trust the legitimacy of the issuers 402, 404, 406 in terms of digital licenses. In the event that the issuer is not properly reviewed (e.g., fraudulent issuer 416), the verification authority 410 may refuse to sign the IA public key and generate a digital certificate for the unauthorized issuer 416. Relying party 414 only has to maintain a connection with central verification authority 410 rather than hundreds of issuers 402, 404, 406. The issuing authorities 402, 404, 406 benefit from reducing fraud and increasing acceptance of their issued digital licenses. In contrast to localized systems, users may use their digital licenses in a wide variety of areas.

FIG. 4B illustrates a master list model 450, according to various embodiments. In the master list model 450, all issuers 452, 454, 456 store their public keys 462, 464, 466 on a master list 460, which may be stored on a remote server (e.g., on the cloud). The master list distributor (e.g., validation authority 470) may then sign the master list (instead of each individual IA public key 462, 464, 466) using the master list distributor private key. Relying party 480 then uses the master list distributor public key to check if master list 460 is authentic and retrieves the associated IA public key 462, 464, 466 from master list 460. According to the master list model, the digital certificate is not related to the digital license. Instead, the master list distributor authenticates the master list 460 of IA public keys. The master list model may be applicable where the issuer does not allow a third party, such as validation authority 470, to modify or validate the digital license. According to various embodiments, global coverage may require multiple master list distributors. The master list distributor must implement strong, consistent, and extensible control and management to verify the legitimacy of each self-service signature issuer and to prevent key spoofing (e.g., to prevent fraud issuer 474 from inserting fraudulent IA public key 472 in master list 460).

FIG. 5 illustrates an exemplary use case of digital licenses in accordance with various embodiments. According to an exemplary use case, the digital license may include a mobile vaccination card 502 (e.g., a digital vaccination passport) configured on the user device 500 by an issuer (e.g., a local healthcare provider). The local healthcare provider can verify the identity of the user, vaccinate the user with the desired vaccine, and issue a mobile vaccination card 502 to the user's user device 500 (mVC). mVC 502 may include various information including, but not limited to, user identification information (e.g., user name, user date of birth, user photograph), vaccine identification information (e.g., manufacturer, lot number, serial number, date of administration, dose number, composition). The local healthcare provider may sign mVC with the IA private key 502. The validation authority may validate and establish secure communications with the local healthcare provider. The validation authority may then validate the local healthcare provider and may sign the local healthcare provider's IA public key using the CA private key. The validation authority may generate and provide digital certificates to the local healthcare provider for configuration on the user device 500 as associated with mVC 502. Alternatively, the validation authority may update mVC 502 configured on the user device 500 with the digital certificate generated by the validation authority. According to various embodiments, a validation authority may provide a digital licensed mobile application. In some embodiments, the digital license (and associated digital certificate issued by the validation authority) may be configured on a digital wallet of the user device.

The validation authority may share a CA public key with the relying party. The validation authority may also provide mobile validation applications to the relying party as needed. When the user presents his 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 mVC. The relying party may use the same mobile authentication application to authenticate mVC multiple users.

As shown in fig. 5, the user may select the type, level, and content of information to be shared with the relying party. For example, the user may choose whether to publish all data 504 with the relying party or a subset 506 of the data. The user may decide which information to share based on the identity of the relying party. For example, it may be appropriate to share all data at a customs checkpoint, but it may be sufficient to issue only minimal data as a condition for entering a restaurant. The relying party's mobile application 510 can receive information from the user device (e.g., by reading the machine-readable code 512).

Fig. 6 shows a flow chart of steps according to various embodiments. At step S608, verification mechanism 600 may share a CA public key with relying party 606. As explained above, validation authority 600 may send the CA public key directly to relying party 606. Otherwise, validation authority 600 may store the CA public key at cloud storage accessible by relying party 606.

The issuer may request the certificate from the verification authority 600. The request may include an IA public key. As part of authenticating an issuer, the verification authority 600 may interact with the issuer to collect and verify information about the issuer. For example, the validation authority 600 may authenticate the issuer using a set of authentication steps. In some embodiments, the validation authority 600 may first identify the identity of the issuer. The verification authority 600 may then determine a set of authentication steps based on the identity of the issuer or the type of verification issued by the issuer. The verification authority 600 may authenticate the issuer based on a set of authentication steps associated with the issuer. According to various embodiments, a first set of authentication steps may be performed to authenticate a first issuer (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 issuer (e.g., a local healthcare provider).

Verification authority 600 may generate a digital certificate associated with an issuer and send the digital certificate to a recipient to associate the digital certificate with a digital license generated by the issuer. The recipient may be an issuer. The digital certificate includes a digitally signed IA public key that is digitally signed using a CA private key. For example, the validation authority 600 may embed the digitally signed IA public key in a digital certificate.

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

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

In step S616, user device 604 may send the digital license to relying party 606 along with the digital certificate. The digital license is associated with (e.g., includes) a digital certificate signed by a validation authority using a CA private key that is paired with a CA public key. As described above, relying party 606 may have received (or otherwise retrieved) the CA public key.

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

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

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

As described above, the digital certificate and digital license are stored or installed on the mobile device. In some embodiments, the mobile device may allow the user to gain access to location or security data. An exemplary mobile device may include a computer-readable medium that may reside within the body of the mobile device. The computer readable medium may be in the form of a memory storing data. In some cases, the memory may also store information such as digital licenses associated with digital certificates. In general, any suitable method may be used, including using an antenna or contactless element, with any of this information being transmitted by the mobile device to another device. 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 an associated wireless transmission (e.g., data transmission) element, such as an antenna. The contactless element may be coupled to (e.g., embedded in) a mobile device, and data or control instructions sent via the cellular network may be applied to the contactless element by means of a contactless element interface (not shown). The contactless element may be able to transmit and receive data using a short range wireless communication capability. The mobile device may include components for receiving and transmitting data. Thus, the mobile device may be able to transmit and send data or control instructions via a cellular network (or any other suitable wireless network, such as the internet or other data network) and short-range communications.

The mobile device may also include a processor (e.g., a microprocessor) for processing the functions of the mobile device and a display that allows the consumer to see telephone numbers and other information and messages. The mobile device may also include an input element that allows a user to input information into the device, a speaker that allows the user to hear voice communications, music, etc., a microphone that allows the user to send his voice through the mobile device, and a camera for photographing or scanning machine readable code. The mobile device may also include an antenna for wireless data transfer (e.g., data transmission).

The memory may be in the form of one or more memory devices (e.g., RAM, EEPROM, ROM chips) using any suitable data storage mode. In some embodiments, the 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 (e.g., a validation authority computer) according to various embodiments includes a processor and a memory. The network interface and the non-transitory computer readable medium may be coupled to a processor.

A processor may be implemented as one or more integrated circuits (e.g., 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 a plurality of applications executable by the processor, as well as a public/private key pair generated by the computer.

The network interface may be configured to connect to one or more communication networks to allow the computer to communicate with other entities (e.g., external computers, issuer 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. The wireless protocols enabled by the network interface may include Wi-Fi ^TM . The data communicated via the network interface may be in the form of signals, which may be electrical, electromagnetic, optical, or any other signal capable of being received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between a network interface and other devices via a communication path or channel. As noted above, any suitable communication path or channel may be used, such as wire or cable, fiber optic, telephone line, cellular link, radio Frequency (RF) link, WAN or LAN network, the internet, or any other suitable medium.

A computer-readable medium may include one or more non-transitory media for storing and/or transmitting. Suitable media include, for example, random Access Memory (RAM); read Only Memory (ROM); magnetic media such as hard disk drives; or an optical medium such as a CD (compact disc) or DVD (digital versatile disc); flash memory, etc. The computer readable medium may be any combination of such storage or transmission devices. The computer-readable medium may be embodied by any number of non-volatile memory (e.g., flash memory) and volatile memory (e.g., 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: authenticating the issuing authority; receiving an issuer public key from an issuer; digitally signing the issuer public key using the private key of the verifier; generating a digital certificate associated with an issuer, wherein the digital certificate includes a digitally signed issuer public key; transmitting a digital certificate to a recipient to associate the digital certificate with a digital license generated by an issuer; and sharing the certificate authority public key with one or more parties adapted to receive the digital license and associated digital certificate from a holder of the digital license.

Embodiments provide various advantages. According to various embodiments, digital licenses configured on the user device can also be used during mobile wallet configuration. Digital licenses can be used to match account holder and device holder data during configuration of an account on a user device, thus limiting the possibilities of configuring tokens and fraud information on the user device. In some embodiments, the digital license may be used to authenticate and link an account or loan application with the submitter, thereby reducing the opportunity for fraud using a stolen identity. In other embodiments, the digital license and merchant authentication process allows for automated age verification and reduces the number of illegal/illegal purchases and activities, e.g., with the purchase of alcohol and tobacco; entering bars, clubs, gambling sites; vehicle rental, and the like. Digital licenses are also used in the aerospace industry to link device owners with boarding documents on their mobile devices, as well as to simplify the traditional ID verification process and reduce the use of fraudulent IDs during travel. Notary responsibility is to ensure the identity of each signer, which if not done so, may assume civil or criminal responsibility. Digital licenses provide the opportunity to authenticate a document and more closely associate it with its holder, thereby eliminating the risk of notarization and reducing notarization of fraudulent information. Other use cases include secure building access, traffic interception, work qualification verification, prescription and drug purchasing, selection registration, government planning, entertainment licenses, and licenses.

Any of the software components or functions described in this application may be implemented as software code that is executed by a processor using any suitable computer language, such as Java, C, C++, C#, objective-C, swift, or scripting language, such as Perl or Python, using, for example, conventional or object-oriented techniques. The software codes may be stored as a series 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 (e.g., hard disk drive or floppy disk), or optical media (e.g., compact Disk (CD) or Digital Versatile Disk (DVD)), flash memory, and the like. The computer readable medium may be any combination of such storage devices or transmission devices.

Such programs may also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and/or wireless networks conforming to various protocols, including the internet. Thus, a computer readable medium according to an embodiment may be generated using a data signal encoded by such a program. The computer readable medium encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., downloaded over the internet). Any such computer-readable medium may reside on or within a single computer product (e.g., hard drive, CD, or entire computer system), and may reside 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. Many variations on the embodiments will become apparent to those of ordinary skill in the art upon reading this disclosure. Accordingly, the scope should be determined not with reference to the above description, but should instead be determined with reference to the pending claims along with their full scope or equivalents.

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

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

Claims

1. A method, comprising:

authenticating, by a verification mechanism computer of the verification mechanism, the issuer;

receiving, by the verification authority computer, an issuer public key from an issuer computer of the issuer;

digitally signing, by the verification authority computer, the issuer public key using a verification authority private key;

generating, by the verification authority computer, a digital certificate associated with the issuer, wherein the digital certificate includes a digitally signed issuer public key;

transmitting, by the validation authority computer, the digital certificate to a recipient to associate the digital certificate with a digital license generated by the issuer; and

A verification authority public key is shared by the verification authority computer with one or more parties adapted to receive the digital license and associated digital certificate from a holder of the digital license.

2. The method of claim 1, wherein the recipient is the issuer and the issuer associates the digital certificate with the digital license generated by the issuer.

3. The method of claim 1, wherein the recipient is a user device on which the digital license is configured, and further comprising:

receiving, by the validation authority computer, a request from the user device to validate the digital license configured on the user device; and

the digital certificate is sent by the validation authority computer to the user device to link to the digital license on the user device.

4. The method of claim 1, further comprising:

the digitally signed issuer public key is embedded into the digital certificate by the verification authority computer.

5. The method of claim 1, wherein the digital license comprises one or more of: driver's license, vaccination passport, ordinary passport, medical prescription, entertainment license, registration confirmation of a selection of people, and identification document for entry into a building.

6. The method of claim 1, wherein the digital license is configured by the issuer on a user device.

7. The method of claim 1, further comprising:

identifying, by the verification authority computer, an identity of the issuer;

determining, by the verification authority computer, a set of authentication steps based on the identity of the issuer or a type of verification issued by the issuer; and

authenticating, by the verification authority computer, the issuer based on the set of authentication steps associated with the issuer.

8. The method of claim 7, wherein a first set of authentication steps is performed for authenticating a first issuer and a second set of authentication steps, different from the first set of authentication steps, is performed for authenticating a second issuer.

9. The method of claim 1, further comprising:

receiving, by the verification authority computer, a request from the issuer to authenticate the issuer; and

as part of authenticating the issuer, interaction with the issuer is performed by the verification issuer computer to collect and verify information about the issuer.

10. A validation authority computer associated with a validation authority, the validation 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:

authenticating the issuing authority;

receiving an issuer public key from the issuer;

digitally signing the issuer public key using an issuer private key;

generating a digital certificate associated with the issuer, wherein the digital certificate includes a digitally signed issuer public key;

transmitting the digital certificate to a recipient to associate the digital certificate with a digital license generated by the issuer; and

the certificate authority public key is shared with one or more parties adapted to receive the digital license and associated digital certificate from a holder of the digital license.

11. The verification authority computer of claim 10, wherein sending the digital certificate to the recipient comprises: the digital certificate is sent to the issuer, which associates the digital certificate with the digital license generated by the issuer.

12. The validation mechanism computer of claim 10, wherein the instructions, when executed by the one or more processors, cause the one or more processors to:

transmitting the verification mechanism public key to the one or more parties; or (b)

The certificate authority public key is stored at a storage device and access credentials to the storage device are sent to the one or more parties.

13. The validation authority computer of claim 10, wherein the digital license comprises one or more of: a driver's license, a vaccination passport, a general passport, a medical prescription, an entertainment license, a selection registration confirmation, and an identification document for entering a building, which are configured on a user device by the issuer.

14. The verification authority computer of claim 10, wherein the instructions to authenticate the issuer further comprise instructions to:

identifying, by the verification authority computer, an identity of the issuer;

determining, by the verification authority computer, a set of authentication steps based on the identity of the issuer or a type of verification issued by the issuer, wherein a first set of authentication steps is performed for authenticating a first issuer and a second set of authentication steps, different from the first set of authentication steps, is performed for authenticating a second issuer; and

15. The verification authority computer of claim 10, wherein the instructions to authenticate the issuer further comprise instructions to:

generating the private key of the verification mechanism and the public key of the verification mechanism; and

the validation authority public-private key pair is stored at a database.

16. The verification authority computer of claim 10, wherein the instructions to authenticate the issuer further comprise instructions to:

receiving information associated with an identity of the issuer from the issuer; and

as part of authenticating the issuer, verifying 231692 1pwcn associated with the identity of the issuer

And the information is linked.

17. A method, comprising:

receiving, by the relying party computer, a verification mechanism public key from the verification mechanism;

receiving, by the relying party computer, a digital license from a user device issued by an issuer, wherein the digital license comprises a digital certificate signed by the verifier with a verifier private key, wherein the verifier private key is paired with the verifier public key;

Validating, by the relying party computer, the digital certificate using a validation authority public key, wherein the digital certificate comprises an issuer public key; and

the information contained in the digital license is verified by the relying party computer using the issuer public key.

18. The method of claim 17, further comprising:

decrypting, by the relying party computer, the digital certificate using the certificate authority public key;

retrieving, by the relying party computer, the issuer public key from the decrypted digital certificate; and

the information contained in the digital license is retrieved by the relying party computer using the issuer public key.

19. The method of claim 17, wherein the digital license comprises one or more of: driver's license, vaccination passport, ordinary passport, medical prescription, entertainment license, registration confirmation of a selection of people, and identification document for entry into a building.

20. The method of claim 17, wherein a level of detail of the information contained in the digital license depends on an identity of a relying party associated with the relying party computer.