Patent ID: 12259960

DETAILED DESCRIPTION

The principles described herein relate to the acquisition and use of child verifiable credential from a parent verifiable credential, in order to restrict disclosure of claims to less than all of the claims made in the parent verifiable credential. Verifiable credentials themselves are known in the art. One conventional implementation of a verifiable credential is described by a W3C Recommendation dated Nov. 19, 2019 in a document entitled “Verifiable Credentials Data Model 1.0.”

In order to introduce the reader to the concept of a verifiable credential, an example verifiable credential100will first be described with respect toFIG.1. Furthermore, an environment200in which a verifiable credential is created and used will then be described with respect toFIG.2. The principles of the present invention will then be described with respect toFIGS.3through13.

As used herein, an “issuer” is an entity that makes at least one assertion about a subject. That assertion is also called herein a “claim”. A “credential” is a set of one or more claims. A “verifiable credential” is a credential in which cryptographic mechanisms (such as a digital signature) are used to detect whether the credential has been tampered with since the time that the credential was issued, and can be used to verify identity of the issuer of the credential. Claims within a verifiable credential need not be about the same subject, and the subject of any claim need not be the same as a holder of the verifiable credential.

FIG.1illustrates a verifiable credential100that includes multiple verifiable claims110. The verifiable claims110are shown as including four verifiable claims111through114, though the ellipsis115represents that the verifiable credential100may include any number (one or more) of verifiable claims. The verifiable credential110also includes proof instructions120that are used to verify that the verifiable credential100has not been tampered with since the verifiable credential100was created by the issuer of the verifiable credential100, and to verify the identity of the issuer of the verifiable claims110. An example of a proof instruction is a digital signature of the issuer.

FIG.2illustrates an environment200in which a verifiable credential (such as verifiable credential100ofFIG.1) is created and used. The environment200includes an issuer computing system210that operates within a sphere of trust of an issuer. Examples of issuers include corporations, organizations, associations, governments, agencies, individuals, or any other entity that can make assertions that could be relied upon by others. The issuer performs the role of asserting claims, causing the issuer computing system210to create a verifiable credential (such as verifiable credential100ofFIG.1) for these claims, and causing the issuer computing system210to transmit the verifiable credential to a holder computing system220as represented by arrow201. The issuer computing system210may also be referred to herein as simply “issuer210”. As represented by arrow211, the issuer210also transmits verify identifiers and use schemas to a registry computing system240.

As also represented by arrow201, a holder computing system220acquires the transmitted verifiable credential. The holder computing system220operates on behalf of a holder, who uses the holder computing system220to possess and potentially store the verifiable credential. As represented by arrow202, the holder also causes the holder computing system to present the verifiable credential to a verifier computing system230. The holder computing system220may also be referred to herein as simply “holder220”. As represented by arrow212, the holder220also transmits identifiers and use schemas to the registry computing system240.

The holder220presents the verifiable credential itself, or presents data from the verifiable credential in the form of 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 such a way that the authorship of the data is verifiable. If verifiable credentials are presented directly, they become verifiable presentations. Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, are also included within the definition of a verifiable presentation.

As also represented by the arrow202, a verifier computing system230acquires the transmitted verifiable credential (optionally within a verifiable presentation). The verifier computing system230operates on behalf of a verifier, which is a relying party that relies on one or more claims made in the verifiable credential. The verifier computing system230evaluates whether a verifiable credential is an untampered with (and unexpired) statement of the issuer210. This includes following any proof instructions (e.g., proof instructions120) that are present within the verifiable credential (e.g., verifiable credential100). The verifier computing system230then may take action based on this verification, such as treating the claim(s) made in the verifiable credential as being valid and issued by the issuer210. The verifier computing system230will sometimes also be referred to hereinafter as “verifier230”. As part of the verification, the verifier230sends verify identifiers and schemas to the registry computing system240, as represented by arrow213.

The registry computing system240mediates the creation and verification of identifiers, keys, verifiable credential schemas, revocation registries, issuer public keys, and so on. Example verifiable data registries include trusted databases, decentralized databases, and distributed ledgers. Each of the issuer computing system210, the holder computing system220, the verifier computing system230, and the registry computing system240is structured as described below for the computing system1300ofFIG.13.

Accordingly,FIGS.1and2describe verifiable credentials and dataflows associated with the creation and use of verifiable credentials. However, the inventors have recognized that portability of the verifiable credential is important in improving utility of the verifiable credential. As an example, such portability includes the ability to efficiently issue verifiable credentials to multiple holders, and the ability for any given holder to utilize the verifiable credential at different locations, and even with the verifiable credential being presented using multiple devices under the control of the holder (e.g., holder220). Tracking usage of a verifiable credential in such a manner can become quite difficult. However, there is presently no mechanism for keeping track of how a verifiable credential is being used, let alone how the verifiable credential is used if multiple devices are employed to present the verifiable credential.

FIG.3illustrates a flowchart of a method300for acquiring and using a child verifiable credential that includes a selected subset of verifiable claims that are present within a parent verifiable credential, in accordance with the principles described herein. The method300is performed by a computing system, such as the computing system1300described below with respect toFIG.13. In that case, the computing system1300performs the method300in response to the at least one hardware processing unit1302executing computer-executable instructions that are stored on the memory1304. Accordingly, the computer-executable instructions are specially structured to cause the computing system1300to perform the method300. In one embodiment, the method300is performed by a holder computing system, such as the holder computing system220ofFIG.2.

