grafting.html

<h1>Grafting</h1>

<p>Because peer DIDs are globally unique at the moment of creation, their <a>numeric basis</a>
    will not exist on any other blockchain unless someone copies it there. Blockchain-based DID methods can
    therefore (redundantly) register a peer DID doc using their own method. We call this process <dfn>grafting</dfn>.
    Grafting might be useful when a peer DID needs to be accepted as the submitter or target of a transaction on a
    blockchain, when a blockchain is used as a deaddrop for a peer DID, when it's important to use existing DID
    tools that assume a global source of truth (e.g., <a href="https://github.com/decentralized-identity/universal-resolver"
            target="_blank">DIF's Universal Resolver</a>), or in other circumstances where a peer DID needs some form
    of partially public reference.</p>
<p>Grafting can be done in several ways.</p>
<ul>
    <li>By combining another DID method's prefix with a peer DID's encoded NSI: <code>
        did:peer:1z479...cbe &mdash;> did:xyz:1z479...cbe</code></li>
    <li>By creating a child namespace for peer DIDs beneath another method: <code>
        did:peer:1z479...cbe &mdash;> did:xyz:peer:1z479...cbe</code></li>
    <li>By re-encoding the <a>numeric basis</a> of a peer DID using rules of another method: <code>
        did:peer:1zQmZMygzYqNwU6Uhmewx5Xepf2VLp5S4HLSwwgf2aiKZuwa &mdash;>
        did:xyz:5pYZg1p63mAsAbJoBCb43FYK4Ducbn6bDz9btjQ5NwdPw</code> (here, the <code>xyz</code>
        method requires base58 but encodes numeric basis differently).
    </li>
</ul>
<p>There are pros and cons to each approach.</p>
<p>If a peer DID is registered and grafted into another DID namespace, using any grafting method,
    the result is two DIDs with different namespace&mdash;one peer and one anchored&mdash;each with
    its own DID doc. A decision must be made about which DID is normative for the relationship,
    or whether both should continue to be used. If both will be used, it should be understood that
    the two DID docs hold keys and other data for two different DIDs, regardless of the shared
    history of those DIDs. Ideally, there would be no difference between the DID docs stored in each place,
    but even with the best intentions of the DID controller, differences may arise.</p>