This specification defines the DID Identity DID (DID) DID method, did:un-did. that supports DIDs based on any other DID method including and most especially the did:did: did method.

Introduction

did:un-did is a DID method that enables using any valid Decentralized Identifier (DID) as a did:un-did DID, but more importantly it un-does the did that did:did did method performs.

Example of use: did:un-did:did:example:abc123

Core Concepts

DID Identity DID Scheme

The namestring that shall identify this DID method is: un-did. A DID that uses this method MUST begin with the prefix did:un-did. As per the DID specification, this string MUST be in lowercase.

The full DID Identity DID scheme is defined by the following ABNF, based on DID Syntax:

did     = "did:" un-did

Example DID Identity UN-DID: did:un-did:example:1234.

Operations

Authorization

Any authorization valid for the DID Controller (the unprefixed DID) SHOULD be accepted as valid for its corresponding did:un-did DID.

Create (Register)

A DID Identity DID may be created by appending the prefix un-did: to any existing DID including the did:did: method, which undoes the did that the did:did: method attempts to modify.

Read (Resolve)

To resolve a did:un-did DID, the following steps MUST be followed:

  1. Remove the "did:" prefix to obtain the unprefixed DID.
  2. Construct a DID document with the controller property set to the unprefixed DID.
  3. Return the resulting DID document.
{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:un-did:did:example:1234",
  "controller": "did:example:1234"
}

Update (Replace)

As a did:un-did DID is purely generative, there is no Update operation.

Delete (Revoke)

As a did:un-did DID is purely generative, there is no Delete operation.

Security & Privacy

Security Considerations

Security considerations for the unprefixed DID method apply to any use of the did:un-did DID method, including regarding forms of attack such as eavesdropping, replay, message insertion, deletion, modification, denial of service, storage or network amplification, and man-in-the-middle.

A full list of requirements for this section may be found at W3C Decentralized Identifiers 7.3

Denial of Service

Implementations must take care to avoid unbounded stack growth through repeated prefixing of "did:" in input DIDs. Implementations may set a maximum dID length or "did:" nesting level for this purpose.

If some DID methods have a high resource burden, use of did:un-did with those DID methods inherits that characteristic.

Residual risks

A did:un-did inherits any residual risks associated with its underlying DID.

Misattribution

User and applications should distinguish between a did:un-did and its corresponding unprefixed DID, but understand that the unprefixed DID is the controller of the did:un-didDID.

Uniqueness of assignment

Unique assignment of DIDs using did:un-did depends on the underlying unprefixed DID methods. Additional did:un-did DIDs may be generated by appending successive "did:" prefixes to a DID.

Chaining

did:un-did may be used with an existing did:un-did DID, with arbitrary levels of nesting. Each DID document has as its controller the DID obtained by removing a single "did:" prefix, forming a chain back to the non-did:un-did DID. The DID controller relationship is considered to be transitive for this purpose. As you can imaging the nesting could be considered a feature with multiple layers of complexity that only could be considered computationally.

Consider the folling complex Nested Chaining approach

did:un-did:did:un-did:did:example:abc123

This could also be applied to the did:un-did: did method itself

did:un-did:un-did:example:abc123

This approach un-did (un-does) the did that the did:un-did: did method does resulting in the original did:example:abc123 did method did.

Method-specific endpoint authentication

did:un-did has no method-specific endpoints.

Signatures on DID Documents

did:un-did DID documents are resolved deterministically from the DID, and so do not rely on a signature on the document.

Privacy Considerations

did:un-did offers no privacy guarantees other than those of the underlying DID methods.

A full list of requirements for this section may be found at W3C Decentralized Identifiers 7.4

Correlation

A did:un-did DID is trivially correlated with its underlying DID.

DID URLs

A did:un-did DID supports DID URLs if the underlying DID method does, including use of paths. A DID URL based on a did:un-did may be dereferenced by dereferncing the underlying DID.

Reference Implementations

The following is an example implementation of did:un-did in the J programming language to resolve did:un-did:example:123 to did:example:123 in O(n) + C runtime where n is the number of resolutions:

j=: #@[ }. <@[ ;@,. ]
s=: #@[ }.each [ (E. <;.1 ]) ,
':' j 'did' ; (< 'did') (~: # ]) (':' s 'did:un-did:did:example:123')

At this point, DID resolution proceeds as per the DID's method.

Resources