System and method for encrypted verifiable credentials

Abstract

A cryptographic verifiable credential (VC) is encrypted and one or more instructions are generated, at least one of which grants a dependent entity a scope of permissions associated with the VC. The scope of permissions includes permission to access a subset of data contained in the VC or a portion of data that can be derived from the data contained in the VC. The encrypted VC and the one or more instructions are sent to a credential issuer or the dependent entity to cause the credential issuer to generate a response containing the subset of data or the derived data with a proof code. The proof code is configured to prove the validity of the subset of data or the derived data.

Description

Background Technology

[0001] Digital identity is a mechanism for tracking entities across different digital environments. Once an identity is established, appropriate actions can be taken against the entity possessing that identity. For example, authorization, privileges, customization, and access can be granted to the entity. Therefore, digital identity is an important mechanism for ensuring that information is confined within appropriate trust boundaries by appropriately including authorization and privileges. Digital identity is also an important mechanism for ensuring a positive and consistent user experience when accessing data and customization.

[0002] Most identity verification documents or records currently in use are issued by central organizations, such as governments, companies, schools, employers, or other service centers or regulatory bodies. These organizations typically maintain the identity of each member within a centralized identity management system. A centralized identity management system is a centralized information system used by organizations to manage issued identities, authentication, authorization, roles, and permissions. Centralized identity management systems are considered secure because they often use professionally maintained hardware and software. Typically, identity issuing organizations set terms and requirements for those registering within the organization. When one party needs to verify the identity of another, the verifying party often needs to obtain information for verification and / or authentication of the other party's identity through a centralized identity management system.

[0003] A decentralized identifier (DID) is a type of updated identifier. A DID is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technologies, such as blockchain, provide the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a distributed ledger to verifiably record transactions between two or more parties. Once a transaction is recorded, it is impossible to trace changes to the data in a part of the ledger without altering all subsequent parts of the ledger. This provides a fairly secure platform where it is difficult or impossible to tamper with the data recorded in the distributed ledger. Because DIDs are typically not controlled by a centralized management system but are owned by the owner of the DID, DIDs are sometimes referred to as permissionless identities.

[0004] The subject matter claimed herein is not limited to embodiments that address any shortcomings or operate only in environments such as those described above. Rather, this background is provided merely to illustrate an exemplary technical field in which some of the embodiments described can be practiced. Summary of the Invention

[0005] The present invention is provided to introduce the chosen concepts in a simplified form, which will be further described in the detailed description below. This present invention is not intended to identify key or essential features of the claimed subject, nor is it intended to be used as an aid in determining the scope of the claimed subject.

[0006] Existing computing technologies provide a data structure called a "verifiable certificate" (hereinafter also referred to as "VC"). In these technologies, the certificate issuer makes one or more claims against a subject entity and generates a VC. The VC includes these claims along with proof (e.g., a cryptographic signature or code) proving that the claims have not been tampered with and were indeed issued by the certificate issuer. Therefore, the proof is also called a proof code. The certificate issuer then provides the VC to the certificate holder for submission to any dependent party that relies on the authenticity of these claims. When the subject entity is a person, the subject entity and the certificate holder are typically the same entity. When the subject entity is not a person (e.g., a device, a pet), the certificate holder can be the owner of the subject entity.

[0007] For example, the issuing entity could be a computing system associated with a government agency responsible for issuing driver's licenses. The government agency can generate a VC containing statements about the citizen, such as date of birth, residential address, weight, eye color, hair color, driving authorization, and driving authorization restrictions. The government agency issues the VC to the citizen just as it issues a physical driver's license. The user stores the VC on a computing system (such as a mobile phone) or in cloud storage accessible to the user's computing system.

[0008] If a user wants to rent a car from a car rental company, the user can present a Verification Code (VC). The computing system associated with the rental company can then use the verification code to verify that the statement includes a driving license, that it was issued by a government agency, and that it has not been tampered with since its issuance. In another example, when a user attempts to purchase alcohol, the user can also present the same VC. The computing system associated with the hotel can then use the verification code to verify that the statement includes information about whether the user is of legal age.

[0009] However, existing VCs have several problems. First, when a user presents such a VC, all claims contained within the VC are submitted to the relying entity, just as a user submits a driver's license to a relying entity. In many cases, the user may only want to display certain claims in the VC, and the relying entity may only need to know certain information from the VC or information that can be derived from the VC. For example, a car rental company only needs to know whether the user is authorized to drive, while a liquor store only needs to know whether the user is of legal age.

[0010] Secondly, existing VCs (similar to physical driver's licenses) also have validity issues. For example, a issued VC can be revoked under certain circumstances. Simply allowing a user to present a issued VC generally does not prove that the VC is still valid or has not been revoked. Similar to a driver's license being suspended, the driver can still hold a physical driver's license and present it to the rental company. If the rental company does not conduct further research in the government database, it is highly likely that the rental company will not know that the driver (holding the driver's license card) is no longer authorized to drive.

[0011] The embodiments described herein address the aforementioned problems by allowing certificate holders to request a subset of the data contained in a Certificate Controller (VC) or data that can be derived from the data contained in the VC. First, the computing system associated with the certificate issuer encrypts the VC using the certificate issuer's public key. Because the VC is encrypted with the certificate issuer's public key, the certificate issuer is the only entity capable of accessing the encrypted VC content using its private key. The certificate issuer's public key can be obtained from the certificate's metadata or through other means (e.g., retrieved from a distributed ledger or obtained from the certificate issuer or certificate authority).

[0012] The certificate holder's computing system also generates one or more instructions. At least one instruction instructs the certificate issuer to grant the dependent entity a scope of permissions associated with the encrypted VC. The scope of permissions includes at least access to a subset of data that can be extracted from the VC or a portion of data that can be derived from the VC. The encrypted VC and the instructions are then sent to the dependent entity and / or the certificate issuer. In either case, the certificate issuer is required to decrypt the encrypted VC and make specific portions of the data contained in the VC and / or data that can be derived from the VC based on the instructions available. In some embodiments, at least one instruction granting the scope of permissions to the dependent entity is wrapped in a second VC. The second VC is issued to the dependent entity on behalf of the principal entity. The second VC includes at least one statement granting the dependent entity a scope of permissions associated with the encrypted VC.

[0013] In some embodiments, one or more instructions further include at least one of the following: (1) a data encryption scheme for encrypting the VC; and (2) the address or identifier of the entity receiving the response. The entity receiving the response includes at least one of the following: (1) a certificate holder, (2) a principal entity, or (3) a dependent entity. Some instructions are appended as metadata to the encrypted first VC and / or second VC. Alternatively or additionally, some instructions are appended to the request sent to the dependent entity or the certificate issuer having the encrypted first VC and second VC.

[0014] In some cases, one or more instructions are generated based on user input. Alternatively or additionally, one or more instructions are generated based on a request from a dependent entity. For example, the computing system receives a request from a dependent entity to verify specific information associated with a VC. In response to receiving the request, the computing system may notify the user of the request, and the user may approve or reject the request through user input. In response to the user's request, the computing system may then generate one or more instructions.

[0015] In some embodiments, within a decentralized environment, the state of a Certificate Authority (VC) is propagated to a distributed ledger. Therefore, the certificate issuer can perform claim verification by accessing the data propagated to the distributed ledger. For example, when the state of a VC changes (e.g., the VC is revoked), the changed state (e.g., revocation) is propagated to the distributed ledger so that the certificate issuer can retrieve information related to the VC's state from the distributed ledger. In such a decentralized environment, each VC can be associated with one or more decentralized identifiers (DIDs). For example, at least one of the principal entity, certificate holder, dependent entity, or certificate issuer is the owner of a DID. Therefore, a VC is associated with a DID, and specific data or transformed data associated with the VC is propagated to the corresponding distributed ledger.

