EP4690649A1

EP4690649A1 - An apparatus and a method for managing decentralized identifiers, an endpoint storing encrypted personal information and a decentralized identifier document

Info

Publication number: EP4690649A1
Application number: EP24712491.0A
Authority: EP
Inventors: Oleksandr VOLOSHKO; Rik CLAESEN; Kasper DE BLIECK
Original assignee: Sony Europe BV; Sony Group Corp
Current assignee: Sony Europe BV; Sony Group Corp
Priority date: 2023-03-30
Filing date: 2024-03-20
Publication date: 2026-02-11
Also published as: WO2024200166A1

Abstract

An apparatus for managing decentralized identifiers, DID, comprises circuitry operable in a first mode of operation. In the first mode of operation, the circuitry generates an asymmetric key pair based on a mnemonic seed (130) as well as a DID based on the asymmetric key pair.

Description

An apparatus and a method for managing decentralized identifiers, an Endpoint storing encrypted personal information and a decentralized identifier document

Field

Examples relate to management of decentralized identifiers, for example in terms of automated creation, backup and restore.

Background

Decentralized identifiers (DIDs) are identifiers that enable verifiable, decentralized digital identity. A DID identifies any DID subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that a controller of the DID decides it can identify. Other than federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. While other parties might be used to help to enable the discovery of information related to a DID, the design of the entire system enables the controller of a DID to maintain control over it without requiring permission from any other party. In a technical implementation, DIDs are Uniform Resource Identifiers (URIs) that associate a DID subject with a DID document enabling trustable interactions associated with that subject.

A DID maybe associated to an asymmetric key pair, enabling the DID subject to proof that he is the rightful owner of the DID.

A person or any other DID subject may have multiple DIDs associated to multiple key pairs. Management of multiple DIDs may become costly. Hence, there may be a demand for efficient management of decentralized identifiers.

Summary

Said demand is fulfilled by the subject matter of the independent claims. Embodiments of an apparatus for managing decentralized identifiers (DID) comprise circuitry to implement the apparatuses functionality. In a first mode of operation, the circuitry generates an asymmetric key pair based on a mnemonic seed and a DID based on the asymmetric key pair. A user of said embodiment only needs to memorize the mnemonic seed to be able to generate a decentralized identifier and its associated asymmetric key pair. Likewise, if the apparatus is lost, the DIDs are easily recoverable by using another apparatus together with the same mnemonic seed.

Embodiments of a method to backup personal information associated with a DID encrypt the personal information and store the encrypted personal information on an endpoint using an identifier associated to the DID. Not only the DID itself but also further personal information associated to the DID may so be automatically backed up so that the personal information is not lost even in the event that a user loses an apparatus for managing decentralized identifiers.

Brief description of the Figures

Some examples of apparatuses and/or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

Fig. 1 illustrates a schematic illustration of an apparatus for managing decentralized identifiers;

Fig. 2 illustrates generation of DIDs and backup of private information associated with the DIDs by an embodiment of the apparatus of fig. 1;

Fig. 3 illustrates generation of DIDs and recovery of associated private information using by embodiment of the apparatus of fig. 1; and

Fig. 4 illustrates a flowchart of an embodiment of a method to backup personal information associated with a decentralized identifier. Detailed Description

Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

Throughout the description of the figures same or similar reference numerals refer to same or similar elements and/or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and/or areas in the figures may also be exaggerated for clarification.

When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and/or B" may be used. This applies equivalently to combinations of more than two elements.

If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and/or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and/or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and/or a group thereof.

Fig. 1 illustrates a schematic illustration of an apparatus for managing decentralized identifiers 100. The apparatus comprises circuitry 110 configured to perform or execute an algorithm and to eventually interact with further external entities. The circuitry 110 may be implemented as one of or as a combination of configurable or non- configurable analog or digital elements, such as for example general purpose processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed or otherwise configured to perform the functions of the apparatus that will be described in greater detail in the following paragraphs. The apparatus itself may be implemented as a dedicated device (e.g. named a recoverable SSI Wallet) to implement said functions only or it may be embedded in another device providing further and eventually different functionality such as, for example, a mobile phone or a personal computing device.

The apparatus may optionally further comprise an input/output interface 120 to communicate with external devices or entities such as for example with external endpoints or public ledgers.