FIG.4illustrates an environment400in which a holder computing system420acquires and presents a child verifiable credential412, in accordance with the principles described herein. The child verifiable credential412is derived from a parent verifiable credential411. The holder computing system420acquires the child verifiable credential412from the issuer computing system410, and presents the child verifiable credential412to the verifier computing system430. In one embodiment, the holder computing system420is the holder computing system220ofFIG.2, the issuer computing system410is the issuer computing system210ofFIG.2, and the verifier computing system430is the verifier computing system230ofFIG.2. As the method300ofFIG.3is performed in the environment400ofFIG.4, the method300ofFIG.3will now be described with frequent reference to the environment400ofFIG.4.

The method includes the holder computing system obtaining a child verifiable credential that is derived from a parent verifiable credential (act310). InFIG.4, the parent verifiable credential is the parent verifiable credential411, and the child verifiable credential is the child verifiable credential412.FIG.4shows a state in which the holder computing system410has already obtained the child verifiable credential and thus shows a state of the environment400after act310has already been performed. Prior to act410being performed, the holder computing system420would not yet have possession of the child verifiable credential412.

The child verifiable credential412is modified with the term “child”, and the parent verifiable credential411is modified with the term “parent”. This nomenclature is used to emphasize that the child verifiable credential412is derived from the parent verifiable credential411. The child verifiable credential412includes one or more, but less than all, of the claims that are included within the parent verifiable credential. Obtaining and presenting a child verifiable credential will be useful if the holder computing system wanted to present some, but not all, of the verifiable claims within a verifiable credential.

The obtaining of the child verifiable credential (act310) includes a number of constituent acts, including acts311,312and313. Specifically, the holder computing system selects a subset of verifiable claims from the parent verifiable credential (act311). Referring toFIG.4, the holder computing system420selects a subset of the claims within the parent verifiable credential411. In an illustrative example that will be called herein the “subject example”), suppose that the parent verifiable credential411is structured as described above for the verifiable credential100ofFIG.1, and that the holder computing system420selects claims111and113, but not claims112and114.

The selection of the subset of verifiable claims is performed in response to the holder or an agent of the holder interfacing with the holder computing system420). In one example, the verifiable credential is represented within a data structure called herein a “portable identity card”. A visualization of the portable identity card is presented to the user, and the user may interact with the visualization in a predetermined manner so as to cause the subset of claims to be selected.

Returning toFIG.3, after the subset of claims is selected (act310), the holder computing system causes a request to be transmitted to a claims issuer computing system for the child verifiable credential that includes the selected subset of verifiable claims (act312). InFIG.4, this transmission is represented by arrow401. The request401includes enough information for the issuer computing system410to identify the parent verifiable credential411, and to identify the selected subset of claims. The issuer computing system410then generates a new verifiable credential (i.e., the child verifiable credential412) that includes the selected subset of verifiable claims, but does not include the claims of the parent verifiable credential that were not in that subset. As represented by arrow402, the issuer computing system410then transmits the child verifiable credential412to the holder computing system420.

FIG.5illustrates a verifiable credential500that represents an example of the child verifiable credential412ofFIG.4. The verifiable credential500includes a set of verifiable claims510and proof instructions520for verifying the verifiable claims. Specifically, in the subject example in which the parent verifiable credential411took the form of the verifiable credential100ofFIG.1, the holder computing system selected the claims111and113from the parent verifiable credential411. Accordingly, the verifiable claim set410includes the selected claims111and113, but does not include the claims112and114that were not selected from the parent verifiable credential.

Returning toFIG.3, the holder computing system detects receipt of the child verifiable credential (act313), thereby completing the act of obtaining the child verifiable credential (act310). The holder computing system then exposes the child verifiable credential to a verifying computing system (act320), so that the verifier computing system follows the proof instructions to verify claims in the child verifier credential. For instance, inFIG.4, the holder computing system420receives (as represented by arrow402) the child verifiable credential412from the issuer computing system410. The holder computing system420then presents (as represented by arrow403) the child verifiable credential to the verifying computing system430.

The issuer computing system410generates the verifiable credential412in the same way that verifiable credential411was created, the difference being that the claims included within the child verifiable credential are a smaller set of those claims that were included within the parent verifiable credential. An example issuer experience associated with generating verifiable credentials is described below with respect toFIGS.7A through8F. An example holder experience associated with presenting verifiable credentials is described below with respect toFIGS.9A through10C. Although the verifiable credential need not be represented within a portable identity card, the verifiable credential is represented within a portable identity card in some embodiments. Accordingly, a portable identity card and associated user experience will now be described with respect toFIGS.6through10C.

FIG.6illustrates a data structure600that represents one example of how a portable identity card is represented in storage and/or memory of a computing system of a claims holder. The portable identity card data structure600includes a verifiable credential610as well as usage data620of that verifiable credential. The verifiable credential610includes one or more claims611as well as proof instructions612for verifying integrity of the claims, and validating that the claims were made by an issuer identified within the claims. Accordingly, in one example, the verifiable credential610is the verifiable credential100ofFIG.1.

The verifiable credential610is included in the portable identity card data structure600in the sense that the portable identity card data structure600is used to access the verifiable credential610. In one example, the verifiable credential610is expressly included within the portable identity card data structure600. Alternatively, the verifiable credential610is referenced in the portable identity card data structure600. As an example, the portable identity card data structure600includes a pointer to (or an identifier of) the verifiable credential.

