Presenting verifiable credentials with usage data

Abstract

Presentation of verifiable credentials represented within a data structure that represents the verifiable credentials as well as usage data for the verifiable credentials. Usage of the verifiable credentials is monitored such that as the usage of the verifiable credentials changes or progresses, the stored usage data also changes. This data structure can be used not only to cause a visual representation of the verifiable credentials to be displayed to a user, but the user can selectively cause at least some of this usage data to be presented to the user as well. Thus, a user can easily track how their verifiable credentials are being used, regardless of where the verifiable credentials are presented or from which device they are presented.

Description

BACKGROUND

[0001] A digital identity is a mechanism to track an entity across different digital contexts. After an identity is determined, appropriate actions can be taken on the entity with that identity. For example, the entity can be provided with authorizations, permissions, customizations, and access. Thus, a digital identity is an important mechanism for ensuring that information is restricted within the appropriate trust boundary by appropriately including authorizations and permissions. A digital identity is also an important mechanism for ensuring a positive and consistent user experience when accessing the user’s data and customizations.

[0002] Most of the documents or records that are currently used to prove identity are issued by a central organization, such as a government, a company, a school, an employer, or other service center or regulatory organization. These organizations typically maintain the identity of each member in a centralized identity management system. A centralized identity management system is a centralized information system used by an organization to manage issued identities, identity verification, authorizations, roles, and permissions. Centralized identity management systems are considered secure because they typically use professionally maintained hardware and software. Often, the identity-issuing organization will set the terms and requirements for registering a person in the organization. When a party needs to verify the identity of another party, the verifying party often needs to go through the centralized identity management system to obtain information that verifies and / or authenticates the other party’s identity.

[0003] A decentralized identifier (DID) is a newer type of identifier. A decentralized identifier is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (e.g., blockchain) provides an opportunity to use a fully decentralized identifier. Distributed ledger technology uses a distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, it is not possible to change the data in that portion of the ledger retroactively without changing all subsequent portions of the ledger. This provides a fairly secure platform in which it is difficult or impossible to tamper with data recorded in the distributed ledger. Since a DID is typically not controlled by a centralized management system, but is owned by the owner of the DID, a DID is sometimes referred to as a permissionless identity.

[0004] The subject matter claimed herein is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided only to illustrate one example technology area where some embodiments described herein can be practiced. SUMMARY

[0005] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

[0006] Existing computing technology provides a data structure known as a "verifiable credential." In these technologies, a claim issuer makes one or more claims about a subject and generates a verifiable credential. The verifiable credential includes those claim(s) as well as proof instructions (e.g., metadata) to prove that the claim(s) have not been tampered with and were indeed issued by the claim issuer. The claim issuer then provides the verifiable credential to a claim holder to provide to any relying party that relies on the authenticity of the claims.

[0007] For example, the claim issuer can be a computing system associated with a government agency responsible for issuing driver's licenses. The government agency can generate a verifiable credential containing claims about a citizen, such as date of birth, residential address, weight, eye color, hair color, driving authorization, driving authorization restrictions, etc. The government agency issues the verifiable credential to the citizen. If the user is stopped by law enforcement, the citizen can present the verifiable credential, whereby a computing system associated with the law enforcement can use the proof instructions to verify that the claims were issued by the government agency and have not been tampered with since issuance. In another example, an organization that provides vaccinations can issue claims to a child's parents that the child has received certain vaccinations. The parents can then submit these vaccination claims to a school that the child will attend.

[0008] However, the inventors have recognized that the portability of verifiable credentials is important to improving the utility of verifiable credentials. For example, such portability includes the ability to efficiently issue verifiable credentials to multiple holders, as well as the ability of any given holder to use the verifiable credential in different locations, even when presented using multiple devices controlled by the holder. Keeping track of the use of verifiable credentials in this way can become very difficult. However, there is currently no mechanism to track how verifiable credentials are used, much less when multiple devices are used to present the verifiable credential.

[0009] Embodiments disclosed herein relate to the presentation of verifiable credentials that are represented within a data structure that represents the verifiable credential as well as usage data for the verifiable credential. The usage of the verifiable credential is monitored such that as the usage of the verifiable credential changes or progresses, the stored usage data also changes. This data structure can be used not only to cause a visual representation of the verifiable credential to be displayed to a user, but the user can selectively cause at least some of this usage data to also be presented to the user. Thus, the user can easily keep track of how their verifiable credential is being used, regardless of where the verifiable credential is presented or from which device it is presented.

[0010] In some embodiments, the usage data includes a frequency with which the verifiable credential is exposed to relying party computing systems, an identity of a relying party computing system to which the verifiable credential was most recently exposed, and / or a time at which the verifiable credential was most recently exposed. Thus, a user can obtain a comprehensive view of the usage of the verifiable credential over time.

[0011] In some embodiments, at least one of the verifiable claims or some of the verifiable claims can have a subject referenced by the decentralized identifier. Thus, the principles described herein can be used to track usage of verifiable credentials having claims about a decentralized identity.

[0012] In some embodiments, the visual representation of the verifiable credential includes a human-readable visual representation of the attribute names and values of each of one, some, or possibly all of the verifiable claims within the verifiable credential. Alternatively or additionally, the visual representation can include a machine-readable representation of the attribute names and values of each of one, some, or all of the verifiable claims within the verifiable credential, such as a bar code or QR code. Alternatively or additionally, the attestation instructions can also be presented in the visual representation in human-readable or machine-readable form. Thus, even without electronic connection to a computing system or device of the claim holder, a human or even a machine can easily read and interpret what is claimed, and the machine can additionally interpret how to attest that the claim was made by the claim issuer and has not been tampered with since the time the claim was made by the claim issuer.

[0013] Additional features and advantages will be set forth in the description that follows, and in part will be obvious from the description, or can be learned by practice of the teachings herein. Features and advantages of the application will be realized and attained by the instrumentalities particularly pointed out in the appended claims. Features of the present application will become more fully apparent from the following description and appended claims, or can be learned by practice of the application as described in the following description. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to describe the manner in which the above-recited and other features and advantages can be obtained, a brief description of a suitable environment in which the subject matter described herein can be implemented is provided below. Again, the

[0015] Figure 1 A verifiable credential including a plurality of verifiable claims, and attestation instructions for attesting that the claims were made by the issuer are shown;