[0016] Furthermore, another problem with traditional VCs is that they are not easily understood by ordinary users or the public because such VCs are typically documented in a code format, such as JSON Web Token (JWT). The embodiment described in this article transforms the code of a traditional verifiable claim into a personal identity card. A personal identity card is a data structure that includes not only the data contained within the VC but also additional metadata (e.g., the claim issuer's logo, usage data, presentation format, etc.). The personal identity card is then presented to the user as one or more visualizations similar to physical identity cards. The visualization also allows users to easily interact with the certificate issuer and / or dependent entities. For example, the visualization of the personal identity card can allow a user to request the certificate issuer to extract and / or derive information from the claim contained in the VC.

[0017] Additional features and advantages will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention can be realized and obtained by means of the tools and combinations particularly pointed out in the appended claims. The features of the invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as described below. Attached Figure Description

[0018] To describe how the above and other advantages and features can be obtained, the subject matter briefly described above will be described in more detail with reference to specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments and therefore should not be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein: Figure 1A The diagram illustrates an example data structure for the declaration; Figure 1B The diagram illustrates a sample data structure for the first verifiable certificate (VC). Figure 1C The illustration shows an example implementation of encrypting the first VC using the certificate issuer's public key; Figure 1D The illustration shows an example declaration that grants a dependent entity the scope of permissions associated with the first VC; Figure 1E The illustration shows an example of a second VC permission that includes a statement granting a dependent entity the scope of permissions associated with the first VC; Figure 2A The illustration shows a sample JWT request token generated by the certificate holder; Figure 2B The illustration shows a sample JWT response token generated by the certificate issuer; Figure 3 The illustration shows an example communication pattern that can occur between the computing systems of the certificate issuer, the certificate holder, and the dependent entities. Figure 4 The diagram illustrates an example data structure for a portable identity card; Figure 5A The illustrations show several visual sample identity card gallery user interfaces, including portable identity cards; Figure 5B This illustration shows an example visualization of a portable identity card that resembles the front of a physical identity card; Figure 5C The illustration shows a sample visualization of a portable identity card that allows users to view additional data and interact with the data contained in the portable identity card; Figure 6 The illustration shows a sample user interface that allows a user to request a subset of data contained in VC or a portion of data exported from VC. Figure 7 The diagram illustrates a flowchart of an example method for encrypting a VC and requesting the certificate issuer to extract a portion of the data contained in the VC or to derive a portion of the data from the VC. Figure 8 The diagram illustrates a flowchart of an example method for responding to a request from a certificate issuer for a subset of data contained in the VC or data that can be exported from the VC. Figure 9 The diagram illustrates a flowchart of an example method for requesting data contained in or that can be exported from a VC from a certificate holder. Figure 10 The illustration shows a sample environment used to create decentralized identifiers (DIDs); Figure 11 The diagram illustrates example environments for various DID management operations and services; and Figure 12 An example computing system that can employ the principles described in this paper is illustrated. Detailed Implementation

[0019] The principles described herein relate to requesting a subset of verifiable data contained in a verifiable certificate (VC) and / or data that can be derived from the data contained in the VC from a certificate issuer. These embodiments can be implemented in a computing system associated with a certificate holder. The computing system (associated with the certificate holder) receives the VC from the certificate issuer. A VC is a data structure containing one or more claims about a subject entity, and is typically issued by the same claim issuer. In some embodiments, attribute-value pairs are used to express the claims. Figure 1A The diagram illustrates an example data structure representing claim 100A. Claim 100A includes a subject 111A, attributes 112A, and a value 113A. For example, subject 111A includes an identifier for the subject entity (e.g., a decentralized identifier (DID)). Attribute 112A can be any attribute of the subject of the DID, such as name, address, date of birth, etc. Value 113A is the value of the corresponding attribute 112A. For example, when attribute 112A is "name", value 113A would be the name of subject entity 111A, such as John Doe. When the attribute is "address", value 113A would be the address of subject entity 111A, such as 123 Main Street, city, state, zip code.

[0020] A declaration issuer (hereinafter also referred to as a certificate issuer) is typically able to issue multiple declarations for each subject entity. For example, the Department of Motor Vehicles (DMV) can issue numerous declarations to a citizen, such as date of birth, residential address, weight, eye color, hair color, driving authorization, driving authorization limits, etc. One or more declarations issued by the same declaration issuer can be bundled and issued to a citizen as a VC, just as a physical driver's license card is issued. A physical driver's license card includes a variety of information about the driver, not just driving authorization or driving authorization limits.

[0021] Figure 1BAn example VC 100B is illustrated. VC 100B includes one or more claims 110B (e.g., claims 11IB, 112B) and a proof code 120B. The proof code 120B typically includes a cryptographic signature signed by the private key of the claim issuer. When a dependent entity receives VC 100B, the dependent entity can retrieve the claim issuer's public key and decrypt the cryptographic signature, and compare the decrypted signature with the data contained in claim 110B to at least verify that (1) the VC was indeed issued by the claim issuer, and (2) the claims contained in the VC have not been reconciled. In some embodiments, VC also includes various metadata 130B, which is data associated with VC 100B. For example, metadata 130B may include (1) a unique identifier identifying the corresponding VC 100B, (2) one or more conditions for accessing VC 100B, or (3) one or more revocation mechanisms for revoking the corresponding VC 100B.

[0022] When a VC holder interacts with a dependent entity, the VC holder can present or send the VC to the dependent entity via various channels, including but not limited to wide area network (WAN), local area network (LAN), Bluetooth (BLE), near field communication (NFC), 2G / 3G / 4G / 5G mobile communication networks, SMS, barcode scanning, or QR code. When the dependent entity receives the VC 100B, the dependent entity can use the verification code 120B to verify the claim 110B contained in the VC.

[0023] However, when a VC is sent to a dependent entity, all 110B claims contained within the VC become available to that entity. For example, if the VC is a driver's license and the dependent entity is a liquor store, the liquor store can see not only the principal entity's exact date of birth, but also its legal name, driver's license number, and home address. Therefore, the principal entity's privacy may be compromised.

[0024] This is achieved by allowing certificate holders to request subsets of data contained in a VC and / or data that can be derived from the VC, and granting dependent entities access only subsets of the data and / or derived data. To achieve this, the computing system associated with the certificate holder is configured to obtain the certificate issuer's public key and encrypt the verifiable certificate 100B using that public key. In some embodiments, the issuer's public key is included in the verifiable certificate 100B. In some embodiments, the public key is recorded with the authentication service and can be retrieved from the authentication service. In yet other embodiments, in a decentralized environment, the public key can be propagated to and retrieved from a distributed ledger.

[0025] Figure 1CAn example embodiment 100C of an encrypted verifiable certificate 100B is illustrated. In some implementations, the entire VC 100B is encrypted using the claim issuer's public key 120C. After encryption, the VC becomes a cipher 111C. Appendage metadata 112C is appended to the cipher 111C to form the data structure of the encrypted VC 110C. In some implementations, only a portion of the VC 100B is encrypted using the claim issuer's public key 120C. For example, the encrypted portion of the VC 100B may be one or more claims 110B, and the proof code 120B and / or metadata 130B may not be encrypted. Unencrypted data (e.g., proof code 120B and / or metadata 130B) may be appended to the cipher 111C as part of the metadata 112C. The term "encrypted" or "encrypted VC" as used in this application refers to encrypting the entire VC or an encrypted portion of the VC.

[0026] After the VC 100B is encrypted, the computing system then generates one or more instructions. At least one instruction grants the dependent entity a scope of permissions associated with the encrypted VC. The scope of permissions includes at least access to a subset of data that can be extracted from the VC or a portion of data that can be derived from the VC. For example, when a user wants to rent a car, the user can instruct the certificate issuer (e.g., DMV) to disclose only to the rental company multiple statements related to driving authorization and / or driving authorization restrictions. In some cases, one of the multiple instructions may instruct the certificate issuer to obtain specific information from one or more statements containing the VC. For example, when a user wants to buy alcohol, the user can instruct the certificate issuer (e.g., DMV) to disclose only to the liquor store that the object entity has reached adulthood, which can be derived from a statement related to the subject entity's date of birth.

[0027] In some cases, one of several instructions can direct a certificate issuer to verify at least one claim contained in a VC. In a decentralized environment, some data associated with a VC can be propagated to a distributed ledger. In this case, the certificate issuer verifies the claim by accessing the data propagated to the distributed ledger. For example, when the state of any claim changes (e.g., the claim is revoked), the changed state (e.g., revocation) is propagated to the distributed ledger so that the certificate issuer can retrieve information related to the claim's state from the distributed ledger. In such a decentralized environment, each claim and / or VC can be associated with one or more decentralized identifiers (DIDs). For example, at least one of the principal entity, certificate holder, dependent entity, or certificate issuer is the owner of a DID. Therefore, a VC is associated with a DID, and some data, or transformed data, associated with the VC is propagated to the corresponding distributed ledger.

[0028] In some cases, the one or more instructions may also include: (1) a data encryption scheme for encrypting the VC; and (2) the address and / or identifier of the entity receiving the response. The entity receiving the response may be a certificate holder, a principal entity, and / or a dependent entity. In some cases, at least one of the principal entity, certificate holder, dependent entity, or certificate issuer is the owner of the distributed identifier. In this case, the one or more instructions include (multiple) DIDs, and a portion of the data associated with the VC or DID is propagated to the distributed ledger. The encrypted VC and one or more instructions are then sent as a request to the dependent entity and / or certificate issuer. Some of the one or more instructions may be appended as metadata to the encrypted VC. Alternatively or additionally, some of the one or more instructions may be included in the request sent to the dependent entity or certificate issuer.

[0029] In some embodiments, at least one instruction granting a scope of permissions to a dependent entity is wrapped in a second VC. The second VC is issued to the dependent entity on behalf of the principal entity. The second VC includes at least one statement granting the dependent entity the scope of permissions associated with the encrypted VC. For clarity, in the following text, the encrypted VC 100, relating to the principal entity, is referred to as the first VC. Note that the first VC 100 and the second VC have two sets of certificate issuers, principal entities, and dependent entities. However, since the primary purpose of the transaction is to allow the dependent entities of the first VC to access the scope of permissions associated with the first VC, the terms "principal entity," "dependent entity," and "certificate issuer" are themselves referred to as the principal entity, dependent entity, and certificate issuer of the first VC.

[0030] Figure 1D The illustration shows an example declaration 120D that grants the scope of permissions associated with the dependent entity to the first VC100. Figure 1E The illustration shows an example of a second VC100E containing declaration 120D. (See diagram for example.) Figure 1DAs shown, the principal entity of declaration D 120D is a dependent entity of the first VC 100. Attribute 122D of declaration D 120D is the scope of permissions to access a subset of data contained in the first VC 100. Attribute value 123D can be true or false. For example, the scope of permissions 122D could be the birth date of the principal entity of the first VC 100, and value 123D could be true. Therefore, the second VC 120D allows the dependent entity to access the birth date of the principal entity of the first VC 100. Declaration 120D is published by the principal entity of the first VC 100. As mentioned above, the first VC 100 is published by a certificate issuer (e.g., DMV), the principal entity 121 of the first VC 100 can be a user or consumer (e.g., a driver), and the dependent entity of the first VC 100 can be a business entity (e.g., a liquor store). The principal entity of the first VC 100 can also publish declarations and VCs. As an example, the second claim 120D is issued by the principal entity 121 of the first VC 100 (e.g., a user or consumer). The principal entity 121D of the second claim 120D is a dependent entity of VC 100 (e.g., a business entity). The dependent entity of the second claim 120D is the claim issuer of the first VC 100 (e.g., a DMV).

[0031] Proof 130E is then generated and appended to claim D 120D to transform claim D 120D into the second VC 100E. This proof can be a proof code, such as a signature signed by the private key of the issuer (i.e., the principal entity 121 of the first VC), proving that VC 100E was issued by the issuer (i.e., the principal entity 121 of the first VC). Additional metadata 140E can also be generated and appended to the second VC 100E. In some embodiments, some of one or more other instructions may be appended to the second VC as part of the metadata. The encrypted first VC 100C and second VC 100E are then sent to the dependent entity of the first VC 100 and / or the certificate issuer of the first VC 100.

[0032] When a certificate issuer receives a request, it decrypts the VC using its private key and generates a response based on one or more instructions (e.g., the scope of permissions granted contained in a second VC). In some cases, the response includes information derived from the original first VC. For example, when an instruction instructs the certificate issuer to disclose only whether the subject has reached adulthood, the certificate issuer accesses values ​​related to the subject's date of birth contained in the statement and determines whether the subject entity has reached adulthood. In response to the determination that the subject entity has reached adulthood, the certificate issuer generates verifiable data including a determination and a proof code. The proof code may include a cryptographic signature signed by the certificate issuer's private key. The verifiable data is then included in the response, which is sent to the dependent entity, the subject entity, and / or the certificate holder. In some cases, the response includes a new VC, which includes a subset of the statements contained in the original VC and / or one or more new statements derived from the statements in the original VC. Because the verifiable data is newly generated, its timestamp can be used to prove the validity of the data.

[0033] In some implementations, the response is sent directly to the dependent entity. In other implementations, the response is sent to the certificate holder, who then forwards at least the verifiable data contained in the response (i.e., a subset / derivative of the data and the proof key) to the dependent entity.

[0034] In some embodiments, the request from the certificate holder and the response from the certificate issuer are wrapped in a JWT token. The JWT token is then sent between the various entities. Figure 2A The illustration shows a sample request token 200A that can be sent from the certificate holder to the certificate issuer or a dependent entity. Figure 2B The illustration shows a sample 200B response token that can be sent from the certificate issuer to the certificate holder or dependent entity. (Reference) Figure 2A The request token 200A includes data 210A indicating the token issuer and data 220A indicating the token issuance time. Here, the token issuer can be a certificate holder or a dependent entity. When the certificate holder or dependent entity is the owner of the DID, data 210A may include the certificate issuer's DID.

[0035] The request token 200A also includes data 230A indicating the requested certificate. The requested certificate 230A contains the certificate type 231A and the encryption certificate 232A. For example, the VC type could be a driver's license, and the encryption VC could be an encryption driver's license VC of the certificate holder (i.e., the token issuer). The request token 200A also includes a second VC 240A issued to the dependent entity. If the dependent entity is the DID owner, the second VC 240A will include the DID of the dependent entity 241A. Figure 2AAs shown, the second VC240A indicates whether the dependent entity has been granted access permissions by the certificate holder / principal entity that have reached the legal age of majority 242A. The request token 200A also includes the address of the dependent entity 250A (e.g., the URL of the dependent entity or the DID of the dependent entity). Token 200A also includes an expiration time 260A. The ellipsis 270A indicates that additional information may be included in request 200A.

[0036] When the certificate issuer receives the request token 200 A, it decrypts the encrypted driver's license (VC) using its private key and verifies whether the subject entity is of legal age. Based on the verification result, the certificate issuer then generates... Figure 2B The response token shown is 200B. (See reference.) Figure 2B The response token 200B includes data 210B indicating the issuer of the response token (i.e., the certificate issuer) and data 220B indicating the token issuance time. When the certificate issuer is the owner of the DID, data 210B may include the certificate issuer's DID. The response token 200B also includes a claim 230B and a proof 240B. The claim 230B includes data 231B indicating the identifier of the subject entity. When the subject entity is the owner of the DID, data 231B may include the subject entity's DID. The claim 230B also includes attribute-value pairs 232B. Here, the attribute is "legal age of adulthood," and the value is "true," indicating that the subject entity has reached the legal age of adulthood. The proof 240B includes data 241B indicating the authentication method, data 242B indicating the creation time of the claim, data 243B indicating the creator of the claim (e.g., the certificate issuer), a random number 244B, and a signature 245B. The proof 240B allows the relying entity to verify that claim 230B is true and correct. The ellipsis 250B indicates that additional data may be included in the response token 200B.

[0037] Request token 200A and response token 200B are merely illustrative examples illustrating the possible formats of a request from the certificate holder and a response from the certificate issuer. Additional and / or different tags, syntax, and programming languages ​​may be used to achieve the same or similar communication purposes.

[0038] Various communication modes can be implemented during the request and presentation of verifiable data exported from VC. Figure 3 The illustration depicts an example communication pattern 300 that can occur between the certificate issuer 310, the certificate holder 320, and the dependent entity 330. (Reference) Figure 3Communication mode 300 begins with the computing system associated with the certificate issuer 310, which publishes and sends a VC to the certificate holder 320, as indicated by arrow 311. In some cases, a dependent entity 330 may request information contained in or that can be derived from the VC from the certificate holder 320, as indicated by dashed arrow 312. However, the certificate holder 320 does not need to receive such a request from any dependent entity before instructing the certificate issuer 310 to perform any transformations on the data contained in the VC.

[0039] Certificate holder 320 (holding the VC) retrieves the certificate issuer's public key and encrypts at least a portion of the VC using that public key. Furthermore, certificate holder 320 generates one or more instructions, at least instructing the certificate issuer to extract a subset of the data contained in the VC or derive a portion of the data from the VC, as indicated by arrow 313. If certificate holder 320 has previously received a request from dependent entity 330, certificate holder 320 may generate one or more instructions based on the request from dependent entity 330.

[0040] Certificate holder 320 then sends the encrypted VC and instructions to dependent entity 330, as indicated by arrow 314. Alternatively or additionally, certificate holder 320 sends the encrypted VC and instructions(s) directly to certificate issuer 310, as indicated by dashed arrow 316. Because the VC is encrypted with the certificate issuer's public key, even if dependent entity 330 receives the encrypted VC, it cannot access the contents contained in the VC. Instead, dependent entity 330 needs to forward the encrypted VC and instructions to certificate issuer 310, as indicated by arrow 315.

[0041] Upon receiving an encrypted VC and instructions from dependent entity 330, certificate issuer 310 decrypts the VC, extracts or derives information from the decrypted VC based on the instructions, and generates verifiable response data, indicated by arrow 317. In some embodiments, the response is then sent to dependent entity 330, indicated by arrow 318. Alternatively, the response is sent to certificate holder 320, and certificate holder 320 sequentially sends at least the verifiable data contained in the response to the dependent entity, indicated by dashed arrows 321 and 322. Verifiable data includes not only the extracted and / or derived data but also proof that the extracted and / or derived data is authentic and correct. In many cases, the proof includes a signature signed with the certificate issuer's private key. The dependent entity can decrypt the signature using the certificate issuer's public key to determine the validity of the data signed by the signature, as indicated by arrow 323.

[0042] Furthermore, as mentioned above, VCs are typically recorded in a code format that is easily understood by the computing system but not by the public, such as the JSON Web Token (JWT) format. The embodiments described in this paper address this issue by converting the code of a traditional verifiable claim into a personal identity card. A personal identity card is a data structure that includes not only the data contained in the VC but also additional metadata (e.g., the claim issuer's logo, usage data, presentation format, etc.). The personal identity card is then presented to the user as one or more visualizations. At least one visualization resembles a physical identity card. Presentation can be performed by a mobile application, a web browser, and / or a web application. In a decentralized environment, a mobile application can be part of the user's DID management module (e.g., a wallet application).

[0043] Figure 4 The illustration shows an example data structure 400 for a portable identity card. Data structure 400 includes a verifiable certificate 410 containing at least one or more claims 411 and verification codes 412. Data structure 400 also includes metadata 420. Metadata 420 includes usage data 421. The ellipsis 422 indicates that there may be additional metadata included in the portable identity card 400, including but not limited to the logo of the claim issuer, a photograph of the subject entity, and the presentation format.

[0044] Figures 5A to 5C The illustrations show various example visualizations of portable identity cards that can be presented to users, namely 500A, 500B, and 500C. Figure 5A The illustration shows a library of ID cards 500A with multiple visualizations of portable ID cards 510A, 520A, and 530A. The ellipsis 540A indicates that any number of portable ID cards can be displayed in the ID card library 500A. Each visualization of portable ID cards 510A-530A displays the issuer's logo, card type, subject name, and / or claimed attributes. The ellipsis 511A, 521A, and 531A indicate that additional or different information may exist in each visualization 510A-530A. Users can select any portable ID card corresponding to visualizations 510A-530A. When a specific portable ID card is selected, a larger visualization of that portable ID card can be displayed.

[0045] Figure 5B The illustration shows an exemplary larger visualization 500B of a portable identity card. In some implementations, the visualization 500B resembles the front of a physical identity card. Alternatively, in some implementations, the visualization 500B may expose only the non-personally identifiable data or metadata associated with the VC, without exposing the value of each claim. Figure 5BAs shown, visualization 500B includes certificate type 510B, subject name 520B, certificate issuer's logo 530B, issuer name 540B, issuance date 550B, and expiration date 560B. For example, certificate type 510B could be a driver's license; subject name 520B could be the driver's name; and issuer name 540B could be a DMV in a specific state.

[0046] Figure 5C The illustration shows another example of a portable identity card, the Visual 500C. In some implementations, the Visual 500C can resemble the back of a physical identity card. Alternatively, in some implementations, the Visual 500C includes various user interfaces that allow users to interact with and perform various VC-related functions. Users can switch between one or more visualizations by interacting with a touchscreen or any other input device, such as a mouse, keyboard, voice input, etc.

[0047] like Figure 5C As shown, Visualization 500C includes a list of Declarations 510C, containing Declaration A (driver's license number of the subject entity), Declaration B (date of birth of the subject entity), and Declaration C (street address of the subject entity). Visualization 500C includes an Rights Section 520C indicating various rights attached to the VC. For example, when a certificate holder uses a portable ID card to purchase parking rights, the parking rights are listed in Rights Section 520C. As another example, when a certificate holder uses a portable ID card to purchase a toll tag, the toll tag is listed in Rights Section 520C. The ellipsis 560C indicates that there may be additional content in Visualization 500C.

[0048] The visualization 500C also includes the update certificate icon 530C. For example, most VCs may have an expiration date. Certificate holders may be allowed to click the update certificate icon 530C to trigger the VC's renewal. In some cases, certificate issuers may charge a fee (e.g., a certain amount of cryptocurrency) to grant the renewal, and when a user clicks the update certificate icon 530C, an additional user interface may be presented to the user, allowing them to pay the required fee or submit a certain amount of cryptocurrency in exchange for the VC's renewal.

[0049] The Visualization 500C also includes a Usage Data section, 540C, where users can view their past VC usage data. Usage data is metadata attached to the portable ID card. Each time a user uses the portable ID card or VC, usage data is recorded in the portable ID card's metadata. For example, if a user presents a VC at a liquor store, the portable ID card can record the liquor store's identifier, as well as the location and time of the transaction. Later, the user can view their usage data by clicking the Usage Data icon, 540C.

[0050] In addition, the visualization 550C may also include a request icon 550C that allows users to perform various actions related to the VC. For example, when a user touches the icon 550C, a separate user interface may be presented to the user, allowing the user to enter additional data and request the certificate issuer to provide a portion of the data contained in the VC to the dependent entity.

[0051] Figure 6 The illustration depicts an example user interface 600 that can be presented to a user, allowing the user to send a request to the certificate issuer. User interface 600 includes an input field 610 that allows the user to enter the DID of a dependent entity. The user can enter the DID manually 611 or by scanning a QR code 612. User interface 600 also includes an input field 620 for the user to enter one or more instructions. The user can select any claim 621 contained in the VC and request the certificate issuer to generate a response that verifies only one claim is true and correct. The user can also manually enter instructions via the manual input field 622. In response to user input from user interface 650C, the certificate issuer's computing system can retrieve the certificate issuer's public key and encrypt the VC using the public key, as well as generate and send one or more instructions to the certificate issuer and / or dependent entities.

[0052] In some embodiments, the information contained in the user interface 600 may be automatically populated in response to a request received from a dependent entity. In some cases, the user may be prompted to review the automatically populated information before the computing system sends instructions to the certificate issuer. In other cases, the computing system may send instructions to the certificate issuer without requiring user review.

[0053] Figures 5A-5C The user interfaces 500A-500C and 600 shown in Figures 6 and 7 are merely examples. Various arrangements can be implemented to achieve similar functionality. For example, some content displayed on visualization 500B can be presented on visualization 500C, and vice versa.

[0054] The following is about Figures 7-9 The discussion now involves many methods and method actions that can be performed. While method actions may be discussed in a specific order or illustrated in a flowchart as occurring in a specific order, a specific order is not required unless specifically stated otherwise, or because an action depends on another action that is completed before that action is performed.

[0055] Figure 7The diagram illustrates a flowchart of an example method 700 for encrypting a VC (also known as a first VC) and requesting the certificate issuer to extract a portion of the data contained in the VC or derive a portion of the data from the VC. This is likely implemented at a computing system associated with the certificate holder. The certificate holder can store the VC on a mobile device, a personal PC, and / or cloud storage. In a decentralized environment, the certificate holder can be the owner of the DID, and the VC can be stored in a management module (e.g., a wallet application), an ID hub, and / or a user agent.

[0056] Method 700 includes obtaining the certificate issuer's public key (710). In some cases, the public key is contained within the VC. In some cases, the public key can be retrieved from a distributed ledger. In still other cases, the public key can be obtained from an authentication service. The computing system then encrypts the VC using the public key (720). In some embodiments, the entire VC is encrypted and additional metadata is appended to the encrypted VC. In some other embodiments, only a portion of the VC is encrypted (721). For example, only the claims contained in the VC can be encrypted, while proofs and other metadata are not encrypted. In this case, unencrypted data can be appended as metadata to the encrypted data.

[0057] The computing system also generates one or more instructions to instruct the certificate issuer (730). At least one of the instructions grants the dependent entity (731) a scope of permissions associated with the VC. The scope of permissions includes permissions to access a subset of data contained in the VC or a portion of data that can be derived from the VC. In some embodiments, at least one of the instructions is wrapped in a second VC, which is issued to the dependent entity on behalf of the principal entity.

[0058] In some cases, one of the instructions indicates the data encryption scheme used to encrypt the VC, enabling the certificate holder to decrypt the encrypted VC based on the data encryption scheme (732). In some cases, one of the instructions indicates the address of the dependent entity or the address of the principal entity, enabling the certificate issuer to send a response to the address (733). Some instructions are appended as metadata to the encrypted first or second VC. Alternatively or additionally, some instructions are appended to the request sent to the dependent entity or the certificate issuer.

[0059] The computing system sends the encrypted VC and (multiple) instructions to the certificate issuer (740), and the certificate issuer generates a response based on the instructions (750). The response may be sent to the dependent entity or the computing system. When the response is sent to the computing system (760), the computing system then passes at least a portion of the data contained in the response to the dependent entity (770).

[0060] Figure 8The diagram illustrates a flowchart of an example method 800 for receiving a request including an encrypted VC and one or more instructions and generating a response based on that request, which may be performed by a computing system associated with a certificate issuer. The computing system first receives the encrypted VC and one or more instructions from the certificate holder (810). The VC is encrypted using the certificate issuer's public key, and the computing system decrypts the encrypted VC using the corresponding private key (820). The decrypted VC includes one or more statements previously issued by the certificate issuer.

[0061] The computation system then generates a response (830) based on one or more instructions. In some cases, one or more instructions may instruct the computation system to verify the state of at least one statement contained in the VC. In this case, the computation system verifies the state of at least one statement and generates a response (831) indicating the validity of the at least one statement.

[0062] In some cases, the instructions(s) instruct the computing system to extract portions of the data contained in the VC. In this case, the computing system sequentially extracts portions of the data contained in the decrypted VC (832). In some cases, the instructions(s) instruct the computing system to derive portions of the data from the VC. The computing system sequentially derives portions of the data from the VC (834). In any of these cases, the instructions(s) may also instruct the computing system to issue a new VC containing portions of the extracted and / or derived data. The computing system sequentially generates a new VC including the extracted and / or derived data and proof that the extracted and / or derived data is authentic and correct (833, 835). In some embodiments, a cryptographic signature is proven by the private key of the computing system or the certificate issuer. For example, a cryptographic signature can be generated by using a one-way hash function to generate hash H from the claims contained in the VC, and then encrypting hash H using the private key of the computing system or the certificate issuer. When the dependent entity receives the VC containing the cryptographic signature, the dependent entity decrypts the cryptographic signature using the certificate issuer's public key to recover H'. Simultaneously, the dependent entity also recreates hash H from the claims contained in the VC using the same hash function. The recreated H is then compared with H'. If the recreated H is the same as H', the signature is considered genuine or valid. Otherwise, the statement contained in VC has been altered, or the signature was not generated by the certificate issuer.

[0063] The extracted and / or exported data and / or new VCs (including proofs) are included in the response. The response is then sent to the certificate holder or dependent entity (840). In a decentralized environment, at least one of the certificate holder, principal entity, certificate issuer, and / or dependent entity is the owner of the DID. In this case, the computing system may also propagate portions of the data related to access to the VC or data related to newly issued VCs to the distributed ledger (850).

[0064] Figure 9 A flowchart of method 900 for requesting data that contains or can be derived from a VC is illustrated, which may be implemented in a computing system associated with a dependent entity. The computing system first requests verifiable data from a certificate holder (910). For example, the computing system may be associated with a liquor store and want to verify that a customer has reached the legal age of majority. The customer is the VC holder of the driver's license, and the customer's mobile device receives the request from the computing system, generates an encrypted VC and one or more instructions. The encrypted VC is encrypted with the DMV's public key and one or more instructions instructing the DMV to generate a response proving that the customer has reached the legal age of majority. The customer's mobile device sends the encrypted VC and instructions to the liquor store's computing system. Upon receiving the encrypted VC and one or more instructions (920), the computing system forwards the encrypted VC and one or more instructions to the certificate issuer (930). The term "forwarding" does not necessarily mean that the original message received from the certificate holder is literally forwarded to the certificate issuer. Rather, in some cases, the computing system may perform some transformation on the data and repackage it in a JWT request token, and send the JWT request token to the certificate issuer (930). The JWT request token corresponds to Figure 2A JWT request token 200A.

[0065] Upon receiving an encrypted VC and one or more instructions, the certificate issuer sends a response, including the requested verifiable data, to the certificate holder or dependent entity. When the response is sent to the dependent entity, the computing system receives the response (940). The computing system then verifies that the received verifiable data is authentic and correct (950). The verifiable data may include a cryptographic signature signed by the certificate issuer's private key. The computing system can decrypt the cryptographic signature using the certificate issuer's public key and compare the decrypted data with the verifiable data to determine whether the verifiable data was genuinely generated by the certificate issuer and whether the data has been altered. In some cases, the computing system may notify the certificate issuer of the verification result (960). For example, when a liquor store receives data related to a customer and verifies that the customer has reached the legal age of majority, the computing system associated with the liquor store may notify the customer's mobile device and complete the customer's purchase transaction. Upon receiving the notification, the customer's device may display a visualization of the portable identity card and record the completed transaction as metadata about the portable identity card's usage.

[0066] As mentioned earlier, the principles described in this article can be implemented in a decentralized environment. As an example, the computing system associated with the certificate holder could be a digital wallet, such as those discussed below. Figure 11 The described DID management module 1120. Alternatively or additionally, the declared subject and issuer identifiers can be decentralized identifiers (DIDs). Alternatively or additionally, the portable identity card data structure (or a portion thereof) can be stored in the DID document. This will be particularly useful because the holder can access the portable identity card from any device associated with the holder's DID. Therefore, reference will now be made to... Figure 10 and Figure 11 Identifiers that describe decentralization.

[0067] like Figure 10 As shown, DID owner 1001 can own or control DID 1005, which represents the digital identity of DID owner 1001. DID 1005 is the digital identity associated with (i.e., identifies) DID owner 1001 across different digital contexts. DID owner 1001 can register a DID using the creation and registration service, which will be explained in more detail below.

[0068] DID Owner 1001 can be any entity that can benefit from digital identity. For example, DID Owner 1001 can be a person or an organization of a person. Such organizations can include corporations, departments, governments, agencies, or any other organization or group of organizations. Every individual may have a DID, and the organizations to which each individual belongs may also have DIDs.

[0069] DID owner 1001 may alternatively be a machine, system, or device, or a collection of (multiple) machines, (multiple) devices, and / or (multiple) systems. In other embodiments, DID owner 1001 may be a sub-part of a machine, system, or device. For example, a device may be a printed circuit board, wherein sub-parts of the circuit board are various components of the circuit board. In such embodiments, the machine or device may have a DID, and each sub-part may also have a DID. DID owner may also be a software component, such as those mentioned above. Figure 12 The executable component 1206 is described. An example of a complex executable component 1206 could be artificial intelligence. Therefore, artificial intelligence could also have a DID.

[0070] Therefore, DID owner 1001 can be any entity, human or non-human, capable of creating DID 1005 or having at least DID 1005 created for them and / or associated with them. Although DID owner 1001 is shown as having a single DID 1005, this is not necessarily the case, as any number of DIDs associated with DID owner 1001 may exist where circumstances permit.

[0071] As mentioned, DID owner 1001 can create and register DID 1005. DID 1005 can be any identifier that can be associated with DID owner 1001. Preferably, the identifier is unique to DID owner 1001 and is expected to be used by the DID at least within the following scope. As an example, the identifier can be a locally unique identifier, and perhaps more ideally, a globally unique identifier for an identity system expected to operate globally. In some embodiments, DID 1005 can be a Uniform Resource Identifier (URI) (e.g., a Uniform Resource Locator (URL)) or other pointer that associates DID owner 1001 with a mechanism for participating in and trusting interactions with DID owner 1001.

[0072] DID 1005 is "decentralized" because it does not require a centralized third-party management system to generate, manage, or use it. Therefore, DID 1005 remains under the control of DID owner 1001. This differs from traditional centralized IDs, which are based on trust in a centralized authority and remain under the control of a corporate directory service, certificate authority, domain name registry, or other centralized authority (collectively referred to as the "central authority" in this document). Therefore, DID 1005 can be any identifier under the control of DID owner 1001 and independent of any centralized authority.

[0073] In some embodiments, the structure of DID 1005 can be as simple as a username or some other human-understandable term. However, in other embodiments, for enhanced security, DID 1005 can preferably be a random string of numbers and letters. In one embodiment, DID 1005 can be a string of 128 numbers and letters. Therefore, the embodiments disclosed herein do not depend on any particular implementation of DID 1005. In a very simple example, DID 1005 is shown in the figure as "123ABC".

[0074] For example Figure 10 As shown, DID owner 1001 controls the private key 1006 and public key 1007 pair associated with DID 1005. Because DID 1005 is independent of any central authority, private key 1006 should always be completely under the control of DID owner 1001. That is, the private and public keys should be generated in a decentralized manner to ensure that they remain under the control of DID owner 1001.

[0075] As will be described in more detail below, the private key 1006 and public key 1007 pair can be generated on a device controlled by DID owner 1001. The private key 1006 and public key 1007 pair should not be generated on a server controlled by DID owner 1001, as this could result in the private key 1006 and public key 1007 pair not always being fully under the control of DID owner 1001. Although Figure 10 While this description has already covered private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may also be used when circumstances permit.

[0076] Figure 10 The diagram also illustrates a DID document 1010 associated with DID 1005. As will be explained in more detail below, DID document 1010 can be generated when DID 1005 is created. In its simplest form, DID document 1010 describes how DID 1005 is used. Therefore, DID document 1010 includes a reference to DID 1005, which is the DID described by DID document 1010. In some embodiments, DID document 1010 may be implemented according to a method specified by a distributed ledger 1020 (e.g., a blockchain), which will be used to store a representation of DID 1005, as will be explained in more detail below. Therefore, DID document 1010 can have different methods depending on the specific distributed ledger.

[0077] DID document 1010 also includes a public key 1007 or some other equivalent cryptographic information created by DID owner 1001. Public key 1007 can be used by third-party entities authorized by DID owner 1001 to access information and data owned by DID owner 1001. Public key 1007 can also be used to verify that DID owner 1001 actually owns or controls DID 1005.

[0078] DID document 1010 may also include authentication information 1011. Authentication information 1011 specifies one or more mechanisms by which DID owner 1001 can prove that DID owner 1001 owns DID 1005. In other words, the mechanism of authentication information 1011 demonstrates proof of the binding between DID 1005 (and therefore its DID owner 1001) and DID document 1010. In one embodiment, authentication information 1011 specifies a public key 1007 for a signing operation to prove ownership of DID 1005. Alternatively or additionally, authentication information 1011 specifies a public key 1007 for a biometric operation to prove ownership of DID 1005. Therefore, authentication information 1011 includes any number of mechanisms by which DID owner 1001 can prove that DID owner 1001 owns DID 1005.

[0079] DID document 1010 may also include authorization information 1012. Authorization information 1012 allows DID owner 1001 to authorize a third-party entity to modify DID document 1010 or certain portions thereof, without granting the third party the right to prove ownership of DID 1005. In one example, authorization information 1012 allows a third party to use any specified update mechanism to update any specified set of one or more fields in DID document 1010. Alternatively, the authorization information allows a third party to restrict DID owner 1001's use of DID 1005 for a specified period. This can be useful when DID owner 1001 is a minor and the third party is the child's parent or guardian. Authorization information 1012 can allow a parent or guardian to restrict DID owner 1001's use until the child is no longer a minor.

[0080] Authorization information 1012 also specifies one or more mechanisms that third parties will need to follow to prove they are authorized to modify DID document 1010. In some embodiments, these mechanisms may be similar to those discussed earlier with respect to authentication information 1011.

[0081] DID document 1010 also includes one or more service endpoints 1013. A service endpoint includes a network address representing the operation of a service on behalf of DID owner 1001. Examples of specific services include discovery services, social networks, file storage services (such as identity servers or hubs), and verifiable claims repository services. Therefore, service endpoint 1013 serves as a pointer to a service operating on behalf of DID owner 1001. DID owner 1001 or third-party entities can use these pointers to access the service operating on behalf of DID owner 1001. Specific examples of service endpoint 1013 will be explained in more detail later.

[0082] DID document 1010 also includes identification information 1014. Identification information 1014 includes personally identifiable information, such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 1001. Therefore, identification information 1014 is listed in DID document 1010 for different roles representing DID owners 1001 for different purposes.

[0083] Roles can be pseudo-anonymous. For example, DID owner 1001 might include a pseudonym in their DID document when identifying themselves as an author of articles published on a blog. Roles can also be completely anonymous. For instance, DID owner 1001 might only want to disclose their job title or other background information (e.g., school teacher, FBI agent, adult over 21, etc.) in their DID document, rather than their name. As yet another example, roles can be specific to DID owner 1001 as an individual. For example, DID owner 1001 might include information identifying them as a volunteer for a specific charity, an employee of a specific company, a recipient of a specific award, etc.

[0084] DID document 1010 also includes certificate information 1015, which may also be referred to herein as proof. Certificate information 1015 can be any information associated with the background of DID owner 1001. For example, certificate information 1015 can be (but is not limited to) qualifications, achievements, government ID, government rights such as a passport or driver's license, payment provider or bank account, university degree or other educational history, employment status and history, or any other information regarding the background of DID owner 1001.

[0085] DID document 1010 also includes various other information 1016. In some embodiments, the other information 1016 may include metadata specifying when the DID document 1010 was created and / or when it was last modified. In other embodiments, the other information 1016 may include cryptographic proof of the integrity of the DID document 1010. In yet another embodiment, the other information 1016 may include additional information specified by a particular method of implementing the DID document or required by the DID owner 1001 document.

[0086] Figure 10 Distributed ledger 1020 is also illustrated. Distributed ledger 1020 can be any decentralized distributed network, including various computing systems communicating with each other. In one example, distributed ledger 1020 includes a first distributed computing system 1030, a second distributed computing system 1040, a third distributed computing system 1050, and any number of additional distributed computing systems represented by ellipse 1060. Distributed ledger 1020 operates according to any known standards or methods for distributed ledgers. Examples of conventional distributed ledgers corresponding to distributed ledger 1020 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0087] In the context of DID 1005, the distributed ledger or blockchain 1020 is used to store a representation of DID 1005 pointing to DID document 1010. In some embodiments, DID document 1010 may be stored on the actual distributed ledger. Alternatively, in other embodiments, DID document 1010 may be stored in a data storage device (not shown) associated with the distributed ledger 1020.

[0088] The representation of DID 1005 is stored on each distributed computing system of the distributed ledger 1020. For example, in Figure 10 In this context, this is shown as DID hash 1031, DID hash 1041, and DID hash 1051, which ideally are identical hash copies of the same DID. DID hashes 1031, 1041, and 1051 point to the location of DID document 1010. The distributed ledger or blockchain 1020 can also store many other representations of other DIDs, as shown in references 1032, 1033, 1034, 1042, 1043, 1044, 1052, 1053, and 1054.

[0089] In one embodiment, when DID owner 1001 creates DID 1005 and the associated DID document 1010, DID hashes 1031, 1041, and 1051 are written to distributed ledger 1020. Distributed ledger 1020 thus records that DID 1005 now exists. Because distributed ledger 1020 is decentralized, DID 1005 is not controlled by any entity other than DID owner 1001. In addition to pointers to the DID, DID hashes 1031, 1041, and 1051 may each include document 1010, a record specifying when DID 1005 was created, or a timestamp. Later, when DID document 1010 is modified, each modification (and possibly a timestamp of the modification) is also recorded in DID hashes 1031, 1041, and 1051. DID hashes 1031, 1041, and 1051 may also include a copy of the public key 1007, so that DID 1005 is cryptographically bound to DID document 1010.

[0090] Already referenced Figure 10 The DID and how it generally works have been described; now we will refer to Figure 11 Explain a specific implementation of the DID environment. Figure 11 The illustration shows an example environment 1100, which can be used to perform various DID management operations and services, and will now be explained. It should be understood that... Figure 11 The environment can be referenced as needed. Figure 10 The elements in the text are for easy interpretation.

[0091] like Figure 11 As shown, environment 1100 includes various devices and computing systems owned or controlled by DID owner 1001. These may include user equipment 1101. User equipment 1101 may be, but is not limited to, mobile devices such as smartphones, computing devices such as laptops, or any device such as automobiles or appliances that include computing capabilities. Device 1101 includes a web browser 1102 running on the device and an operating system 1103 running on the device. More broadly, the dashed line 1104 indicates that all these devices may be owned or controlled by DID owner 1001.

[0092] Environment 1100 also includes a DID management module 1120. In operation, as indicated by the corresponding arrows 1101a, 1102a, and 1103a, the DID management module 1120 resides on and is executed by one or more of the user device 1101, web browser 1102, and operating system 1103. Therefore, for ease of illustration, the DID management module 1120 is shown as separate. The DID management module 1120 can also be described as a "wallet" because it can store various claims made by or about a particular DID. In one example, the DID management module 1120 is arranged as described above for executable component 1206.

[0093] like Figure 11 As shown, the DID management module 1120 includes a DID creation module 1130. The DID owner 1001 can use the DID creation module 1130 to create DID 1005 or any number of additional DIDs, such as DID 1131. In one embodiment, the DID creation module may include or otherwise access a user interface (UI) element 1135 that can guide the DID owner 1001 in creating DID 1005. The DID creation module 1130 has one or more drivers configured to work with a specific distributed ledger (e.g., distributed ledger 1020) such that DID 1005 conforms to the underlying methodology of that distributed ledger.

[0094] Specific embodiments will now be described. For example, UI 1135 may prompt the user to enter a username or some other human-recognizable name. This name can be used as the display name for the generated DID 1005. As previously mentioned, DID 1005 can be a long string of random numbers and letters, so having a human-recognizable name for the display name can be advantageous. DID creation module 1130 can then generate DID 1005. In an embodiment with UI 1135, DID 1005 can be displayed in an identity list and can be associated with a human-recognizable name.

[0095] The DID creation module 1130 may also include a key generation module 1150. The key generation module can generate the previously described private key 1006 and public key 1007 pair. The DID creation module 1130 can then use the DID 1005 and the private and public key pair to generate a DID document 1010.

[0096] In operation, the DID creation module 1130 accesses a registrar 1110 configured to record transactions associated with DID 1005 in a specific distributed ledger. The DID creation module 1130 uses the registrar 1110 to record DID hashes 1031, 1041, and 1051 in the distributed ledger as described above, and stores the DID document 1010 as described above. This process may utilize the public key 1007 in hash generation.

[0097] In some embodiments, the DID management module 1120 may include an ownership module 1140. The ownership module 1140 can provide a mechanism to ensure that the DID owner 1001 has sole control over DID 1005. In this way, the provider 1120 of the DID management module can ensure that the provider does not control DID 1005, but only provides management services.

[0098] Key generation module 1150 generates a private key 1006 and a public key 1007 pair, and then records the public key 1007 in DID document 1010. Therefore, public key 1007 can be used by all devices associated with DID owner 1001 and by all third parties wishing to provide services to DID owner 1001. Thus, when DID owner 1001 wishes to associate a new device with DID 1005, DID owner 1001 can execute DID creation module 1130 on the new device. DID creation module 1130 can then use registrar 1110 to update DID document 1010 to reflect that the new device is now associated with DID 1005; this update will be reflected in transactions on distributed ledger 1020.

[0099] However, in some embodiments, having a public key for each device 1101 owned by the DID owner 1001 can be advantageous, as this allows the DID owner 1001 to sign with a device-specific public key without having to access a general public key. In other words, since the DID owner 1001 will use different devices at different times (e.g., a mobile phone in one instance and a laptop in another), using a key associated with each device to provide efficiency in signing with that key is beneficial. Therefore, in such embodiments, when the attached device executes the DID creation module 1130, the key generation module 1150 generates additional public keys 1008 and 1009. These additional public keys may be associated with the private key 1006, or in some cases, paired with a new private key.

[0100] like Figure 11 As shown, in those embodiments where additional public keys 1008 and 1009 are associated with different devices, additional public keys 1008 and 1009 are recorded in DID document 1010 as associated with those devices. Besides Figure 11 In addition to the information shown (information 1008, 1009, and 1165), DID document 1010 may include previous information about Figure 10 The information described (information 1005, 1007, and 1010 to 1016). If DID document 1010 already exists before the generation of the device-specific public key, DID document 1010 will be updated by creation module 1130 through registrar 1110, which will be reflected in the update transaction on distributed ledger 1020.

[0101] In some embodiments, the DID owner 1001 may wish to keep the association between the device and the public key or the association between the device and DID 1005 confidential. Therefore, the DID creation module 1130 can make such data secretly displayed in the DID file 1010.

[0102] As described so far, DID 1005 is already associated with all devices under the control of DID owner 1001, even though these devices have their own public keys. However, in some embodiments, each device or a subset of devices under the control of DID owner 1001 may each have its own DID. Therefore, in some embodiments, DID creation module 1130 may generate an additional DID for each device, such as DID 1131. DID creation module 1130 then generates a private key and public key pair and a DID document for each device and records them on distributed ledger 1020 in the manner described above. Such embodiments may be advantageous for devices whose ownership can change, as the device-specific DID can be associated with the new owner by granting authorization rights to the new owner and revoking such rights from the old owner in the DID document.

[0103] As previously stated, to ensure that the private key 1006 remains entirely under the control of the DID owner 1001, the private key 1006 is created on a user device 1101, browser 1102, or operating system 1103 owned or controlled by the DID owner 1001, which executes the DID management module 1120. In this way, the likelihood of a third party (and most importantly, the provider of the DID management module 1120) gaining control over the private key 1006 is very small.

[0104] However, the device storing private key 1006 could be lost by DID owner 1001, potentially causing DID owner 1001 to lose access to DID 1005. Therefore, in some embodiments, UI 1135 includes an option to allow DID owner 1001 to export private key 1006 to an off-device secure database 1105 controlled by DID owner 1001. As an example, database 1105 could be the following... Figure 12One of the identity hubs 1210 described. Storage module 1180 is configured to store data (e.g., private key 1006 or authentication done by or about DID owner 1001) off-device in database 1105 or identity hub 1210. In some embodiments, private key 1006 is stored as a QR code scanned by DID owner 1001.

[0105] In other embodiments, the DID management module 1120 may include a recovery module 1160 that can be used to recover a lost private key 1006. In operation, the recovery module 1160 allows the DID owner 1001 to select one or more recovery mechanisms 1165 when creating DID 1005, which can later be used to recover the lost private key. In those embodiments with a UI 1135, the UI 1135 may allow the DID owner 1001 to provide information that will be used by one or more recovery mechanisms 1165 during recovery. The recovery module 1160 can then be run on any device associated with DID 1005.

[0106] DID management module 1120 may also include revocation module 1170 for revoking or disconnecting the device from DID 1005. In operation, the revocation module uses UI element 1135, which allows DID owner 1001 to indicate a desire to remove the device associated with DID 1005. In one embodiment, revocation module 1170 accesses DID document 1010 and causes all references to the device to be deleted from DID document 1010. Alternatively, the device's public key may be removed, and this change is then reflected in DID document 1010, and subsequently as an update transaction on distributed ledger 1020.

[0107] Because the principles described in this article are executed within the context of a computing system, they will be discussed in detail below. Figure 12 This section provides an introductory discussion of the computational system. Then, the description returns to the principles of the decentralized identifier (DID) platform regarding the remaining graph.

[0108] Computing systems are increasingly taking on a variety of forms. For example, a computing system can be a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include any device or system (or a combination thereof) comprising at least one physical and tangible processor, and physical and tangible memory capable of having a computer thereon—executable instructions executable by the processor. The memory can take any form and can depend on the nature and form of the computing system. Computing systems can be distributed in a networked environment and can comprise multiple component computing systems.

[0109] like Figure 12 As shown, in its most basic configuration, the computing system 1200 includes at least one hardware processing unit 1202 and a memory 1204. The processing unit 1202 includes a general-purpose processor. Although not strictly necessary, the processing unit 1202 may also include a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other dedicated circuitry. In one embodiment, the memory 1304 includes physical system memory. This physical system memory may be volatile, non-volatile, or some combination of both. In a second embodiment, the memory is a non-volatile mass storage device, such as a physical storage medium. If the computing system is distributed, the processing, memory, and / or storage capacity may also be distributed.

[0110] The computing system 1200 also has several structures thereon, commonly referred to as "executable components." For example, the memory 1204 of the computing system 1200 is shown to include an executable component 1206. The term "executable component" is a name for a structure well known to those skilled in the art in the field of computing, which can be a software, hardware, or a combination thereof. For example, when implemented in software, those skilled in the art will understand that the structure of an executable component can include software objects, routines, methods (etc.) that can be executed on the computing system. Such executable components reside in the heap, computer-readable storage medium, or a combination thereof of the computing system.

[0111] Those skilled in the art will recognize that the structure of an executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by processor threads), the computing system causes the execution of a function. This structure can be directly computer-readable by the processor (in the case of a binary executable component). Alternatively, the structure can be constructed to be interpretable and / or compileable (whether in a single stage or in multiple stages) to produce such a binary structure that can be directly interpreted by the processor. This understanding of an example structure of an executable component, when used with the term "executable component," is entirely within the comprehension of those skilled in the art of computing.

[0112] The term "executable component" is also well understood by those skilled in the art to include structures such as hard-coded or hard-wired logic gates, which are implemented exclusively or nearly exclusively in hardware, such as in a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other special-purpose circuit. Therefore, the term "executable component" is a term for structures well understood by those skilled in the art of computing, whether implemented in software, hardware, or a combination thereof. In this description, the terms "component," "agent," "manager," "service," "engine," "module," "virtual machine," etc., may also be used. As used in this description and examples, these terms (with or without modifications) are also intended to be synonymous with the term "executable component" and therefore also have structures well understood by those skilled in the art of computing.

[0113] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If these actions are implemented in software, one or more processors (of the associated computing system performing the action) direct the operation of the computing system in response to executed computer-executable instructions constituting executable components. For example, such computer-executable instructions may be embodied on one or more computer-readable media forming a computer program product. An example of such operation involves data manipulation. If such actions are implemented exclusively or nearly exclusively in hardware (e.g., within an FPGA or ASIC), the computer-executable instructions may be hard-coded or hard-wired logic gates. The computer-executable instructions (and the processed data) may be stored in memory 1204 of computing system 1200. Computing system 1200 may also include a communication channel 1208 that allows computing system 1200 to communicate with other computing systems (e.g., network 1210).

[0114] While not all computing systems require a user interface, in some embodiments, computing system 1200 includes a user interface system 1212 for interaction with a user. User interface system 1212 may include an output mechanism 1212A and an input mechanism 1212B. The principles described herein are not limited to a precise output mechanism 1212A or input mechanism 1212B, and will therefore depend on the nature of the device. However, output mechanism 1212A may include, for example, a speaker, display, haptic output, virtual or augmented reality, hologram, etc. Examples of input mechanism 1212B may include, for example, a microphone, touchscreen, virtual or augmented reality, hologram, camera, keyboard, mouse or other pointer input, any type of sensor, etc.

[0115] As discussed in more detail below, the embodiments described herein may include or utilize dedicated or general-purpose computing systems including computer hardware, such as one or more processors and system memory. The embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible to a general-purpose or dedicated computing system. A computer-readable medium storing computer-executable instructions is a physical storage medium. A computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: storage media and transmission media.

[0116] Computer-readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other physical and tangible storage medium that can be used to store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computing system.

[0117] A “network” is defined as one or more data links that enable the transmission of electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or other communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computing system correctly regards the connection as a transmission medium. The transmission medium may include networks and / or data links, which may be used to carry desired program code in the form of computer-executable instructions or data structures and accessible by general-purpose or special-purpose computing systems. Combinations of the above should also be included within the scope of computer-readable media.

[0118] Furthermore, upon arrival at various computing system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be cached in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computing system RAM and / or lesser volatile storage media at the computing system. Therefore, it should be understood that storage media can be included in computing system components that also (or even primarily) utilize the transmission medium.

[0119] Computer-executable instructions include, for example, instructions and data, which, when executed at a processor, cause a general-purpose computing system, a special-purpose computing system, or a special-purpose processing device to perform a specific function or group of functions. Alternatively or additionally, computer-executable instructions can configure a computing system to perform a specific function or group of functions. Computer-executable instructions can be, for example, binary instructions or even instructions that have undergone some translation (e.g., compilation) before being directly executed by the processor, such as intermediate format instructions like assembly language or even source code.

[0120] Although the subject has been described in language specific to structural features and / or methodological behavior, it should be understood that the subject defined in the appended claims is not necessarily limited to the features or behaviors described above. Rather, the described features and actions are disclosed as exemplary forms for implementing the claims.

[0121] Those skilled in the art will understand that this invention can be implemented in network computing environments with a variety of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (e.g., glasses), etc. This invention can also be practiced in distributed system environments, where local and remote computing systems perform tasks via network links (via hardwired data links, wireless data links, or a combination of hardwired and wireless data links). In a distributed system environment, program modules can reside in local and remote memory storage devices.

[0122] Those skilled in the art will also understand that the present invention can be implemented in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be internationally distributed within an organization and / or have components owned across multiple organizations. In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services. The definition of “cloud computing” is not limited to any of the many other advantages that can be obtained from such a model when properly deployed.

[0123] For the processes and methods disclosed herein, the operations performed within the processes and methods may be implemented in different orders. Furthermore, the operations outlined are provided merely as examples, and some of these operations may be optional, may be combined into fewer steps and operations, supplemented with more operations, or extended into additional operations without departing from the essence of the disclosed embodiments.

[0124] This invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A computing system associated with a certificate holder, comprising: One or more processors; as well as One or more computer-readable media having computer-executable instructions configured to cause the computing system to perform the following operations when executed by the one or more processors: Receive a verifiable certificate (VC) from the certificate issuer, the VC containing one or more claims about the subject entity; Obtain the public key of the certificate issuer; The VC is encrypted using the public key of the certificate issuer; Generate one or more instructions, at least one of which instructs the certificate issuer to grant the dependent entity a scope of permissions associated with the encrypted VC, the scope of which includes at least access to a subset of data that can be extracted from the VC or a portion of data that can be exported from the VC. The encrypted VC and one or more instructions are sent to the certificate issuer or the dependent entity; This ensures that if the encrypted VC and the one or more instructions have been sent to the dependent entity, the dependent entity will forward the encrypted VC and the one or more instructions to the certificate issuer. The certificate issuer generates a response containing the subset or portion of verifiable data and a proof code configured to prove the validity of the subset or portion of the data. as well as The certificate is issued to the computing system associated with the certificate holder or to the dependent entity, and the response is sent accordingly.

2. The computing system according to claim 1, wherein: The VC is the first VC, and The computing system is further configured to issue a second VC on behalf of the principal entity to the dependent entity, wherein at least one statement of the second VC is associated with the at least one instruction that grants the dependent entity a scope of the permissions associated with the encrypted VC.

3. The computing system of claim 2, wherein at least one of the instructions is appended as metadata to the encrypted first VC or the second VC.

4. The computing system according to claim 1, wherein the one or more instructions include at least one of the following: (1) a data encryption scheme for encrypting the VC, and (2) an address or identifier of the entity receiving the response.

5. The computing system according to claim 1, wherein: At least one of the principal entity, the certificate holder, the dependent entity, or the certificate issuer is the owner of the decentralized identifier (DID).

6. The computing system of claim 4, further comprising enabling the propagation of portions of the data associated with the VC or the DID to a distributed ledger.

7. The computing system of claim 1, wherein the response comprises a new VC, the new VC containing a subset of the extracted data or a portion of the exported data in the original VC.

8. The computing system according to claim 1, wherein the computing system is further configured such that: Receive the response from the certificate issuer; and At least the subset or portion of the data, along with the proof code, is forwarded to the dependent entity.

9. The computing system according to claim 1, wherein: The computing system is further configured to receive requests from the dependent entity; and The one or more instructions are generated based on the request from the dependent entity.

10. The computing system according to claim 1, wherein: The computing system is further configured to receive user input; and The one or more instructions are generated based on the user input.

11. The computing system according to claim 1, wherein the computing system is further configured such that: Create the data structure for the portable identity card; Insert the VC into the data structure of the portable identity card; and The data structure of the personal identification card is presented as one or more visualizations, at least one of which resembles the physical identification card.

12. The computing system according to claim 11, wherein: At least one of the one or more visualizations is configured to receive user input, which instructs the certificate issuer to extract a subset of the data contained in the VC or to derive a portion of the data from the VC. as well as In response to the user input, the computing system is caused to generate the one or more instructions.

13. The computing system according to claim 11, wherein the computing system is further configured such that: The communication between the computing system, the certificate issuer, or the dependent entity is recorded as metadata of the portable identity card.

14. The computing system of claim 11, wherein at least one of the one or more visualizations displays at least one of the following: (1) certificate type, (2) subject name, (3) publisher identifier, (4) publisher name, (5) publication date, (6) expiration date, (7) user interface configured to receive user input, (8) data related to the one or more claims, (9) the rights of the VC, (10) one or more dependent entities, and (11) usage data.

15. A method, implemented at a computing system, for requesting from a certificate issuer a subset of verifiable data contained in a verifiable certificate (VC), or a subset of verifiable data deriveable from said VC, comprising: Receive a first VC from the certificate issuer, the first VC containing one or more claims about the subject entity; Obtain the public key of the certificate issuer; The first VC is encrypted using the public key of the certificate issuer; Generate one or more instructions, at least one of which instructs the certificate issuer to extract a subset of the data contained in the first VC or to derive a portion of the data from the first VC; On behalf of the principal entity, a second VC is issued to the dependent entity, wherein at least one statement of the second VC is associated with at least one of the one or more instructions, such that the second VC grants the dependent entity access to the subset of data extracted from the VC or the portion of data exported from the VC. The encrypted first VC and the second VC are sent to the certificate issuer or dependent entity, such that if the encrypted VC and the one or more instructions are sent to the dependent entity, the dependent entity is triggered to forward the encrypted VC and the one or more instructions to the certificate issuer. The certificate issuer generates a response containing the subset or portion of verifiable data and a proof code configured to prove the validity of the subset or portion of the data. as well as The certificate is issued to the computing system associated with the certificate holder or to the dependent entity, and the response is sent accordingly.

Images