Verifiable credentials with dynamic claims

Abstract

Allowing a claim holder to obtain a limited verifiable credential with previously issued verifiable credentials. This is done by having the limited verifiable credential include only a selected subset of the verifiable claims that exist in the previously issued verifiable credentials. The limited verifiable credential can then be exposed to a relying entity computing system such that the relying entity computing system can verify any of the selected subset of verifiable claims, but cannot verify verifiable claims outside of the selected subset of verifiable claims.

Description

Technical Field

[0001] Embodiments of this disclosure relate to verifiable credentials with dynamic claims. Background Technology

[0002] Digital identity is a mechanism for tracking entities across different digital environments. Once an identity is established, appropriate actions can be taken in relation to 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 restricted to appropriate trust boundaries through appropriate authorization and privileges. Digital identity is also an important mechanism for ensuring a positive and consistent user experience when accessing data and customization.

[0003] Existing computing techniques provide a data structure called a "verifiable credential." In these techniques, a claim publisher makes one or more claims about an object and generates a verifiable credential. The verifiable credential includes these claims along with proof instructions (e.g., metadata) that prove the claims have not been tampered with and were indeed issued by the claim publisher. The claim publisher then provides the verifiable credential to the claim holder for presentation to any dependent parties who rely on the authenticity of these claims.

[0004] For example, the issuer of the statement might be a computing system associated with a government agency responsible for issuing driver's licenses. The government agency might generate a verifiable credential containing a citizen's information, such as date of birth, residential address, weight, eye color, hair color, driving authorization, and driving authorization restrictions. The government agency issues the verifiable credential to the citizen. If a user is stopped by law enforcement, the citizen can present the verifiable credential, and the computing system associated with law enforcement can use that credential to verify that the statement was issued by the government agency and has not been tampered with since its issuance. In another example, an organization providing vaccines might issue a statement to parents claiming their child has received certain vaccines, which the parents can then present to their child's school.

[0005] 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 merely intended to illustrate an exemplary technical field in which some of the embodiments described herein may be practiced. Summary of the Invention

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

[0007] Existing computing techniques provide a data structure called a "verifiable credential." In these techniques, a claim publisher proposes one or more claims on a topic and generates a verifiable credential. Each claim contains an attribute-value pair. The verifiable credential includes those claims along with proof instructions (such as metadata) to prove that the claims have not been tampered with and were indeed published by the claim publisher. The claim publisher then provides the verifiable credential to the claim holder, for use by any dependent party that relies on the authenticity of these claims.

[0008] For example, the issuer of a statement might be a computing system associated with a government agency responsible for issuing driver's licenses. The government agency can generate verifiable credentials containing statements about a citizen, such as date of birth, residential address, weight, eye color, hair color, driving authorization, and driving authorization restrictions. The government agency issues these verifiable credentials to the citizen. If a user is stopped by law enforcement, the citizen can present the verifiable credentials, allowing the computing system associated with law enforcement to use a verification instruction to confirm that the statement was issued by the government agency and has not been tampered with since its issuance. In another example, an organization providing vaccinations could issue statements to the parents of their children claiming that their child has received certain vaccinations, which the parents can then present to the school their child will attend.

[0009] Verifiable credentials are used to declare objects whose values ​​associated with attributes remain unchanged. For example, if the declaration is that a particular object has a specific last name, then the attribute would be the last name, and the value would be that person's last name (e.g., Smith). This last name is unlikely to change frequently, and if it does, a new verifiable credential would be issued with the new last name. The principles described here allow for the use of verifiable credentials that include dynamic declarations, where the value of a particular property can change more frequently (e.g., a person's goal or bank balance) without the need to reissue verifiable credentials. This is done by making the value either a location where the actual value is stored or a pointer to another location. For example, a bank could now issue a declaration for an account holder stating that the bank balance may be found in a specific network location.

[0010] The embodiments described herein involve verifying certificates including dynamic claims. A dependent computing system accesses a verifiable credential provided by the claim-holding computing system. In response, the dependent computing system follows the proof instructions within the verifiable credential to prove a claim having attributes and value about an object. This value is a location or a pointer to another location, which the dependent computing system then retrieves a remote value from the pointed-to network location and associates with the attribute so that the dependent computing system accepts the remote value of the object having the attribute.

[0011] In some embodiments, the dependent party first identifies verifiable claims that can be used to claim the holding computing system. The dependent computing system then determines to obtain a claim with attribute-value pairs, and then causes a request for verifiable credentials to be sent to the claim holding computing system.

[0012] In some embodiments, the network location includes a Uniform Resource Locator (URL) such that the network location storing the remote value can be any network location, such as a website location.

[0013] In some embodiments, at least one or more verifiable claims may have objects referenced by a decentralized identifier. Therefore, the principles described herein can utilize verifiable credentials with claims regarding a decentralized identity.

[0014] In some embodiments, the network location has a remote value that changes over time. In this case, the method can be executed multiple times without altering the verifiable credentials. For example, suppose a remote value was obtained for the first time. Then, a second time after the first time, a remote value is obtained from the network location again, this time with a second value that is different from the first value obtained the first time. This second remote value is then associated with an attribute such that the dependent computing system accepts the attribute as having the second value.

[0015] 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 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

[0016] 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 are therefore not to be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein: Figure 1 shows a verifiable credential, which includes multiple verifiable claims and proof instructions to prove that the claims were made by the issuer. Figure 2 illustrates the environment for creating and using verifiable credentials (such as the verifiable credentials in Figure 1); Figure 3 A flowchart is shown illustrating a method for issuing verifiable credentials, including dynamic claims, based on the principles described herein; Figure 4A flowchart is shown illustrating a method for verifying verifiable credentials, including dynamically declared ones, based on the principles described herein; Figure 5 An environment including verifiable credentials and network location is shown and will be used for illustration. Figure 3 Methods and Figure 4 Illustrative examples of the methods; Figure 6 The portable identity card data structure is shown, which includes verifiable credentials and usage data; Figures 7A to 7F A series of user interfaces are shown, in which publishers create portable identity card templates, which will be used to create portable identity cards for various holders; Figures 8A to 8F A series of user interfaces are shown, in which the holder obtains from Figures 7A to 7F Portable identity cards generated from portable identity card templates; Figures 9A to 9C A series of user interfaces are shown, in which the holder presents the portable identity card to the dependent party; Figures 10A to 10C show additional user interfaces that allow users to manage portable identity cards; Figure 11 shows an example environment for creating decentralized identifiers (DIDs); Figure 12 illustrates an example environment for various DID management operations and services; and Figure 13 An example computing system is shown, in which the principles described herein can be employed. Detailed Implementation