The same is true of the usage data620. That is, in one example, the usage data620is included in the portable identity card data structure600in the sense that the portable identity card data structure600is used to access the usage data620. In one example, the usage data620is expressly included within the portable identity card data structure600. Alternatively, the usage data620is referenced in the portable identity card data structure600. As an example, the portable identity card data structure600includes a pointer to (or an identifier of) the usage data620.

The usage data620includes any historical information about how the verifiable credential is being used. As examples, the usage data includes 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 last exposed, a time that the verifiable credential was last exposed, a device that was used to present the verifiable credential, and so forth.

The verifiable credential610is stored on the holder computing system, such as the holder220ofFIG.2. Alternatively, the verifiable credential610is stored in a way to be accessible by multiple different holder computing systems, each under the control of the same holder. As examples, the verifiable credential610can 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 toFIG.9, content of a DID document is accessible by using a decentralized identifier (DID). Thus, in this embodiment, the holder computing system accesses the verifiable credential610from whatever holder computing system is in the control of the holder, by using the DID of the holder.

The portable identity card data structure600is stored on the holder computing system, such as the holder220ofFIG.2. Alternatively, the portable identity card data structure600is stored in a way to be accessible by multiple different holder computing systems, each under the control of the same holder. As examples, the portable identity card data structure600can be stored in a centralized location, or in a decentralized distributed ledger, such as in a decentralized identifier (DID) document. Thus, in this embodiment, the holder computing system accesses the portable identity card data structure600from whatever holder computing system is in the control of the holder, by using the DID of the holder.

Thus, the portable identity card data structure600, along with the associated verifiable credential610and the usage data620for that verifiable credential, are available on different computing systems or devices of the holder. Accordingly, the holder may present the portable identity card from a variety of different devices, and also keep track of usage of the verifiable credential despite the verifiable credential being presented from various systems or devices in control of the holder. The holder may also present verifiable credentials from outside of any given sphere of trust (e.g., outside of a corporate network), since the portable identity card can be securely accessed by any of the holder's devices.

An example use scenario for a portable identity card will now be described with respect to the user interfaces ofFIGS.7A through10C. In this particular use scenario, an issuer is a fictional baseball league called the Contoso Baseball League (or simply “Contoso”), who is to issue a verifiable credential to players in that baseball league. Also, the holder is a player (called John Doe in the example) of the Contoso Baseball League. The verifiers are various partners (called Partner A, Partner B, and so forth) that provide benefits to players of the Contoso Baseball League.

InFIGS.7A through7F, the issuer creates a portable identity card template, which is used to create a portable identity card for each player who authenticates to the issuer and requests their respective portable identity card.

InFIG.7A, the issuer computing system presents the issuer with a user interface700A that allows the issuer to begin the process of creating a portable identity card template. The initial user interface700A displays a card front region701that the issuer will interface with to populate the front of the portable identity card template, a card back region702that the issuer will interface with to populate the back of the portable identity card template, and a card preview control703that the issuer interfaces with to see a preview of the portable identity card template to date.

The card front region701includes a card type area711that will display the type of portable identity card template. The card front region701also includes a subject name area712that will display the subject about which the issuer will make claims on the portable identity card. In this example, the subject name will be the player's name, and will remain unpopulated in the portable identity card template. The subject name will only become populated in the respective portable identity card when the player authenticates to the issuer, and requests their respective portable identity card. The card front region701also includes an issuer logo area713that will display a logo of the issuer, and an issuer identity region714that will display an identity of the issuer. The front of card region701also includes an edit control715that the issuer will select to begin populating the areas711,713and714of the front of the portable identity card template.

The card back region702includes a data source region721A that will represent the source of data from which data will be drawn to create the portable identity card from the portable identity card template. The issuer initiates selection of the data source by first activating the select data source control721B. The card back region702also includes a benefits region722A that will show any card benefits the holder will have. The issuer initiates identification of these benefits by first activating the add card benefits control722B. The card back region702also includes an issuer verification region723A that the issuer interfaces with in order to authenticate the identity of the issuer by first activating the verify your organization control723B.

FIG.7Bshows a user interface700B that appears after the issuer selects the edit control715to thereby show a card front detail window730. To emphasize that the issuer is entering information from the front of the card, the front of card region701is highlighted. In this card front detail window730, the issuer enters a schema (or type) of the portable identity card (in this case Verified player) in the schema input field731, a name of the issuer in the issuer name field732, a file name identifying a logo file for the issuer in the icon field733, a card class in the card class field734, and a card instance in the card instance field735. The issuer saves this information and closes the card front detail window730by selecting the save control736. Alternatively, the issuer discards the entered information and closes the card front detail window730by selecting the cancel control737.

FIG.7Cillustrates a user interface700C that appears when the issuer selects the save control736ofFIG.7B, and thereafter activates the select data source control721B. The selection of the save control736causes the card front region701to now be populated with the card type “Verified Player”, the issuer logo (here, a logo of the fictional baseball league Contoso), and the issuer name of “Contoso”. At this stage, the subject name remains unpopulated because this portable identity card template is to be used to create multiple portable identity cards for multiple subjects (baseball players in this example). The selection of the select data source control721B opens a card back data window740. To emphasize that the issuer is now working on identifying the data source to be used to populate portable identity cards, the data source region721A is highlighted.

