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.

`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
```

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`

.

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.

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

- Remove the "did:" prefix to obtain the
*unprefixed DID*. - Construct a DID document with the
`controller`

property set to the*unprefixed DID*. - Return the resulting DID document.

{ "@context": ["https://www.w3.org/ns/did/v1"], "id": "did:un-did:did:example:1234", "controller": "did:example:1234" }

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

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

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

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.

A `did:un-did`

inherits any residual risks associated with its underlying DID.

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-did`

DID.

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.

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

`did:un-did`

has no method-specific endpoints.

`did:un-did`

DID documents are resolved deterministically from the DID, and so do not rely on a signature on the document.
`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

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

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.

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.