grafting.html

<h2>Grafting</h2>
<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 either by combining another DID method's prefix with peer DID's NSI (<code>
    "did:peer:1-F1220abcd1234" &mdash;> "did:xyz:1-F1220abcd1234"</code>), or by creating a child namespace for peer
    DIDs beneath another method (<code>"did:peer:1-F1220abcd1234" &mdash;> did:xyz:peer:1-F1220abcd1234"</code>).</p>
<p>If a peer DID is registered and grafted into another DID namespace, using either method,
    the result is two DIDs with different namespaces, one peer and one anchored, 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>