[0017] The principles described in this article relate to the verification of credentials, including those with dynamic claims. Verifiable credentials are known in the art but do not have dynamic claims. On November 19, 2019, the W3C Recommendation described a traditional implementation of verifiable credentials with static claims in a document entitled “Verifiable Credential Data Model 1.0”.

[0018] To introduce the concept of verifiable credentials to readers, we will first refer to... Figure 1 The description example verifies credential 100. Additionally, refer to... Figure 2 Describe the environment 200 that verifies the creation and use of credentials. Then refer to... Figures 3 to 13 Describe the principles of this invention.

[0019] As used herein, a “publisher” is an entity that makes at least one assertion about an object. This assertion is also referred to herein as a “claim.” A “credential” is a set of one or more claims. A “verifiable credential” is a credential in which cryptographic mechanisms (such as digital signatures) are used to detect whether the credential has been tampered with since its issuance and can be used to verify the identity of the credential issuer. Claims in a verifiable credential do not necessarily relate to the same object, and the object of any claim does not necessarily have to be the same as the holder of the verifiable credential.

[0020] Figure 1 The illustration depicts a verifiable credential 100 comprising multiple verifiable claims 110. Verifiable claims 110 are shown as comprising four verifiable claims 111 to 114, although the ellipsis 115 indicates that the verifiable credential 100 may include any number (one or more) of verifiable claims. The verifiable credential 100 also includes a verification instruction 120 for verifying that the verifiable credential 100 has not been tampered with since its creation by its issuer, and for verifying the identity of the issuer of the verifiable claims 110. An example of a verification instruction is the issuer's digital signature.

[0021] Figure 2 The diagram illustrates an environment 200 in which verifiable credentials (e.g.) are created and used. Figure 1 Verifiable credentials 100). Environment 200 includes a publisher computing system 210 operating within the trust scope of the publisher. Examples of publishers include companies, organizations, associations, governments, institutions, individuals, or any other entity that can make assertions that others can rely on. The publisher performs the role of asserting the claims, enabling the publisher computing system 210 to create verifiable credentials (e.g., verifiable credentials 100) for these claims. Figure 1 The publisher computing system 210 transmits the verifiable credential 100 to the holder computing system 220, as indicated by arrow 201. Publisher computing system 210 may also be referred to herein simply as "Publisher 210". As indicated by arrow 211, Publisher 210 also transmits the verification identifier and usage pattern to registry computing system 240.

[0022] As indicated by arrow 201, the holder computing system 220 acquires the transmitted verifiable credentials. The holder computing system 220 operates on behalf of the holder, who uses it to possess and potentially store the verifiable credentials. As indicated by arrow 202, the holder also causes the holder computing system to present the verifiable credentials to the verifier computing system 230. The holder computing system 220 may also be referred to herein simply as "holder 220". As indicated by arrow 212, the holder 220 also transmits the identifier and usage pattern to the registry computing system 240.

[0023] Holder 220 presents the verifiable credential itself, or data derived from the verifiable credential in another data structure, which may also be referred to herein as a "verifiable presentation." A verifiable presentation expresses data from one or more verifiable credentials and is packaged in a way that verifies the data's authorship. If verifiable credentials are presented directly, they become verifiable presentations. Data formats derived from verifiable credentials can be cryptographically verified, but they do not contain the verifiable credential itself, nor are they included in the definition of a verifiable representation.

[0024] As indicated by arrow 202, verifier computing system 230 acquires the transmitted verifiable credential (optionally within a verifiable presentation). Verifier computing system 230 acts on behalf of a verifier, which is a dependent party relying on one or more claims made in the verifiable credential. Verifier computing system 230 evaluates whether the verifiable credential is an authentic (and unexpired) claim of publisher 210. This includes following any proof instructions (e.g., proof instruction 120) present in the verifiable credential (e.g., verifiable credential 100). Verifier computing system 230 can then take action based on this verification, such as deeming the claim made in the verifiable credential valid and issued by publisher 210. Verifier computing system 230 is sometimes referred to as "verifier 230" hereinafter. As part of the verification, verifier 230 sends a verification identifier and schema to registry computing system 240, as indicated by arrow 213.

[0025] Registry computing system 240 mediates the creation and verification of identifiers, keys, verifiable credential patterns, revocation registry entries, publisher public keys, etc. Example verifiable data registries include trusted databases, decentralized databases, and distributed ledgers. The structure of each of the publisher computing system 210, holder computing system 220, verifier computing system 230, and registry computing system 240 is as follows: Figure 13 The computing system 1300 is described.

[0026] Therefore, Figures 1 and 2 illustrate the verifiable credentials and data flow associated with the creation and use of verifiable credentials. However, the inventors have recognized that the portability of verifiable credentials is important for improving their usability. For example, this portability includes the ability to efficiently issue verifiable credentials to multiple holders, and the ability for any given holder to use verifiable credentials in different locations, even when the verifiable credentials are presented using multiple controlled devices (e.g., holder 220). Tracking the use of verifiable credentials in this way can become very difficult. However, there is currently no mechanism for tracking how verifiable credentials are used, let alone how they are used if multiple devices are used to present them.

[0027] Figure 3 The diagram illustrates a flowchart of method 300 for issuing verifiable credentials, including dynamically declared ones, based on the principles described herein. Some actions of method 300 are performed by the publisher computing system, which issues the verifiable credentials, and... Figure 3 The left column is indicated under the heading "Publisher". An example of a publisher calculation system is publisher calculation system 210 in Figure 2. Other actions of method 300 are performed by the holder calculation system, which receives verifiable credentials issued by the publisher calculation system, and these actions are illustrated in Figure 2. The right column of Figure 3 is under the heading "Holder". An example of a holder calculation system is... Figure 2 The holder of the computing system 220.

[0028] In Figure 3, the publisher's computational system generates a certificate that includes name-value pairs, where the value points to the network location where the remote value is stored (Action 311). In one example, a Uniform Resource Locator (URL) is used to identify the network location. The remote value stored at the network location is a value that changes over time.

[0029] Figure 5 The illustration shows an environment 500 including verifiable credentials 501 and a network location 530, and will be used for illustration. Figure 3 Method 300 and Figure 4 An illustrative example of method 400. Similar to... Figure 1 Verifiable credentials 100 Figure 1 As shown, the verifiable credential 501 includes a statement and a proof instruction. For example, the verifiable credential 501 includes a statement 510 and a proof instruction 520 for proving the statement 510.