In a first mode of operation, the circuitry generates an asymmetric key pair 132 based on a mnemonic seed 130 and it generates a DID 134 based on the asymmetric key pair 132. While the embodiments described herein intend to ease management of one or more DIDs generated by an embodiment of an apparatus according to the present disclosure, the following description will focus on the use of a single asymmetric key pair 132 and its associated DID 134 for the sake of conciseness. It is to be understood, however, that embodiments may be capable to handle arbitrary numbers of DIDs in an identical manner. Asymmetric key pairs as described herein are commonly used in cryptographic applications. A DID may be a URI scheme conformant with [RFC3986] and composed of three parts separated by DID = "did:" method-name method-specific-id' . Figure one gives one particular example for a valid DID Syntax of no practical use: did:example: 123.. . abc.

A user of said embodiment only needs to memorize the mnemonic seed 130 to be able to generate not only the associated asymmetric key pair 132 but also the associated decentralized identifier 134. The associated decentralized identifier 134 is derivable from the asymmetric key pair 132 in a deterministic manner so that once the asymmetric key pair 132 is known a unique associated decentralized identifier 134 can be derived based on a single mnemonic seed 130. A mnemonic seed may, for example, consist of a passphrase with random words or a sentence of a book a user can remember well. Further embodiments may not only be capable to generate asymmetric key pairs 132 and associated DIDs 134 but also to manage them, for example to generate or store personal information associated to the DIDs, to back up the personal information and to restore the entire information based on the mnemonic seed 130 alone. Such optional further functionality will be subsequently described with respect to figs. 2 and 3.

Fig 2 will be used to describe functionality in a first mode of operation that may be also denoted as a normal mode of operation. In the first mode of operation, a user generates DIDs and associated personal information 136 and said information is automatically backed up for subsequent recovery in the event of loss of apparatus 100 presently used by the user.

Fig. 3 will be used to describe functionality in a second mode of operation where the backed up information is restored.

In the first mode of operation, the circuitry 100 also stores personal information 136 associated with the DID 134. The personal information 136 is generated using the DID 134 for verification and/or identification purposes and may be any type of information. For example, the personal information 136 may be one of a verifiable credential or the parameters of a DIDComm Messaging channel.

A verifiable credential can represent all of the same information that a physical credential represents. However, the addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts and also more accessible. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to proof they possess verifiable credentials with certain characteristics. At least one proof mechanism and the details necessary to evaluate that proof need to be defined for a credential or for presentation to be a verifiable credential or a verifiable presentation. The proof mechanism causes the credential to be verifiable. The verifiable credentials are generated using a DID to identify the subject of the verifiable credential. Hence, the DID is linked to the verifiable credential and the verifiable credential is an example for personal information 136 associated to a DID.

As a result of the generation, verifiable credentials are digital credentials for which everyone can verify the authenticity. An issuer issues credentials to a holder. The holder keeps the credentials safe and can provide it to a verifier to prove his identity. If the verifier trusts the issuer, they can verify the credentials and be sure the holder is legit. The standard is based on asymmetric encryption. The holder of verifiable credentials needs to take care of the cryptographic keys associated with his private DIDs, the credentials issued by the issuers.

A DIDComm Messaging Channel provides a secure, private communication methodology built atop the decentralized design of DIDs. The DIDComm Messaging Channel is established using the DIDs of the communicating partners and once established can be used without the necessity to reauthenticate using the DIDs. The parameters determined upon establishing the DIDComm Messaging Channel are another example for personal information 136 that is associated to a DID. The participant in a DIDComm channels needs to take care of the cryptographic keys associated with DIDComm channel and of the established DIDComm channels.

Depending on the implementation, any such type of personal information 136 may be input by a user that generates DIDComm Messaging channels, verifiable credentials or any other type of information manually. Alternatively, an embodiment may also generate the personal information 136 automatically upon user instruction.

Generally, publicly accessible DIDs and non-accessible private DIDs may be used in any of the embodiments. An anywise DID is a publicly resolvable DID and is also referred to as a public DID which is typically stored on a public ledger. A public DID can, for example, be used by a company or organization that wants to be contacted.

A pairwise DID is a non-publicly resolvable DID and is also referred to as a private DID. A private DID is typically used by a person and never made public. To establish a Self Sovereign Identity (SSI) connection with a private party whose DID cannot be looked up on a public ledger, both parties use a private DID. Any individual may use or re-use a newly generated private DID to avoid DID correlation and hence reveal his identity.

