This specification defines the DID Identity DID (DID) DID method, `did:did`

. that supports DIDs
based on any other DID method.

`did:did`

is a DID method that enables using any valid Decentralized Identifier (DID) as a `did:did`

DID.

The namestring that shall identify this DID method is: `did`

.
A DID that uses this method MUST begin with the prefix
`did: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 = "did:" did

Example DID Identity DID: `did:did:example:1234`

.

A DID Identity DID may be created by appending the prefix `did:`

to any existing DID.

To resolve a did: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:did:example:1234", "controller": "did:example:1234" }

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

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

Security considerations for the unprefixed DID method apply to any use of the `did: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:did`

with those DID methods inherits that characteristic.

A `did:did`

inherits any residual risks associated with its underlying DID.

User and applications should distinguish between a `did:did`

and its corresponding unprefixed DID, but understand that the unprefixed DID is the controller of the `did:did`

DID.

Unique assignment of DIDs using `did:did`

depends on the underlying unprefixed DID methods. Additional `did:did`

DIDs may be generated by appending successive "did:" prefixes to a DID.

`did:did`

may be used with an existing `did: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:did`

DID. The DID controller relationship is considered to be transitive for this purpose.

`did:did`

has no method-specific endpoints.

`did:did`

DID documents are resolved deterministically from the DID, and so do not rely on a signature on the document.
`did: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:did DID is trivially correlated with its underlying DID.

A `did:did`

DID supports DID URLs if the underlying DID method does, including use of paths. A DID URL based on a `did:did`

may be dereferenced by dereferncing the underlying DID.

The following is an example implementation of `did:did`

in the
J programming language to
resolve `did:did: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:did:did:example:123')

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