We introduce did:self, a Decentralized Identifier (DID) method that does not depend on any trusted registry for storing the corresponding DID documents. Information for authenticating a did:self subject can be disseminated using any means and without making any security assumption about the delivery method. did:self is lightweight, it allows controlled delegation, it ofers increased security and privacy, and it can be used for identifying people, content, as well as IoT devices. Furthermore, DID documents in did:self can be implicit, allowing re-construction of DID documents based on other authentication material, such as JSON Web Tokens and X.509 certificates.
Identifiers in did:self are created using the thumbprint of a public key. Accordingly, DID documents
are protected by a proof generated by the DID controller; this proof can be validated with the public
key that was used for creating the corresponding identifier. Therefore, given a did:self DID and the
corresponding DID document and proof, any entity can verify their binding, as well as the correctness
and the integrity of the DID document. Similarly to self-signed digital certificates, proof vericfiation
does not require any auxiliary information. A unique feature of did:self is that it supports secure DID
sharing and controlled delegation. By leveraging this property, earlier versions of our DID method were
used for implementing content-centric security for Information-Centric Networking architectures [
In this paper, we introduce an update to the did:self specification that brings the following improvements: • DIDs can have a (human-readable) sufix that provides clearer semantics about the entities that share the same identifier. • We generalize the concept of proof and introduce implicit DID documents. To this end, we propose two methods for generating DID documents using JSON Web Tokens and X.509 certificates. This enables interoperability with existing authentication and authorization systems.
The remainder of this paper is organized as follows. In Section 2 we introduce DIDs. In Section 3 we present the design of our solution. In Section 4 we discuss related work in this area. We conclude our paper in Section 5.
Decentralized Identifiers (DIDs), defined by W3C, are a new type of globally unique identifier designed to enable individuals and organizations to generate their own identifiers using systems they trust. A DID architecture can be regarded as a key-value lookup system, where the key is the Decentralized Identifier (DID) and the value is a DID document. DID specifications allow multiple DID methods to co-exist; the main diferentiating factor among existing DID methods is how the resolution from a DID to the corresponding DID document is implemented. A DID is expressed as a URI composed of three parts separated by “:”; the first part is the word “did”, the second part is the DID method name, and the third part is a method specific identifier.
A DID document contains “properties”, serialized according to a particular syntax, that may include (among other things) verification methods (e.g., public keys) and verification relationships that express a relationship between a verification method and the DID subject. Examples of verification relationships are authentication, which means that a verification method is used for authenticating the DID subject, and assertion, which means that a verification method is used for verifying assertions, e.g., digital signatures, made by the DID subject.
Listing 1 illustrates an example of a DID document. The DID of the subject is
did:self:iQ9PsBKOH1nLT9FyhsUGvXyKoW00yqm_-_rVa3W7Cl0/device1 (line 2). In lines
310 a verification method is defined, which is a public key. This public key has an identifier (i.e.,
“#key1”), and it is encoded using the type “JsonWebKey2020” [
A did:self DID4 is generated by a controller who creates a public/private key pair. The did:self
identifier is the thumbprint of the JSON Web Key (JWK) representation of the controller’s public key
(as defined by RFC 7638 [
: :<ℎ> / < >
The corresponding DID document is protected by a proof generated using the controller’s private key. A controller is not necessarily the DID holder. Our method supports multiple holders per DID, each of which may use a public/private key pair it controls for implementing a verification relationship (e.g., authentication). As a motivating example consider the case of an IoT system, where the IoT system owner is the controller and each IoT device can be a holder. IoT devices can use a key pair they control to implement a verification relationship. In this case, for each IoT device a DID document is created that defines a verification relationship based on the public key that the device controls (see for example Listing 1). The proof for this document is generated by the controller. In this use case, for each IoT device a sufix can be added to the DID. Additionally, two IoT devices may share the same DID, allowing, for example, device rotation in case of failure or representation of virtual devices composed of multiple physical ones (e.g., “smart home”). This use case is illustrated in Figure 1, which shows two drones that share the same DID, but use a diferent authentication key.
A straightforward approach for creating a proof is by generating a JSON Web Signature (JWS) [
The payload of the JWS is the DID document. Therefore, validating such a proof is a simple three-steps process: (i) extract the public key from the JWS header, (ii) verify that the thumbprint of the extracted 4In the following we use the terms did:self DID and did:self identifier interchangeably public key is equal to the thumbprint included in the did:self identifier, and (iii) validate the JWS signature using as input the extracted public key and the DID document.
In the next sections we discuss how did:self can be used with JSON Web Tokens (JWT) and X.509 certificates.
A did:self DID document that includes a single verification method can be represented as a JSON
Web Token (JWT) [
iss sub cnf
The did:self identifier without any sufix The sufix of the did:self identifier
A public key controlled by the DID holder represented as a JWK
Listing 2 includes the payload of a JWT representing the DID document of Listing 1. Such a JWT is signed by the controller using its private key. The JWS header must include either the jwk claim whose value will be the JWK representation of the controller’s public key or the x5c field representing a certificate chain (see next section). Again, the JWT verification is a three-steps process: (i) extract the public key from the JWS header, (ii) verify that the thumbprint of the extracted public key is equal to the thumbprint included in the iss claim, and (iii) validate the JWS signature using as input the extracted public key and the JWT.
Listing 2: A did:self DID document represented as a JWT
Similarly, a did:self DID document that includes a single verification method can be represented as an X.509 certificate chain. The first certificate of the chain is a self-signed certificate that includes the controller’s public key and the did:self identifier (without any sufix) in the Subject Alternative Name field. This certificate is signed using the controller’s private key. The last certificate of the chain includes the holder’s public key and the did:self identifier (with a sufix if necessary) in the Subject Alternative Name field. The chain may include intermediate certificates issued by the DID controller. The intermediate certificates give greater flexibility to the controller, which can have multiple public did:self:<controller> DID document { } "id":"did:self:<controller>/lamp1" "verificationMethod":[{ "id":"#key1", … }], "authentication":["#key1”]
DID document { } "id":"did:self:<controller>/plug1" "verificationMethod":[{ "id":"#key1", … }], "authentication":["#key1”]
DID document { "id":"did:self:<controller>/drone1" "verificationMethod":[{ "id":"#key1", … }], "authentication":["#key1”] } } DID document { "id":"did:self:<controller>/drone1" "verificationMethod":[{ "id":"#key2", … }], "authentication":["#key2”] keys associated with its DID with varying level of security. The validation of the certificate chain follows the standard X.509 validation rules. Additionally, a verifier should verify that the thumbprint included in the Subject Alternative Name is the same as the thumbprint of the JWK representation of the public key included in the first certificate of the chain.
Although DID document registries management, they create lock-in conditions, decrease DID
selfsovereignty, and add communication overhead, which in some scenarios is intolerable. For this reason,
various eforts propose registry-less DID systems. NaCL:did [
did:peer [
did:web [
ION [
The Key Event Receipt Infrastructure (KERI) proposal [
Compared to all these DID methods, did:self is the only DID method that allows multiple DID documents per DID, as well as controlled DID document delegation. As we discuss in Section 4, these properties enable intriguing security and privacy features.
Due to the security and privacy characteristics of the DID paradigm, many research eforts investigate
the potential of using DIDs to improve the security and privacy of emerging technologies. Chadwick et
al. [
In this paper we presented the did:self DID method and introduced two new extensions: identifier sufixes and implicit DID documents. Our DID method gives controllers absolute control over their identifiers and removes any dependency on middlemen, hence increasing self-sovereignty and privacy. At the same time, did:self allows multiple DID documents per DID enabling delegation and sharing. Our solution is not only compatible with W3C specifications, but is also easier to integrate in existing systems, by removing the complexity of interacting with a DID registry.
By leveraging implicit DID documents, we presented two constructions for generating a did:self DID document: one using JSON Web Tokens and another based on X.509 certificates. This enables interoperability with existing authentication and authorization systems. At the same time however, it prevents taking advantage of the full potential of DIDs, since legacy DID documents can carry more information beyond a single public key.
Although the lack of a registry and the support for multiple DID documents per DID enable novel applications and ofer significant security and privacy advantages, they create challenges related to revocation. Currently, did:self replies mainly on the expiration time to handle revoked verification material, but other more eficient mechanisms are also being explored. [26] D. Lagutin, Y. Kortesniemi, N. Fotiou, V. A. Siris, Enabling decentralised identifiers and verifiable credentials for constrained IoT devices using oauth-based delegation, in: Proceedings of the Workshop on Decentralized IoT Systems and Security (DISS 2019), in Conjunction with the NDSS Symposium, San Diego, CA, USA, volume 24, 2019. [27] C. Munoz, SSI and eIDAS: a vision on how they are connected, 2019. URL: https://ec.europa.eu/ futurium/en/system/files/ged/eidas_supported_ssi_may_2019_0.pdf.