Describe use of versionId (and maybe versionTime) DID parameters about tswg-did-method-webs-specification

[swcurran]

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?

[peacekeeper]

Do ACDCs have an issuance and/or validity date, like the "validFrom" property in the VCDM or "nbf" / "iat" claims in JWT?

[dhh1128]

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.

[dhh1128]

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

[dhh1128]

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.