In the card back data window740, the issuer has entered the type of data source (here, JWT or JSON Web Token) in drop down field741, the accepted issuer value in accepted issuer value field742, and the source JSON Web Token uniform resource identifier in the source JWKs URI field743. The accepted issuer value is the source that the issuer accepts as being accurate data for making claims. Later, when a player requests a portable identity card, the data source will be used to populate the claims that the issuer identifies in the card contents field744. Thus, the verifiable credential for the player will include those claims identified in the card contents field744.

In this example, the issuer specified in field744A that the credential is to include a claim of type player_bday (a player birthday as selected from a drop down menu of various claim types) from the Birthdate field having data type Date of the selected data source. Additionally, the issuer specified in field744B that the credential is to include a claim of type player_first (a player first name as selected from the drop down menu) from the First Name field having data type String of maximum length 60. The issuer specified in field744C that the credential is to include a claim of type player_last (a player last name from the drop down menu) from the Last Name field also of type string having a maximum length of 60. If the credential is to include further claims, the user may select the add field control745. Thus, the fields744represent which data will be extracted and what form the data will take when claims are actually generated at the time each respective portable identity card is created from the portable identity card template.

The user interface700D ofFIG.7Dis shown when the has selected the add card benefits control722B in the benefits region722A of the card back region702. This causes the information from the card back data window740to be saved as the data source and claims that are to be used to generate subsequent portable identity cards from the portable identity card template. The completion of entry of the data source is now represented by a check mark in the data source region721A, and the other highlighting is now removed from the data source region721A.

The selection of the add card benefits control722B also causes the benefits region722A to be highlighted, and the card back benefits window750to appear. Here, the issuer identifies a human-readable description of the benefits in the field751, and also identifies partner apps (for partners or services where the portable identity cards can be used by the respective holders) in the partner apps field752. The issuer may then select the save control753to save these benefits to the portable identity card template or the cancel control754to cancel entry of these benefits without saving them to the portable identity card template. Suppose in our example that the issuer has saved the benefits using the save control753.

In the user interface700E ofFIG.7E, the issuer has now selected the verify your organization control723B in the issuer verification region723A of the card back region702. This causes the issuer verification region723A to be highlighted, and causes the card back issuer verification window760to appear. The completion of the entry of benefits information in the benefits region722A is also represented by the benefits region722A containing a check mark. The issuer then entered a decentralized identity (DID) type called ION from the drop down field761, a key store identity (herein, “Key Store A”) in the key store drop down field762, a web domain for the issuer in the web domain field763, and a revocation method for revoking the verifiable credential in the revocation drop down field764. The issuer then selects the save control765to save these issuer verification details, or the cancel control766to cancel entry of these benefits without saving them to the portable identity card.

Suppose in our example that the issuer has saved the verification details using the save control765.FIG.7Fshows a resulting interface700F that now shows all details windows being closed, and showing the issuer verification field with a check mark. The issuer computing system responds by creating a portable identity card template data structure, which is now ready to be used to create portable identity cards for individual holders (e.g., players) after they authenticate to the issuer.

An example holder user experience will now be described with respect to the user interfaces ofFIGS.8A through8F.FIG.8Aillustrates a user interface800A in which the holder (in this case a Contoso Baseball League player) signs into a player dashboard offered by the issuer (in this case the Contoso Baseball League).

FIG.8Billustrates an interface800B displayed to the player after authentication is completed. Here, basic information about the player (name, player ID, team, status, position) is displayed, along with a QR code that allows the player to download a further authenticator. In this fictional example, the name of the Contoso Baseball League player that signed into the issuer portal is “John Doe”.

In the user interface800C ofFIG.8C, the player (John Doe) is given an option to scan a QR code in order to add or share (i.e., present) a credential. Recall that there is a portable identity card template that has been created inFIGS.7A through7Fprecisely for creating portable identity cards for Contoso baseball players such as John Doe. Accordingly, when the player scans the QR code ofFIG.8C, the portable identity card template is used to create a portable identity card data structure using John Doe's information. This includes creating the verifiable credential with the designated claims about John Doe. In addition, as represented by the user interface800D ofFIG.8D, John Doe is presented with a visualization of the front of the portable identity card now populated with John Doe's name.

Suppose that John Doe selects that “Add card” control in the user interface800D ofFIG.8D. The verified player portable identity card is then added to John Doe's available portable identity cards. Furthermore, player John Doe can now interface with the portable identity card as illustrated in the user interface800E ofFIG.8E. As an example, the user selects control801to see details of the card, as illustrated in the user interface800F ofFIG.8F. The player can see their name, baseball player ID, their status, the partners that the player can present their portable identity card to, and issuer identification. The player may now present the portable identity card to any of the identified partners.

In the example ofFIGS.9A through9C, the player presents the portable identity card to a verifier (or relying party), which is one of the partners listed in the portable identity card. The user interface900A ofFIG.9Ais presented to John Doe when John Doe selected Partner A from his portable identity card displayed in the user interface800E ofFIG.8E. Player John Doe scans the QR code, resulting in user interface900B ofFIG.9B. John Doe may then cause the QR code to be presented to a computing system of Partner A. John Doe is then presented with the user interface900C orFIG.9C, in which the user selects the “Allow” control to present the verifiable credential (or an associated verifiable presentation) associated with the portable identity card with Partner A. When the verifiable credential is presented to Partner A, the computing system of Partner A follows the proof instruction (which may include contacting the issuer computing system, or the registry computing system) to verify the verifiable credential.

