Abstract: Embodiments disclosed herein are related to computing systems and methods for generating one or more pseudonymous names for use by a Decentralized Identifier (DID) owner when interacting with third party entities. An indication is received from a DID owner who is associated with a DID. The indication indicates that the DID owner desires to interact with various third party entities. A list is generated of pseudonymous names that are to be used in place of the DID as the DID owner interacts with the one or more third party entities. A selection is received for a specific one of the generated pseudonymous names. The selected specific pseudonymous name is bound to the DID so that the selected specific pseudonymous name is used during the interaction.

Abstract: Storing and executing an application in a personal storage with a user-granted permission in a decentralized network that implements a distributed edger. First, receiving a request from an entity for storing an application in a data storage that is associated with a DID owner. The application is configured to use data stored in the data storage as one or more inputs to generate one or more results. Next, one or more characteristics of the application associated with the entity is identified. Based on identified one or more characteristics, a write permission is to be granted to the entity, and the application is stored in the data storage. Thereafter, the application stored in the data storage is executed using data stored in the data storage.

Abstract: An attestation component to make attestations about itself to a relying party. The attestation component offers identity attestations of a particular decentralized identity, and manages use of a private key of that decentralized identity. However, the attestation component also has its own private key that is different than the private key of the decentralized identity for which it offers attestations. As an example, the attestation component might, using its own private key, provide an integrity attestation from which an integrity with which the attestation component has managed the private key of the decentralized identity may be determined. Based on this integrity attestation, a relying party can determine whether to trust other attestations provided by the attestation component on behalf of the decentralized identity.

Abstract: Embodiments disclosed herein are related to computing systems and methods for a DID owner to control the delegated use of DID-related data. Delegation permissions are attached to DID-related data objects that are provided by the DID owner to a first third-party entity. The delegation permissions specify interactions that should occur between a DID owner and second third-party entities who receive the DID-related data objects from the first third-party entity. The DID-related data objects are provided to the first third-party entity. Various interactions are received from the second third-party entities who attempt to use the DID-related data objects. The second third-party entities are allowed to use the DID-related data objects when the received interactions satisfy the delegation permissions.

Abstract: Encrypting and sharing one or more data objects stored or to be stored in a personal storage that is associated with a DID. First an encryption/decryption key is generated using a passphrase and an identifier of the personal storage that stores or is to store a data object in the personal storage. The data object stored or to be stored in the personal storage is then encrypted by the generated encryption/decryption key. The encrypted data object is then stored in the personal storage. The encrypted data object may then be accessed by a DID management module that is configured to manage the DID or be shared to another entity that is not associated with the DID.

Abstract: Embodiments disclosed herein are related to computing systems and methods for generating attestation User Interface (UI) elements based on signed attestations for use by a DID owner. Attestation UI elements are rendered by a DID management module. The attestation UI elements are based underlying DID signed attestations that provide information about the DID owner from various third party entities. The management module may receive physical input from the DID owner. In response to receiving the physical input, the DID owner may be provided access to the rendered attestation UI elements.

Abstract: Embodiments disclosed herein are related to the deauthorization of a private key associated with a decentralized identifier. While a user of a computing system is authenticated as a decentralized identifier, the system detects user input, and determines based on that user input that the private key associated with the decentralized identity is to be revoked. In response to this determination, the private key is deauthorized so that the private key cannot be used to perform actions for the decentralized identity at least until the private key is restored.

Abstract: Generation of a cryptographic key using one of multiple possible entropy generation components that may provide input entropy. A key generation component provides an interface that exposes one or more characteristics for input entropy to be used to generate a cryptographic key. For applications that are more sensitive to improper key discovery, higher degrees of input entropy may be used to guard against key discovery. During key generation, the key generation component connects with an appropriate entropy generation component via the interface. For instance, the entropy generation component may be selected or adjusted so that it does indeed provide the input entropy meeting the characteristics described by the interface. The key generation component receives the input entropy via the interface, and then uses the input entropy to generate the cryptographic key.

Abstract: Authorizing access to a verifiable claim so that a user who is the subject of the verifiable claim need not actively authorize the access. An access token is generated that is configured to provide access to a verifiable claim that was previously issued on behalf of a user that is the subject of the verifiable claim. The access token is then provided to an entity that is to be given access to the verifiable claim. The access token is next received from the entity when the entity attempts to access the verifiable claim and is validated. Finally, the entity is provided with access to the verifiable claim upon validation of the access token without the user having to actively authorize the access.

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: Decentralized authentication anchored by decentralized identifiers. A user indication is received. The user indication includes selecting at least one of a plurality of authentication mechanisms. In response to a user indication, a decentralized identifier and a DID document are generated. The DID document includes at least (1) data related to the decentralized identifier and (2) data related to the selected at least one authentication mechanism. At least a portion of data contained in the DID document is then propagated onto a distributed ledger.

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: Delegating a scope of permission between pairwise DIDs. First, a computing system determines a relationship between the first DID and a second DID. The first DID and the second DID are pairwise DIDs. Based on the relationship, the computing system delegates a scope of permission owned by the first DID to the second DID. In particular, the computing system defines the scope of permission, grants a public key of the second DID the scope of the permission. The delegation of the defined scope of permission is signed by a private key of the first DID, such that the signature is a proof of the delegation. A portion of data related to the delegation is then propagated onto the distributed ledger.

Abstract: Embodiments disclosed herein are related to making a determination that a wearable device that is configured to host or access a DID management module is in contact with the skin of a DID owner. A determination is then made that the DID owner is authorized to use a DID that is associated with the DID management module. Finally, one or more DID-related functions are performed using the DID that is associated with the DID management module by communicating with a second computing system that is associated with a second DID. The wearable device allows the one or more DID-related functions to be performed in a portable and secure manner.

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: 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: Embodiments disclosed herein are related to computing systems and methods for providing a self-help mechanism to DID owners. 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. One or more DID-related data such as a DID-related intent or attestation is received from a third party entity. The received DID-related data is analyzed to determine a meaning of the DID-related data and/or the implications of providing information that is requested in the DID-related data to the third party entity or to another entity. A report based on the analysis is provided to the DID owner. The report includes information about the meaning of the DID-related data and/or the implications of providing the data to the third party entity or to another entity.

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: Embodiments disclosed herein are related to computing systems and methods for a DID owner to control the delegated use of DID-related data. Delegation permissions are attached to DID-related data objects that are provided by the DID owner to a first third-party entity. The delegation permissions specify interactions that should occur between a DID owner and second third-party entities who receive the DID-related data objects from the first third-party entity. The DID-related data objects are provided to the first third-party entity. Various interactions are received from the second third-party entities who attempt to use the DID-related data objects. The second third-party entities are allowed to use the DID-related data objects when the received interactions satisfy the delegation permissions.

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.