Identifying and parsing "continuation" DID documents

[kimdhamilton]

BTCR's use of "continuation" DID documents introduces the following problems:
1.type to identify a DID document in an external document
2. dealing with unknown terms in the DID document

Existing examples brush over (1) by searching the continuation document for a placeholder DID document type, e.g. DidDocument. If that approach is valid, we need to confirm what this type name is.

An alternate solution for (1) is to require that the continuation document is a standalone DID document; i.e. not nested.

Regarding (2), during BTCR resolution, we merge in known terms (e.g. authentication, publicKey) but need to define how to handle unknown terms. The current proposal is that we append all within the continuation DID document, and ignore everything else.

[rxgrant]

Naming for (1): How about DidDocumentContinuation or DidDocumentPatch?

Regarding the alternate solution of trying not to nest: nesting is a cheap module system that can reduce errors in updates and key rotation. Even if the BTCR spec ended up not supporting it, we'd still want to figure out the types for purposes of interoperability of DidDocument (diddo) tooling such as editing and compilation.

It would be nice if my BTCR diddo and my DID on a competing method both acted as thin bootstrapping wrappers around my main DidDocumentPatch.