Patent Description:
Most currently used documents or records that prove identity are issued by centralized organizations, such as governments, corporations, schools, employers, or other service centers or regulatory organizations. These organizations often maintain every member's identity in a centralized identity management system. A centralized identity management system is a centralized information system used for organizations to manage the issued identities, their authentication, authorization, roles and privileges. Centralized identity management systems have been deemed as secure since they often use professionally maintained hardware and software. Typically, the identity issuing organization sets the terms and requirements for registering people with the organization. When a party needs to verify another party's identity, the verifying party often needs to go through the centralized identity management system to obtain information verifying and/or authenticating the other party's identity.

Decentralized Identifiers (DIDs) are a more recent type of identifier. Decentralized identifiers are independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) provides the opportunity for using fully decentralized identifiers. Distributed ledger technology uses distributed ledgers to record transactions between two or more parties in a verifiable way. Once a transaction is recorded, the data in the section of ledger cannot be altered retroactively without the alteration of all subsequent sections of 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 generally not controlled by a centralized management system, but rather is owned by an owner of the DID, DIDs are sometimes referred to as identities without authority.

<CIT> describes a method applied to an onboard terminal including receiving a payment authentication request sent by a server, and forwarding the payment authentication request to a user device having an established communication connection, the payment authentication request including a user identifier; receiving encrypted payment certification information responded by the user device and sending the encrypted payment certification information to the server, the encrypted payment certification information including the user identifier and a user device identifier; and receiving a certification result sent by the server and performing payment processing according to the certification result, the certification result indicating whether there is a binding relationship between the user identifier and the user device identifier. The present disclosure solves a technical problem of poor payment security in an existing mobile payment technology applied to onboard terminals. <CIT> describes computing systems, computer program products, and methods for selecting and providing an attestation in response to a request from an entity. A request is received from an entity for attestation that included in various attestations related to an owner of the attestations. The attestations define information about the owner of the attestations that the entity desires to obtain. The request includes request metadata that identifies a type of the attestation that is being requested. The request metadata is analyzed to determine the attestation that is being requested. Based on the analysis, the attestation is selected. Access to the attestation is provided to the entity making the request.

This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description.

Existing computing technologies provide for a data structure called a "verifiable credential" (hereinafter also called a "VC"). In these technologies, a credential issuer makes one or more claims about a subject entity, and generates a VC. The VC includes those claim(s) as well as a proof (e.g., cryptographic signature or code) to prove that claim(s) have not been tampered with and were indeed issued by the credential issuer. Thus, the proof is also called proof code. The credential issuer then provides the VC to a credential holder, for presentation to any relying party that relies upon the veracity of those claims. When the subject entity is a person, the subject entity and the credential holder are often the same entity. When the subject entity is not a person (e.g., a device, a pet), the credential holder may be the owner of the subject entity.

As an example, the claims issuer might be a computing system associated with a government agency in charge of issuing driver licenses. The government agency may generate a VC with claims about a citizen, such as the date of birth, residence address, weight, eye color, hair color, authorization to drive, restrictions on authorization to drive, and so forth. The government agency issues the VC to the citizen, just like issuing a physical driver license. The user stores the VC in a computing system (e.g., a mobile phone) or in a cloud storage that the user's computing system has access to. A VC that is used to assert claims about a user is also called a "user VC.

If the user is to rent a car from a car rental company, the user may present the user VC, whereby a computing system associated with the rental car company may use the proof code to verify that the claims include authorization to drive, and were issued by the government agency and indeed have not been tampered with since issuance.

However, like a physical identity card (e.g. a physical driver license card), when such a user VC is presented to a computing system of a relying entity, even though the computing system of the relying entity can use the proof code to verify that the VC was issued by a credential issuer about a subject entity, there is no proof that the person and/or the device presenting the VC is associated with the subject entity. For example, if a second user obtains a VC of a first user, the second user may present the VC of the first user as his/her own identifier. The principles described herein mitigate this problem by associating a unique identifier of a device with an identifier of a user or a user VC. Since each device has its own unique identifier, and many devices belong to a single user, the device identifier can be associated with a user identifier or a user VC as part of an identity protection system, therefore, to enhance the security of user transactions.

The embodiments described herein are related to a computing system that is configured to issue a claim that includes a unique device identifier of the device, such as an International Mobile Equipment Identity (IMEI), a media access control (MAC) address, etc. Since such a claim is related to a property of a device, not a user, this type of claim is also called "device claim. " The computing system then generates and attaches a proof to the device claim to generate a verifiable device credential (hereinafter also called a VDC). The VDC can then be associated with a user's identifier or a user VC. Various embodiments can be implemented to associating a VDC with a user's identifier or a user VC, including, but not limited to, (<NUM>) signing the device claim with a private key associated with a user, (<NUM>) associating the VDC with a user VC by computing systems of relying entities, and/or (<NUM>) incorporating the VDC into a user VC by computing systems of credential issuers.

In some embodiments, the proof includes a signature signed by the user's private key, such that a relying entity can decrypt the signature using the user's public key to verify that the VDC was indeed issued by the user using the user's private key. In a decentralized environment, when the user is an owner of a decentralized identifier (DID), the VDC is signed by a private key of the DID, and a portion of data associated with the VDC is propagated onto a DID document or a distributed ledger. The relying entity can further verify the VDC using the data propagated onto the DID document or the distributed ledger.

In some embodiments, the VDC also contains metadata indicating one or more revocation mechanisms of the VDC. The revocation mechanisms allow users to revoke the previously issued VDC. For example, when the device is misplaced or stolen, the user can revoke the VDC. As another example, an expiration time is included as one of the revocation mechanisms. In such a case, a VDC must be renewed periodically, or a new VDC must be generated after the expiration of an existing VDC. As such, the security of the device is further improved.