This process may repeat for John Doe many times for many different issuers. As an example, Partner A may be a relying party, but may also itself be an issuer. Accordingly, in addition to presenting verifiable claims to Partner A, Partner A may provide John Doe with another portable identity card.

FIG.10Aillustrates a user interface1000A that shows John Doe a stack of now two portable identity cards—the Verified player portable identity card provided by the Contoso Baseball League, as well as a Data Manager portable identity card provided by Partner A. Suppose that the user interfaces with the Player portable identity card to view transaction history associated with the verifiable credential of that portable identity card. The user interface1000B ofFIG.10Bis then displayed to John Doe showing several transactions of that card with the Data Manager application of Partner A.FIG.10Cillustrates a user interface1000C that allows John Doe to view which Partners have been granted access to the Verified player portable identity card, and to potentially revoke access.

The principles described herein may be performed in a decentralized context. As an example, the holder computing system can be a digital wallet, such as the DID management module1220described below with respect toFIG.12. Alternatively, or in addition, the subject of the claims, and the issuer identifier, can be decentralized identifiers (DIDs). Alternatively, or in addition, the portable identity card data structure (or portions thereof) may be stored in a DID document. This would be especially helpful as the portable identity card would then be accessible by the holder from any device associated with the holder's DID. Accordingly, decentralized identifiers will first be described with respect toFIGS.11and12.

As illustrated inFIG.11, a DID owner1101may own or control a DID1105that represents a digital identity of the DID owner1101. The DID1105is a digital identity that correlates with (i.e., identifies) the DID owner1101across different digital contexts. The DID owner1101may register a DID using a creation and registration service, which will be explained in more detail below.

The DID owner1101may be any entity that could benefit from a digital identity. For example, the DID owner1101may be a human being or an organization of human beings. Such organizations might include a company, department, government, agency, or any other organization or group of organizations. Each individual human being might have a DID while the organization(s) to which each belongs might likewise have a DID.

The DID owner1101may alternatively be a machine, system, or device, or a collection of machine(s), device(s) and/or system(s). In still other embodiments, the DID owner1101may be a subpart of a machine, system or device. For instance, a device could be a printed circuit board, where the subpart of that circuit board are individual components of the circuit board. In such embodiments, the machine or device may have a DID and each subpart may also have a DID. A DID owner might also be a software component such as the executable component1306described above with respect toFIG.13. An example of a complex executable component1306might be an artificial intelligence. Accordingly, an artificial intelligence may also own a DID.

Thus, the DID owner1101may be any entity, human or non-human, that is capable of creating the DID1105or at least having the DID1105created for and/or associated with them. Although the DID owner1101is shown as having a single DID1105, this need not be the case as there may be any number of DIDs associated with the DID owner1101as circumstances warrant.

As mentioned, the DID owner1101may create and register the DID1105. The DID1105may be any identifier that may be associated with the DID owner1101. Preferably, that identifier is unique to that DID owner1101, at least within a scope in which the DID is anticipated to be in use. As an example, the identifier may be a locally unique identifier, and perhaps more desirably a globally unique identifier for identity systems anticipated to operate globally. In some embodiments, the DID1105may be a Uniform Resource identifier (URI) (such as a Uniform Resource Locator (URL)) or other pointer that relates the DID owner1101to mechanisms to engage in trustable interactions with the DID owner1101.

The DID1105is “decentralized” because it does not require a centralized, third party management system for generation, management, or use. Accordingly, the DID1105remains under the control of the DID owner1101. This is different from conventional centralized IDs which base trust on centralized authorities and that remain under control of corporate directory services, certificate authorities, domain name registries, or other centralized authority (referred to collectively as “centralized authorities” herein). Accordingly, the DID1105may be any identifier that is under the control of the DID owner1101and that is independent of any centralized authority.

In some embodiments, the structure of the DID1105may be as simple as a user name or some other human-understandable term. However, in other embodiments, for increased security, the DID1105may preferably be a random string of numbers and letters. In one embodiment, the DID1105may be a string of 128 numbers and letters. Accordingly, the embodiments disclosed herein are not dependent on any specific implementation of the DID1105. In a very simple example, the DID1105is shown within the figures as “123ABC”.

As also shown inFIG.11, the DID owner1101has control of a private key1106and public key1107pair that is associated with the DID1105. Because the DID1105is independent of any centralized authority, the private key1106should at all times be fully in control of the DID owner1101. That is, the private and public keys should be generated in a decentralized manner that ensures that they remain under the control of the DID owner1101.

As will be described in more detail to follow, the private key1106and public key1107pair may be generated on a device controlled by the DID owner1101. The private key1106and public key1107pair should not be generated on a server controlled by any centralized authority as this may cause the private key1106and public key1107pair to not be fully under the control of the DID owner1101at all times. AlthoughFIG.11and this description have described a private and public key pair, it will also be noted that other types of reasonable cryptographic information and/or mechanisms may also be used as circumstances warrant.

FIG.11also illustrates a DID document1110that is associated with the DID1105. As will be explained in more detail to follow, the DID document1110may be generated at the time that the DID1105is created. In its simplest form, the DID document1110describes how to use the DID1105. Accordingly, the DID document1110includes a reference to the DID1105, which is the DID that is described by the DID document1110. In some embodiments, the DID document1110may be implemented according to methods specified by a distributed ledger1120(such as blockchain) that will be used to store a representation of the DID1105as will be explained in more detail to follow. Thus, the DID document1110may have different methods depending on the specific distributed ledger.

