Minor change to validFrom requested

[David-Chadwick]

validFrom is currently defined as

If present, 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 grammatical meaning of this paragraph is that the credential becomes valid at some point in the future, but it does not cater for the past. Please replace with

If present, 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 either became valid, or will become valid i.e. 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 is valid.

[TallTed]

Tweaked replacement (NOTE: some URIs here and above point to pr-preview targets... this text cannot be cut-and-pasted; it must be manually merged into the existing doc):

If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] combined date-time string value representing the date and time the credential became, or will become, valid. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property is valid.

[dlongley]

Note that this value represents the earliest point in time at which the information associated with the credentialSubject property is valid.

It applies to all the information in the VC -- so while this is true, saying this may cause people to think it doesn't apply to everything else too (e.g., the issuer field or the credentialStatus field).

[TallTed]

Re-revised. Better, @dlongley?

If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] combined date-time string value representing the date and time the credential became, or will become, valid. Note that this value represents the earliest point in time at which any information in the VC — including that associated with any credentialSubject property and any metadata about the VC itself (e.g., the issuer property or the credentialStatus property) — is valid.

[dlongley]

Yup, thanks, @TallTed!

[TallTed]

@David-Chadwick — What say you? Should the paragraph draft above go into the document(s)?

[David-Chadwick]

No I dont agree with the second change unless the validUntil definition is similarly updated. It is important that both validFrom and validUntil are consistently worded. To remind you, this is the current text of validUntil

If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value exists, the validUntil value MUST be temporally greater than the validFrom value.

You will note that my original change to validFrom was consistent with the current validUntil.

So we either update both validFrom and validUntil with @dlongley 's proposed change, or neither.

[TallTed]

@David-Chadwick -- So, if I understand you correctly, you do agree with the latter validFrom version (reproduced below, with small edits) if both validUntil and validFrom are changed in similar fashion, so with validUntil defined as below? Please confirm.

• If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] combined date-time string value representing the date and time the credential became, or will become, valid. Note that this value represents the earliest point in time at which any information in the VC — including that associated with any credentialSubject property and any metadata about the VC itself (e.g., the issuer property or the credentialStatus property) — is valid. If a validUntil value also exists, the validFrom value MUST be temporally earlier than the validUntil value.

• If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] combined date-time string value representing the date and time the credential ceased, or will cease, to be valid. Note that this value represents the latest point in time at which any information in the VC — including that associated with any credentialSubject property and any metadata about the VC itself (e.g., the issuer property or the credentialStatus property) — is valid. If a validFrom value also exists, the validUntil value MUST be temporally later than the validFrom value.

@dlongley (and anyone else) -- Please confirm whether you agree with the above, and if not, where your disagreement lies.

[David-Chadwick]

@TallTed Yes, very good. Thanks

[dlongley]

@dlongley (and anyone else) -- Please confirm whether you agree with the above, and if not, where your disagreement lies.

Looks good to me. I guess we should probably adjust the MUST statements to allow for equivalent times as well (for whomever wants a VC to be valid for exactly one particular second):

If a validUntil value also exists, the validFrom value MUST be temporally the same or earlier than the validUntil value.

And:

If a validFrom value also exists, the validUntil value MUST be temporally the same or later than the validFrom value.

[TallTed]

Now we just need a PR.... :-)

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

2.7. Minor change to validFrom requested (issue vc-data-model#1231)

See github issue vc-data-model#1231.

Brent Zundel: next is 1231. minor change to validFrom. change to normative language so before CR.

[msporny]

@TallTed wrote:

Now we just need a PR.... :-)

Done. :)

PR #1250 has been raised to address this issue. This issue will be closed once PR #1250 is merged.

[David-Chadwick]

Unfortunately the version of the pr as at 22 Aug 23 still does not contain the required and agreed upon text

[TallTed]

Unfortunately the version of the pr as at 22 Aug 23 still does not contain the required and agreed upon text

PR #1250 was updated during the 2023-08-22 call.
(Note ambiguity of "22 Aug 23", disambiguated by using ISO8601 format)