`validFrom` and `validUntil` fields need better specification of `dateTime`

[aphillips]

Validity Period https://www.w3.org/TR/vc-data-model-2.0/#validity-period

validFrom A credential MUST have an validFrom property. The value of the validFrom 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. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid.

The text says a "combined date-time string", but this is not actually a type in XMLSchema 1.1. The type that is being referred to is dateTime.

A challenge of this data type is that it allows values both with (2023-06-15T00:00:00Z or 2023-06-15T00:00:00-08:00) and without (2023-06-15T00:00:00) time zone offsets. Since validFrom and validTo need to be interpreted as timestamp values, the spec should probably require that values without zone offsets be treated as being in the UTC time zone.

I would suggest writing this as:

validFrom A credential MUST have an validFrom property. The value of the validFrom property MUST be a string value of an [XMLSCHEMA11-2] dateTime string representing the date, time and timezone offset the credential becomes valid, which could be a date and time in the future. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. Values without a timezone offset MUST be treated as being in the UTC time zone.

(Note that the quotes/suggestions above are about validFrom: the same comments/edits apply to validTo)

Further, note that SEDATE is late in its review cycle and will likely become an RFC before terribly long. This extension of RFC3339 might assist in addressing some of the serialization woes found in XMLSchema.

(There has been extensive discussion of this issue in #1183. @aphillips will continue to make comments on that PR and others related to it. This issue was created to close the loop on I18N's tracker mechanism)

[msporny]

A challenge of this data type is that it allows values both with (2023-06-15T00:00:00Z or 2023-06-15T00:00:00-08:00) and without (2023-06-15T00:00:00) time zone offsets. Since validFrom and validTo need to be interpreted as timestamp values, the spec should probably require that values without zone offsets be treated as being in the UTC time zone.

Yes, that's correct and why we're trying to change to XMLSCHEMA11-2 dateTimeStamp, which requires the usage of a timezone offset. We've already seen some examples in the wild that didn't include a timezone offset and thus were being interpreted as local timezone (instead of Zulu timezone). While we have no reports of this blowing up on people in the field, it's only a matter of time until it does, so we're requiring a timezone to be included in all dateTimeStamp values (which every date time field uses at present). This is what this PR is attempting to do: https://github.com/w3c/vc-data-model/pull/1183

All this to say that your feedback is valid and we're already trying to address the issue. Thank you for your feedback on PR https://github.com/w3c/vc-data-model/pull/1183 ... we're trying to incorporate your feedback into the PR now.

[filip26]

@aphillips please note the referenced specification draft defines validUntil not validTo property. Let's stick with the current terms to avoid confusion. Thank you.

[David-Chadwick]

My belief is that the original text was created when it was thought that there was a difference between a credential and a verifiableCredential (i.e. the former lacked a proof). Now that it has been resolved that these two objects are identical, then we need to clarify the difference between the validFrom property in the DM and the created property in the data integrity proof and the nbf in the JWT/Jose spec, and between validUntil in the DM and expires in the data integrity proof and exp in the JWT.

We really do not need this duplication (if they are identical), but if they are different, we need to know the difference

[iherman]

The issue was discussed in a meeting on 2023-07-25

• no resolutions were taken

View the transcript

#### 3.2. `validFrom` and `validUntil` fields need better specification of `dateTime` (issue vc-data-model#1193) _See github issue [vc-data-model#1193](https://github.com/w3c/vc-data-model/issues/1193)._ **Manu Sporny:** assign to me and pre-CR.

[msporny]

PR #1183 was merged awhile ago, which I believe addressed the i18n review concerns (please confirm @aphillips).

PR #1211 addressed @David-Chadwick's concern about the difference between a "credential" and a "verifiable credential" (there is a difference, which is now documented in the core specification).

PR https://github.com/w3c/vc-data-integrity/pull/155 further clarified the difference between the timestamp on the signature and the time stamp on the verifiable credential.

The only thing that might be left to do is clarify this in the VC-JOSE-COSE specification, but I leave @David-Chadwick up to determine that by raising an issue on that specification (like he did on the Data Integrity specification) and requesting a similar PR to https://github.com/w3c/vc-data-integrity/pull/155 to further clarify the difference between the timestamps in JOSE/COSE land and the VC.

Therefore, since all of those PRs are now merged, and no other changes are contemplated to the VC specification, I believe we can close this issue. Please speak up if you disagree.