reserved.html

<h2>Reserved Values</h2>

<p class="note">This section is still being debated and may be removed. It got merged as a matter of git
    merge convenience, a bit before it was mature.</p>

<p>The sixteen peer DID values that have 64 identical hex digits (all 0s, all 1s, all 2s, etc) are reserved for
    testing, debugging, and other meta purposes. They cannot be resolved in a normal and valid way, since we haven't
    done the massive amount of computation that would tell us what DID Doc content would produce the associated numeric
    bases. Instead, they MAY trigger the special handling described below, beginning in implementations that offer
    support for this spec at <a>Layer 2a</a> or <a>Layer 2b</a>. Implementations SHOULD NOT define semantics that
    contradict these.
</p>
<dl>
    <dt>The <dfn>bitbucket DID</dfn> (did:peer:11-0000...0000)</dt>
    <dd><p>This DID is somewhat like <code>/dev/null</code>; it is a predefined identity that acts as a sink, accepting
        incoming messages but refusing to respond. Messages routed to this DID should be swallowed/deleted without an error.
        Thus <a href="https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#types-of-protocols"
                target="aries">1-step notification protocols</a> will always succeed when this DID is the target, and
        <a href="https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#types-of-protocols"
                target="aries">2-step request-response protocols</a> will always timeout waiting for a response. Resolving
        this DID should return a DID doc containing at least <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/tree/master/features/0114-predefined-identities#key-1-ed25519">
            key-1</a>, <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/tree/master/features/0114-predefined-identities#key-3-secp256k1">
            key-3</a>, and <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/tree/master/features/0114-predefined-identities#key-5-4096-bit-rsa">
            key-5</a> from the <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/tree/master/features/0114-predefined-identities">Aries
            Predefined Identities RFC (0114)</a>. This allows zero-setup interactions from various crypto foundations.
        [TODO: Do we need other key types?]</p>
    </dd>

    <dt>The <dfn>anywise self DID</dfn> (did:peer:11-1111...1111)</dt>
    <dd><p>
        This DID is somewhat analogous to the use of "loopback" or "localhost" in TCP/IP; it means an anywise or
        public "self" for whatever entity sees it in a DIDComm stack. An agent that emits a message for this DID
        should see the message come back to itself without passing through any mediators or relays, with no trust
        degradation in its <a href="https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0029-message-trust-contexts/README.md"
            target="aries">message trust context</a> and with minimal latency. Protocols that depend on cooperation from
        another party should always get maxiumum cooperation from this one; for example, an invitation to connect
        that arrives at this DID should always be accepted <code>:-)</code> &mdash; though negotiation of a new
        pairwise DID should ensue. Attempts to resolve this DID should return a DID Doc that contains the same set
        of keys as the <a>bitbucket DID</a>. This makes it a flexible, low-risk identity to connect with or talk to
        in a way that short-circuits many layers of communication complexity.
    </p>

    <dt>The <dfn>pairwise self DID</dfn> (did:peer:11-2222...2222)</dt>
    <dd><p>
        This DID is like the <a>anywise self DID</a> (including a DID doc the resolves to identical content except
        for the DID value). It differs in that it is assumed to already be connected in a pairwise relationship, and
        to be private. Thus, interacting with this DID is a great way
        to exercise any pairwise protocol without going through <a target="aries"
            href="https://github.com/hyperledger/aries-rfcs/tree/master/features/0033-did-exchange">DID Exchange</a>.
    </p>
    </dd>

    <dt>The <dfn>n3 DID</dfn> (did:peer:11-3333...3333) and the <dfn>n4 DID</dfn> (did:peer:11-4444...4444)</dt>
    <dd><p>
        These two DIDs are like the <a>pairwise self DID</a> (including a DID doc the resolves to identical content except
        for the DID value). They differ in that they are assumed to already be connected to the current context and
        to one another in a 3-wise relationship. That is:
    </p>
        <figure id="n3-n4">
            <img src="n3-n4.png"/>
            <figcaption>n3 and n4 are pre-connected to self and to each other</figcaption>
        </figure>
    </dd>

    <dt>did:peer:11-5555...5555 to did:peer:11-bbbb...bbbb</dt>
    <dd>No special semantics are defined for these, in the current version of the spec. Implementations or
        particular software packages may define them (or not) according to preference.</dd>

    <dt>The <dfn>corrupted DID</dfn> (did:peer:11:cccc...cccc)</dt>
    <dd>This DID should resolve to the string <code>invalid DID doc</code>, triggering JSON deserialization
        errors.</dd>

    <dt>The <dfn>disconnected DID</dfn> (did:peer:11-dddd...ddddd)</dt>
    <dd>This is a pairwise DID that does NOT have an active connection (e.g., that someone else knows about but
        that is unrecognized in the current context, or that has sent an <code>abandon_connection/announce</code>
        message).
    </dd>

    <dt>The <dfn>empty DID</dfn> (did:peer:11:eeee...eeee)</dt>
    <dd>This DID should resolve to a DID doc that is well formed JSON-LD but that contains no keys, no service
        endpoints, and empty containers for other sections. Attempting to interact with such a DID should trigger
        DID Doc validation errors but not raw JSON deserialization errors.</dd>

    <dt>The <dfn>never resolvable DID</dfn> (did:peer:11:ffff...ffff)</dt>
    <dd>This DID is reserved for triggering resolution errors. [[TODO: Markus, what is the equivalent of
        "not found" as a DID resolution error?]]</dd>
</dl>