[0016] Figure 2 Creating and using a verifiable credential (e.g.,Figure 1 an environment for verifiable credentials (e.g., of the type described in the W3C

[0017] Figure 3 A portable identity card data structure is shown, including verifiable credentials and usage data according to the principles described herein;

[0018] Figures 4A-4F A series of user interfaces are shown in which an issuer creates a portable identity card template that will be used to create portable identity cards for various holders;

[0019] Figures 5A-5F A series of user interfaces are shown in which a holder obtains a portable identity card generated from the portable identity card template of Figures 4A-4F

[0020] Figures 6A-6C A series of user interfaces are shown in which a holder presents a portable identity card to a relying party;

[0021] Figures 7A-7C Additional user interfaces are shown that allow a user to manage a portable identity card;

[0022] Figure 8 A flowchart of a method for presenting verifiable credentials according to the principles described herein is shown;

[0023] Figure 9 A flowchart of a method for using a portable identity card data structure according to the principles described herein is shown;

[0024] Figure 10 An example environment for creating a decentralized identifier (DID) is shown;

[0025] Figure 11 An example environment for various DID management operations and services is shown; and

[0026] Figure 12 An example computing system in which the principles described herein can be employed is shown. DETAILED DESCRIPTION

[0027] The principles described herein relate to the use of data structures that include verifiable credentials, as well as usage data for the verifiable credentials. Verifiable credentials are known in the art per se. One conventional implementation of verifiable credentials is described in the document entitled “Verifiable Credentials Data Model 1.0” as a W3C Recommendation of November 19, 2019.

[0028] To introduce the reader to the concept of verifiable credentials, reference will first be made to Figure 1 An example verifiable credential 100 is described. Further, reference will subsequently be made to Figure 2 ​An environment 200 in which verifiable credentials are created and used is described. Then, beyond the concept of a verifiable credential itself and extending to the embodiments herein, reference will be made to Figure 3 A portable identity card that includes verifiable credentials is described. Subsequently, reference will be made to Figures 4 through Figure 7C Examples of use of the portable identity card are described. Thereafter, reference will be made to Figures 8-12 Principles of the embodiments herein are described.

[0029] As used herein, an “issuer” is an entity that makes at least one assertion about a subject. The assertion is also referred to herein as a “claim.” A “credential” is a collection of one or more claims. As used herein, the term “credential” can include claims made by multiple issuers, but the term also applies to a set of claims with a single issuer, as in the example of Figures 4A-7C “Verifiable credentials” are a type of credential in which cryptographic mechanisms, such as digital signatures, are used to detect whether the credential has been tampered with since the date of its issuance and can be used to verify the identity of the credential issuer. The claims within a verifiable credential need not be about the same subject, and the subject of any claim need not be the same as the holder of the verifiable credential.

[0030] Figure 1 A verifiable credential 100 that includes multiple verifiable claims 110 is shown. Although the ellipsis 115 indicates that the verifiable credential 100 can include any number (one or more) of verifiable claims, the verifiable claims 110 are shown as including four verifiable claims 111 through 114. The verifiable credential 100 also includes attestation instructions 120 that are used to verify that the verifiable credential 100 has not been tampered with since the verifiable credential 100 was created by the issuer of the verifiable credential 100 and to verify the identity of the issuer of the verifiable claims 110. An example of attestation instructions is a digital signature of the issuer.

[0031] Figure 2 An environment 200 in which verifiable credentials, such as the verifiable credential 100 of Figure 1 are created and used is shown. The environment 200 includes an issuer computing system 210 that operates within the trust domain of an issuer. Examples of issuers include a company, an organization, an association, a government, an institution, an individual, or any other entity that can make assertions that others can rely on. The issuer performs the role of asserting claims, and the issuer computing system 210 creates verifiable credentials for those claims, such as the verifiable credential 100. Figure 1verifiable credential 100), and causes the issuer computing system 210 to transmit the verifiable credential to the holder computing system 220, as indicated by arrow 201. The issuer computing system 210 can also be referred to herein simply as “issuer 210.” The issuer 210 also transmits the verification identifier and the usage pattern to the registry computing system 240, as indicated by arrow 211.

[0032] As also indicated by arrow 201, the holder computing system 220 obtains the transmitted verifiable credential. The holder computing system 220 operates on behalf of a holder who uses the holder computing system 220 to possess and potentially store the verifiable credential. As indicated by arrow 202, the holder also causes the holder computing system to present the verifiable credential to the verifier computing system 230. The holder computing system 220 can also be referred to herein simply as “holder 220.” The holder 220 also transmits the verification identifier and the usage pattern to the registry computing system 240, as indicated by arrow 212.

[0033] The holder 220 presents the verifiable credential itself, or presents data from the verifiable credential in the form of another data structure, which can 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 is verifiable as to the authorship of the data. If the verifiable credential is presented directly, then they become a verifiable presentation. Data formats derived from verifiable credentials that are cryptographically verifiable but that do not themselves contain verifiable credentials are also included within the definition of a verifiable presentation.

[0034] As also indicated by arrow 202, the verifier computing system 230 obtains the transmitted verifiable credential (optionally within a verifiable presentation). The verifier computing system 230 operates on behalf of a verifier, which is a relying party that relies on one or more statements made in the verifiable credential. The verifier computing system 230 assesses whether the verifiable credential is an unaltered (and unexpired) statement by the issuer 210. This includes following any proof instructions (e.g., proof instructions 120) that exist within the verifiable credential (e.g., verifiable credential 100). The verifier computing system 230 can then take action based on that verification, such as treating the statement(s) made in the verifiable credential as valid and issued by the issuer 210. The verifier computing system 230 is also sometimes referred to herein as “verifier 230.” As part of the verification, the verifier 230 sends the verification identifier and the pattern to the registry computing system 240, as indicated by arrow 213.

[0035] The registry computing system 240 mediates the creation and verification of identifiers, keys, verifiable credential schemas, revocation registries, issuer public keys, and the like. Example verifiable data registries include trusted databases, decentralized databases, and distributed ledgers. Each of the issuer computing system 210, the holder computing system 220, the verifier computing system 230, and the registry computing system 240 are structured as described below with respect to the computing system 1200 of Figure 12

[0036] Thus, Figure 1 and Figure 2 Verifiable credentials and data flows related to the creation and use of verifiable credentials are described. However, the inventors have recognized that the portability of verifiable credentials is important to improving the utility of verifiable credentials. For example, such portability includes the ability to efficiently issue verifiable credentials to multiple holders, as well as the ability of any given holder to use a verifiable credential in different locations, even when the verifiable credential is presented using multiple devices controlled by the holder (e.g., the holder 220). Keeping track of the use of verifiable credentials in this way can become very difficult. However, there are currently no mechanisms to keep track of how verifiable credentials are used, much less when verifiable credentials are used when multiple devices are used to present the verifiable credential.

[0037] Figure 3 A data structure 300 is shown, which represents one example of how a portable identity certificate can be represented in storage and / or memory of a computing system of a declarer holder. The portable identity certificate data structure 300 includes a verifiable credential 310, as well as usage data 320 for that verifiable credential. The verifiable credential 310 includes one or more claims 311, as well as attestation instructions 312 for verifying the integrity of the claims, and verifying that the claims were made by the issuer identified within the claims. Thus, in one example, the verifiable credential 310 is a verifiable credential 100 of Figure 1

[0038] The verifiable credential 310 is included in the portable identity certificate data structure 300 in the sense that the portable identity certificate data structure 300 is used to access the verifiable credential 310. In one example, the verifiable credential 310 is explicitly included within the portable identity certificate. Alternatively, the verifiable credential 310 is referenced in the portable identity certificate data structure 300. As an example, the portable identity certificate data structure 300 includes a pointer to the verifiable credential (or an identifier thereof).

[0039] ​​The same is true of the usage data 320. That is, in one example, the usage data 320 is included in the portable identity certificate data structure 300 in the sense that the portable identity certificate data structure 300 is used to access the usage data 320. In one example, the usage data 320 is explicitly included within the portable identity certificate data structure 300. Alternatively, the usage data 320 is referenced in the portable identity certificate data structure 300. As an example, the portable identity certificate data structure 300 includes a pointer to the usage data 320 (or an identifier thereof).

[0040] The usage data 320 includes any historical information about how the verifiable credential is being used. As an example, the usage data includes a frequency with which the verifiable credential is exposed to relying party computing systems, an identity of a relying party computing system to which the verifiable credential was most recently exposed, a time at which the verifiable credential was most recently exposed, a device used to present the verifiable credential, and so forth.

[0041] The verifiable credential 310 is stored on a holder computing system, such as the holder 220 of Figure 2 . Alternatively, the verifiable credential 310 is stored in a manner that is accessible by multiple different holder computing systems, each of which is under the control of the same holder. As an example, the verifiable credential 310 can be stored in a centralized location or in a decentralized distributed ledger, such as a decentralized identifier (DID) document. As described below with respect to Figure 10 , the contents of the DID document can be accessed by using the decentralized identifier (DID). Thus, in this embodiment, the holder computing system accesses the verifiable credential 310 from any holder computing system that is under the control of the holder by using the holder’s DID.

[0042] The portable identity certificate data structure 300 is stored on a holder computing system, such as the holder 220 of Figure 2 . Alternatively, the portable identity certificate data structure 300 is stored in a manner that is accessible by multiple different holder computing systems, each of which is under the control of the same holder. As an example, the portable identity certificate data structure 300 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 certificate data structure 300 from any holder computing system that is under the control of the holder by using the holder’s DID.

[0043] Accordingly, the portable identity card data structure 300, along with the associated verifiable credential 310 and the usage data 320 for the verifiable credential, is available on different computing systems or devices of the holder. Accordingly, the holder can present the portable identity card from a variety of different devices, and can also track usage of the verifiable credential, despite the verifiable credential being presented from a variety of systems or devices under the control of the holder. The holder can also present the verifiable credential from outside of any given trust boundary (e.g., outside of a corporate network), as any of the devices of the holder device can securely access the portable identity card.

[0044] An example use case for the portable identity card will now be described with reference to a user interface of Figures 4A-7C In this particular use case, the issuer is an imaginary baseball league, called the Contoso Baseball League (or simply “Contoso”), which will issue verifiable credentials to players in the baseball league. In addition, the holder is a player of the Contoso Baseball League (referred to as John Doe in the example). The verifiers are various partners that provide benefits to players of the Contoso Baseball League (referred to as Partner A, Partner B, etc.).

[0045] In Figures 4A-4F , the issuer creates a portable identity card template that is used to create a portable identity card for each player that authenticates to the issuer and requests their respective portable identity card.

[0046] In Figure 4A , the issuer computing system presents the issuer with a user interface 400A that allows the issuer to begin the process of creating a portable identity card template. The initial user interface 400A displays a card front region 401 that the issuer will interact with to fill out the front of the portable identity card template, a card back region 402 that the issuer will interact with to fill out the back of the portable identity card template, and a card preview control 403 that the issuer interacts with to view a preview of the portable identity card template as of the present.

[0047] The card front area 401 includes a card type area 411 that will display the type of portable identity card template. The card front area 401 also includes a subject name area 412 that will display the subject that the issuer will make a statement about on the portable identity card. In this example, the subject name will be the player's name and will remain blank in the portable identity card template. The subject name will only be filled in the respective portable identity card when the player authenticates with the issuer and requests their respective portable identity card. The card front area 401 also includes an issuer logo area 413 that will display the issuer's logo and an issuer identity area 414 that will display the issuer's identity. The card front area 401 also includes an edit control 415 that the issuer will select to begin filling in the areas 411, 413, and 414 of the front of the portable identity card template.

[0048] The card back area 402 includes a data source area 421A that will represent the data source from which data will be extracted for creating a portable identity card from the portable identity card template. The issuer initiates the selection of a data source by first activating the select data source control 421B. The card back area 402 also includes a benefits area 422A that will display any card benefits that the holder will have. The issuer initiates the identification of these benefits by first activating the add card benefits control 422B. The card back area 402 also includes an issuer verification area 423A that the issuer interacts with to authenticate the issuer's identity by first activating the verify your organization control 423B.

[0049] Figure 4B A user interface 400B is shown after the issuer selects the edit control 415, causing the card front details window 430 to appear. To emphasize that the issuer is entering information from the card front, the card front area 401 is highlighted. In this card front details window 430, the issuer enters the mode (or type) of the portable identity card in the mode entry field 431 (in this case, a verified player), the issuer's name in the issuer name field 432, the file name that identifies the logo file for the issuer in the icon field 433, the card category in the card category field 434, and the card instance in the card instance field 435. The issuer saves this information and closes the card front details window 430 by selecting the save control 436. Alternatively, the issuer discards the entered information and closes the card front details window 430 by selecting the cancel control 437.

[0050] Figure 4C A user interface 400C is shown after the issuer selects the edit control 415, causing the card back details window 440 to appear. To emphasize that the issuer is entering information from the card back, the card back area 402 is highlighted. In this card back details window 440, the issuer enters the data source in the data source entry field 441, the card benefits in the card benefits entry field 442, and the issuer's identity in the issuer identity entry field 443. The issuer saves this information and closes the card back details window 440 by selecting the save control 444. Alternatively, the issuer discards the entered information and closes the card back details window 440 by selecting the cancel control 445. Figure 4Bthe user interface 400C that appears when the save control 436 is selected and the select data source control 421B is subsequently activated. Selection of the save control 436 causes the card front region 401 to now be filled in with the card type "Verified Player," the issuer logo (here, the logo of the fictional baseball league Contoso), and the issuer name "Contoso." At this stage, the subject name remains unfilled, as this portable identity card template will be used to create multiple portable identity cards for multiple subjects (baseball players in this example). Selection of the select data source control 421B opens the card back data window 440. To emphasize that the issuer is now working on a data source whose logo is to be used to fill in the portable identity card, the data source region 421 A is highlighted.

[0051] In the card back data window 440, the issuer has entered the type of data source (here, JWT or JSON Web Token) in the drop-down field 441, the accepted issuer value in the accepted issuer value field 442, and the source JSON Web Token uniform resource identifier in the source JWKs URI field 443. The accepted issuer value is the issuer's acceptance of the source as accurate data for making claims. Later, when a player requests a portable identity card, the data source will be used to fill in the claims identified in the card content fields 444. Thus, the player's verifiable credentials will include those claims identified in the card content fields 444.

[0052] In this example, the issuer specifies in field 444A that the credentials will include a claim of type player_bday (the player's birth date, selected from a drop-down menu of various claim types) from the birth date field, whose data type is a date of the selected data. In addition, the issuer specifies in field 444B that the credentials will include a claim of type player_first (the player's first name, selected from a drop-down menu) from the first name field, whose data type is a string of maximum length 60. The issuer specifies in field 444C that the credentials will include a claim of type player_last (the player's last name, from a drop-down menu) from the last name field, whose type is also a string of maximum length 60. If the credentials are to include other claims, the user can select the add field control 445. Thus, the fields 444 represent which data will be extracted and in what form the data will take when the claims are actually generated at the time each respective portable identity card is created from the portable identity card template.

[0053] when the add card benefit control 422B in the benefits region 422A of the card back region 402 has been selected, Figure 4DThe user interface 400D is shown. This allows information from the data window 440 on the back of the card to be saved as a data source and statement, which will be used to generate subsequent portable ID cards from the portable ID card template. The completion of the data source input is now indicated by a check mark in the data source area 421A, and other highlights are now removed from the data source area 421A.

[0054] Selecting the Add Card Benefits control 422B also highlights the Benefits area 422A and brings up the Benefits window 450 on the back of the card. Here, the issuer identifies a human-readable benefit description in field 451 and also identifies a partner application (for the corresponding holder to use the portable ID card with a partner or service) in the Partner Application field 452. The issuer can then choose to save the benefits to the portable ID card template using the Save control 453, or choose to cancel the input of these benefits without saving them to the portable ID card template using the Cancel control 454. Assuming in our example, the issuer has already saved the benefits using the Save control 453.

[0055] exist Figure 4E In the user interface 400E, the issuer has now selected the "Verify Your Organization" control 423B in the issuer verification area 423A on the back of the card 402. This highlights the issuer verification area 423A and causes the issuer verification window 460 on the back of the card to appear. The completion of the benefit information input in the benefit area 422A is also indicated by the benefit area 422A containing checkmarks. The issuer then enters the decentralized identity (DID) type called ION from the drop-down field 461, the keystore identity (here, "Keystore A") in the keystore drop-down field 462, the network domain for the issuer in the network domain field 463, and the revocation method for revoking verifiable credentials in the revocation drop-down field 464. The issuer then selects the save control 465 to save these issuer verification details, or selects the cancel control 466 to cancel these benefit inputs without saving them to the portable ID.

[0056] In our example, we assume that the publisher has already saved the verification details using the save control 465. Figure 4F Results interface 400F is shown, which now displays that all details windows are closed and that the issuer verification field is checked. The issuer calculation system responds by creating a portable ID template data structure, which can now be used to create portable IDs for individual holders (e.g., players) after they have authenticated with the issuer.

[0057] Now refer to Figures 5A-5F The user interface is used to describe the user experience of the example holder. Figure 5AUser interface 500A is shown, in which the holder (in this case, a Contoso Baseball League player) logs into the player control panel provided by the issuer (in this case, the Contoso Baseball League).

[0058] Figure 5B The diagram 500B shows the interface displayed to the player after authentication is complete. Here, basic player information (name, player ID, team, status, position) and a QR code allowing the player to download an additional authenticator are displayed. In this hypothetical example, the Contoso Baseball League player logging into the publisher's portal is named "John Doe".

[0059] exist Figure 5C In the 500C user interface, players (John Doe) are given the option to scan QR codes to add or share (i.e., present) credentials. Recall that in... Figures 4A-4F A portable ID template was created, specifically for creating portable IDs for Contoso baseball players like John Doe. Therefore, when players scan... Figure 5C When using the QR code, the portable ID template was used to create the portable ID data structure using John Doe's information. This included creating a verifiable credential with a specified claim about John Doe. Additionally, as... Figure 5D As shown in the 500D user interface, a visualization of the front of the portable ID card, now filled with John Doe's name, is presented to John Doe.

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

[0061] exist Figures 6A-6C In the example, the player presents a portable ID to a verifier (or dependent party), who is one of the partners listed in the portable ID. When John Doe from Figure 5Ewhen he selects partner A in the user interface 500E of his portable identity card, Figure 6A The user interface 600A is presented to John Doe. The player John Doe scans the QR code, resulting in Figure 6B The user interface 600B. John Doe can then cause the QR code to be presented to the computing system of partner A. John Doe then presents the user interface 600C or Figure 6C where the user selects the "Allow" control to present the verifiable credential (or associated verifiable presentation) associated with the portable identity card of partner A. When the verifiable credential is presented to partner A, the computing system of partner A follows the proof instructions (which can include contacting the issuer computing system or the registry computing system) to validate the verifiable credential.

[0062] This process can be repeated for John Doe multiple times for many different issuers. For example, partner A can be a relying party, but partner A itself can also be an issuer. Thus, in addition to presenting the verifiable claim to partner A, partner A can also provide another portable identity card to John Doe.

[0063] Figure 7A A user interface 700A is shown that presents John Doe with a stack of two existing portable identity cards - the verified player portable identity card provided by Contoso Baseball League, and the data manager portable identity card provided by partner A. Assume that the user interacts with the player portable identity card to view the transaction history associated with the verifiable credential of this portable identity card. Then, John Doe is shown Figure 7B The user interface 700B that shows the card with several transactions with the data manager application of partner A. Figure 7C A user interface 700C is shown that allows John Doe to view which partners have been authorized to access the verified player portable identity card, and possibly revoke access.

[0064] Figure 8 A flowchart of a method 800 for presenting a verifiable credential in accordance with the principles described herein is shown. The method 800 includes representing a verifiable credential within a data structure (act 801). As an example, in Figure 3 The verifiable credential 310 is represented within the portable identity card data structure 300. Thus, the verifiable credential 310 is an example of the verifiable credential of act 801, and the portable identity card data structure 300 is an example of the data structure of act 801. Recall that the verifiable credential 310 includes multiple verifiable claims. As an example, if the verifiable credential 310 is as for Figure 1The verifiable credential 310 includes a plurality of verifiable claims if the verifiable credential 100 is constructed as described.

[0065] The method 800 also includes monitoring use of the verifiable credential (act 802). Such monitoring can include when and where the verifiable credential is presented, to which relying parties the verifiable credential is presented, a time at which the verifiable credential was most recently presented to a relying party, and so on. In Figure 7B In the example, the user interface 700B displays to the user the transaction date, a portable identity certificate identifier that uniquely identifies the portable identity certificate, an issuer of the portable identity certificate, a third-party application to which the portable identity certificate was presented as part of the respective transaction, and what the result of the respective verification with the issuer was (e.g., valid or no response).

[0066] The method 800 also includes storing the use data also with the data structure (act 803). As an example, reference is made to Figure 3 The use data 320 is also stored within the portable identity certificate data structure 300. In Figure 8 In the example, the arrows 811 and 812 represent that as the monitoring continues (act 802), the use data is updated (act 803) such that the use data is new. That is, as the use of the verifiable credential changes or progresses, the stored use data also changes. Thus, the acts 802 and 803 within the dashed box 810 represent a continuous process.

[0067] Figure 9 A flowchart of a method 900 for using a portable identity certificate data structure according to the principles described herein is shown. In one example, the method 800 and the method 900 are each performed by a holder computing system, such as the holder computing system 220 of Figure 2 For example, if the holder computing system 220 is constructed as described below for the computing system 1200 of Figure 12 the method 800 and the method 900 can be performed by the computing system 1200 in response to at least one hardware processor 1202 executing computer-executable instructions that are structured such that, when executed by the at least one hardware processor 1202, cause the computing system 1200 to perform the method 800 or the method 900.

[0068] The method 90 includes causing (act 901) a visual representation of the verifiable credential to be displayed to a user. The visual representation is representative of an attribute name and a value for each verifiable claim in at least a subset of the verifiable claims of the verifiable credential. As an example, in Figure 5F In the example, the user interface 500F shows a plurality of attribute-value pairs that represent the claims (in human-readable form) of the respective verifiable credential. In Figure 5FIn the document, verifiable claims include: for one claim, the attribute name and value "John Doe"; for a second claim, the attribute baseball player ID and value 123456; for a third claim, the attribute status and value active, and so on. Therefore, the holder can see the claims contained in each verifiable credential.

[0069] However, visual representations can also include machine-readable representations of declared attribute-value pairs and / or proof instructions for verifiable credentials. Examples of such machine-readable representations include barcodes or QR codes. Such machine-readable representations can also represent proof instructions for verifiable credentials. Therefore, verifiable credentials are automatically verified by the verifier's computational system by scanning a barcode or QR code.

[0070] Method 900 also includes at least selectively presenting at least some usage data to the user (action 902). This allows the user to visualize how the verifiable credentials have been used. For example, the user can see when and where the credentials were used, which dependent parties depend on the credentials, what devices were used to present the verifiable credentials, and so on.

[0071] Therefore, the principles described in this paper provide a portable identity data structure that includes verifiable credentials and usage data. As mentioned earlier, the principles described in this paper 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 11 The described DID management module 1120. Alternatively or additionally, the declared subject and issuer identifier can be a decentralized identifier (DID). Alternatively or additionally, the portable ID 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 ID from any device associated with the holder's DID. Therefore, reference will be made first. Figure 10 and Figure 11 Describe a decentralized identifier.

[0072] 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 a digital identity associated with (i.e., identifying) 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.

[0073] The DID owner 1001 can be any entity that can benefit from a digital identity. For example, the DID owner 1001 can be a person or an organization of people. Such an organization can include a company, a department, a government, an agency, or any other organization or group of organizations. Each individual person can have a DID, and each person's organization(s) can also have a DID.

[0074] Alternatively, the DID owner 1001 can be a machine, system, or device, or a collection of machine(s), device(s), and / or system(s). In other embodiments, the DID owner 1001 can be a sub-portion of a machine, system, or device. For example, a device can be a printed circuit board, where the sub-portions of the printed circuit board are individual components of the circuit board. In such embodiments, the machine or device can have a DID and each sub-portion can also have a DID. A DID owner can also be a software component, such as the executable component 1206 described above with respect to Figure 12 An example of a complex executable component 1206 can be an artificial intelligence. Thus, an artificial intelligence can also own a DID.

[0075] Thus, the DID owner 1001 can be any entity, human or non-human, that can create a DID 1005 or at least has a DID 1005 created for it and / or associated with it. Although the DID owner 1001 is shown as having a single DID 1005, this need not necessarily be the case, as there can be any number of DIDs associated with the DID owner 1001 as circumstances permit.

[0076] As mentioned, the DID owner 1001 can create and register a DID 1005. The DID 1005 can be any identifier that can be associated with the DID owner 1001. Preferably, the identifier is unique to the DID owner 1001 at least within the scope of the intended use of the DID. As an example, the identifier can be a locally unique identifier, and perhaps more desirably a globally unique identifier for an identity system intended to operate globally. In some embodiments, the DID 1005 can be a Uniform Resource Identifier (URI) (e.g., a Uniform Resource Locator (URL)) or other pointer that associates the DID owner 1001 with a mechanism for engaging in trusted interactions with the DID owner 1001.

[0077] 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 conventional centralized IDs, which rely on 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 herein as “centralized authority”). Therefore, DID 1005 can be any identifier under the control of DID owner 1001 and independent of any centralized authority.

[0078] 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".

[0079] 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 centralized institution, private key 1006 should always be completely controlled by 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.

[0080] 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 the DID owner 1001. The private key 1006 and public key 1007 pair should not be generated on a server controlled by any centralized authority, as this could result in the private key 1006 and public key 1007 pair not always being fully under the control of the DID owner 1001. Although Figure 10 While the manual has described private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may be used as appropriate.

[0081] Figure 10A DID document 1010 associated with the DID 1005 is also shown. As will be explained in greater detail below, the DID document 1010 can be generated at the time the DID 1005 is created. In its simplest form, the DID document 1010 describes how to use the DID 1005. Thus, the DID document 1010 includes a reference to the DID 1005, which is the DID that is described by the DID document 1010. In some embodiments, the DID document 1010 can be implemented according to methods specified by the distributed ledger 1020 (e.g., a blockchain) that will be used to store a representation of the DID 1005, as will be explained in greater detail below. Thus, the DID document 1010 can have different methods depending on the particular distributed ledger.

[0082] The DID document 1010 also includes a public key 1007 or some other equivalent cryptographic information created by the DID owner 1001. The public key 1007 can be used by third party entities that are given permission by the DID owner 1001 to access information and data owned by the DID owner 1001. The public key 1007 can also be used to verify that the DID owner 1001 actually owns or controls the DID 1005.

[0083] The DID document 1010 can also include authentication information 1011. The authentication information 1011 specifies one or more mechanisms by which the DID owner 1001 can prove that the DID owner 1001 owns the DID 1005. In other words, the mechanisms of authentication information 1011 show proof of the binding between the DID 1005 (and thus its DID owner 1001) and the DID document 1010. In one embodiment, the authentication information 1011 specifies the public key 1007 for use in a signature operation to prove ownership of the DID 1005. Alternatively or additionally, the authentication information 1011 specifies the public key 1007 for use in a biometric operation to prove ownership of the DID 1005. Thus, the authentication information 1011 includes any number of mechanisms by which the DID owner 1001 can prove that the DID owner 1001 owns the DID 1005.

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

[0085] The authorization information 1012 also specifies one or more mechanisms that a third party will need to follow in order to prove that they are authorized to modify the DID document 1010. In some embodiments, these mechanisms can be similar to those discussed previously with respect to the authentication information 1011.

[0086] The DID document 1010 also includes one or more service endpoints 1013. The service endpoints include network addresses at which services operate on behalf of the DID owner 1001. Examples of particular services include discovery services, social networks, file storage services such as identity servers or identity hubs, and verifiable claim repositories services. Thus, the service endpoints 1013 serve as pointers to services that operate on behalf of the DID owner 1001. The DID owner 1001 or a third party entity can use these pointers to access services that operate on behalf of the DID owner 1001. Specific examples of service endpoints 1013 will be explained in greater detail below.

[0087] The DID document 1010 also includes identification information 1014. The identification information 1014 includes personally identifiable information such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 1001. Thus, the identification information 1014 listed in the DID document 1010 represents different roles of the DID owner 1001 for different purposes.

[0088] The role can be pseudonymous. As an example, in identifying DID owner 1001 as the author of a post on a blog, he or she can include a pen name in the DID document. The role can be fully anonymous. For example, DID owner 1001 can only want to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years of age, etc.) in the DID document without disclosing his or her name. As yet another example, the role can be specific to the person that is DID owner 1001 as an individual. As an example, DID owner 1001 can include information that identifies him or her as a volunteer for a particular charity, an employee of a particular company, a recipient of a particular award, etc.

