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 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 disclosed herein are related to computing systems, and methods for determining patterns in received data that are indicative of common characteristics of the one or more users of a computing system. Data from first users of the computing system is received. The received data defines information about the first users. The type of the data that is received is determined by the first users. The received data is analyzed to determine one or more patterns in the received data. The one or more patterns are indicative of one or more common characteristics shared by the first users. Information related to the determined one or more patterns is provided to second users. The information includes a DID for each of the f first users that may be used by the second users to communicate with the first users.

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: The resolving of a decentralized identifier at a customized security level. When a decentralized identity is resolved, it is resolved into a data structure (e.g., a document) that corresponds to the decentralized identity. The resolving includes causing a user interface to be rendered to the user, detecting user interaction with the user interface, and then based on that user interaction identifying a level of resolver security to use when resolving that decentralized identifier. The method then resolve the decentralized identity using that identifier level of resolver security. As an example, higher levels of resolver security may be obtained by using consensus from multiple resolvers.

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.

Abstract: Performing late binding of a social network identification (ID) to a guest ID for use in an identity platform. A guest ID is created for a second user that gives access to a shared application of an identity platform that is associated with a first user. Subsequent to creating the guest ID, permission is requested from the second user to bind social network IDs of social networks of which the second user is a member to the guest ID. In response to receiving permission, binding the social network IDs to the guest ID is performed. The binding gives the identity platform access to profile attributes of the second user from the social networks, and allows it to write information such as a merit badge back on the second user's social network profile. A federation binding may also be created that allows the second user to sign into the shared application using their social network ID.

Abstract: Embodiments disclosed herein are related to computing systems and methods for broadcasting an intent of a first user to a second user of a decentralized network. 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. Intent from first users of the computing system is received. The intent data defines potential interactions between the first users and second users of the computing system. Broadcast messages are generated. The broadcast messages include a DID for each of the first users and information specifying the potential interactions. The generated broadcast messages are provided to the second users.

Abstract: Selecting a persona for a Decentralized Identifier (DID) and associated DID document based on a trust score. A request for data or services associated with an owner of various decentralized identifiers (DID) is received. Each of the plurality of DIDs may have an associated DID document. The associated DID document for each of the DIDs defines a persona based on an amount of identifying information included in the DID document. Based on the received request, a trust score is assigned to an entity that generated the received request. The trust score is at least partially based on the verifiability of an identity of the entity that generated the received request. Based on the trust score, the persona and the associated DID and DID document that should be used by the owner for interacting with the entity that generated the request is selected.

Abstract: Embodiments disclosed herein are related to computing systems and methods for providing a presentation interrupt for a DID attestation. A DID attestation is accessed that is issued by a first entity of a decentralized network. The DID attestation defines information that has been generated by the first entity about a DID owner who is the subject of the DID attestation. The DID attestation includes interrupt metadata that directs that the first entity be contacted prior to the DID owner being able to present the DID attestation to a second entity of the decentralized network. In response to the DID owner attempting to present the DID attestation to the second entity, the first entity is contacted as directed by the interrupt metadata. Authorization information is received from the first entity. The authorization information indicates if the DID owner is able to present the DID attestation to the second entity.

Abstract: Using an association data structure corresponding to a derived decentralized identifier of a subject entity to share a verified claim about the subject entity to one or more relying entities. A decentralized identifier of a subject entity is derived from a source decentralized identity of the subject entity. Next, an association data structure is created using the derived decentralized identifier. The association data structure is structured to be interpretable by a relying entity as demonstrating that a verified claim is about the derived decentralized identity. The relying entity is then caused to be provided the verified claim about the subject entity. The verified claim includes the association data structure that was created using the derived decentralized identifier.

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: Use of a validation data structure in order to securely communicate an encrypted claim that has a decentralized identifier as a subject. The sending system generates the validation data structure and presents the validation data structure to a user that owns the decentralized identifier. The sending system encrypts the claim using at least the validation data structure, and constructs a message that includes the encrypted claim, but which does not include the validation data structure. The relying party receives the message. However, without separately receiving the validation data structure from the user, the relying party computing system cannot decrypt the encrypted claim. If the user wishes the relying party computing system to have access to the claim, the user may communicate the validation data structure to the relying party computing system.

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: Channeling data with at least partially synchronized decentralized identity stores The computing system monitors latency in interfacing with each of at least some of the multiple of decentralized identity stores. In response to the computing system determining that data is to be channeled between (e.g., written to or read from) one of the decentralized identity stores and the computing system, the computing system selects one of the decentralized identity stores based on the monitored latency of each of at least some of the multiple decentralized identity stores. Then, the data is channeled with the selected decentralized identity store. For instance, that data might be read from or written to the selected decentralized identity store.

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 a DID owner to select a permission scope for sharing DID-associated data. A set of permission scopes are accessed for DID-associated data. The DID-associated data is associated with a DID of a DID owner. The set of permission scopes define entities whom are to be given access to the DID-associated data by the DID owner. The DID owner is prompted to select a specific permission scope of the set of permission scopes for one or more of the DID-associated data. The selected permission scope is applied to the one or more of DID-associated data. The selected permission scope defines the specific entities that are to be given access to the one or more of the DID-associated data.

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.