In some situations, the VDC alone is sufficient to serve as proof of a user's identity. For example, when a user tries to subscribe to a device-based service, such as mobile wireless service, streaming service, etc., the service provider does not need to know personally identifiable information of the user; instead, the service provider only needs to know that the user has control over the device, which is proven by the VDC. Thus, in such a case, the device identifier alone is sufficient for the service provider to provide the service to the user, and the user's privacy and personally identifiable information are further protected.

In some embodiments, additional self-issued claims are also incorporated into the VDC. The users can use the additional self-issued claims to self-identify himself or herself. This is useful in situations where verification of formal identity is not required, such as casual online communications, signing up for social media accounts, etc. For example, when a user signs up for a social media account, he or she often needs to provide a name or a screen name. Such a name may be the user's real name or an alias, and no third-party verification is required. The user can issue a self-issued claim asserting his or her name, and incorporate the self-issued claim into the device claim.

In some embodiments, the above described mechanisms are implemented mutually between devices of any two entities. For example, when two devices or computing systems (including computing systems of credential holders, relying entity and credential issuers) are communicating with each other, the two devices exchange their VDCs in addition to other entity information (e.g., other self-issued VC or VC issued by other credential issuers).

In addition to issuing VDCs and presenting a VDC with a VC by devices of a credential holder, in some embodiments, computing systems of relying entities are configured to further associate the received VDCs with the corresponding VCs. For example, when a first computing system of a relying entity receives the VDC from a second computing system of a credential holder, the device identifier of the second computing system contained in the VDC is recorded in a communication log. When the first computing system receives a new communication request from the same second entity, the device identifier of the new communication request is compared with the device identifier in the recorded communication log. When the newly received device identifier does not match any existing device identifiers recorded in the communication log, an alert is generated, or additional verification is required. When the newly received device identifier is found in the communication log, the first computing system would understand that the entity has used the same device in the past, thus the communication is likely to be legitimate.

Alternatively, or in addition, computing systems of credential issuers are also configured to associate VDCs with VCs. In some cases, a computing system of a credential issuer is configured to incorporate device claims into VCs, such that only the incorporated devices are allowed to present the corresponding VCs. For example, a VDC of a credential holder is sent to a credential issuer that is configured to issue user VCs. The credential issuer is caused to incorporate the device claim into the user VC. For example, a user of a driver license uses his/her phone to generate a VDC, and sends the VDC to the DMV. The DMV will perform various verifications to make sure that the device is truly the user's device. After the verification, the DMV adds the device claim into the user's driver license VC, such that only the device(s) contained in the driver license VC is allowed to present the driver license VC to a relying entity.

After the device claim is included in the user VC, the VDC and the VC can then be presented to a computing system of a relying entity. Receiving the VDC and the VC, the computing system of the relying entity extracts the device identifier contained in the VDC and the device identifier contained in the VC, and compare the two device identifiers to determine whether they match. In response to a determination of match, the computing system of the relying entity determines that the device is an authorized device for presenting the user VC. The computing system of the relying entity then sends the determination to the device of the credential holder. As such, only the authorized devices are allowed to present a user VC to a computing system of a relying entity.

Similarly, when a device requests the credential issuer to update a user claim contained in a user VC, the device also sends the VDC to the credential issuer. The computing system of the credential issuer extracts the device identifier contained in the VDC and the device identifier contained in the user VC and compares the two device identifiers to determine whether the two device identifiers match. In response to a determination of match, the credential issuer updates the user claim based on the user's request; otherwise, the request is denied. As such, unauthorized devices cannot validate or make changes to an existing user VC.

Accordingly, the principles described herein allow a user's device to assert a self-issued VDC containing the unique device identifier, which is, in turn, used as proof of user's identification, and/or as part of an identity protection system, such that the user's identity is further protected, and the user transactions are also further secured.

Finally, another problem of the traditional VCs is that they are not easily understood by the general users because such VCs are often recorded in a code format, such as the JSON Web Token (JWT) format. The embodiments described herein solve this problem by transforming the code of the VDC into a personal identity card. The personal identity card is a data structure that not only includes the data contained in the VDC, but also includes additional metadata (e.g., an image of the device, usage data, presentation format, etc.). The personal identity card is then presented to a user as one or more visualizations that resemble a physical identity card. The visualizations also allow users to easily modify the VDC and/or interact with relying entities. For example, a visualization of the personal identity card may allow the user to revoke or renew a VDC or send the VDC to a particular relying entity.

The principles described herein are related to issuing a verifiable device credential (VDC) asserting a value of a unique device identifier (herein after also called device identifier). The embodiments are likely implemented in a computing system that is owned and used by a limited number of users, such as a mobile device, a home computer. The computing system is configured to retrieve a value of a device identifier of itself and generates a claim asserting the value of the device identifier.

A claim is often expressed using a property-value pair. <FIG> illustrates an example data structure that represents a claim 100A. The claim 100A includes a subject 111A, a property 112A, and a value 113A. For example, the subject 111A includes an identifier of the subject entity (e.g., a decentralized identifier (DID)). The property 112A may be any property of the subject of the DID, such as a name, an address, a date of birth, etc. The value 113A is the value of the corresponding property 112A. For example, when the property 112A is a "name", the value 113A would be the name of the subject entity 111A, e.g., John Doe. When the property is an "address", the value 113A would be the address of the subject entity 111A, e.g., <NUM> Main St. , City, State, Zipcode. A claim that asserts a value of a property of a user is called a user claim.

Here, since the claim issued by the computing system asserts a value of a device property (e.g., a device identifier), such a claim is called a device claim. For example, the device claim may assert a value of IMEI of a mobile phone. In such a case, the property of the claim would be IMEI, and the value of the claim would be the IMEI number (e.g., <NUM>-<NUM>-<NUM>-<NUM>).