[0089] DID document 1010 also includes credential information 1015, which can also be referred to herein as attestation. Credential information 1015 can be any information associated with the background of DID owner 1001. For example, credential information 1015 can be, but is not limited to, qualifications, achievements, government IDs, government rights such as a passport or driver's license, payment providers or bank accounts, university degrees or other education history, employment status and history, or any other information about the background of DID owner 1001.

[0090] DID document 1010 also includes various other information 1016. In some embodiments, other information 1016 can include metadata that specifies when DID document 1010 was created and / or when it was last modified. In other embodiments, other information 1016 can include cryptographic proof of the integrity of DID document 1010. In still further embodiments, other information 1016 can include additional information specified by the particular method that implements the DID document or required by the DID document.

[0091] Figure 10 A distributed ledger 1020 is also shown. Distributed ledger 1020 can be any decentralized distributed network that includes various computing systems that communicate 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 ellipsis 1060. Distributed ledger 1020 operates according to any known standard or method for a distributed ledger. Examples of conventional distributed ledgers that correspond to distributed ledger 1020 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0092] 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 store (not shown) associated with the distributed ledger 1020.

[0093] The representation of DID 1005 is stored on each distributed computing system of the distributed ledger 1020. For example, in Figure 10 In this diagram, DID hashes 1031, 1041, and 1051 are shown, 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 by reference numerals 1032, 1033, 1034, 1042, 1043, 1044, 1052, 1053, and 1054.

