intro.html

<h1>Introduction</h1>

<section class="informative">
    <h2>Overview</h2>

    <p>Most documentation about Decentralized Identifiers (DID) describes them as identifiers that are rooted in a public source of truth like a
        blockchain, a database, a distributed filesystem, or similar. This publicness lets arbitrary parties <a
                target="_blank" href="https://w3c-ccg.github.io/did-resolution/">resolve</a> the DIDs to an endpoint and
        keys. It is an important feature for many use cases.</p>

    <p>However, the vast majority of relationships between people, organizations, and things have simpler requirements.
        When Alice<code>(</code>Corp<code>|</code>Device<code>)</code> and Bob want to interact, there are exactly and
        only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve
        their DIDs, only Alice and Bob do. Peer DIDs are perfect in these cases. In many ways, peer DIDs are to public,
        blockchain-based DIDs what <a target="cryptoc"
                href="https://education.district0x.io/general-topics/understanding-ethereum/understanding-plasma/">Ethereum Plasma</a>
        or <a target="cryptoc" href="https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/">
            state channels</a> are to on-chain smart contracts&mdash; or what <a target="cryptoc"
                href="https://lightning.network/">Bitcoin's Lightning Network</a> is to on-chain cryptopayments. They move the bulk
        of interactions off-chain, but offer options to connect back to a chain-based ecosystem as needed. Peer DIDs create the conditions
        for people, organizations and things to have full control of their end of the digital relationships they are engaged in.
    </p>

    <p>Some formal terminology may make the application of this insight to DIDs clearer:</p>

    <dl>
        <dt><dfn>Anywise</dfn> DID</dt><dd>A DID intended for use with an unknowable number of parties (e.g., the global public
        or some subset thereof).</dd>
        <dt><dfn>Pairwise</dfn> DID</dt><dd>A DID intended to be known by its subject and exactly one other party (e.g., one
        usable in the Alice and Bob example just above).</dd>
        <dt><dfn>N-wise</dfn> DID</dt><dd>A DID intended to be known by exactly <em>N</em> enumerated parties including
        its subject. A business partnership with 3 members might be a modeled with n-wise DIDs. Pairwise DIDs are
        just a special case of an N-wise DID (<em>N</em> = 2). For more on n-wise DIDs, see <a href="#groups-info">
            Groups</a> in the appendices.</dd>
    </dl>

    <p>Generally, an anywise DID needs to be resolvable by strangers (i.e. publicly anchored DID). These strangers can use
        the DID to reference its subject (usually by resolving it on a public ledger) without establishing a relationship.
        On the other hand, pairwise and n-wise DIDs only need to be resolvable by the parties in the relationship, and
        <em>each</em> party in the relationship has to contribute a DID to make the relationship work. Because of the
        reciprocal nature of DID usage in enumerated relationships like this, we call the parties "peers", and it is this
        dynamic that gives our DID method its name.
    </p>
</section>

<section class="informative">
    <h2>Benefits</h2>
    <p>Peer DIDs are not suitable for <a>anywise</a> use cases, which are usually public by intent. However, peer
        DIDs have certain virtues that make them desirable for private relationships between a small number of
        enumerable parties:</p>
    <ul>
        <li>They have no transaction costs, making them essentially free to create, store, and maintain.</li>
        <li>They scale and perform entirely as a function of participants, not with any central system's capacity.</li>
        <li>Because they are not persisted in any central system, there is no trove to protect.</li>
        <li>Because only the parties to a given relationship know them, concerns about personal data and
            privacy regulations due to third-party data controllers or processors are much reduced.
        </li>
        <li>Because they are not beholden to any particular blockchain, they have minimal political or technical
            baggage.
        </li>
        <li>They can be mapped into the namespaces of other DID ecosystems, allowing a peer DID to have predictable
            meaning in 1 or more other blockchains (see <a href="#grafting">Grafting</a>). This creates an
            interoperability bridge and solves a problem with blockchain forks fighting over the ownership of a DID.
        </li>
        <li>Because they avoid a dependence on a central source of truth, peer DIDs free themselves of the often-online
            requirement that typifies most other DID methods, and are thus well suited to use <a target="aries"
            href="https://github.com/hyperledger/aries-rfcs/blob/master/features/0116-evidence-exchange/README.md">cases
            that need a decentralized peer-oriented architecture</a>. Peer DIDs can be created and maintained for an entire
            lifecycle without any reliance on the internet, with no degradation of trust. They thus align closely with
            the ethos and the architectural mindset of the <a href="https://www.inkandswitch.com/local-first.html"
            target="_blank">local-first</a> and <a target="_blank" href="http://offlinefirst.org/">offline-first</a>
            software movements.
        </li>
    </ul>
    <p>For more on when peer DIDs do and do not make sense, see <a href="#comparison">Comparison to Other DID Methods</a>
    in the Appendices.</p>
</section>