Thereafter, the computing system associates the device claim with a user of the computing system. In particular, the computing system generates a proof (e.g., proof code) which proves that the claim is issued on the user's behalf. The proof is then attached to the device claim to generate a verifiable device credential (VDC). In many cases, the proof is a signature of the device claim that is signed by the user's private key. When a relying entity receives the VDC, the relying entity is caused to decrypt the signature using the user's public key to verify the decrypted proof code is consistent with the asserted value of the device claim.

<FIG> illustrates an example VC 100B. The VC 100B includes one or more claims 110B (e.g., claims 111B, 112B), and proof code 120B. The proof code 120B often includes a cryptographic signature that is signed by a private key of the claim issuer. When a relying entity receives the VC 100B, the relying entity can retrieve a public key of the claim issuer and decrypt the cryptographic signature, and compare the decrypted signature with the data contained in the claims 110B to verify at least that (<NUM>) the VC was indeed issued by the claim issuer, (<NUM>) the claims contained in the VC have not been tempered. In some embodiments, the VC also includes various metadata 130B, which is data related to the VC 100B. For example, the metadata 130B may include (<NUM>) a unique identifier identifying the corresponding VC 100B, (<NUM>) one or more conditions for accessing the VC 100B, and/or (<NUM>) one or more revocation mechanisms for revoking the corresponding VC 100B.

When a VC holder interacts with a relying entity, the VC holder can present or send the VC to the relying entity via various channels, including but are not limited to wide area network (WAN), local area network (LAN), Bluetooth (BLE), near field communication (NFC), <NUM>/<NUM>/<NUM>/<NUM> mobile communication networks, SMS, a scan of a bar code or QR code. When the relying entity receives the VC 100B, the relying entity can use the proof code 120B to authenticate the claims 110B contained in the VC.

<FIG> illustrates an example embodiment <NUM> of that a device <NUM> is configured to assert a device claim <NUM>. The device <NUM> is a computing system, such as a mobile device. As illustrated in <FIG>, the device <NUM> is associated with various device identifiers <NUM>, <NUM>, <NUM>, each of which is a unique identifier associated with the device <NUM>, or a hardware component <NUM>, <NUM> of the device <NUM>. Some device identifiers are associated with the device <NUM>, such as IMEI <NUM>. Some device identifiers are associated with a hardware component <NUM>, <NUM> of the device. For example, a MAC address <NUM> is associated with a network adapter <NUM> of the device <NUM>, and an integrated circuit card identifier (ICCID) is associated with a subscriber identity module (SIM) card <NUM> of the device <NUM>. The ellipsis <NUM> represents that there may be any number of device identifiers associated with the device <NUM> or components of the device <NUM>, and each of these device identifiers may be included in a device claim or a VDC. These device identifiers <NUM>, <NUM>, <NUM> are often hard programmed into the device <NUM> or components <NUM>, <NUM> upon manufacture, thus, each of these device identifiers <NUM>, <NUM>, and/or <NUM> can be used to identify the device <NUM>. Since many devices belong to a single user or a small group of users (family members), the device can also be used to identify the user or the group of users.

The device <NUM> retrieves a value of at least one of the device identifiers <NUM>, <NUM>, <NUM>, and generates a device claim <NUM> asserting the value of the at least one device identifier and associating the device claim with a user of the device. As illustrated in <FIG>, the device claim <NUM> includes a property-value pair <NUM>, <NUM> of IMEI. The subject of the device claim is an identifier (ID) of the user <NUM>. In a decentralized environment, the user ID <NUM> may be a DID of the user. The device claim <NUM> is merely an example device claim. In some cases, the device has its own DID. In such a case, the subject entity of the device claim may be the DID of the device.

As described above, each device often has multiple unique device identifiers. Additionally, each user also often has multiple identifiers (DIDs) for various purposes. Thus, the device <NUM> is capable of issuing multiple device claims associating different user identifiers into each of the claims or asserting values of different device identifiers for different purposes. For example, when the user uses the device to subscribe a wireless service, the value of MEI <NUM> is asserted in a device claim; when the user uses the device to subscribe a streaming service, the value of MAC address is asserted in a device claim; and when additional security is required, values of multiple device identifiers may be asserted.

As briefly described above, after the device claim is generated, the computing system further generates and attaches a proof to the device claim to make it into a VC. The proof is often a cryptographic signature, signed by a private key of a user. Since the VC is signed by the user and presented by the user, such a VC is also called self-issued VC. For brevity, without further specification, all the VDCs described herein are self-issued VCs.

<FIG> illustrates an example self-issued VDC <NUM>. The self-issued VDC <NUM> includes one or more device claims <NUM>, including a claim <NUM> asserting a value of IMEI of the device. The ellipsis <NUM> represents that there may be any number of device claims contained in the VDC <NUM>. The additional claims may contain information related to the user (e.g., a username) or information related to additional device identifiers. The VDC <NUM> also includes a proof <NUM> and metadata <NUM>. The proof <NUM> includes a signature <NUM> signed by a private key of the user, who is also the holder of the VDC <NUM>. The metadata <NUM> includes one or more revocation mechanism(s) of the VDC <NUM>. In some embodiments, the one or more revocation mechanism(s) includes an expiration time of the VDC <NUM>, and the VDC <NUM> is required to be renewed periodically or be reissued upon expiration. The expiration time is especially helpful when a user misplaces and/or forgets about a device that has issued a VDC associated with the user. Even if the user forgot about the device, the VDC will expire automatically, and no one can use the device to perform transactions on behalf of the user upon the expiration of the VDC.