[0094] 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 a pointer to DID document 1010, DID hashes 1031, 1041, and 1051 may each include a record or timestamp indicating when DID 1005 was created. Subsequently, when DID document 1010 is modified, each modification (possibly along with the modification timestamp) 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.

[0095] Already referenced Figure 10 The DIDs and how they generally operate have been described; now, refer to Figure 11 Explain a specific implementation of a DID environment. Now, the explanation will begin. Figure 11 A sample environment 1100 is shown that can be used to perform various DID management operations and services. It should be understood that... Figure 11 The environment can be referenced as needed. Figure 10elements in order to facilitate explanation.

[0096] As shown in Figure 11 Environment 1100 includes various devices and computing systems owned by or otherwise controlled by DID owner 1001. These can include user device 1101. User device 1101 can be, but is not limited to, a mobile device such as a smartphone, a computing device such as a laptop, or any device such as a car or an appliance with computing capabilities. Device 1101 includes a web browser 1102 running on the device and an operating system 1103 running the device. More broadly, dashed line 1104 represents that all of these devices can be owned by or otherwise controlled by DID owner 1001.

[0097] Environment 1100 also includes DID management module 1120. In operation, as represented by respective arrows 1101a, 1102a, and 1103a, DID management module 1120 resides on and is executed by one or more of user device 1101, web browser 1102, and operating system 1103. Thus, for ease of explanation, DID management module 1120 is shown as separate. DID management module 1120 can also be described as a “wallet” in that it can hold various claims made by or about a particular DID. In one example, DID management module 1120 is structured as described above for executable component 1206.

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