In order to provide for the functionality of automated backup of the previously described personal information 136 associated to a DID 134, the personal information 136 may be encrypted and an endpoint 140 can be made to store the encrypted personal information 138 together with an identifier associated to the DID 134. An endpoint may be any publicly available entity capable to store information, such as for example distributed ledgers of any kind. A distributed ledger can be characterized as a digital database that is spread across multiple nodes or computers in a network. In contrast to traditional centralized databases, where a single entity maintains control over the data, distributed ledgers are maintained collectively by a decentralized network of participants. Each node in the network has a copy of the ledger, and any changes made to the ledger are validated by the network through a consensus mechanism. This means that any updates to the ledger must be agreed upon by the majority of the network participants, making it difficult to manipulate or falsify data. Distributed ledgers so provide a secure and transparent way to store and manage data without the need for intermediaries. Alternatively, also a centralized storage may be used to store the encrypted personal information 138. The endpoint my, for example, be addressable by a URI.

In order to identify the encrypted personal information 138 once it is to be retrieved again, it is stored together with an identifier associated to the DID 134. According to some embodiments, the identifier associated to the DID 134 is the DID 134 itself or information depending on the DID 134 or on the asymmetric key pair 132 associated with the DID 134. Said dependency should to be such that there exists a one to one dependency between the DID 132 and the identifier so that the latter can be used for its purpose of identification.

According to some embodiments, encrypting the personal information 136 comprises encrypting the personal information 136 with a random key using symmetric encryption and encrypting the random key with the private key of the asymmetric key pair 132. In such an embodiment, the encrypted personal information 138 is stored on the endpoint 140 together with the encrypted personal information 138.

According to some embodiments, the circuitry further generates a DID document 150 having information on the endpoint 140. A conventional DID document 150 serves to define the interactions possible with a DID and the information retrievable from a third party from the DID. According to the embodiments, the DID document 150 is further generated such to additionally comprise information on the endpoint 152 which enables to access the endpoint 140 having stored the personal information 136 once one is able to read the DID document 150. For example, the information on the endpoint 152 may be a URI under which the stored encrypted personal information 138 can be retrieved from the endpoint 140. As initially mentioned, the description focuses on a single DID 132 having associated a single piece of personal information 136 to be backed up at a single endpoint 140. However, in further embodiments, a single DID 132 may likewise have associated multiple pieces of personal information which may be stored at a single endpoint or, alternatively, at multiple endpoints. Similarly, a single piece of personal information may be redundantly stored at different endpoint. As a consequence, a DID document of further examples may comprise information on multiple endpoints.

According to further embodiments, circuitry 110 is further configured to include information on an authorization mechanism 154 for the endpoint 140 into the DID Document 150. Said information may be used to indicate what kind of credential and authentication algorithm the endpoint 140 expects before allowing a user or the circuit 110 to download the encrypted personal information 138. According to the example illustrated in fig. 2, the credential is composed of the DID 132 itself and the authentication algorithm to use is defined to be RsaVerificationKey2018.

As compared to conventional DID documents comprising information on trustable interactions with the subject associate to the DID, DID documents 150 generated by embodiments of the present disclosure can - at least - further comprise information on an endpoint 152 having stored personal information associated to a subject of the DID 132.

According to some embodiments, circuitry 110 is further configured to submit the DID 132 and the DID document 150 to a public ledger 160 so that the DID document 150 is always accessible for restore purposes and identifiable by means of the DID 132.

According to a specific embodiment, both the DID 134 and the DID document 150 are stored in a smart contract on a public blockchain.

While automatic backup of DIDs and their associated private information is performed in the first mode of operation described previously, the second mode of operation performing automatic backup of the saved personal information associated to DIDs will subsequently be described with respect to fig. 3. Fig. 3 illustrates generation of DIDs and recovery of associated private information using an embodiment of the apparatus of fig.1.

In the second mode of operation, circuitry 110 generates the asymmetric key pair 132 based on the mnemonic seed 130. The mnemonic seed 130 may, for example, be input or provided by a user. The circuit further generates the decentralized identifier 134 based on the asymmetric key pair 132. Those operations are performed in the same deterministic manner used in the first mode of generation.

Once the DID 134 is generated, actual backup begins and the circuit 100 communicates with public ledger 160 to receive DID document 150 associated to the DID 134.

Once the DID document 150 is available, circuit 110 extracts the information on the endpoint 152 from the DID document 150 in order to subsequently communicate with the endpoint 140 to receive the encrypted personal information 138.

In some embodiments, circuitry 110 decrypts encrypted personal 138 information using the asymmetric key pair 132 and stores the resultant personal information 136.