<FIG> illustrates an example communication session <NUM>, in which two user devices <NUM>, <NUM> mutually present their self-issued VDC <NUM>, <NUM> to each other. Device A <NUM> belongs to user <NUM>. Device A <NUM> retrieves its own device identifier and generates a device claim A <NUM> and uses the user <NUM>'s private key to generate a signature of the device claim A <NUM>. The signature is attached to the device claim A <NUM> to turn it into a VDC <NUM>. The VDC <NUM> is then sent to device B <NUM>. Subsequently, or substantially simultaneously, device B <NUM> also retrieves its own device identifier and generates a device claim B <NUM>. Similarly, device B <NUM> signs the device claim B <NUM> using the user <NUM>'s private key to generate a VDC <NUM>. The VDC <NUM> is then sent to device A <NUM>. Each of device A <NUM> and device B <NUM> verifies that the VDC <NUM>, <NUM> is indeed issued by the other device.

In some cases, each of device A <NUM> or device B <NUM> records the communication session in a log. The log includes the device identifier and user identifier of each party. In some embodiments, incoming communications are analyzed based on the previously recorded log to detect potential fraud. In a decentralized environment, certain data related to the communications or transactions is propagated onto a distributed ledger. Thus, the entities can also use the data propagated onto the distributed ledger to further validate whether the device has been previously used by the same user in the past transactions.

For example, when user <NUM> bought a new phone, he/she will start to use the new phone to communicate with user <NUM>. When the new phone is used, the new phone will generate a VDC using its device identifier. Receiving the VDC of the new phone, device B <NUM> will determine that the new phone's identifier is different from any device identifiers of user <NUM> recorded in the previous communication sessions. In such a case, device B <NUM> may request the user <NUM> to provide additional user information to prove that the new device is truly the user <NUM>'s device.

For example, in some cases, device B <NUM> may require the user <NUM> to further authenticate himself/herself using various biometrics (e.g., fingerprint, iris scan, facial recognition, etc.). Alternatively, or in addition, device B <NUM> may send an email or text message, and/or call the user's phone number to have the user <NUM> to authenticate via a second communication channel. As another example, device B <NUM> may require the user <NUM> to further present a self-issued VC that includes additional personal data of the user <NUM> (e.g., date of birth, answer of a secret question, etc.). Alternatively, or in addition, device B <NUM> may require the user <NUM> to provide a VC (e.g., a driver license VC) that is issued by a neutral credential issuer or an identity provider. As such, self-issued VDCs can be presented amongst parties to provide additional protection to users' identities.

In addition to use the self-issued VDCs in direct communications, a user can also request other credential issuers to incorporate the device claims into user VCs. <FIG> illustrates an example environment 500A, in which a credential holder <NUM>'s device <NUM> requests a credential issuer <NUM> to issue or update a VC issued to the credential holder to include a device claim <NUM>. As illustrated in <FIG>, the credential holder <NUM>'s device <NUM> generates a self-issued VDC <NUM> including a device claim A <NUM>. The device <NUM> sends the VDC <NUM> to the credential issuer <NUM>. For example, the credential issuer <NUM> may be the DMV, which has issued a driver license VC to the credential holder <NUM>. Receiving the VDC <NUM> from the credential holder <NUM>'s device <NUM>, the credential issuer <NUM> updates the existing driver license VC <NUM> issued to the credential holder <NUM>, or issues a new driver license VC <NUM> to include the device claim <NUM> in the driver license VC <NUM>.

As discussed earlier, a VC may include multiple claims. For example, a driver license VC would include multiple claims about a driver, such as the legal name, the date of birth, residence address, weight, eye color, hair color, authorization to drive, restrictions on authorization to drive, and so forth. The principles described herein allows the users to request credential issuers to include one or more device claims into new VCs or existing VCs issued by a credential issuer. As illustrated in <FIG>, the credential issuer <NUM> issues or updates a VC <NUM> of the credential holder <NUM> to include the device claim <NUM>. As such, the VC <NUM> not only includes the claims about the credential holder <NUM> (e.g., claim B <NUM> asserting the name of the credential holder <NUM>), but also includes the device claim <NUM>.

In many cases, a same user may have multiple devices. Each of these devices can similarly generate a VDC and have the credential issuer <NUM> to incorporate its device claim into the verifiable credential <NUM>. As such, the verifiable credential <NUM> may include multiple device claims corresponding to multiple user devices.

Each time, a new device claim is added to the claim set <NUM>, a new proof <NUM> is generated. The new proof <NUM> is attached to the new claim set <NUM> to make the new claim set <NUM> to be verifiable. In many cases, the new claim set <NUM> is signed by a private key of the credential issuer <NUM> to generate a signature <NUM>, and the signature <NUM> is then attached to the claim set <NUM> as the proof <NUM>. The VC <NUM> may also include various metadata <NUM>, which is data related to the VC <NUM>, such as a unique identifier identifying the VC <NUM>, one or more revocation mechanism(s), etc. The updated or newly issued VC <NUM> is then sent back to the device <NUM>, which is represented by arrow <NUM>. The credential holder <NUM> can then present the VC <NUM> and the self-issued VDC <NUM> to other relying entities.

<FIG> illustrates an example environment 500B, in which the credential holder <NUM>'s device <NUM> sends the self-issued VDC <NUM> and the user VC <NUM> (issued by the credential issuer <NUM>) to a relying entity <NUM>, which is represented by arrow <NUM>. Receiving both the VDC <NUM> and user VC <NUM>, the relying entity <NUM> extracts the device identifier contained in the VDC <NUM> and the device identifier contained in the VC <NUM>. The relying entity <NUM> then compares the extracted device identifiers to determine whether the two extracted device identifiers match, which is represented by arrow <NUM>. The determination is then sent back to the device <NUM>, which is represented by arrow <NUM>.

Only when the device identifiers in the two device claims <NUM> and <NUM>' match, the relying entity will further consider the user claim B <NUM> contained in the VC <NUM>. As such, the user not only must possess a copy of the VC <NUM>, but also need to present the VC <NUM> using one of the devices that have been registered with the relying entity <NUM> (i.e., contained in the VC). When another user obtains a copy of the VC <NUM>, the user using a different device cannot present the VC <NUM> as his/her own identifier. Thus, the user's identity is further protected.

