Describe use of versionId (and maybe versionTime) DID parameters
peacekeeper opened this issue · 5 comments
Using the KEL, this DID method can nicely support a history of DID documents. The value of the versionId DID parameter could be a sequential number, or a KERI-specific way of identifying a "version of the KEL".
Supporting versionTime may be harder. According to PhilF:
KERI events don't have time associated with them per se, but implementations store their own local "first seen" date/time for each event. We could use that, but it gets tricky if the host of the DID Doc is the controller and the events are seen by a watcher that could be at some time after they actually occur
We only care about the timings in the KEL/TEL associated with the DIDDoc, if that helps.
It sounds like watchers process the events to create their own KEL/TEL, possibly with different times? Presumably that means the times are not part of the chain of events in the KEL/TEL, since using local times would result in different outcomes.
Is KERI only concerned with the ordering of events, and not their time, or does (local) time play into the event stream?
Do ACDCs have an issuance and/or validity date, like the "validFrom" property in the VCDM or "nbf" / "iat" claims in JWT?
Is KERI only concerned with the ordering of events, and not their time, or does (local) time play into the event stream?
I believe local time is a form of available metadata, but is not considered trustworthy. What is guaranteed is relative order.
Do ACDCs have an issuance and/or validity date, like the "validFrom" property in the VCDM or "nbf" / "iat" claims in JWT?
There is no guaranteed timestamp info in an ACDC; it has or doesn't have such info depending on the schema. https://trustoverip.github.io/tswg-acdc-specification/draft-ssmith-acdc.html#name-top-level-fields
To summarize my answers: I agree with @peacekeeper that versionId is trivial to support. KEL versions are simply numbered with sequential integers, so the value of the versionId arg would be a number like 1, 2, 3.
It is possible to support versionTime in specifically constrained KERI ecosystems, but there is no generic features upon which versionTime could be implemented with trustworthiness and precision. So I would vote that we simply not support it in this method.
Of these 2, I think versionId is actually far more useful, anyway. Distributed timestamping is a wicked hard problem.