DID Document versioning

[Drabiv]

I was thinking on how to make audit of DID Document updates as easy and as transparent as possible. How resolver of DID makes sure that it has that latest version of DID Document? If resolver needs to get the whole history of DID Documents for DID how it makes sure that it has a whole history without any omissions? I realise that this is DLT and DID method specific, but still are there any recommendations or explanation of the best way it should be done or about MUST requirements for this. Are any explanations of this for implemented DID Method specifications availalble?

Also, to make audit of DDoc history as transparent and as simple as possible I propose to add "updateNumber" property to DID Documents. On every DDoc update the value of updateNumber MUST grow by 1. Two or more DDocs with the same updateNumber, but with different content are NOT ALLOWED. This property would allow to have a clear audit trail of changes. It will allow to know from one glance how many changes happened with that DDoc.

[msporny]

We should raise this issue with the CCG. The proposal is to make versioning a responsibility of the DID Method where the version would go on the transaction/operation that is sent to or received from the ledger. That is, the version is metadata around the DID Document.

[kimdhamilton]

tl;dr I think we should move this issue to a CCG repo; most likely the DID method registry.

Right, at least informally, we've been approaching this as a responsibility of the DID method, in terms of the requirements it imposes on the resolver to ensure the latest version is obtained.

Regarding update numbers: for BTCR, we've specified updates as spending the output of an existing transaction; so in order to find the latest, all we care about is finding the end of the transaction trail and ensuring signatures (in continuation document/s) are consistent. In this case, the need to specify an updateNumber property in the continuation doc might be more of a bookkeeping burden than useful for disambiguation (but the resolver could calculate it if the property were desired...)

That said, in BTCR we've informally discussed the ability to update the continuation documents outside of the transactions (if the continuation document is not in an immutable ledger). In this case, an update number might be interesting, but hard to discover conflicts and enforce.

This brings up several points:

• If it is a responsibility of the method specs, this needs to be made explicit. It's clear that method specs must describe how to update the DID doc, but it's not clear they always address finding "the latest" (BTCR does but BTCR updates are entirely tied to the ...)
• We've discussed in the past the idea of getting a DID document at a specific point in time, if the DID method and ledger allow it. I'm still interested in keeping this scenario in mind (for longer-lived claims)
• It's not clear that DID method specs are supporting audit trails in general. We are interested in this for BTCR (and expose relevant metadata), but it has not been discussed across method specs afaik

[kimdhamilton]

Created issue in CCG community repo. The proposal is to address this as part of the DID resolver method spec

https://github.com/w3c-ccg/community/issues/20

Per CCG discussion, I believe this issue can be closed

[peacekeeper]

+1 to treating versioning and audit trails as method-specific. Not all DID methods can support version numbers in a way that is independently verifiable (such as in did:btcr if the off-ledger continuation doc changes, or in did:ipid if the IPFS document changes).

The primary way to ensure that a resolver returns the latest version of a DID document is to simply define this as a requirement for compliant methods and resolvers. If a DID method doesn't have a way to reliably return the latest version, then that method is broken.

[peacekeeper]

Just created issue https://github.com/w3c-ccg/did-resolution/issues/12 so we can also track this topic over there in the DID Resolution spec.