Further, as briefly described above, VCs are often recorded in a code format, such as the JSON Web Token (JWT) format, which can be easily understood by computing systems, but not by the general public. The embodiments described herein solve this problem by transforming the code of a traditional verifiable claim into a personal identity card. The personal identity card is a data structure that not only includes the data contained in the VC, but also includes additional metadata (e.g., a photo of the user, an image of the device, usage data, presentation format, etc.). The personal identity card is then presented to a user as one or more visualizations. At least one of the visualizations resembles a physical identity card. The presentation may be performed by a mobile app, a web browser, and/or a web application. In a decentralized environment, the mobile app may be a part of a user's DID management module (e.g., a wallet app).

<FIG> illustrates an example data structure <NUM> of portable identity card. The data structure <NUM> includes a verifiable credential <NUM> containing at least one or more claims <NUM> and proof code <NUM>. The data structure <NUM> also includes metadata <NUM>. The metadata <NUM> includes usage data <NUM>. Ellipsis <NUM> represents that there may be additional metadata contained in the portable identity card <NUM>, including but are not limited to, a logo of the claim issuer, an image of the device, presentation format, etc..

As described above, a VDC is a special type of VC that is issued by the subject entity. Either a VDC or a VC issued can be stored in the data structure of a personal identity card and presented as one or more visualizations. <FIG> illustrate various example visualizations 700A and 700B of a portable identity card that may be presented to a user. As illustrated in <FIG>, the visualization 700A resembles a front side of a physical identity card. The visualization 700A includes the credential type 710A, which indicates the type of the VC. Here, the credential type is VDC. The visualization 700A also includes data related to the VC, such as the device name 720A, a device image 730A, the IMEI value of the device 740A, the VC's issue date 750A, and expiration data 750A. The ellipsis 760A represents that there may be additional or different data presented on the visualization 700A.

<FIG> illustrates another example visualization 700B, through which users can review additional metadata associated with the VC. Users are also allowed to interact with various user interfaces contained in the visualization 700B to perform different actions. For example, the visualization 700B includes a benefit section 710B, which lists one or more benefits that are associated with the device, such as wireless service, streaming service, etc. The visualization 700B also includes a revocation interface 720B and a renewal interface 730B. A user can interact with the revocation interface 720B to revoke the VDC or interact with the renewal interface 730B to renew the VDC. The visualization 700B also includes a usage data section 740B, through which the user can see data associated with the use of the VDC. For example, the user may be able to see a log including all the entities, to which the device has presented the VDC. The visualization 700B also includes a request interface 750B, through which the user can send the VDC to a particular relying entity or a credential issuer. The ellipsis 760B represents that there may be additional or different user interface or sub-visualizations contained in the visualization 700B.

The visualizations 700A and 700B shown in <FIG> are merely schematic examples. Various arrangements and contents may be implemented to achieve the same, similar, or additional functions. In some embodiments, users may be allowed to design or customize the visualizations of each personal identity card.

The following discussion with respect to <FIG> now refers to a number of methods and method acts that may be performed.

<FIG> illustrates a flowchart of an example method <NUM> for generating and presenting a VDC as part of an identity protection system. The method <NUM> is likely implemented at a user's computing system. The computing system first retrieves a device identifier of itself (<NUM>). For example, the device identifier may be an IMEI number of the device. The computing system then generates a device claim including the device identifier.

The computing system then generates and attach a proof to the device claim to generate a VC (<NUM>). In many cases, the device claim is signed by a private key of a user of the computing system to generate a signature, and the signature is attached to the device claim to generate a VDC (<NUM>). In a decentralized environment, when the user is an owner of a DID, the device claim is signed with a private key of the DID (<NUM>). A portion of data related to the VDC is then propagated onto a distributed ledger (<NUM>). Finally, the VDC is presented to a relying entity as part of an identity protection system (<NUM>).

<FIG> illustrates a flowchart of an example method <NUM> for verifying an identity of a user using a self-issued VDC. The method <NUM> is likely incorporated at a computing system of a relying entity. The relying entity may be another user, a service provider, and/or a credential issuer. The computing system receives a request from a device, including a self-issued VDC (<NUM>). In some cases, the request includes a request for service (<NUM>). In some cases, the request includes a request to communicate with another entity (<NUM>). In some other cases, the request includes a request that requests a credential issuer to issue a VC containing the device claim (<NUM>). For example, the credential issuer may be requested to update an existing VC issued to a device user to include the device claim. Alternatively, the credential issuer may be requested to issue a new VC containing the device claim.

Receiving the request and the self-issued VDC, the computing system verifies that the VDC was issued by the user using the proof code contained in the VDC (<NUM>). In many cases, additional identification data is also sent to the relying entity at the same time. Thus, other verifications may also be performed (<NUM>). For example, a VC issued by a credential issuer and the VDC may be sent to the relying entity substantially simultaneously. The VC and the VDC will both be verified by the computing system. After the device and the user are both verified (<NUM>), the computing system then accepts (<NUM>) or rejects (<NUM>) the request.

Finally, as previously mentioned, the principles described herein may be performed in a decentralized context. As an example, the computing system associated with a credential holder can be a digital wallet, such as the DID management module <NUM> described below with respect to <FIG>. Alternatively, or in addition, the subject of the claims, and the issuer identifier, can be decentralized identifiers (DIDs). Altematively, 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 now be described with respect to <FIG> and <FIG>.

As illustrated in <FIG>, a DID owner <NUM> may own or control a DID <NUM> that represents a digital identity of the DID owner <NUM>. The DID <NUM> is a digital identity that correlates with (i.e., identifies) the DID owner <NUM> across different digital contexts. The DID owner <NUM> may register a DID using a creation and registration service, which will be explained in more detail below.

