BTCR Resolver difference in resolving continuation documents based on im/mutable storage

[kimdhamilton]

BTCR Resolver specification describes different expectations depending on whether the continuation DID document (referenced in the OP_RETURN) is in an immutable store.

The reason is the simple issue that in BTCR, we don't know the DID until the transaction is confirmed (it's an encoding of the tx location once confirmed) and so we don't know the id to use in the DID document at time of creation. So we allow id fragments (e.g. "#keys-2") rather than full did values

We've dealt with this by considering continuation DID documents in an immutable store effectively signed by the transaction (i.e. the content address is part of the tx). Otoh, we require continuation DID documents in mutable stores (1) to be updated after issuance with the specific DID value and (2) signed

This requirement introduces the oddity that resolvers would have to be aware of which stores are mutable or not.

This might be acceptable since this can be associated with URI schemes (e.g. ipfs://), but let's ensure this is what we want.

[peacekeeper]

I always thought the Continuation DID Document was just a partial doc which gets merged into a final DID Document during the resolution process. Therefore this partial doc doesn't have to be valid/complete by itself, i.e. it doesn't need an @id, therefore it can be created when the Bitcoin transaction is submitted, and it doesn't have to be updated once the DID is known.

[kimdhamilton]

We decided not to handle the case of continuation documents in immutable storage for v0.1

https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/final-documents/btcr_0_1.pdf