[0030] Furthermore, in this example, declaration 510 includes static declarations 511 and 512 (in... Figure 5 (Represented by rectangles in the diagram), where the value of each claim does not change unless the verifiable credential is replaced or revoked. For example, if the issuer is a baseball league, a static claim might be that a specific person is a player in the baseball league. Such a claim will not change unless the verifiable credential itself is replaced or revoked. For example, once that person is no longer a player in the baseball league, the verifiable credential will be revoked, causing verification of the verifiable credential to fail even if Proof Directive 520 is followed.

[0031] However, with Figure 1The verifiable credential 100 is quite different. Claim 510 also includes claim 513 having a name-value pair 514 (including name 514A and value 514B), where value 514B points to a network location 530 (identified by a Uniform Resource Locator) that stores value 531. This value 531 is referred to herein as a “remote value” because it is not within claim 513 itself, but is stored at network location 530, which is pointed to only by value 514B within claim 514 (as indicated by arrow 540).

[0032] Although the network location 530 pointed to by value 514B remains unchanged, the remote value 530 within network location 530 is likely to change over time without replacing the verifiable credential 501. Therefore, claim 513 will also be referred to hereinafter as a "dynamic claim" and symbolically represented by a claim 513 with an elliptical shape. Thus, to change a claim being made, the publisher does not republish the verifiable credential, but instead changes the value 531 stored in network location 530. Network location 530 is trusted by the publisher to store the value of the claim made by the publisher, for example, in... Figure 2 The registration computing system 240, or a website hosted by the publisher or otherwise trusted. A verifiable credential with at least one dynamic claim will also be referred to herein as a "dynamic certificate".

[0033] By issuing dynamic credentials, publishers can reduce the number of times they need to issue verifiable credentials and can make claims about dynamically changing things. For example, remote values ​​can store batting averages or other dynamically changing performance statistics of players, players' career goals, players' injury status, and other values ​​that do not require the baseball league to reissue verifiable credentials.

[0034] Returning to Figure 3, the publisher computing system generates a dynamic credential (Action 311), stores the initial remote value in the network location (Action 312), and provides the dynamic credential to the holder computing system (Action 313). The holder computing system then receives the dynamic credential (Action 321) and stores it (Action 322).

[0035] Figure 4 The diagram illustrates a flowchart of method 400 for verifying certificates, including dynamically claimed certificates, based on the principles described herein. An example of such a certificate is... Figure 5 The dynamic certificate 500. Therefore, it will now be referenced. Figure 5 The illustrative example of dynamic certificate 500 is used to describe method 400.

[0036] The actions performed by the holder computing system are indicated under the heading "Holder" in the left column of Figure 4. An example of such a holder computing system is the same system that receives dynamic credentials in action 321 of Figure 3 and stores them in action 322 of Figure 3. Now, in Figure 4, the holder computing system presents the dynamic credentials of the validator computing system. The actions performed by the validator computing system to verify the dynamic credentials are indicated under the heading "Validator" in the right column of Figure 4. In one example, the holder computing system is... Figure 2 The holder computing system 220, the validator system is Figure 2 The verifier computing system 230.

[0037] The validator computation system and the holder computation system collaborate (as indicated by bidirectional arrow 401) to enable the validator computation system to identify verifiable claims that can be presented by the holder computation system (action 421). As an example, the holder computation system publishes the identity of verifiable claims that can be presented by the holder computation system (action 411). In the example of Figure 5, it is assumed that the validator computation system identifies claim 513 (i.e., dynamic claim) that can be presented by the holder computation system.

[0038] Next, the verifier computation system determines that at least one claim has been obtained (action 422). The remainder of method 400 assumes that this includes at least one dynamic claim (e.g., Figure 5 The dynamic claim 513). The validator computing system then requests the holder computing system to present the corresponding verifiable claim (action 423). The holder computing system receives the request (action 424) and, in response, presents the verifiable credential with the requested claim to the validator computing system (action 413). The validator computing system then accesses the verifiable credential (action 424). In the example shown, the verifiable claim accessed is the dynamic credential 501 of Figure 5.

[0039] In response to accessing verifiable credentials, the validator computation system follows proof instructions to prove each claim (action 425). In this example, the validator computation system follows proof instruction 520 to verify that claim 510 was issued by the publisher and has not been tampered with since the publisher issued claim 510. This verification includes verifying dynamic claim 513. At this point, the validator computation system has proven that the publisher issued claim 513, which includes a name 514A and an identifier 514B for network location 530. As an example, suppose claim 513 relates to a player's batting average. Claim 513 could have a name 514A "batting average" and a value 514B representing a network location (e.g., network location 530 in Figure 3). Therefore, at this point, the validator computation system has proven that for a name, its value can be found in the named network location.

[0040] Therefore, in order to complete the understanding of statement 513, the validator computation system executes the content of dashed box 430. Specifically, the validator computation system obtains the remote value from the network location. (See reference) Figure 5 The validator calculates the network address 514B, which is the value of the name-value pair 514, to navigate to network location 530 and retrieve the remote value 531 stored at network location 530. In the batting average example, the validator calculates the system to retrieve the player's batting average.

[0041] The validator calculation system then associates the remote value with the name of the name-value pair (Action 432). As an example, regarding dynamic claims, the validator calculation system treats the name as having a retrieved remote value, rather than treating the name as the original value. Therefore, in the average batting average example, the validator calculation system treats the name "average batting average" as being associated with the actual average batting average retrieved remotely. The validator calculation system then acts to accept the name as having a remote value (Action 433). As an example, the validator calculation system is the batting coach's calculation system, and the batting coach then tailors batting drills for players based on current statistics.

[0042] The content of box 430 is repeatable because the value stored at the network location changes. As an example, a baseball player's average batting average changes in each game. Therefore, the same verifiable credentials are used to retrieve the remote value from the same network location the next time (action 431). In the average batting average example, the remote value is the updated average batting average since the last execution of the content of box 430. The new remote value (e.g., the updated average batting average) is then associated with a name (e.g., "average batting average") (action 432), and then dependent on the new remote value (action 433). Therefore, the declared value is dynamic because it is updated without having to republish the verifiable credentials used to make the declaration.

[0043] Method 300 is executed by the computing system, for example, for... Figure 3 The left column shows the publisher's calculation system for the behavior, and the system targeting... Figure 3 The right column shows the holder computation system for the behavior. Method 400 also consists of computation systems, such as the holder computation system for the behavior in the left column of Figure 4, and the validator computation system for the behavior in the right column of Figure 4. The structure of each publisher computation system, holder computation system, and validator computation system is similar to the following... Figure 13 The computing system 1300 is described.

[0044] In that case, in response to at least one hardware processing unit 1302 executing computer-executable instructions stored in memory 1304, computing system 1300 executes corresponding portions of method 300 and / or method 400. Therefore, the computer-executable instructions are specifically structured to enable computing system 1300 to execute corresponding portions of method 300 and / or method 400. In one embodiment, method 300 is executed by the holding computing system, for example... Figure 2 The holder of the computing system 220.

[0045] The following describes an example publisher experience associated with generating verifiable credentials with reference to Figures 7A through 8F. The following describes an example holder experience associated with presenting verifiable credentials with reference to Figures 9A through 10C. While verifiable credentials do not need to be in a portable identity card, in some embodiments, verifiable credentials are represented within the portable identity card. Therefore, reference will now be made to… Figures 6 to 10C Describe the portable ID card and related user experience.

[0046] Figure 6 The diagram illustrates data structure 600, an example of how a portable identity card is represented in the storage and / or memory of a claim holder's computing system. Portable identity card data structure 600 includes a verifiable credential 610 and usage data 620 for that verifiable credential. Verifiable credential 610 includes one or more claims 611 and verification instructions 612 for verifying the integrity of the claim and verifying that the claim was made by the issuer identified in the claim. Therefore, in one example, verifiable credential 610 is... Figure 1 Verifiable credentials 100.

[0047] In the sense that the portable identity card data structure 600 is used to access the verifiable credential 610, the verifiable credential 610 is included within the portable identity card data structure 600. In one example, the verifiable credential 610 is explicitly included within the portable identity card data structure 600. Alternatively, the verifiable credential 610 is referenced within the portable identity card data structure 600. As an example, the portable identity card data structure 600 includes a pointer (or identifier) ​​to the verifiable credential.

[0048] The same applies to usage data 620. That is, in one example, usage data 620 is included in the portable identity card data structure 600 in the sense that it is used by the portable identity card data structure 600 to access usage data 620. In one example, usage data 620 is explicitly included in the portable identity card data structure 600. Alternatively, usage data 620 is referenced in the portable identity card data structure 600. As an example, the portable identity card data structure 600 includes a pointer (or identifier) ​​to usage data 620.

[0049] Usage data 620 includes any historical information about how verifiable credentials are used. As an example, usage data includes the frequency with which verifiable credentials are exposed to dependent computing systems, the identity of the last dependent computing system to which the verifiable credentials were exposed, the time of the last exposure of the verifiable credentials, the device used to present the verifiable credentials, etc.

[0050] Verifiable credentials 610 are stored on the holder's computing system, for example Figure 2 The holder 220. Alternatively, the verifiable credential 610 can be stored in a manner accessible to multiple different holder computing systems, each under the control of the same holder. As an example, the verifiable credential 610 can be stored in a centralized location or in a decentralized distributed ledger, such as in a decentralized identifier (DID) document. As described below with respect to Figure 9, the contents of the DID document can be accessed using the decentralized identifier (DID). Therefore, in this embodiment, the holder computing system accesses the verifiable credential 610 from any holder computing system controlled by the holder by using the holder's DID.

[0051] The portable identity card data structure 600 is stored on the holder's computing system, for example... Figure 2 Holder 220. Alternatively, the portable identity card data structure 600 is stored in a manner accessible by multiple different holder computing systems, each under the control of the same holder. As an example, the portable identity card data structure 600 can be stored in a centralized location or in a decentralized distributed ledger, such as a decentralized identifier (DID) document. Thus, in this embodiment, the holder computing system accesses the portable identity card data structure 600 from any holder computing system controlled by the holder by using the holder's DID.

[0052] Therefore, the portable identity card data structure 600, along with the associated verifiable credential 610 and its usage data 620, is available on the holder's various computing systems or devices. Thus, the holder can present the portable identity card from a wide variety of devices and also track the use of the verifiable credential, even though it is presented from various systems or devices controlled by the holder. The holder can also provide verifiable credentials from outside any given trust scope (e.g., outside a corporate network), as the portable identity card can be securely accessed from any of the holder's devices.

[0053] Now regarding Figures 7A to 10CThe user interface describes an example use case for the portable identity card. In this particular use case, the issuer is a fictitious baseball league called the Contoso Baseball League (or simply "Contoso"), which issues verifiable credentials to players within that league. Furthermore, the holder is a player in the Contoso Baseball League (referred to as John Doe in the example). The verifiers are various partners (referred to as Partner A, Partner B, etc.) that provide benefits to players in the Contoso Baseball League.

[0054] exist Figures 7A to 7F In this process, the publisher creates a portable identity card template, which is used to create a portable identity card for each player who authenticates with the publisher and requests their own portable identity card.

[0055] exist Figure 7A In the process, the publisher computing system presents a user interface 700A to the publisher, allowing the publisher to begin the process of creating a portable identity card template. The initial user interface 700A displays the front area 701 of the card, which the publisher will interact with to fill the front of the portable identity card template, the back area 702 of the card, which the publisher will interact with to fill the back of the portable identity card template, and a card preview control 703, which the publisher can interact with to view a preview of the portable identity card template so far.

[0056] The front area 701 of the card includes a card type area 711, which displays the type of the portable identity card template. The front area 701 also includes an object name area 712, which displays the object for which the publisher will make a claim on the portable identity card. In this example, the object name will be the player's name and will remain unfilled in the portable identity card template. The object name will only be filled into the corresponding portable identity card when the player authenticates with the publisher and requests their respective portable identity card. The front area 701 also includes a publisher logo area 713 that displays the publisher's logo, and a publisher identity area 714 that displays the publisher's identity. The front area 701 also includes an editing control 715, which the publisher will select to begin filling areas 711, 713, and 714 on the front of the portable identity card template.

[0057] The back area 702 of the card includes a data source area 721A, which represents a data source from which data is extracted to create a portable identity card from the portable identity card template. The publisher initiates the selection of a data source by first activating the Select Data Source control 721B. The back area 702 also includes a benefits area 722A, which displays any card benefits the holder will have. The publisher initiates the identification of these benefits by first activating the Add Card Benefits control 722B. The back area 702 also includes a publisher verification area 723A, with which the publisher interacts to verify the publisher's identity by first activating the Verify Your Organization control 723B.

[0058] Figure 7B The user interface 700B that appears after the publisher selects the edit control 715 to display the card front details window 730 is shown. To emphasize that the publisher is entering information from the front of the card, the card front area 701 is highlighted. In the card front details window 730, the publisher enters the pattern (or type) of the portable identity card (in this case, the verified player) in the pattern input field 731, the publisher's name in the publisher name field 732, the name of the file identifying the publisher's logo file in the icon field 733, the card category in the card category field 734, and the card instance in the card instance field 735. The publisher saves this information by selecting the close control 736 to close the card front details window 730. Alternatively, the publisher discards the entered information and closes the card front details window 730 by selecting the cancel control 737.

[0059] Figure 7C This shows when the publisher selects... Figure 7B The user interface 700C appears when the save control 736 is selected and subsequently the select data source control 721B is activated. Selecting the save control 736 causes the card front area 701 to now be filled with the card type "Verified Player," the publisher logo (here, the logo of the fictional baseball league Contoso), and the publisher name "Contoso." At this stage, the object name remains unfilled because this portable ID card template will be used to create multiple portable ID cards for multiple objects (baseball players in this example). Selecting the select data source control 721B opens the card back data window 740. To emphasize that the publisher is now working to identify the data source to be used to populate the portable ID cards, the data source area 721A is highlighted.

[0060] In the data window 740 on the back of the card, the issuing institution enters the type of data source (here, JWT or JSON Web Token) in the dropdown field 741, the accepted issuing institution value in the accepted issuing institution value field 742, and the resource identifier in the source JSON Web Token Uniform Source JWKs URI field 743. The accepted publisher value is the source accepted by the publisher as the exact data for submitting the claim. Later, when a player requests a portable identity card, the data source will be used to populate the claim identified by the publisher in the card content field 744. Therefore, the player's verifiable credentials will include those claims identified in the card content field 744.

[0061] In this example, the publisher specifies in field 744A that the certificate will include a statement of type player_bday from the birthday field (the player's birthday selected from a dropdown menu of various statement types), with the data type being the date resource of the selected data. Additionally, the publisher specifies in field 744B that the certificate will include a statement of type player_first from the name field (the player's name selected from a dropdown menu), which has a data type string with a maximum length of 60. The publisher specifies in field 744C that the certificate will include a statement of type player_last from the last name field (the player's last name from a dropdown menu), also a string type with a maximum length of 60. If the certificate will include further statements, the user can optionally add field control 745. Therefore, field 744 indicates which data will be extracted and in what form when the statements are actually generated when creating each corresponding portable ID card from the portable ID card template.

[0062] Figure 7D The user interface 700D is displayed when the Add Card Rights control 722B in the rights area 722A of the card back area 702 has been selected. This allows information from the card back data window 740 to be saved as a data source and used to generate subsequent portable identity card claims from the portable identity card template. The completion of the data source input is now indicated by a check mark in the data source area 721A, and other highlights are now removed from the data source area 721A.

[0063] Selecting the Add Card Benefits control 722B also causes the Benefits area 722A to be highlighted, and the Card Return Benefits window 750 to appear. Here, the publisher identifies a human-readable benefit description in field 751 and also identifies a partner application (for the corresponding holder to use a portable ID card's partner or service) in the Partner Application field 752. The publisher can then choose to save the benefits to the portable ID card template using the Save control 753 or select the Cancel control 754 to cancel the entry of these benefits without saving them to the portable ID card template. In our example, we assume the publisher uses the Save control 753 to save the benefits.

[0064] In the user interface 700E of Figure 7E, the publisher has now selected the Authenticate Your Organization control 723B in the Publisher Authenticate area 723A on the back of the card 702. This causes the Publisher Authenticate area 723A to be highlighted and the Publisher Authenticate window 760 on the back of the card to appear. The completion of the rights information input in the rights area 722A is also indicated by the rights area 722A containing a check mark. The publisher then enters the Decentralized Identity (DID) type called ION in the drop-down field 761, the Key Store Identity (here "Key Store A") in the Key Store drop-down field 762, the Web Domain field 763, and the Revocation Method for revoking the verifiable credentials in the Revocation drop-down field 764. The publisher then selects the Save control 765 to save these publisher authentication details, or selects the Cancel control 766 to cancel the input of these rights without saving them on the identity card they want to carry with them.

[0065] In our example, we assume that the publisher has already saved the verification details using the save control 765. Figure 7F The results interface 700F is displayed, which now shows all detail windows closed and the publisher verification field with a checkmark. The publisher's calculation system responds by creating a portable identity card template data structure, which can now be used to create portable identity cards for individual holders (e.g., players) after they have authenticated with the publisher.

[0066] Now regarding Figures 8A to 8F Example of user interface description for holder user experience. Figure 8A The illustration shows user interface 800A, in which the holder (in this case, a Contoso Baseball League player) logs into the player data homepage provided by the publisher (in this case, the Contoso Baseball League).

[0067] Figure 8BThe image shows interface 800B displayed to the player after authentication. It displays basic player information (name, player ID, team, status, position) and a QR code allowing the player to download another authenticator. In this hypothetical example, the Contoso Baseball League player logging into the publisher portal is named "John Doe".

[0068] In the user interface 800C of Figure 8C, the player (John Doe) is given the option to scan a QR code to add or share (i.e., present) credentials. Recall that a portable identity card template was created in Figures 7A through 7F, which was specifically used to create portable identity cards for Contoso baseball players like John Doe. Therefore, when the player scans the QR code in Figure 8C, the portable identity card template is used to create the portable identity card data structure using John Doe's information. This includes creating a verifiable credential with a specified statement about John Doe. Furthermore, as shown in the user interface 800D of Figure 8D, a visualization of the front of the portable identity card is presented to John Doe, now filled with John Doe's name.

[0069] Assuming John Doe is Figure 8D In the user interface 800D, the "Add Card" control is selected. The verified player portable ID card is then added to John Doe's available portable ID cards. Furthermore, player John Doe can now interact with the portable ID card, as shown in the user interface 800E of Figure 8E. As an example, the user selects control 801 to view card details, such as... Figure 8F The user interface is shown in Figure 800F. Players can see their name, baseball player ID, their status, the partners to whom they can present their portable ID cards, and the issuer's identifier. Players can now present their portable ID cards to any identified partner.

[0070] exist Figures 9A to 9C In the example, the player presents a portable identity card to a validator (or dependent party), who is one of the partners listed on the portable identity card. When John Doe from Figure 8E When his portable ID card is selected in the user interface of the 800E, it is displayed. Figure 9A User interface 900A is presented to John Doe. Player John Doe scans the QR code to obtain user interface 900B (Figure 9B). Then, user interface 900C or... Figure 9CThe user selects an "Allow" control to present a verifiable credential (or associated verification presentation) associated with the portable identity card to Partner A. When the verifiable credential is presented to Partner A, Partner A's computing system follows verification instructions (which may include contacting the issuing computing system or the registration computing system) to verify the verifiable credential.

[0071] This process might be repeated multiple times for John Doe for many different publishers. For example, Partner A might be a dependent, but also a publisher. Therefore, in addition to providing a verifiable claim to Partner A, Partner A could also provide John Doe with another portable identity card.

[0072] Figure 10A illustrates a user interface 1000A that shows John Doe a stack of two portable identity cards—a verified player portable identity card provided by the Contoso Baseball League, and a data manager portable identity card provided by Partner A. Assume the user interface for the player portable identity card is used to view the transaction history associated with the verifiable credentials of that portable identity card. Then, John Doe is shown the user interface 1000B of Figure 10B, displaying several transactions between the card and Partner A's data manager application. Figure 10C illustrates the user interface 1000C that allows John Doe to see which partners have been authorized to access the verified player portable identity card, and potentially revoke access.

[0073] The principles described here can be implemented in a decentralized environment. As an example, the holder computation system could be a digital wallet, such as the one discussed below. Figure 12 The DID management module 1220 is described. Alternatively or additionally, the declared object 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, decentralized identifiers will first be described with reference to Figures 11 and 12.

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

[0075] The DID owner 1101 can be any entity that can benefit from a digital identity. For example, the DID owner 1101 can be a person or an organization of a person. Such organizations may include corporations, departments, governments, agencies, or any other organization or group of organizations. Each person may have one DID, and the organization to which each person belongs may also have one DID.

[0076] DID owner 1101 may alternatively be a machine, system, or device, or a collection of machines, devices, and / or systems. In other embodiments, DID owner 1101 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. The DID owner may also be a software component, such as those mentioned above. Figure 13 The executable component 1306 is described. An example of a complex executable component 1306 could be artificial intelligence. Therefore, artificial intelligence might also have a DID.

[0077] Therefore, DID owner 1101 can be any entity, human or non-human, capable of creating DID 1105 or having at least DID 1105 created for and / or associated with them. Although DID owner 1101 is shown to have a single DID 1105, this is not necessarily the case, as any number of DIDs can be associated with DID owner 1101 when circumstances permit.

[0078] As mentioned, DID owner 1101 can create and register DID 1105. DID 1105 can be any identifier that can be associated with DID owner 1101. Preferably, the identifier is unique to the DID owner 1101 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 1105 can be a Uniform Resource Identifier (URI) (e.g., Uniform Resource Locator (URL)) or other pointer that associates DID owner 1101 with a mechanism involved in trusted interactions with DID owner 1101.

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

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

[0081] As shown in Figure 11, DID owner 1101 controls the private key 1106 and public key 1107 pair associated with DID 1105. Because DID 1105 is independent of any central authority, private key 1106 should always be fully controlled by DID owner 1101. 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 1101.

[0082] As will be described in more detail below, the private key 1106 and public key 1107 pair can be generated on a device controlled by DID owner 1101. The private key 1106 and public key 1107 pair should not be generated on a server controlled by DID owner 1101, as this could result in the private key 1106 and public key 1107 pair not always being fully under the control of DID owner 1101. Although Figure 11 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.

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

[0084] DID document 1110 also includes a public key 1107 or some other equivalent cryptographic information created by DID owner 1101. Public key 1107 can be used by third-party entities authorized by DID owner 1101 to access information and data owned by DID owner 1101. Public key 1107 can also be used to verify that DID owner 1101 actually owns or controls DID 1105.

[0085] DID document 1110 may also include authentication information 1111. Authentication information 1111 specifies one or more mechanisms by which DID owner 1101 can prove that DID owner 1101 owns DID 1105. In other words, the authentication information mechanism 1111 demonstrates proof of the binding between DID 1105 (and therefore its DID owner 1101) and DID document 1110. In one embodiment, authentication information 1111 specifies a public key 1107 for signing operations to prove ownership of DID 1105. Alternatively or additionally, authentication information 1111 specifies a public key 1107 for biometric operations to prove ownership of DID 1105. Therefore, authentication information 1111 includes any number of mechanisms by which DID owner 1101 can prove that DID owner 1101 owns DID 1105.

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

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

[0088] DID document 1110 also includes one or more service endpoints 1113. A service endpoint includes a network address representing a service operating on behalf of DID owner 1101. 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 1113 serves as a pointer to a service operating on behalf of DID owner 1101. DID owner 1101 or a third-party entity can use these pointers to access the service operating on behalf of DID owner 1101. Specific instances of service endpoint 1113 will be described in more detail below.

[0089] DID document 1110 also includes identity information 1114. Identity information 1114 includes personally identifiable information, such as the name, address, occupation, family members, age, hobbies, and interests of DID owner 1101. Therefore, the DID owner 1101 listed in DID document 1110 represents different roles of DID owner 1101 for different purposes.

[0090] The role can be pseudo-anonymous. As an example, DID owner 1101 might include a pseudonym in the DID document when identifying him or her as an author of articles published on a blog. The role can also be completely anonymous. For example, DID owner 1101 might only want to disclose his or her job title or other background data (e.g., school teacher, FBI agent, adult over 21, etc.) rather than his or her name in the DID document. As yet another example, the role can be specific to DID owner 1101 as an individual. As an example, DID owner 1101 could include information identifying him or her as a volunteer for a specific charity, an employee of a specific company, a recipient of a specific award, etc.

[0091] DID document 1110 also includes credential information 1115, which may also be referred to herein as proof. Credential information 1115 can be any information associated with the background of DID owner 1101. For example, credential information 1115 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 about the background of DID owner 1101.

[0092] DID document 1110 also includes various other information 1116. In some embodiments, the other information 1116 may include metadata specifying when the DID document 1110 was created and / or when it was last modified. In other embodiments, the other information 1116 may include a cryptographic proof document 1110 of the DID's integrity. In a further embodiment, the other information 1116 may include additional information specified by a particular method of implementing the DID document or expected by the DID owner 1101.

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

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

[0095] The representation of DID 1105 is stored on each distributed computing system of the distributed ledger 1120. For example, in Figure 11 In this context, this is shown as DID hash 1131, DID hash 1141, and DID hash 1151, which ideally are identical hash copies of the same DID. DID hash 1131, DID hash 1141, and DID hash 1151 point to the location of DID document 1110. The distributed ledger or blockchain 1120 can also store many other representations of other DIDs, such as references 1132, 1133, 1134, 1142, 1143, 1144, 1152, 1153, and 1154.

[0096] In one embodiment, when DID owner 1101 creates DID 1105 and the associated DID document 1110, DID hashes 1131, 1141, and 1151 are written to distributed ledger 1120. Distributed ledger 1120 thus records that DID 1105 now exists. Because distributed ledger 1120 is decentralized, DID 1105 is not controlled by any entity other than DID owner 1101. In addition to pointers to the DID, DID hashes 1131, 1141, and 1151 may each include document 1110, a record or timestamp specifying when DID 1105 was created. Later, when modifications are made to DID document 1110, each modification (and possibly a timestamp of the modification) is also recorded in DID hash 1131, DID hash 1141, and DID hash 1151. DID hash 1131, DID hash 1141, and DID hash 1151 may also include a copy of public key 1107 so that DID 1105 is cryptographically bound to DID document 1110.

[0097] Having described DID and its general operation with reference to Figure 11, a specific embodiment of a DID environment will now be explained with reference to Figure 12. Figure 12 illustrates an example environment 1200 that can be used to perform various DID management operations and services, which will now be explained. It should be understood that... Figure 12 The environment can be referenced as needed. Figure 11 The elements in the text are for easy interpretation.

[0098] like Figure 12 As shown, environment 1200 includes various devices and computing systems owned or controlled by DID owner 1101. These may include user device 1201. User device 1201 may be, but is not limited to, mobile devices (e.g., smartphones), computing devices (e.g., laptops), or any device (e.g., a car or an appliance with computing capabilities). Device 1201 includes a web browser 1202 running on the device and an operating system 1203 running the device. More broadly, the dashed line 1204 indicates that all these devices may be owned or controlled by DID owner 1101.

[0099] Environment 1200 also includes a DID management module 1220. In operation, as indicated by the respective arrows 1201a, 1202a, and 1203a, the DID management module 1220 resides in the user device 1201, the web browser 1202, and the operating system 1203. Therefore, for ease of illustration, the DID management module 1220 is shown as separate. The DID management module 1220 can also be described as a "wallet" because it can store various claims made by or about a specific DID. In one example, the structure of the DID management module 1220 is as described above for executable component 1306.

[0100] As shown in Figure 12, the DID management module 1220 includes a DID creation module 1230. The DID owner 1101 can use the DID creation module 1230 to create DID 1105 or any number of additional DIDs, such as DID 1231. In an embodiment, the DID creation module may include or otherwise access a user interface (UI) element 1235 that can guide the DID owner 1101 in creating DID 1105. The DID creation module 1230 has one or more drivers configured to work with a specific distributed ledger, such as distributed ledger 1120, so that DID 1105 conforms to the underlying methods of that distributed ledger.

[0101] A specific embodiment will now be described. For example, UI 1235 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 1105. As previously mentioned, DID 1105 can be a long string of random numbers and letters, so having a human-recognizable name for the display name may be advantageous. DID creation module 1230 can then generate DID 1105. In an embodiment with UI 1235, DID 1105 can be displayed in an identity list and can be associated with a human-recognizable name.

[0102] The DID creation module 1230 may also include a key generation module 1250. The key generation module can generate the previously described private key 1106 and public key 1107 pair. The DID creation module 1230 can then use the DID 1105 and the private and public key pair to generate a DID document 1110.

[0103] In operation, the DID creation module 1230 accesses a registrar 1210 configured to record transactions associated with DID 1105 in a specific distributed ledger. The DID creation module 1230 uses the registrar 1210 to record DID hashes 1131, 1141, and 1151 stored in the distributed ledger as described above, and to store the DID document 1110 as described above. This process may utilize the public key 1107 in hash generation.

[0104] In some embodiments, the DID management module 1220 may include an ownership module 1240. The ownership module 1240 can provide a mechanism to ensure that the DID owner 1101 has sole control over the DID 1105. In this way, the provider 1220 of the DID management module can ensure that the provider does not control the DID 1105, but only provides management services.

[0105] Key generation module 1250 generates a private key 1106 and a public key 1107 pair, and then records the public key 1107 in DID document 1110. Therefore, all devices associated with DID owner 1101, as well as all third parties wishing to provide services to DID owner 1101, use public key 1107. Thus, when DID owner 1101 wishes to associate a new device with DID 1105, DID owner 1101 can execute DID creation module 1230 on the new device. DID creation module 1230 can then use registrar 1210 to update DID document 1110 to reflect that the new device is now associated with DID 1105; this update will be reflected in transactions on distributed ledger 1120.

[0106] However, in some embodiments, having a public key for each device 1201 owned by the DID owner 1101 may be advantageous, as this allows the DID owner 1101 to sign using a device-specific public key without accessing a general public key. In other words, since the DID owner 1101 will use different devices at different times (e.g., a mobile phone in one instance and a laptop in another), having a key associated with each device to provide efficiency in signing using those keys is advantageous. Therefore, in such embodiments, when the attached device executes the DID creation module 1230, the key generation module 1250 generates additional public keys 1108 and 1109. These additional public keys may be associated with the private key 1106, or in some cases, paired with a new private key.

[0107] In those embodiments where additional public keys 1108 and 1109 are associated with different devices, the additional public keys 1108 and 1109 are recorded in DID document 1110 as associated with which devices, such as... Figure 12 As shown. DID document 1110 may include, in addition to Figure 12 In addition to the information shown (information 1108, 1109, and 1265), the information previously described with respect to Figure 11 (information 1105, 1107, and 1111 to 1116). If DID document 1110 exists publicly before the device-specific key is generated, then DID document 1110 will be updated by creation module 1230 via registrar 1210, which will be reflected in the update transaction on distributed ledger 1120.

[0108] In some embodiments, the DID owner 1101 may wish to keep the association between the device and the public key or the association between the device and DID 1105 confidential. Therefore, the DID creation module 1230 can make such data secretly displayed in the DID file 1110.

[0109] As described above, DID 1105 is already associated with all devices under the control of DID owner 1101, 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 1101 may each have its own DID. Therefore, in some embodiments, DID creation module 1230 may generate an additional DID for each device, such as DID 1231. DID creation module 1230 then generates a private key and public key pair and a DID document for each device. Such embodiments may be advantageous for devices where ownership may change, as the device-specific DID can be associated with the new owner of the device by granting authorization rights in the DID document and revoking those rights from the old owner.

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

[0111] However, the device storing private key 1106 could be lost by DID owner 1101, potentially causing DID owner 1101 to lose access to DID 1105. Therefore, in some embodiments, UI 1235 includes an option to allow DID owner 1101 to export private key 1106 to an off-device secure database 1205 controlled by DID owner 1101. As an example, database 1205 could be one of the identity hubs 1310 described below (Figure 13). Storage module 1280 is configured to store data (e.g., private key 1106 or proof made by or about DID owner 1101) off-device in database 1205 or identity hub 1310. In some embodiments, private key 1106 is stored as a QR code scanned by DID owner 1101.

[0112] In other embodiments, the DID management module 1220 may include a recovery module 1260 that can be used to recover a lost private key 1106. In operation, the recovery module 1260 allows the DID owner 1101 to select one or more recovery mechanisms 1265 at that time, which DID 1105 is created and can later be used to recover the lost private key. In those embodiments with a UI 1235, the UI 1235 may allow the DID owner 1101 to provide information that will be used by one or more recovery mechanisms 1265 during recovery. The recovery module 1260 can then be run on any device associated with DID 1105.

[0113] The device under DID 1105 is not associated with DID 1105. In one embodiment, the revocation module 1270 accesses DID document 1110 and causes all references to the device to be removed from DID document 1110. Alternatively, the device's public key can be deleted, and this change is then reflected in DID document 1110, which can then be reflected as an update transaction on distributed ledger 1120.

[0114] Since the principles described in this article are performed within the context of a computing system, reference will be made to... Figure 13 This section provides an introductory discussion of the computational system. The document then returns to the principles of the Distributed Identifier (DID) platform, which is relevant to the rest of the graph.

[0115] 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.

[0116] like Figure 13As shown, in its most basic configuration, the computing system 1300 includes at least one hardware processing unit 1302 and a memory 1304. The processing unit 1302 includes a general-purpose processor. Although not strictly necessary, the processing unit 1302 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 capabilities may also be distributed.

[0117] The computing system 1300 also has several structures thereon, commonly referred to as "executable components." For example, the memory 1304 of the computing system 1300 is shown as including executable component 1306. 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 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.

[0118] 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 is capable of performing a certain function. This structure can be directly readable by the processor on the computer (as is the case if the executable component is binary). Alternatively, the structure can be constructed to be interpreted and / or compiled (whether in a single stage or in multiple stages) to produce such a binary file that the processor can directly interpret. This understanding of the exemplary 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.

[0119] The term "executable component" is also well understood by a person of ordinary skill in the art to include structures such as hard-coded or hard-wired logic gates that 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 a person of ordinary skill in the field of computing, whether implemented in software, hardware, or a combination thereof. In this specification, 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 possess the skills of a person of ordinary skill in the art of computer architecture regarding structural design.

[0120] 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 relevant computing system performing the action) instruct the operation of the computing system in response to the execution of 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 behavior is 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 manipulation data) may be stored in memory 1304 of computing system 1300. Computing system 1300 may also include a communication channel 1308 that allows computing system 1300 to communicate with other computing systems via, for example, network 1310.

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

[0122] 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, as discussed in more detail below. 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.

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

[0124] 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 via a network or other means, the computing system correctly regards the connection (wired, wireless, or a combination of wired and wireless) 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 may be accessible by general-purpose or special-purpose computing systems. Combinations of the above should also be included within the scope of computer-readable media.

[0125] 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 within 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.

[0126] Computer-executable instructions include, for example, instructions and data that, 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 files 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.

[0127] Although the subject matter has been described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter 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.

[0128] 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 both 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.

[0129] 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, but 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.

[0130] 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.

[0131] 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 computational system for verifying verifiable credentials including dynamically claimed credentials, the computational system comprising: One or more processors; as well as One or more computer-readable media having computer-executable instructions thereon, the computer-executable instructions being executable by the one or more processors to cause the computing system to perform the following operations: Access to a verifiable credential presented by a claim-holding computing system, the verifiable credential including a claim identifying an attribute and an object, wherein the object is an identified network location storing a remote value of the attribute, and wherein the issuer of the claim grants the holder of the claim the right to access the identified network location to retrieve the remote value, the verifiable credential also including instructions for authenticating the claim; as well as In response to accessing the verifiable credentials The statement is thus proven by following the instructions; Access the identified network location to retrieve the first remote value; Associating the first remote value with the attribute, such that the computing system accepts the attribute as having the first remote value to replace the object, wherein the access to the network location and the retrieval of the first remote value are occurring for the first time; In a second instance following the first instance, the identified network location is accessed to retrieve a second remote value, wherein the second remote value obtained in the second instance is different from the first remote value obtained in the first instance; as well as The second remote value is associated with the attribute such that the computing system accepts the attribute as having the second remote value in place of the object.

2. The computing system according to claim 1, wherein the object is a decentralized identifier.

3. The computing system according to claim 1 or claim 2, wherein the computing system further takes the action of accepting the attribute as having the first remote value.

4. The computing system according to claim 1, wherein the identified network location includes a Uniform Resource Locator (URL).

5. The computing system of claim 1, wherein the first remote value stored at the identified network location is a value that changes over time.

6. The computing system of claim 1, wherein the access to the identified network location is performed without the computing system requesting a synchronization request for the first remote value.

7. The computing system of claim 1, wherein the computing system performs the following operations before accessing the verifiable credential: The verifiable credentials are received from the previously claimed holding computing system.

8. A method for verifying a certificate including a dynamically claimed certificate, the method comprising: Access to a verifiable credential presented by a claim-holding computing system, the verifiable credential including a claim identifying an attribute and an object, wherein the object is an identified network location storing a remote value of the attribute, and wherein the issuer of the claim grants the holder of the claim the right to access the identified network location to retrieve the remote value, the verifiable credential also including instructions for authenticating the claim; as well as In response to accessing the verifiable credentials The statement is thus proven by following the instructions; Access the identified network location to retrieve the first remote value; as well as Associating the first remote value with the attribute, such that the computing system accepts the attribute as having the first remote value to replace the object, wherein the first access to the network location and the retrieval of the first remote value occur, the method further includes reusing the verifiable credentials by: In a second instance following the first instance, the identified network location is accessed to retrieve a second remote value, wherein the second remote value obtained in the second instance is different from the first remote value obtained in the first instance; as well as The second remote value is associated with the attribute such that the computing system accepts the attribute as having the second remote value in place of the object.

9. The method according to claim 8, wherein the object is a decentralized identifier.

10. The method of claim 8 or claim 9, further comprising taking an action of accepting the attribute as having the remote value.

11. The method of claim 8, wherein the identified network location includes a Uniform Resource Locator (URL).

12. The method of claim 8, wherein the first remote value stored at the identified network location is a value that changes over time.

13. The method of claim 8, wherein the access to the identified network location to retrieve the second remote value is performed without the computing system requesting a synchronization request for the value.

Images