The DID document1110also includes the public key1107created by the DID owner1101or some other equivalent cryptographic information. The public key1107may be used by third party entities that are given permission by the DID owner1101to access information and data owned by the DID owner1101. The public key1107may also be used to verify that the DID owner1101in fact owns or controls the DID1105.

The DID document1110may also include authentication information1111. The authentication information1111specifies one or more mechanisms by which the DID owner1101is able to prove that the DID owner1101owns the DID1105. In other words, the mechanisms of the authentication information1111shows proof of a binding between the DID1105(and thus its DID owner1101) and the DID document1110. In one embodiment, the authentication information1111specifies that the public key1107be used in a signature operation to prove the ownership of the DID1105. Alternatively, or in addition, the authentication information1111specifies that the public key1107be used in a biometric operation to prove ownership of the DID1105. Accordingly, the authentication information1111includes any number of mechanisms by which the DID owner1101is able to prove that the DID owner1101owns the DID1105.

The DID document1110may also include authorization information1112. The authorization information1112allows the DID owner1101to authorize third party entities the rights to modify the DID document1110or some part of the document without giving the third party the right to prove ownership of the DID1105. In one example, the authorization information1112allows the third party to update any designated set of one or more fields in the DID document1110using any designated update mechanism. Alternatively, the authorization information allows the third party to limit the usages of DID1105by the DID owner1101for a specified time period. This may be useful when the DID owner1101is a minor child and the third party is a parent or guardian of the child. The authorization information1112may allow the parent or guardian to limit use of the DID owner1101until such time as the child is no longer a minor.

The authorization information1112also specifies one or more mechanisms that the third party will need to follow to prove they are authorized to modify the DID document1110. In some embodiments, these mechanisms may be similar to those discussed previously with respect to the authentication information1111.

The DID document1110also includes one or more service endpoints1113. A service endpoint includes a network address at which a service operates on behalf of the DID owner1101. Examples of specific services include discovery services, social networks, file storage services such as identity servers or hubs, and verifiable claim repository services. Accordingly, the service endpoints1113operate as pointers for the services that operate on behalf of the DID owner1101. These pointers may be used by the DID owner1101or by third party entities to access the services that operate on behalf of the DID owner1101. Specific examples of service endpoints1113will be explained in more detail to follow.

The DID document1110further includes identification information1114. The identification information1114includes personally identifiable information such as the name, address, occupation, family members, age, hobbies, interests, or the like of DID owner1101. Accordingly, the identification information1114listed in the DID document1110represents a different persona of the DID owner1101for different purposes.

A persona may be pseudo anonymous. As an example, the DID owner1101may include a pen name in the DID document when identifying him or her as a writer posting articles on a blog. A persona may be fully anonymous. As an example, the DID owner1101may only want to disclose his or her job title or other background data (e.g., a school teacher, an FBI agent, an adult older than 21 years old, etc.) but not his or her name in the DID document. As yet another example, a persona may be specific to who the DID owner1101is as an individual. As an example, the DID owner1101may include information identifying him or her as a volunteer for a particular charity organization, an employee of a particular corporation, an award winner of a particular award, and so forth.

The DID document1110also includes credential information1115, which may also be referred to herein as an attestation. The credential information1115may be any information that is associated with the DID owner1101's background. For instance, the credential information1115may be (but is not limited to) a qualification, an achievement, a government ID, a government right such as a passport or a driver's license, a payment provider or bank account, a university degree or other educational history, employment status and history, or any other information about the DID owner1101's background.

The DID document1110also includes various other information1116. In some embodiments, the other information1116may include metadata specifying when the DID document1110was created and/or when it was last modified. In other embodiments, the other information1116may include cryptographic proofs of the integrity of the DID document1110. In still further embodiments, the other information1116may include additional information that is either specified by the specific method implementing the DID document or desired by the DID owner1101.

FIG.11also illustrates a distributed ledger1120. The distributed ledger1120can be any decentralized, distributed network that includes various computing systems that are in communication with each other. In one example, the distributed ledger1120includes a first distributed computing system1130, a second distributed computing system1140, a third distributed computing system1150, and any number of additional distributed computing systems as represented by the ellipses1160. The distributed ledger1120operates according to any known standards or methods for distributed ledgers. Examples of conventional distributed ledgers that correspond to the distributed ledger1120include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

In the context of DID1105, the distributed ledger or blockchain1120is used to store a representation of the DID1105that points to the DID document1110. In some embodiments, the DID document1110may be stored on the actual distributed ledger. Alternatively, in other embodiments the DID document1110may be stored in a data storage (not illustrated) that is associated with the distributed ledger1120.

A representation of the DID1105is stored on each distributed computing system of the distributed ledger1120. For example, inFIG.11this is shown as DID hash1131, DID hash1141, and DID hash1151, which are ideally identical hashed copies of the same DID. The DID hash1131, DID hash1141, and DID hash1151point to the location of the DID document1110. The distributed ledger or blockchain1120may also store numerous other representations of other DIDs as illustrated by references1132,1133,1134,1142,1143,1144,1152,1153, and1154.