After having stored the personal information 136, automated and secure restore of the personal information 136 associated to the DID 134 is complete without the user being required to memorize more than mnemonic seed 130.

According to some embodiments, decrypting the encrypted personal information 138 comprises decrypting an encrypted symmetric key received from the endpoint 140 using the private key of the asymmetric key pair 132 and subsequently decrypting the encrypted personal information 138 using the decrypted symmetric key.

In the event the that the endpoint 140 requires authentication before submitting the stored encrypted personal information 138, circuit 110 may receive a challenge as defined within the DID document 150 from the endpoint 140. The circuit 110 is then solving the challenge and submitting the result to the endpoint 140 to authenticate with the endpoint, making the latter submit the encrypted personal information 138 to the circuit. As compared to conventional endpoints storing information, an embodiment of an endpoint 140 for storing encrypted personal information 138 may hence comprise circuitry configured to receive a query to download encrypted personal information 138 and an identifier for the encrypted personal information 138. The circuitry of the endpoint may then access a DID document 150 associated with the identifier from public ledger 160 to extract authentication information 154 defined in the DID document 150. The circuit then submits a challenge to an originator of the query based on the authentication information 154 defined in the DID document 150 and only submits the encrypted personal information 138 if a response received upon the challenge is correct.

Fig. 4 illustrates a flowchart of an embodiment of a method 400 to backup personal information associated with a decentralized identifier.

The method comprising encrypting 410 the personal information and storing the encrypted personal information on an endpoint 420 using an identifier associated to the DID.

A further embodiment of the method optionally further comprises storing 430 the DID and an associated DID document on a public ledger as a smart contract.

The embodiments described previously may also be viewed as devices similar to a selfsovereign identity (SSI) hardware wallet. A conventional and safe way to store the cryptographic keys is self-sovereign identity (SSI) hardware wallets. An SSI wallet is a device designed to safely store digital, cryptographic credentials. The cryptographic public/private key pairs used by the wallet are generated using a Hierarchical Deterministic Tree (HDT), based on a mnemonic seed 130. The mnemonic seed 130 usually consists of a list of a passphrase with random words. One advantage is the deterministic nature of the seed. Whenever the same mnemonic is provided to the wallet, the same cryptographic keys will be generated. For example, if the device breaks, you can get a brand-new device, provide the mnemonic seed 130 and restore your keys. Only the mnemonic passphrase should be kept secret and safe. The HD tree structure allows to generate multiple key pairs, parent keys can create children that can become parents again. In summary, based on a single mnemonic seed 130, a tree of an arbitrary number of asymmetric key pairs can be generated deterministically. When the holder regenerates the keys, the personal information such as verifiable credentials are once again backed with cryptographic proof, and the holder of an embodiment of the present disclosure can prove his identity. A similar use case to verifiable credentials is DIDComm messaging channels. Where verifiable credentials are trying to leverage DID’s for decentralized credentials, DIDComm is trying to leverage DID’s for secure communication between parties. From the moment a connection is established between controllers of two DID’s, the parties can communicate securely without the need of future authentication. By the definition in the documentation, the purpose of DIDComm messaging is to provide a secure, private communication methodology built atop the decentralized design of DIDs. With of DIDComm Channels, same issues appear when disaster strikes. All communication channels are lost and the user is responsible to reinstate his own communication channels. Just like in the use case of verifiable credentials, it can be a tedious job to set up the correct channels for the correct keys. Backup and Recovery, however, may be automated by the embodiments disclosed herein as previously described.