The DID owner <NUM> may be any entity that could benefit from a digital identity. For example, the DID owner <NUM> may 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 owner <NUM> may 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 owner <NUM> may 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 component <NUM> described above with respect to <FIG>. An example of a complex executable component <NUM> might be an artificial intelligence. Accordingly, an artificial intelligence may also own a DID.

Thus, the DID owner <NUM> may be any entity, human or non-human, that is capable of creating the DID <NUM> or at least having the DID <NUM> created for and/or associated with them. Although the DID owner <NUM> is shown as having a single DID <NUM>, this need not be the case as there may be any number of DIDs associated with the DID owner <NUM> as circumstances warrant.

As mentioned, the DID owner <NUM> may create and register the DID <NUM>. The DID <NUM> may be any identifier that may be associated with the DID owner <NUM>. Preferably, that identifier is unique to that DID owner <NUM>, 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 DID <NUM> may be a Uniform Resource identifier (URI) (such as a Uniform Resource Locator (URL)) or other pointer that relates the DID owner <NUM> to mechanisms to engage in trustable interactions with the DID owner <NUM>.

The DID <NUM> is "decentralized" because it does not require a centralized, third party management system for generation, management, or use. Accordingly, the DID <NUM> remains under the control of the DID owner <NUM>. 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 DID <NUM> may be any identifier that is under the control of the DID owner <NUM> and that is independent of any centralized authority.

In some embodiments, the structure of the DID <NUM> may be as simple as a user name or some other human-understandable term. However, in other embodiments, for increased security, the DID <NUM> may preferably be a random string of numbers and letters. In one embodiment, the DID <NUM> may be a string of <NUM> numbers and letters. Accordingly, the embodiments disclosed herein are not dependent on any specific implementation of the DID <NUM>. In a very simple example, the DID <NUM> is shown within the figures as "123ABC".

As also shown in <FIG>, the DID owner <NUM> has control of a private key <NUM> and public key <NUM> pair that is associated with the DID <NUM>. Because the DID <NUM> is independent of any centralized authority, the private key <NUM> should at all times be fully in control of the DID owner <NUM>. 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 owner <NUM>.

As will be described in more detail to follow, the private key <NUM> and public key <NUM> pair may be generated on a device controlled by the DID owner <NUM>. The private key <NUM> and public key <NUM> pair should not be generated on a server controlled by any centralized authority as this may cause the private key <NUM> and public key <NUM> pair to not be fully under the control of the DID owner <NUM> at all times. Although <FIG> and 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> also illustrates a DID document <NUM> that is associated with the DID <NUM>. As will be explained in more detail to follow, the DID document <NUM> may be generated at the time that the DID <NUM> is created. In its simplest form, the DID document <NUM> describes how to use the DID <NUM>. Accordingly, the DID document <NUM> includes a reference to the DID <NUM>, which is the DID that is described by the DID document <NUM>. In some embodiments, the DID document <NUM> may be implemented according to methods specified by a distributed ledger <NUM> (such as blockchain) that will be used to store a representation of the DID <NUM> as will be explained in more detail to follow. Thus, the DID document <NUM> may have different methods depending on the specific distributed ledger.

The DID document <NUM> also includes the public key <NUM> created by the DID owner <NUM> or some other equivalent cryptographic information. The public key <NUM> may be used by third party entities that are given permission by the DID owner <NUM> to access information and data owned by the DID owner <NUM>. The public key <NUM> may also be used to verify that the DID owner <NUM> in fact owns or controls the DID <NUM>.

The DID document <NUM> may also include authentication information <NUM>. The authentication information <NUM> specifies one or more mechanisms by which the DID owner <NUM> is able to prove that the DID owner <NUM> owns the DID <NUM>. In other words, the mechanisms of the authentication information <NUM> shows proof of a binding between the DID <NUM> (and thus its DID owner <NUM>) and the DID document <NUM>. In one embodiment, the authentication information <NUM> specifies that the public key <NUM> be used in a signature operation to prove the ownership of the DID <NUM>. Alternatively, or in addition, the authentication information <NUM> specifies that the public key <NUM> be used in a biometric operation to prove ownership of the DID <NUM>. Accordingly, the authentication information <NUM> includes any number of mechanisms by which the DID owner <NUM> is able to prove that the DID owner <NUM> owns the DID <NUM>.

The DID document <NUM> may also include authorization information <NUM>. The authorization information <NUM> allows the DID owner <NUM> to authorize third party entities the rights to modify the DID document <NUM> or some part of the document without giving the third party the right to prove ownership of the DID <NUM>. In one example, the authorization information <NUM> allows the third party to update any designated set of one or more fields in the DID document <NUM> using any designated update mechanism. Alternatively, the authorization information allows the third party to limit the usages of DID <NUM> by the DID owner <NUM> for a specified time period. This may be useful when the DID owner <NUM> is a minor child and the third party is a parent or guardian of the child. The authorization information <NUM> may allow the parent or guardian to limit use of the DID owner <NUM> until such time as the child is no longer a minor.

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

The DID document <NUM> also includes one or more service endpoints <NUM>. A service endpoint includes a network address at which a service operates on behalf of the DID owner <NUM>. 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 endpoints <NUM> operate as pointers for the services that operate on behalf of the DID owner <NUM>. These pointers may be used by the DID owner <NUM> or by third party entities to access the services that operate on behalf of the DID owner <NUM>. Specific examples of service endpoints <NUM> will be explained in more detail to follow.

The DID document <NUM> further includes identification information <NUM>. The identification information <NUM> includes personally identifiable information such as the name, address, occupation, family members, age, hobbies, interests, or the like of DID owner <NUM>. Accordingly, the identification information <NUM> listed in the DID document <NUM> represents a different persona of the DID owner <NUM> for different purposes.

