Microsoft Technology Licensing, LLC

Other

Ankur Patel

Brandon Brian Murdoch

Daniel James Buchner

Ronald John Kamiel Eurphrasia Bjones

Bailey Marie Bercik

Nithya Ganesh

Frank Michael Chiachiere

Sydney Morton

Guillermo P Proano

Eric Christopher Sachs

Ariel Nicolas Gordon

Steven J Ball

Benjamin Richard Vincent

Karen K Wong

Pieter Kasselman

Daniel Godbout

William Thomas

Jonathan J Wang

Logan Girvin

Daniel Luke Strockis

Andreas Mikolajewski

Preeti Rastogi

Swee Chee Pang

Brandon Murdoch

Permitting a claims holder to get a limited verifiable credential leveraging off of a previously-issued verifiable credential. This is done by having the limited verifiable credential include only a selected subset of the verifiable claims present within the previously-issued verifiable credential. The limited verifiable credential may then be exposed to a relying entity computing system so that the relying entity computing system can verify any of the selected subset of verifiable claims, but not verifiable claims that are outside of the selected subset of verifiable claims.

Verifiable credential with dynamic claim

Technology that permits two computing systems to communicate with each other with high confidence that a particular entity is present at the other computing system. As an example, when a first computing system communicates with a second computing system, the first computing system may regularly verify that a particular entity is present at the second computing system. The first computing system is actually in control of a proof capture component on the second computing system. The first computing system causes the second computing system to automatically generate proof of presence, the proof evidencing that the particular entity is present at the second computing system. The first computing system also causes the second computing system to include the generated presence proof when communicating from the second computing system to the first computing system.

Network communication using proof of presence

A first chain of custody verifiable claim is received by a second entity from a first entity. The first chain of custody verifiable claim is signed by the first entity and specifies that an object was in the custody of the first entity. A distributed ledger is accessed to verify the first chain of custody verifiable claim. A second chain of custody verifiable claim is generated that embeds the first chain of custody verifiable claim and is signed by the second entity. The second chain of custody verifiable claim is recorded on the distributed ledger. The second chain of custody verifiable claim is provided to a third entity. The second chain of custody verifiable claim is configured to specify to the third entity that the object was in the custody of the second entity.

Trusted custody chain for verifiable claims

Derived child verifiable credential with selective claims

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

Encrypted verifiable credentials

A computing system retrieves a value of a device identifier of itself and generates a device claim asserting the value of the device identifier. The device claim is then associated with an identifier of a user of the computing system. The computing system then generates and attach proof code to the device claim to turn the device claim into a verifiable device credential (VDC). The proof code proves that the VDC is issued by the user of the computing system. The VDC is later presented to a relying entity as part of an identity protection system to further protect the user's identity.

Device asserted verifiable credential

Upgrading of a verifiable credential by a user interfacing with an upgrade control of a visualization of the verifiable credential. The upgradable verifiable credential includes an authorization claim specifying an authorization scope, and an enhancement claim specifying a condition for enhancing the specified authorization scope. A visualization of the upgradable verifiable credential is then display with the upgrade control to a user of a holder computing system that is the holder of the verifiable credential. Accordingly, if the user interacts with the upgrade control, the condition for upgrading the verifiable credential may be accomplished. The issuer of the authorization claim may then be notified of this. The issuer may then provide an ungraded verifiable credential that includes an authorization claim that includes more or a different authorization scope than the prior verifiable credential.

Visualization-assisted upgrade of verifiable credential

Cross-session acquisition of a verifiable credential. The first session includes generating a user secret known to the first session and to the user, and the generation of an encrypted identity token that includes claims about authentication of the user and the user secrete. In the second session, a second computing system uses the acquired identity token to get a verifiable credential. The user is prompted to prove knowledge of the user secret within the identity token. In response to successful proof of this knowledge and validation of the identity token, the issuer system issues a verifiable credential that relies upon one or more claims that were included within the identity token, and then provides the verifiable credential to the user.

Cross-session issuance of verifiable credential

The resolving of a decentralized identifier to a corresponding data structure using multiple resolvers. This allows for the use of a consensus of resolvers to improve trust in the resolution process. In order to resolve, a decentralized identifier is sent to multiple resolvers. In response, each of at least some of those resolvers will return a data structure of a particular type (e.g., a decentralized identifier document) that is associated with the decentralized identifier. Then, it is determined whether the data structure for at least some number of resolvers matches each other. That is, it is determined whether at least some predetermined threshold of resolvers is returning the same data structure (e.g., the same decentralized identifier document). If so, then it is determined that the matching data structure is indeed associated with the decentralized identifier. Otherwise, the resolution process has failed.

Resolving decentralized identifiers using multiple resolvers

A computing system is configured to receive user data from a user associated with a decentralized identifier (DID) and authenticate the user based on the DID via data recorded on a distributed ledger. In response to authenticating the user, the computing system stores the user data redundantly at each of a plurality of decentralized identity stores. One of the plurality of decentralized identity stores is designated as a primary decentralized identity store. In particular, redundantly storing the user data includes storing the user data at the primary decentralized identity store, and causing each remaining decentralized identity store in the plurality of decentralized identity stores to store the user data following the primary decentralized identity store.

Failover between decentralized identity stores

Bootstrapping trust in decentralized identifiers (DIDs) includes in response to receiving a request from an entity associated with a DID in a decentralized system, obtaining a DID document associated with the DID, and extracting a linked domain that is linked to the DID from the DID document. The DID document contains data associated with the DID that is recorded on the distributed ledger. The request contains the DID and data associated with the DID. Metadata associated with the linked domain is then retrieved from a domain name system (DNS). Based on the metadata associated with the linked domain and the data associated with the DID contained in the request, a trust score, indicating trustworthiness of the DID, is generated.

Bootstrapping trust in decentralized identifiers

Generating self-issued claims anchored by DIDs and using the self-issued claims as self-identification. The computing system generates one or more claims, each of which includes at least information related to (1) a DID, (2) a property of a subject entity who is an owner of the DID, and (3) a value corresponding to the property. For each of the one or more claims, the computing system generates a cryptographic signature by signing the claim with a private key associated with the corresponding DID. The cryptographic signature proves that the claim is a self-issued claim, which is issued by the owner of the corresponding DID and is about the owner of the corresponding DID. A portion of data related to the self-issued claim is then propagated onto a distributed ledger.

Decentralized identification anchored by decentralized identifiers

Generating a private key recovery seed based on random words extracted from an input memory of a user and using the recovery seed to recover the private key. An input that is related to a specific memory of a user is received. The specific memory was previously entered and used to generate random words that are related to each other by being included in the specific memory. The random words are extracted from the received input. The random words are associated with a first private key recovery mechanism for recovering a private key. The random words are input into the first private key recovery mechanism to generate a recovery seed. The recovery seed is input into a second private key recovery mechanism. The second private key recovery mechanism generates a recovered private key upon performing a recovery operation on the private key recovery seed.

Key recovery

The presentation of a verifiable credential that is represented within a data structure that represents the verifiable credential as well as usage data of the verifiable credential. The usage of the verifiable credential is monitored, such that as usage of the verifiable credential changes or progresses, the stored usage data also changes. This data structure may be used to not only cause visual representations of the verifiable credential to be displayed to the user, but the user can selectively cause at least some of that usage data to also be presented to the user. Thus, the user can easily keep track of how their verifiable credential is being used, regardless of where or from which device the verifiable credential is presented.

Growing community of inventors

Sammamish, WA, United States of America

Ankur Patel