Microsoft Technology Licensing, LLC

Other

Brandon Brian Murdoch

Ankur Patel

Daniel James Buchner

Ronald John Kamiel Eurphrasia Bjones

Bailey Marie Bercik

Sydney Morton

Frank Michael Chiachiere

Nithya Ganesh

Raja Charu Vikram Kakumani

Muhammad Omer Iqbal

Guillermo P Proano

Daniel Godbout

Kim Cameron

Michael B Jones

Eric Christopher Sachs

Kristina Yasuda

Ronald Bjones

Steven J Ball

Pieter Kasselman

William Thomas

Logan Girvin

Daniel Luke Strockis

Andreas Mikolajewski

Preeti Rastogi

Prasanna Ramachandran

A digital wallet generates an identification value associated with a DID of a DID owner. The digital wallet generates a first request including the identification value for an authentication token from an identification provider. The first request is provided to the identification provider. The digital wallet receives, in response to the identification provider validating the first request, the authentication token that authenticates the digital wallet with a verifiable claim issuer including the identification value from the identification provider. The digital wallet generates a second request for one or more verifiable claims from the verifiable claim issuer. The second request includes the DID and authentication token including the identification value. In response to the verifiable claim issuer validating the authentication token and the identification value, one or more verifiable claims from the verifiable claim issuer are received by the digital wallet.

Securing authentication flows using a decentralized identifier

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

Methods for composable user journeys for user authentication via an identity experience framework are performed by systems and apparatuses. Initiating a user authentication process for an application triggers application calls for dynamic invocation of a specific identity policy, required by the application, of a number of identity policies managed by a host of the identity experience framework. User interfaces defined by the identity policies are provided from the host to the application for interaction by the user and entry of identity information needed to authenticate the user according to specified verification providers. Identity claims and token requests are provided from the application to the host which then authenticates the identity claims via the verification providers and mints a token that includes the claims required by the application, according to the identity policy. The application consumes the token to complete the token request and allow the user access to the application.

Identity experience framework

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.

Growing community of inventors

Henley-on-Thames, United Kingdom

Brandon Brian Murdoch