[0099] A specific embodiment will now be described. For example, the UI 1135 can prompt the user to enter a username or some other human-recognizable name. This name can be used as a display name for the DID 1005 to be generated. As previously described, the DID 1005 can be a long string of random numbers and letters, and thus it can be advantageous to have a human-recognizable name for the display name. The DID creation module 1130 can then generate the DID 1005. In embodiments with the UI 1135, the DID 1005 can be shown in a list of identities and can be associated with the human-recognizable name.

[0100] The DID creation module 1130 can 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 generate the DID document 1010 using the DID 1005 as well as the private and public key pair.

[0101] In operation, the DID creation module 1130 accesses the registrar 1110 of the particular distributed ledger configured to record transactions relating to the DID 1005. The DID creation module 1130 uses the registrar 1110 to record the DID hash 1031, the DID hash 1041, and the DID hash 1051 in the distributed ledger in the previously described manner, and stores the DID document 1010 in the previously described manner. This process can use the public key 1007 in the hash generation.

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

[0103] The key generation module 1150 generates the private key 1006 and public key 1007 pair, and then the public key 1007 is recorded in the DID document 1010. Thus, the public key 1007 can be used by all devices associated with the DID owner 1001 as well as all third parties desiring to provide services to the DID owner 1001. Thus, when the DID owner 1001 desires to associate a new device with the DID 1005, the DID owner 1001 can execute the DID creation module 1130 on the new device. The DID creation module 1130 can then use the registrar 1110 to update the DID document 1010 to reflect that the new device is now associated with the DID 1005, which update will be reflected in transactions on the distributed ledger 1020.