For the use case verified credentials, the functionality of a specific embodiment may in other words be summarized as follows. In the first mode of operation of circuitry 100, a user generates the cryptographic keys (similar to a HD SSI wallet), keeping the mnemonic seed in a safe location. This mnemonic will determine the recovery of both keys and credentials. Whenever a verified credential is issued, it uses a decentralized identifier (DID) which will be linked to a specific key-pair in the SSI wallet. Using the private key, the holder will later be able to prove he holds the asymmetric key pair which created the DID. The credential is encrypted before it is being stored in an untrusted location. When the remote location is compromised, the data will still be kept secret. To encrypt the data, following steps are applied. A random symmetric key is generated and the data is encrypted using symmetric encryption. The symmetric key is encrypted using the public key linked to the DID. The symmetrically encrypted credential and the asymmetrically encrypted symmetric key are stored off-chain on a URI endpoint. Since the DID is unique, it can be used as an identifier in the URI as well (e.g. https://remote.eom/vc/did:example:12345jklm). The assumption is that the keepers of the verifiable credentials who are hosting this URI will return the credential only to people who can cryptographically prove they own the key-pair which generated the DID. This means having the is sufficient to retrieve the credentials, but no one else will be able to. Next to the DID, a DID document is created. This document will contain multiple fields, but also two related to the backup/recovery process. An authentication section defining verification specifications on how the holder (in this case the DID subject) can prove he owns the DID. For example, the information may consist of public key information and specifications about the authentication type. The URI of the off-chain location where the verifiable credentials can be found. As an alternative identification mechanism, one can use an ID that is derived from the private key. This can, for example, be a cryptographic hash of the private key itself of from its associated public key. The ID will then be part of the URI endpoint. The DID and the DID document are stored in a smart contract on a public blockchain. This allows the holder to look up the location of the credentials based on the DID. As the data is stored on a blockchain, it will be available at any point in time, from any location.

Similarly, for the use case verified credentials, the functionality of second mode of operation of a specific embodiment may in similar terms be summarized as follows.

In case disaster strikes, the holder of the mnemonic seed will be able to restore the entire information. Once the asymmetric key pairs were regenerated, an embodiment of circuit 110 will create the DID’s based on the key pairs in the and look up the DID documents on the public blockchain based on the different DID’s. It connects to the off-chain URI to fetch the symmetrically encrypted credential and the asymmetrically encrypted symmetric key as specified in the DID document. In this call, additional data for authentication will included. The data will be based on the private key, so the holder can prove he is the subject of the DID. Before returning any content for this DID, the host of the URI will look up the DID document for this identifier on the public blockchain. The verification specifications defined in the authentication field will be used to verify the authentication data provided in the call. For example a remote server (endpoint) looks up the DID document stored on the blockchain. The remote server collects the key information and authentication type from the DID document. The remote server sends back a challenge to the initial caller of the URI. An example of such a challenge would be to encrypt some data with the public key in the DID document and ask the caller to decrypt the message with the private key. If the caller is capable to do this, there is proof he owns the private key. Since the circuit which initially called the URI has access to the private key, it will be able to solve the challenge and send to send back a response with the solution to the remote server. The remote server verifies the response and trusts the caller to be the subject of the DID. When the DID authentication succeeds, the symmetrically encrypted credentials and the asymmetrically encrypted symmetric key from the URI specified in the DID document can be downloaded. The verifiable credential will be decrypted by decrypting the symmetric key using the private key in the linked to the DID and by subsequently decrypting the verifiable credential using the de- crypted symmetric key. As an alternative authentication mechanism, embodiments may, for example use a ZKP or ZK-SNARK or Bulletproof that proofs that we own the private key that generated the unique ID used in the URI endpoint to download the item without revealing the private key. Once all verifiable credentials are received, they are stored and the recovery procedure is complete.

Note that the present technology can also be configured as described below.

1. An apparatus for managing decentralized identifiers, DID, the apparatus comprising circuitry configured to, in a first mode of operation: generate an asymmetric key pair based on a mnemonic seed 130; and generate a DID based on the asymmetric key pair.

2. An apparatus according to (1), wherein the circuitry is configured to store personal information associated with the DID; encrypt the personal information; and cause an endpoint to store the encrypted personal information together with an identifier associated to the DID.

3. An apparatus according to (2), wherein the identifier associated to the DID is the DID or information depending on the key pair associated with the DID.

4. An apparatus according to (2) or (3), wherein the circuitry is further configured to generate a DID document having information on the endpoint.

5. An apparatus according to (4), wherein the circuitry is further configured to include information on an authorization mechanism for the endpoint.

6. An apparatus according to any one of (2) to (5), wherein the circuitry is further configured to submit the DID and the DID document to a public ledger.

7. An apparatus according to (6), wherein the circuitry is configured to cause a public blockchain to store the DID and the DID document in a smart contract.

8. An apparatus according to any one of (2) to (7), wherein encrypting the personal information comprises encrypting the personal information with a random key using symmetric encryption, and encrypting the random key with the private key of the asymmetric key pair.

9. An apparatus according to any one of (1) to (8), wherein the circuitry is further configured to, in a second mode of operation: generate an asymmetric key pair based on a mnemonic seed 130; generate a decentralized identifier based on the asymmetric key pair; communicate with a public ledger to receive a DID document associated to the DID; extract information on an endpoint from the DID document; communicate with the endpoint to receive encrypted personal information.

10. An apparatus according to (9), wherein the circuitry is further configured to decrypt the encrypted personal information using the asymmetric key pair; and store the decrypted personal information.

11. An apparatus according to (10), wherein decrypting the encrypted personal information comprises decrypting an encrypted symmetric key using the private key of the asymmetric key pair; and decrypting the personal information using the decrypted symmetric key.

12. An apparatus according to any one of (9) to (11), wherein the circuitry is further configured to receive a challenge defined within the DID document from the endpoint; and solve the challenge and submit the result to the endpoint to authenticate with the endpoint.

13. An Endpoint storing encrypted personal information, the endpoint comprising circuitry configured to receive a query to download encrypted personal information and an identifier; receive a DID document associated with the identifier from a public ledger; submit a challenge to the originator of the query based on authentication information defined in the DID document; receive a response to the challenge; determine whether the response is correct; and submit the encrypted personal information if the response is correct.

14. A method to backup personal information associated with a decentralized identifier, DID, the method comprising encrypting the personal information; and storing the encrypted personal information on an endpoint using an identifier associated to the DID.

15. A method according to (14), further comprising storing the DID and an associated DID document on a public ledger as a smart contract.

16. A decentralized identifier, DID, document comprising information on trustable interactions with an associated subject; and information on an endpoint having stored personal information associated to a subject of the DID.

The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and/or contain machine-executable, processorexecutable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and/or be broken up into several sub-steps, -functions, -processes or -operations.

If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the sub- ject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

Claims What is claimed is:

1. Apparatus for managing decentralized identifiers, DID, the apparatus comprising circuitry configured to, in a first mode of operation: generate an asymmetric key pair based on a mnemonic seed 130; and generate a DID based on the asymmetric key pair.

2. The apparatus of claim 1, wherein the circuitry is configured to store personal information associated with the DID; encrypt the personal information; and cause an endpoint to store the encrypted personal information together with an identifier associated to the DID.

3. The apparatus of claim 2, wherein the identifier associated to the DID is the DID or information depending on the key pair associated with the DID.

4. The apparatus of claim 2, wherein the circuitry is further configured to: generate a DID document having information on the endpoint.

5. The apparatus of claim 4, wherein the circuitry is further configured to include information on an authorization mechanism for the endpoint.

6. The apparatus of claim 2, wherein the circuitry is further configured to submit the DID and the DID document to a public ledger.

7. The apparatus of claim 6, wherein the circuitry is configured to cause a public blockchain to store the DID and the DID document in a smart contract.

8. The apparatus of claim 2, wherein encrypting the personal information comprises encrypting the personal information with a random key using symmetric encryption, and encrypting the random key with the private key of the asymmetric key pair.

9. The apparatus according to claim 1, wherein the circuitry is further configured to, in a second mode of operation: generate an asymmetric key pair based on a mnemonic seed 130; generate a decentralized identifier based on the asymmetric key pair; communicate with a public ledger to receive a DID document associated to the DID; extract information on an endpoint from the DID document; communicate with the endpoint to receive encrypted personal information.

10. The apparatus according to claim 9, wherein the circuitry is further configured to decrypt the encrypted personal information using the asymmetric key pair; and store the decrypted personal information.

11. The apparatus according to claim 10, wherein decrypting the encrypted personal information comprises: decrypting an encrypted symmetric key using the private key of the asymmetric key pair; and decrypting the personal information using the decrypted symmetric key.

12. The apparatus according to claim 9, wherein the circuitry is further configured to: receive a challenge defined within the DID document from the endpoint; and solve the challenge and submit the result to the endpoint to authenticate with the endpoint.

13. Endpoint storing encrypted personal information, the endpoint comprising circuitry configured to: receive a query to download encrypted personal information and an identifier; receive a DID document associated with the identifier from a public ledger; submit a challenge to the originator of the query based on authentication information defined in the DID document; receive a response to the challenge; determine whether the response is correct; and submit the encrypted personal information if the response is correct.

14. A method to backup personal information associated with a decentralized identifier, DID, the method comprising: encrypting the personal information; storing the encrypted personal information on an endpoint using an identifier associated to the DID.

15. The method of claim 14, further comprising: storing the DID and an associated DID document on a public ledger as a smart contract.

16. A decentralized identifier, DID, document comprising: information on trustable interactions with an associated subject; and information on an endpoint having stored per-sonal information associated to a subject of the DID.