A persona may be pseudo anonymous. As an example, the DID owner <NUM> may 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 owner <NUM> may 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 <NUM> 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 owner <NUM> is as an individual. As an example, the DID owner <NUM> may 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 document <NUM> also includes credential information <NUM>, which may also be referred to herein as an attestation. The credential information <NUM> may be any information that is associated with the DID owner <NUM>'s background. For instance, the credential information <NUM> may 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 owner <NUM>'s background.

The DID document <NUM> also includes various other information <NUM>. In some embodiments, the other information <NUM> may include metadata specifying when the DID document <NUM> was created and/or when it was last modified. In other embodiments, the other information <NUM> may include cryptographic proofs of the integrity of the DID document <NUM>. In still further embodiments, the other information <NUM> may include additional information that is either specified by the specific method implementing the DID document or desired by the DID owner <NUM>.

<FIG> also illustrates a distributed ledger <NUM>. The distributed ledger <NUM> can be any decentralized, distributed network that includes various computing systems that are in communication with each other. In one example, the distributed ledger <NUM> includes a first distributed computing system <NUM>, a second distributed computing system <NUM>, a third distributed computing system <NUM>, and any number of additional distributed computing systems as represented by the ellipses <NUM>. The distributed ledger <NUM> operates according to any known standards or methods for distributed ledgers. Examples of conventional distributed ledgers that correspond to the distributed ledger <NUM> include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

In the context of DID <NUM>, the distributed ledger or blockchain <NUM> is used to store a representation of the DID <NUM> that points to the DID document <NUM>. In some embodiments, the DID document <NUM> may be stored on the actual distributed ledger. Alternatively, in other embodiments the DID document <NUM> may be stored in a data storage (not illustrated) that is associated with the distributed ledger <NUM>.

A representation of the DID <NUM> is stored on each distributed computing system of the distributed ledger <NUM>. For example, in <FIG> this is shown as DID hash <NUM>, DID hash <NUM>, and DID hash <NUM>, which are ideally identical hashed copies of the same DID. The DID hash <NUM>, DID hash <NUM>, and DID hash <NUM> point to the location of the DID document <NUM>. The distributed ledger or blockchain <NUM> may also store numerous other representations of other DIDs as illustrated by references <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

In one embodiment, when the DID owner <NUM> creates the DID <NUM> and the associated DID document <NUM>, the DID hash <NUM>, DID hash <NUM>, and DID hash <NUM> are written to the distributed ledger <NUM>. The distributed ledger <NUM> thus records that the DID <NUM> now exists. Since the distributed ledger <NUM> is decentralized, the DID <NUM> is not under the control of any entity outside of the DID owner <NUM>. DID hash <NUM>, DID hash <NUM>, and DID hash <NUM> may each include, in addition to the pointer to the DID document <NUM>, a record or time stamp that specifies when the DID <NUM> was created. At a later date, when modifications are made to the DID document <NUM>, each modification (and potentially also a timestamp of the modification) is also be recorded in DID hash <NUM>, DID hash <NUM>, and DID hash <NUM>. DID hash <NUM>, DID hash <NUM>, and DID hash <NUM> could further include a copy of the public key <NUM> so that the DID <NUM> is cryptographically bound to the DID document <NUM>.

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

As shown in <FIG>, the environment <NUM> includes various devices and computing systems that are owned or otherwise under the control of the DID owner <NUM>. These may include a user device <NUM>. The user device <NUM> may 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 device <NUM> includes a web browser <NUM> operating on the device and an operating system <NUM> operating the device. More broadly speaking, the dashed line <NUM> represents that all of these devices may be owned by or may otherwise be under the control of the DID owner <NUM>.

The environment <NUM> also includes a DID management module <NUM>. In operation, as represented by respective arrows 1101a, 1102a and 1103a, the DID management module <NUM> resides on and is executed by one or more of user device <NUM>, web browser <NUM>, and the operating system <NUM>. Accordingly, the DID management module <NUM> is shown as being separate for ease of explanation. The DID management module <NUM> may 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 module <NUM> is structured as described above for the executable component <NUM>.

As shown in <FIG>, the DID management module <NUM> includes a DID creation module <NUM>. The DID creation module <NUM> may be used by the DID owner <NUM> to create the DID <NUM> or any number of additional DIDs, such as DID <NUM>. In one embodiment, the DID creation module may include or otherwise have access to a User Interface (UI) element <NUM> that may guide the DID owner <NUM> in creating the DID <NUM>. The DID creation module <NUM> has one or more drivers that are configured to work with specific distributed ledgers such as distributed ledger <NUM> so that the DID <NUM> complies with the underlying methods of that distributed ledger.

A specific embodiment will now be described. For example, the UI <NUM> may 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 DID <NUM> that will be generated. As previously described, the DID <NUM> may 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 module <NUM> may then generate the DID <NUM>. In the embodiments having the UI <NUM>, the DID <NUM> may be shown in a listing of identities and may be associated with the human-recognizable name.

The DID creation module <NUM> may also include a key generation module <NUM>. The key generation module may generate the private key <NUM> and public key <NUM> pair previously described. The DID creation module <NUM> may then use the DID <NUM> and the private and public key pair to generate the DID document <NUM>.

In operation, the DID creation module <NUM> accesses a registrar <NUM> that is configured to the specific distributed ledger that will be recording the transactions related to the DID <NUM>. The DID creation module <NUM> uses the registrar <NUM> to record DID hash <NUM>, DID hash <NUM>, and DID hash <NUM> in the distributed ledger in the manner previously described, and to store the DID document <NUM> in the manner previously described. This process may use the public key <NUM> in the hash generation.

In some embodiments, the DID management module <NUM> may include an ownership module <NUM>. The ownership module <NUM> may provide mechanisms that ensure that the DID owner <NUM> is in sole control of the DID <NUM>. In this way, the provider of the DID management module <NUM> is able to ensure that the provider does not control the DID <NUM>, but is only providing the management services.

