Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Embodiments are related to computing systems and methods for event based transfer of DID delegated authority. An indication is received that a first DID user is attempting to use a delegated DID on behalf of a second DID user. The first DID user has previously been delegated authority to use the delegated DID by operation of a legal relationship or a legal agreement between the first and second DID users. A determination is made if an event has occurred that has changed the legal relationship or the legal agreement between the first and second DID users. If an event has occurred, the delegation of authority to use the delegated DID is automatically revoked such that the first DID user is no longer able to use the delegated DID. If an event has not occurred, the first DID user is allowed to continue to use the delegated DID.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A first verifiable claim is received at a second entity from a first entity. The first verifiable claim is signed by the first entity. A second verifiable claim is generated. The second verifiable claim embeds the first verifiable claim therein and specifies a service that is to be performed on behalf of a fourth entity. The second verifiable claim is provided to a third entity. The second verifiable claim is configured to cause the third entity to verify the signature of the first entity with a public key associated with a decentralized identifier (DID) of the first entity to determine that the first entity is a trusted entity that is able to verify that the second entity is authorized to specify the service to be performed on behalf of the fourth entity.

Abstract: Embodiments disclosed herein are related to generating and using a private key recovery seed based on random words extracted from a generated story to recover the private key. An input story is received from a user. The story includes random words and filler words that were previously generated. The number of random words generated is based on an entropy level. The random words included in the story are extracted. This means that the user does not need to enter any random words that are not included in the story to recover the private key. The random words are input into a first key recovery mechanism to thereby generate a private key recovery seed. The private key recovery seed is then input into a second private key recovery mechanism, the second private key recovery mechanism generating a recovered private key upon performing a recovery operation on the private key recovery seed.

Abstract: 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.

Abstract: Embodiments disclosed herein are related to computing systems and methods for localizing how a user will receive and view received DID-related data. The computing system and methods are implemented in the decentralized network that implements a distributed ledger that backs one or more decentralized identities (DID) for one or more users of the computing system. Various sets of rule are accessed. The sets of rules specify how a DID owner will receive and view DID-related data received from a third party entity. The sets of rules are applied to the DID-related data received from the third party entity. The received DID-related data is modified such that the received DID-related data conforms to the one or more sets of rules. The modified DID-related data is provided to the DID owner so that the DID owner is able to view the modified DID-related data according to the applied sets of rules.

Abstract: Enforcing different policy rules that are applicable to different types of data stored at a decentralized storage service that uses a distributed ledger to authenticate and/or authorize users. Receive a request from an entity for operating on data stored or to be stored in a storage that is associated with a DID. A type of data that is requested to be operated on is then determined. One or more policy rules that are applicable to the determined type of data are accessed. Based on the one or more policy rules, determine if the operation to be performed on the data will result in the data complying with the one or more policy rules. Based on the determination, allow the request when the operation will result in the data complying with the one or more policy rules.

Abstract: Executing an application in a container within a scope of user-granted permission in a decentralized network that implements a distributed edger. Receiving a request from an entity for using data stored in a data storage that is associated with a DID as one or more inputs of an application associated with the entity to generate one or more results. One or more characteristics of the application is identified. Based on the identified characteristics, a scope of permission to use the requested data is determined. Next, the scope of permission is granted to a container where the application is stored or is to be stored. The application is then executed in the container using the data within the granted scope of permission as input to generate one or more results.

Abstract: Updating a verifiable claim so that a duration of the verifiable claim can be modified without direct user input. A plurality of verifiable claims that have previously been issued to a user are accessed by a computing system. The plurality of verifiable claims include duration metadata that defines a duration of each of the plurality of verifiable claims. The duration metadata of each of the plurality of verifiable claims is monitored to determine those of the plurality of verifiable claims that are set to expire based on the defined duration. For those verifiable claims that are set to expire, a request is made to a party that issued each verifiable claim for update information that is configured to modify the duration of each verifiable claim. In response to receiving the update information, the duration of each verifiable claim is automatically updated without the need for any direct user input.

Abstract: Enforcing different policy rules that are applicable to different types of data. A plurality of DIDs and a plurality of storages are managed by a computing system. Each of the plurality of storages is associated with at least one of the plurality of DIDs. Receive a request from an entity for operating on data stored or to be stored in one of the plurality of storages. Determine a type of the data requested to be operated on. Access one or more policy rules that are applicable to the type of the data. Based on the accessed one or more policy rules, determine whether the operation to be performed on the data will result in the data complying with the one or more policy rules. Based on the determination, allow or deny the request.

Abstract: 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.

Abstract: Failover between decentralized identity stores in the context of there being multiple decentralized identity stores that are each under the control of a single decentralized identity to store data belonging to or regarding the decentralized identity. Third parties can use the decentralized identity to at least conditionally access the data of the primary decentralized identity store. However, in response to detecting a failover event, one of the remaining decentralized identity stores is promoted as the new primary decentralized identity store. As part of this promotion, the new primary decentralized identity store replaces the old primary decentralized identity store as being the decentralized identity store that is accessed using the decentralized identity.

Abstract: Delegating use of a DID from a first DID owner to a second DID owner. An indication is received that a first DID owner desires to delegate use of a DID owned by the first DID owner to a second DID owner. This may allow the second DID owner to act on behalf of the first DID owner in interactions with third-party entities. A signed claim is generated that specifies that the first DID owner has delegated use of the DID to the second DID owner. The signed claim identifies the DID owned by the first DID owner and defines a scope of permission for the second DID owner when the second DID owner uses the delegated DID on behalf of the first DID owner. The signed claim may then be provided to the second DID owner.