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

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: Inserting media data into existing media data in a way that ensures the inserted data is not accessible to all users. The computing system and methods are implemented in a decentralized network that implements a distributed ledger, the distributed ledger backing one or more decentralized identities (DID) for one or more users of the computing system. Access to a first portion of media data is granted to various users. The access is partially based on a DID that is associated with each of the users. A second portion of media data is received that is inserted into the first portion of media data. The second portion of media data is accessible by only some of the users who have access to the first portion of media data. Access to the second portion of media data is also partially based on the DID of each of the subset of users.

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: 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: 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: Executing an application within a scope of user-granted permission in a decentralized network that implements a distributed edger. First, receiving a request from an entity for using data stored in a data storage that is associated with a DID owner as one or more inputs of an application associated with the entity 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 scope of permission to access the requested data that is to be granted to the entity is determined. Then, the scope of permission is granted to the entity to use the data as the one or more inputs of the application associated with the entity. Finally, the one or more results from the application is received.

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