[0104] However, in some embodiments, it can be advantageous for each device 1101 owned by the DID owner 1001 to possess a public key, as this can allow the DID owner 1001 to sign with a device-specific public key without having to access a universal public key. In other words, since the DID owner 1001 will be using different devices at different times (e.g., a mobile phone in one instance and a laptop in another instance), it can be advantageous to have a key associated with each device to provide efficiency in signing with the key. Thus, in such embodiments, when an additional device executes the DID creation module 1130, the key generation module 1150 generates additional public keys 1008 and 1009. These additional public keys can be associated with the private key 1006, or in some instances can be paired with a new private key.

[0105] In those embodiments in which the additional public keys 1008 and 1009 are associated with different devices, the additional public keys 1008 and 1009 are recorded in the DID document 1010 as being associated with those devices, as shown in Figure 11 In addition to the information shown in Figure 11 , the DID document 1010 can include the information previously described with respect to Figure 10 , (information 1005, 1007, and 1011-1016). If the DID document 1010 exists prior to the device-specific public keys being generated, the DID document 1010 will be updated by the creation module 1130 via the registrar 1110, and this will be reflected in an update transaction on the distributed ledger 1020.

[0106] In some embodiments, the DID owner 1001 can desire that the association of devices with public keys or the association of devices with the DID 1005 be kept secret. Thus, the DID creation module 1130 can cause such data to be shown in the DID file 1010 in secret.

