Millisecond precision called for by VC data model

[vdods]

This is a rather wonky issue I encountered today in an interoperability effort.

Under https://www.w3.org/TR/vc-data-model/#issuance-date the spec says

issuanceDate
A credential MUST have an issuanceDate property. The value of the issuanceDate property MUST be a string value of an [XMLSCHEMA11-2] combined date-time string representing the date and time the credential becomes valid, which could be a date and time in the future.

which refers to [XMLSCHEMA11-2], and if you dig around hard enough, you find in that spec, under https://www.w3.org/TR/xmlschema11-2/#partial-implementation :

• All ·minimally conforming· processors must support ·second· values to milliseconds (i.e. those expressible with three fraction digits) in all datatypes which use the seven-property model defined in The Seven-property Model (§D.2.1) and have a non-·absent· value for ·second· (i.e. dateTime, dateTimeStamp, and time).
• All ·minimally conforming· processors must support fractional-second duration values to milliseconds (i.e. those expressible with three fraction digits).

I think this is not 100% clear, but the suggestion is that these DateTime values should have seconds to millisecond precision and no more. I would personally interpret the spec as "at least millisecond precision" (and this appears to be the case in a previous version of the XML schema), but I'm not sure that's the case. This may or may not have to do with the fact that the Javascript Date object is limited to millisecond precision.

My code (as well as the ssi crate impl, inside of VCDateTime struct) uses chrono::DateTime for these quantities, which keeps nanosecond precision. I think that's great and I like it that way. But in order to be compliant, it might call for rounding chrono::DateTime quantities to millisecond precision (or simply requiring that any chrono::DateTime quantities are supplied already rounded to millisecond precision.

Practically speaking, this could be achieved relatively easily by doing the rounding through the VCDateTime structure and its various trait impls. This potentially could break some round-tripping, if that's something people use, though if this exact-millisecond-precision interpretation is right, that use is based on a lie :-D

Thoughts?

[tristanmiller-spruceid]

Hi, thanks for writing this up!

You say that this came up in an interoperability effort. Is there a chance you can point to alternate implementations that have issues accepting more than 3 decimal digits in their date-times?

My own reading would be that a "minimally conforming" implementation must support 3 decimal digits (millisecond precision), but that implementations are allowed to exceed "minimum conforming" as long as they document.

But as always, interoperability is a topic more complex than language lawyering, so I'd love to know a bit more what issue specifically you were running into. Thanks!

[vdods]

I believe it's this: https://github.com/decentralized-identity/veramo -- I don't have personal experience using it, but another party in the space I operate in uses it. It seems to require exactly millisecond precision on timestamps.