In one embodiment, when the DID owner1101creates the DID1105and the associated DID document1110, the DID hash1131, DID hash1141, and DID hash1151are written to the distributed ledger1120. The distributed ledger1120thus records that the DID1105now exists. Since the distributed ledger1120is decentralized, the DID1105is not under the control of any entity outside of the DID owner1101. DID hash1131, DID hash1141, and DID hash1151may each include, in addition to the pointer to the DID document1110, a record or time stamp that specifies when the DID1105was created. At a later date, when modifications are made to the DID document1110, each modification (and potentially also a timestamp of the modification) is also be recorded in DID hash1131, DID hash1141, and DID hash1151. DID hash1131, DID hash1141, and DID hash1151could further include a copy of the public key1107so that the DID1105is cryptographically bound to the DID document1110.

Having described DIDs and how they operate generally with reference toFIG.11, specific embodiments of DID environments will now be explained with respect toFIG.12.FIG.12illustrates an example environment1200that may be used to perform various DID management operations and services will now be explained. It will be appreciated that the environment ofFIG.12may reference elements fromFIG.11as needed for ease of explanation.

As shown inFIG.12, the environment1200includes various devices and computing systems that are owned or otherwise under the control of the DID owner1101. These may include a user device1201. The user device1201may be, but is not limited to, a mobile device such as a smart phone, a computing device such as a laptop computer, or any device such as a car or an appliance that includes computing abilities. The device1201includes a web browser1202operating on the device and an operating system1203operating the device. More broadly speaking, the dashed line1204represents that all of these devices may be owned by or may otherwise be under the control of the DID owner1101.

The environment1200also includes a DID management module1220. In operation, as represented by respective arrows1201a,1202aand1203a, the DID management module1220resides on and is executed by one or more of user device1201, web browser1202, and the operating system1203. Accordingly, the DID management module1220is shown as being separate for ease of explanation. The DID management module1220may be also described as a “wallet” in that it can hold various claims made by or about a particular DID. In one example, the DID management module1220is structured as described above for the executable component1306.

As shown inFIG.12, the DID management module1220includes a DID creation module1230. The DID creation module1230may be used by the DID owner1101to create the DID1105or any number of additional DIDs, such as DID1231. In one embodiment, the DID creation module may include or otherwise have access to a User Interface (UI) element1235that may guide the DID owner1101in creating the DID1105. The DID creation module1230has one or more drivers that are configured to work with specific distributed ledgers such as distributed ledger1120so that the DID1105complies with the underlying methods of that distributed ledger.

A specific embodiment will now be described. For example, the UI1235may provide a prompt for the user to enter a user name or some other human recognizable name. This name may be used as a display name for the DID1105that will be generated. As previously described, the DID1105may be a long string of random numbers and letters and so having a human-recognizable name for a display name may be advantageous. The DID creation module1230may then generate the DID1105. In the embodiments having the UI1235, the DID1105may be shown in a listing of identities and may be associated with the human-recognizable name.

The DID creation module1230may also include a key generation module1250. The key generation module may generate the private key1106and public key1107pair previously described. The DID creation module1230may then use the DID1105and the private and public key pair to generate the DID document1110.

In operation, the DID creation module1230accesses a registrar1210that is configured to the specific distributed ledger that will be recording the transactions related to the DID1105. The DID creation module1230uses the registrar1210to record DID hash1131, DID hash1141, and DID hash1151in the distributed ledger in the manner previously described, and to store the DID document1110in the manner previously described. This process may use the public key1107in the hash generation.

In some embodiments, the DID management module1220may include an ownership module1240. The ownership module1240may provide mechanisms that ensure that the DID owner1101is in sole control of the DID1105. In this way, the provider of the DID management module1220is able to ensure that the provider does not control the DID1105, but is only providing the management services.

The key generation module1250generates the private key1106and public key1107pair and the public key1107is then recorded in the DID document1110. Accordingly, the public key1107may be used by all devices associated with the DID owner1101and all third parties that desire to provide services to the DID owner1101. Accordingly, when the DID owner1101desires to associate a new device with the DID1105, the DID owner1101may execute the DID creation module1230on the new device. The DID creation module1230may then use the registrar1210to update the DID document1110to reflect that the new device is now associated with the DID1105, which update would be reflected in a transaction on the distributed ledger1120.

In some embodiments, however, it may be advantageous to have a public key per device1201owned by the DID owner1101as this may allow the DID owner1101to sign with the device-specific public key without having to access a general public key. In other words, since the DID owner1101will use different devices at different times (for example using a mobile phone in one instance and then using a laptop computer in another instance), it is advantageous to have a key associated with each device to provide efficiencies in signing using the keys. Accordingly, in such embodiments, the key generation module1250generates additional public keys1108and1109when the additional devices execute the DID creation module1230. These additional public keys may be associated with the private key1106or in some instances may be paired with a new private key.

In those embodiments where the additional public keys1108and1109are associated with different devices, the additional public keys1108and1109are recorded in the DID document1110as being associated with those devices, as shown inFIG.12. The DID document1110may include the information (information1105,1107and1111through1116) previously described in relation toFIG.11in addition to the information (information1108,1109and1265) shown inFIG.12. If the DID document1110existed prior to the device-specific public keys being generated, then the DID document1110would be updated by the creation module1230via the registrar1210and this would be reflected in an updated transaction on the distributed ledger1120.

