comparison.html

<h1>Comparison to Other DID Methods</h1>

<section>
    <h2>Ledger-oriented Methods</h2>
    <p>We could certainly build peer relationships with <a>anywise</a> DIDs based on a public ledger or a similar
        source of truth. However, in the same way that a company doesn't want the public to resolve private host
        names inside its corporate intranet, letting others resolve <a>pairwise</a> and <a>n-wise</a> DIDs is
        unnecessary, and it represents a privacy and security risk as well as a problem of cost, scale, and
        performance. We strongly recommend that peer DIDs be used for peer relationships.
    </p>
    <p>In a similar vein, peer DIDs could be used, hypothetically, for <a>anywise</a> scenarios. The main disadvantage
        would be the lack of a formal publication mechanism. Nothing would prevent a user from publishing a peer DID and
        its associated DID document on a website. However, information published in this way would be hard to discover,
        maintain as DID docs evolved, and integrate into interoperable applications. DID methods that use
        a public ledger or a similar source of truth are a better choice here, because they have authoritative
        answers to the publication problem.
    </p>
</section>

<section>
    <h2><code>did:key</code> and <code>did:nacl</code></h2>
    <p>
        The <a target="_blank" href="https://github.com/digitalbazaar/did-method-key-js">did:key</a> and <a target="_blank"
            href="https://github.com/uport-project/nacl-did">did:nacl</a> methods encode a public
        key directly as a DID value, and generate a very simple DID Doc in a deterministic way from that key. The only
        material that has to be generated or stored when using this method is the public key or DID itself; either
        can derive the other and the DID Doc. Using a <code>did:key</code> or <code>did:nacl</code> is very similar to
        sharing and then using a public SSH key.
    </p>
    <p>
        The benefit of these methods is their simplicity. Like peer DIDs, they have no dependence on an
        external source of truth, and they can be implemented in code with little effort. Like peer DIDs, they are
        cheap to create and use.
    </p>
    <p>
        However, <code>did:key</code> and <code>did:nacl</code> are not direct equivalent of peer DIDs. Here are some
        features of peer DIDs that they do not provide:
    </p>
    <ul>
        <li>In DID Doc, define an endpoint and routing for use in <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm">DID Communication</a>.</li>
        <li>Configure M-of-N policies so a stolen phone doesn't quickly mean a stolen DID.</li>
        <li>Delete or terminate a relationship and its DID.</li>
        <li>Use multiple agents with the DID--each of which has its own keys.</li>
        <li>Trust some keys more than others.</li>
        <li>Rotate, revoke, or retire keys without replacing the DID.</li>
    </ul>
    <p>
        Peer DIDs use a layering approach so the complexity of key rotation and updates need not be supported if only
        static, ephemeral use cases matter. This is the main complexity difference between peer DIDs and these other
        two methods, and is optional with peer DIDs. Peer DIDs also use multicodec to encode keys in the same way that
        <code>did:key</code> does. The hope is that these two methods will remain as similar as possible, and that
        Peer DIDs will be a logical upgrade choice when use cases go beyond those that <code>did:key</code> and
        <code>did:nacl</code> are designed to handle.
    </p>
</section>