The key generation module <NUM> generates the private key <NUM> and public key <NUM> pair and the public key <NUM> is then recorded in the DID document <NUM>. Accordingly, the public key <NUM> may be used by all devices associated with the DID owner <NUM> and all third parties that desire to provide services to the DID owner <NUM>. Accordingly, when the DID owner <NUM> desires to associate a new device with the DID <NUM>, the DID owner <NUM> may execute the DID creation module <NUM> on the new device. The DID creation module <NUM> may then use the registrar <NUM> to update the DID document <NUM> to reflect that the new device is now associated with the DID <NUM>, which update would be reflected in a transaction on the distributed ledger <NUM>.

In some embodiments, however, it may be advantageous to have a public key per device <NUM> owned by the DID owner <NUM> as this may allow the DID owner <NUM> to sign with the device-specific public key without having to access a general public key. In other words, since the DID owner <NUM> will 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 module <NUM> generates additional public keys <NUM> and <NUM> when the additional devices execute the DID creation module <NUM>. These additional public keys may be associated with the private key <NUM> or in some instances may be paired with a new private key.

In those embodiments where the additional public keys <NUM> and <NUM> are associated with different devices, the additional public keys <NUM> and <NUM> are recorded in the DID document <NUM> as being associated with those devices, as shown in <FIG>. The DID document <NUM> may include the information (information <NUM>, <NUM> and <NUM> through <NUM>) previously described in relation to <FIG> in addition to the information (information <NUM>, <NUM> and <NUM>) shown in <FIG>. If the DID document <NUM> existed prior to the device-specific public keys being generated, then the DID document <NUM> would be updated by the creation module <NUM> via the registrar <NUM> and this would be reflected in an updated transaction on the distributed ledger <NUM>.

In some embodiments, the DID owner <NUM> may desire to keep secret the association of a device with a public key or the association of a device with the DID <NUM>. Accordingly, the DID creation module <NUM> may cause that such data be secretly shown in the DID document <NUM>.

As described thus far, the DID <NUM> has been associated with all the devices under the control of the DID owner <NUM>, 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 owner <NUM> may each have their own DID. Thus, in some embodiments the DID creation module <NUM> may generate an additional DID, for example DID <NUM>, for each device. The DID creation module <NUM> would then generate private and public key pairs and DID documents for each of the devices and have them recorded on the distributed ledger <NUM> in 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 key <NUM> is totally in the control of the DID owner <NUM>, the private key <NUM> is created on the user device <NUM>, browser <NUM>, or operating system <NUM> that is owned or controlled by the DID owner <NUM> that executed the DID management module <NUM>. In this way, there is little chance that a third party (and most consequentially, the provider of the DID management module <NUM>) will gain control of the private key <NUM>.

However, there is a chance that the device storing the private key <NUM> may be lost by the DID owner <NUM>, which may cause the DID owner <NUM> to lose access to the DID <NUM>. Accordingly, in some embodiments, the UI <NUM> includes the option to allow the DID owner <NUM> to export the private key <NUM> to an off device secured database <NUM> that is under the control of the DID owner <NUM>. As an example, the database <NUM> may be one of the identity hubs <NUM> described below with respect to <FIG>. A storage module <NUM> is configured to store data (such as the private key <NUM> or attestations made by or about the DID owner <NUM>) off device in the database <NUM> or identity hubs <NUM>. In some embodiments, the private key <NUM> is stored as a QR code that is scanned by the DID owner <NUM>.

In other embodiments, the DID management module <NUM> may include a recovery module <NUM> that may be used to recover a lost private key <NUM>. In operation, the recovery module <NUM> allows the DID owner <NUM> to select one or more recovery mechanisms <NUM> at the time the DID <NUM> is created that may later be used to recover the lost private key. In those embodiments having the UI <NUM>, the UI <NUM> may allow the DID owner <NUM> to provide information that will be used by the one or more recovery mechanisms <NUM> during recovery. The recovery module <NUM> may then be run on any device associated with the DID <NUM>.

The DID management module <NUM> may also include a revocation module <NUM> that is used to revoke or sever a device from the DID <NUM>. In operation, the revocation module uses the UI element <NUM>, which allows the DID owner <NUM> to indicate a desire to remove a device from being associated with the DID <NUM>. In one embodiment, the revocation module <NUM> accesses the DID document <NUM> and causes that all references to the device be removed from the DID document <NUM>. Alternatively, the public key for the device may be removed, and this change is then reflected in the DID document <NUM> may then be reflected as an updated transaction on the distributed ledger <NUM>.

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 to <FIG>. Then, this description will return to the principles of a decentralized identifier (DID) platform with respect to the remaining figures.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> includes a general-purpose processor. Although not required, the processing unit <NUM> may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory <NUM> includes 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 system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, the memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. 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".

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 1212A as well as input mechanisms 1212B. The principles described herein are not limited to the precise output mechanisms 1212A or input mechanisms 1212B as such will depend on the nature of the device. However, output mechanisms 1212A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 1212B 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.

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 may be supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

Claim 1:
A computing system comprising:
one or more processors; and
one or more computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the one or more processors, cause the computing system to perform the following:
retrieve a value of a device identifier of the computing system (<NUM>);
generate a device claim asserting the value of the device identifier (<NUM>);
associate the device claim with an identifier of a user of the computing system;
generate and attach proof code to the device claim to generate a verifiable device credential, VDC (<NUM>), the proof code proving that the VDC is issued by the computing system that is associated with the user; and
present the VDC with additional user information to a second computing system as part of an identity protection system (<NUM>), wherein the second computing system is associated with a relying entity or a credential issuer and when the second computing system receives the VDC, the second computing system is caused to use the proof code to verify whether the VDC was issued by a computing system associated with the user and to analyze the user information with the device identifier to determine whether the device is an authorized device of the user based on previous communication or transaction records.