In some embodiments, the DID owner1101may desire to keep secret the association of a device with a public key or the association of a device with the DID1105. Accordingly, the DID creation module1230may cause that such data be secretly shown in the DID document1110.

As described thus far, the DID1105has been associated with all the devices under the control of the DID owner1101, even when the devices have their own public keys. However, in some embodiments, each device or some subset of devices under the control of the DID owner1101may each have their own DID. Thus, in some embodiments the DID creation module1230may generate an additional DID, for example DID1231, for each device. The DID creation module1230would then generate private and public key pairs and DID documents for each of the devices and have them recorded on the distributed ledger1120in the manner previously described. Such embodiments may be advantageous for devices that may change ownership as it may be possible to associate the device-specific DID to the new owner of the device by granting the new owner authorization rights in the DID document and revoking such rights from the old owner.

As mentioned, to ensure that the private key1106is totally in the control of the DID owner1101, the private key1106is created on the user device1201, browser1202, or operating system1203that is owned or controlled by the DID owner1101that executed the DID management module1220. In this way, there is little chance that a third party (and most consequentially, the provider of the DID management module1220) will gain control of the private key1106.

However, there is a chance that the device storing the private key1106may be lost by the DID owner1101, which may cause the DID owner1101to lose access to the DID1105. Accordingly, in some embodiments, the UI1235includes the option to allow the DID owner1101to export the private key1106to an off device secured database1205that is under the control of the DID owner1101. As an example, the database1205may be one of the identity hubs1310described below with respect toFIG.13. A storage module1280is configured to store data (such as the private key1106or attestations made by or about the DID owner1101) off device in the database1205or identity hubs1310. In some embodiments, the private key1106is stored as a QR code that is scanned by the DID owner1101.

In other embodiments, the DID management module1220may include a recovery module1260that may be used to recover a lost private key1106. In operation, the recovery module1260allows the DID owner1101to select one or more recovery mechanisms1265at the time the DID1105is created that may later be used to recover the lost private key. In those embodiments having the UI1235, the UI1235may allow the DID owner1101to provide information that will be used by the one or more recovery mechanisms1265during recovery. The recovery module1260may then be run on any device associated with the DID1105.

The DID management module1220may also include a revocation module1270that is used to revoke or sever a device from the DID1105. In operation, the revocation module uses the UI element1235, which allows the DID owner1101to indicate a desire to remove a device from being associated with the DID1105. In one embodiment, the revocation module1270accesses the DID document1110and causes that all references to the device be removed from the DID document1110. Alternatively, the public key for the device may be removed, and this change is then reflected in the DID document1110may then be reflected as an updated transaction on the distributed ledger1120.

Because the principles described herein are performed in the context of a computing system, some introductory discussion of a computing system will be described with respect toFIG.13. Then, this description will return to the principles of a decentralized identifier (DID) platform with respect to the remaining figures.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, 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 (e.g., glasses). In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or a combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

As illustrated inFIG.13, in its most basic configuration, a computing system1300includes at least one hardware processing unit1302and memory1304. The processing unit1302includes a general-purpose processor. Although not required, the processing unit1302may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory1304includes a physical system memory. That physical system memory may be volatile, non-volatile, or some combination of the two. In a second embodiment, the memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system1300also has thereon multiple structures often referred to as an “executable component”. For instance, the memory1304of the computing system1300is illustrated as including executable component1306. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods (and so forth) that may be executed on the computing system. Such an executable component exists in the heap of a computing system, in computer-readable storage media, or a combination.

One of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term “executable component”.

The term “executable component” is also well understood by one of ordinary skill as including structures, such as hard coded or hard wired logic gates, that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the terms “component”, “agent”, “manager”, “service”, “engine”, “module”, “virtual machine” or the like may also be used. As used in this description and in the case, these terms (whether expressed with or without a modifying clause) are also intended to be synonymous with the term “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component. For example, such computer-executable instructions may 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 such acts are implemented exclusively or near-exclusively in hardware, such as within a FPGA or an ASIC, the computer-executable instructions may be hard-coded or hard-wired logic gates. The computer-executable instructions (and the manipulated data) may be stored in the memory1304of the computing system1300. Computing system1300may also contain communication channels1308that allow the computing system1300to communicate with other computing systems over, for example, network1310.

While not all computing systems require a user interface, in some embodiments, the computing system1300includes a user interface system1312for use in interfacing with a user. The user interface system1312may include output mechanisms1312A as well as input mechanisms1312B. The principles described herein are not limited to the precise output mechanisms1312A or input mechanisms1312B as such will depend on the nature of the device. However, output mechanisms1312A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms1312B might include, for instance, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Embodiments described herein may comprise or utilize a special-purpose or general-purpose computing system including computer hardware, such as, for example, 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 invention can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.

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.

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.

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 be 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.

Computer-executable instructions comprise, for example, instructions and data which, 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 in addition, the computer-executable instructions may configure the computing system to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries or even instructions that undergo some translation (such as compilation) before direct execution by the processors, such as intermediate format instructions such as assembly language, or even source code.

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.

Those skilled in the art will appreciate that the invention may 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, wearables (such as glasses) and the like. The invention may also be practiced in distributed system environments where local and remote computing system, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

Those skilled in the art will also appreciate that the invention may be practiced in a cloud computing environment. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed 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 (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, an some of the operations may 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.

The present 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 only as illustrative and not restrictive. The scope of the invention is, therefore, indicate by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.