[0107] As described so far, the DID 1005 has been associated with all devices controlled by the DID owner 1001, even if these devices have their own public keys. However, in some embodiments, each of the devices controlled by the DID owner 1001 or some subset can each have their own DID. Thus, in some embodiments, the DID creation module 1130 can generate an additional DID for each device, such as DID 1131. The DID creation module 1130 would then generate a private key and public key pair and DID document for each device and record them on the distributed ledger 1020 in the manner described above. Such embodiments can be advantageous for devices that can change ownership, as a device-specific DID can be associated with a new owner of the device by granting new owner authorization rights in the DID document and revoking such rights from the old owner.

[0108] As described above, to ensure that the private key 1006 is completely 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 that 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 of the private key 1006 is small.

[0109] However, it is possible that the device storing the private key 1006 can be lost by the DID owner 1001, which can result in the DID owner 1001 losing access to the DID 1005. Thus, in some embodiments, the UI 1135 includes an option to allow the DID owner 1001 to export the private key 1006 to an off-device secure database 1105 controlled by the DID owner 1001. As an example, the database 1105 can be one of the identity hubs 1210 described below with respect to Figure 12 The storage module 1180 is configured to store data in the database 1105 or identity hub 1210 in an off-device manner, such as the private key 1006 or attestations made by or about the DID owner 1001. In some embodiments, the private key 1006 is stored as a QR code scanned by the DID owner 1001.

[0110] In other embodiments, the DID management module 1120 can 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 at the time the DID 1005 is created that can later be used to recover a lost private key. In those embodiments with a UI 1135, the UI 1135 can allow the DID owner 1001 to provide information that will be used by the one or more recovery mechanisms 1165 during recovery. The recovery module 1160 can then be run on any device associated with the DID 1005.

[0111] The DID management module 1120 can also include a revocation module 1170 that is used to revoke or sever devices from the DID 1005. In operation, the revocation module uses the UI elements 1135 that allow the DID owner 1001 to indicate a desire to remove a device from association with the DID 1005. In one embodiment, the revocation module 1170 accesses the DID document 1010 and causes all references to the device to be removed from the DID document 1010. Alternatively, the public key for the device can be removed and then this change is reflected in the DID document 1010 which can then be reflected as an updated transaction on the distributed ledger 1020.

[0112] Because the principles described herein are performed in the context of a computing system, some introductory discussion of computing systems will be described with reference to the Figure 12 computing system 1000. Then, the specification will return to the principles of a decentralized identifier (DID) platform with reference to the remaining drawings.

[0113] Computing systems are now increasingly taking a wide variety of forms. Computing systems may be hand-held, laptop computers, desktop computers, mainframes, distributed computing systems, data centers, or even devices that have not conventionally been considered a computing system such as wearables, for example. In this description and in the claims, the term "computing system" is defined broadly to include any device or system that includes at least one physical and tangible processor, and a physical and tangible memory capable of having

[0114] As Figure 12As shown, in its most basic configuration, computing system 1200 includes at least one hardware processor 1202 and memory 1204. Processor 1202 includes a general -purpose processor. Although not required, processor 1202 also can comprise a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, memory 1204 includes physical system memory. This physical system memory can be volatile, non-volatile, or some combination of the two. In a second embodiment, memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory, and / or storage capability can be distributed as well.

[0115] Computing system 1200 also has thereon multiple structures, generally referred to as "executable components." For example, memory 1204 of computing system 1200 is shown to include executable component 1206. The term "executable component" is the name for a structure that is well known to those of ordinary skill in the computing arts, which can be a structure of software, hardware, or a combination thereof. For example, when implemented in software, those of ordinary skill in the art will appreciate that the structure of an executable component can comprise software objects, routines, methods (and the like) that can be executed on the computing system. Such an executable component exists in the heap of the computing system, in the computer-readable storage medium or combination.

[0116] Those of ordinary skill in the art will recognize that the structure of an executable component exists on a computer-readable medium, such that, when the structure is interpreted by one or more processors (e.g., by a processor thread) of a computing system, the computing system is caused to perform certain functionality. This structure can be directly computer-readable by the processor (as is the case if the executable component is binary). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) so as to generate such a binary that is directly interpretable by the processor. This understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the computing arts when using the term "executable component."

[0117] The term“executable component” is also well understood by those of ordinary skill in the computing arts to include structures that are implemented exclusively or substantially exclusively in hardware, such as hard-coded or hard-wired logic gates, for example, structures within a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other special-purpose circuit. Thus, the term“executable component” is a term of art for structures well understood by those of ordinary skill in the computing arts, whether implemented in software, hardware, or a combination thereof. In this specification, the terms“component,”“agent,”“manager,”“service,”“engine,”“module,”“virtual machine,” and the like can also be used. As used in this specification and claims, these terms, whether or not modified by the term“executable,” are also intended to be synonymous with the term“executable component,” and thus also have the structure well understood by those of ordinary skill in the computing arts.

[0118] In the description below, embodiments are described with reference to acts that are performed by one or more computing systems. If the acts are implemented in software, one or more processors (of the relevant computing system(s) that performs the act) directs the operation of the computing system in response to having executed computer-executable instructions constituting an executable component. For example, such computer-executable instructions can be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data. If the acts are implemented exclusively or nearly exclusively in hardware, such as within an FPGA or an ASIC, the computer-executable instructions can be hard-coded or hard-wired logic gates. The computer-executable instructions (and processed data) can be stored in the memory 1204 of the computing system 1200. The computing system 1200 can further include a communication channel 1208 that allows the computing system 1200 to communicate with other computing systems over, for example, the network 1210.

[0119] While not all computing systems require a user interface, in some embodiments, the computing system 1200 includes a user interface system 1212 for interaction with a user. The user interface system 1212 can include output mechanisms 1212A as well as input mechanisms 1212B. The principles described herein are not limited to precise output mechanisms 1212A or input mechanisms 1212B as these will depend on the nature of the device. However, output mechanisms 1212A can include, for example, speakers, displays, tactile outputs, virtual or augmented reality, holograms, and the like. Examples of input mechanisms 1212B can include, for example, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mice or other pointer inputs, sensors of any type, and the like.

[0120] The embodiments described herein can include or utilize special-purpose or general-purpose computing systems that include computer hardware, such as one or more processors and system memory, as discussed in greater detail below. 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 can be any available media that can be accessed by a general-purpose or special-purpose computing system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the application can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.

