Design versioning features

[peacekeeper]

There is consensus that it should be possible to resolve earlier versions of a DID Document, in order to be able to validate proofs, authentication events, etc. at an earlier date. This raises a few topics:

1. When resolving a DID, the output data (DID Document and/or metadata) could include a version identifier and/or timestamps of last update, etc.
2. What if anything at all do we want to say about DID Document version identifiers (method-specific? could be sequential number, UUID, etc.).
3. We should define one or more input parameters for DID Resolution that request a DID Document a) with a given version identifier, or b) at a certain timestamp.
4. Note that while all DID methods MUST support updates, there is no requirement for DID methods to keep all previous DID Document versions, so this may be a method-specific feature.

Thoughts?

[TomCJones]

i would prefer date to version number myself. I can't see all methods agreeing on a common versioning scheme.

[TomCJones]

checking prior "versions" might not be supported by all methods, but i strongly suggest it be a "should" in the governance doc AND that the method always make clear if it is supported. I will not resolve a method that does not support this.

[TomCJones]

btw - another reason not to support "versions" defined by the method is that all versions MUST require a strong absolute ordering. Any mathematician will tell you that is harder to achieve than you might imagine. I certainly do not want to download an ordering algorithm for each method. The alternate is for the resolver spec to define ordering, which means unicode alphabet sets and all the rest. I believe we are past the time when the spec can mandate the use of ASCII in any field. And please require that all dates be UTC. ( an alternate is to use a version field that is a single integer.)

[peacekeeper]

See also w3c-ccg/did-spec#64