[0121] Computer-readable storage media includes 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 which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general- purpose or special-purpose computing system.

[0122] A "network" is defined as one or more data links that enable the transport of electronic data between computing systems and / or modules and / or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computing system, the computing system properly views the connection as a transmission medium. Transmission media can include a network and / or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general-purpose or special-purpose computing system. Combinations of the above should also be included within the scope of computer-readable media.

[0123] Further, upon reaching various computing system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computing system RAM and / or to less volatile storage media at a computing system. Thus, it should be understood that storage media can be included in computing system components that also (or even primarily) utilize transmission media.

[0124] Computer-executable instructions include, for example, instructions and data that, when executed at a processor, cause a general purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions. Alternatively, or additionally, computer-executable instructions can configure computing systems to perform a certain function or group of functions. The computer executable instructions can be, for example, binary or even instructions that are translated during execution, for example, assembly language, intermediate format instructions such as produced by a compiler, or even source code.

[0125] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0126] Those skilled in the art will appreciate that the application can be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, datacenters, wearable devices (e.g., glasses), and the like. The application can also be practiced in distributed system environments where local and remote computing system, which are in communication over a network, perform tasks. In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0127] Those skilled in the art will also appreciate that the application can be practiced in a cloud computing environment. A cloud computing environment can be distributed, but this is not required. When distributed, cloud computing environment can be distributed internationally and / or have components possessed across multiple organizations. In this specification, and in the claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any of the numerous advantages that can be obtained from such a model when properly deployed.

[0128] For the processes and methods disclosed herein, the operations performed in the processes and methods can be implemented in differing order. Furthermore, the outlined operations are only provided as examples, and some of the operations can be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

[0129] The application can take other specific forms without departing from the spirit or characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the application is, therefore, indicated by the appended claims rather than by the description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A computing system for presenting verifiable credentials so that the use of the verifiable credentials can be monitored by a user, the computing system comprising: One or more processors; as well as One or more computer-readable media having computer-executable instructions configured to, when executed by the one or more processors, cause the computing system to perform a method for presenting verifiable credentials, the method comprising: The data structure represents a verifiable credential, which includes multiple verifiable claims and proof instructions; The use of the verifiable credential is monitored to identify at least: the frequency with which the verifiable credential is exposed to dependent computing systems, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and a response indicating whether the verifiable credential has been verified. The use of the aforementioned includes scanning the QR code of the dependent party and allowing the presentation of the verifiable credential to the dependent party, wherein the verifiable credential is a credential that can be verified by following the proof instructions; The usage data of the verifiable credential is also stored in the data structure, such that the stored usage data changes as the use of the verifiable credential changes or progresses. The usage data includes at least: the frequency with which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified; and Using the data structure described above: The visual representation of the verifiable credentials is displayed to the user, the visual representation representing the attribute name and value of each verifiable claim in at least a subset of the plurality of verifiable claims; and At least selectively, at least the following items stored in the usage data are presented to the user: the frequency at which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified.

2. The computing system of claim 1, wherein the visualization representation comprises a human-readable visualization representation of the attribute name and value of each verifiable claim in the subset of verifiable claims.

3. The computing system of claim 1, wherein the visualization representation comprises a barcode or QR code representation of the attribute name and value of each verifiable claim in the subset of verifiable claims.

4. The computing system of claim 1, wherein the visualization representation includes a barcode or QR code representation of instructions for verifying one or more of the plurality of verifiable claims.

5. The computing system of claim 1, wherein at least one verifiable claim in the subset of verifiable claims has a topic referenced by a decentralized identifier.

6. A method for presenting a verifiable credential so that the use of the verifiable credential can be monitored by a user, the method comprising: The verifiable credentials are represented within a data structure, and the verifiable credentials include multiple verifiable claims and proof instructions; The use of the verifiable credential is monitored to identify at least: the frequency with which the verifiable credential is exposed to dependent computing systems, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and a response indicating whether the verifiable credential has been verified. The use of the aforementioned includes scanning the QR code of the dependent party and allowing the presentation of the verifiable credential to the dependent party, wherein the verifiable credential is a credential that can be verified by following the proof instructions; The usage data of the verifiable credential is also stored in the data structure, such that the stored usage data changes as the use of the verifiable credential changes or progresses. The usage data includes at least: the frequency with which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified; and Using the data structure described above: The visual representation of the verifiable credentials is displayed to the user, the visual representation representing the attribute name and value of each verifiable claim in at least one subset of the plurality of verifiable claims; as well as At least selectively, at least the following items stored in the usage data are presented to the user: the frequency at which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified.

7. The method of claim 6, wherein the visualization representation comprises a human-readable visualization representation of the attribute name and value of each verifiable claim in the subset of verifiable claims.

8. The method of claim 6, wherein the visualization representation comprises a barcode or QR code representation of the attribute name and value of each verifiable claim in the subset of verifiable claims.

9. The method of claim 6, wherein the visual representation comprises a barcode or QR code representation of instructions for verifying one or more of the plurality of verifiable claims.

10. The method of claim 6, wherein at least one verifiable claim in the subset of verifiable claims has a topic referenced by a decentralized identifier.

11. A computer program product comprising one or more computer-readable media having computer-executable instructions, the computer-executable instructions being structured to: when executed by a processor of a computing system, cause the computing system to perform a method for presenting a verifiable credential so that the use of the verifiable credential can be monitored by a user, the method comprising: The verifiable credentials are represented within a data structure, and the verifiable credentials include multiple verifiable claims and proof instructions; The use of the verifiable credential is monitored to identify at least: the frequency with which the verifiable credential is exposed to dependent computing systems, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and a response indicating whether the verifiable credential has been verified. The use of the aforementioned includes scanning the QR code of the dependent party and allowing the presentation of the verifiable credential to the dependent party, wherein the verifiable credential is a credential that can be verified by following the proof instructions; The usage data of the verifiable credential is also stored in the data structure, such that the stored usage data changes as the use of the verifiable credential changes or progresses. The usage data includes at least: the frequency with which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified; and Using the data structure described above: The visual representation of the verifiable credentials is displayed to the user, the visual representation representing the attribute name and value of each verifiable claim in at least one subset of the plurality of verifiable claims; as well as At least selectively, at least the following items stored in the usage data are presented to the user: the frequency at which the verifiable credential is exposed to the dependent computing system, the identity of the dependent computing system to which the verifiable credential was most recently exposed, the time of the most recent exposure of the verifiable credential, and the response indicating whether the verifiable credential has been verified.

12. The computer program product of claim 11, wherein the visual representation comprises a human-readable visual representation of the attribute name and value of each verifiable claim in the subset of verifiable claims.

13. The computer program product of claim 11, wherein at least one verifiable claim in the subset of verifiable claims has a subject referenced by a decentralized identifier.

Images