made validFrom optional, fixes #1133

[awoie]

closes #1133, made validFrom optional (also fixed JSON schema)

---

Preview | Diff

[msporny]

I'm a bit unsure about this PR, but not going to block it if we have a good use case. Curious to understand the use case where one can't specify a validFrom date? I'm not sure how we're supposed to interpret a VC that doesn't have a validFrom date.

If validFrom is not present, but the proof clearly has a date on which it was created, can the verifier presume that as the validFrom date? If they can't presume that, then is the VC valid for all time leading up to the validUntil date? If there is no validFrom or validUntil date, then the VC is valid for all time?

If we have answers to the questions above, we should write them down in this PR. If we don't, then I'm a bit more concerned about the ecosystem issuing VCs that don't have any validity periods, or how those validity periods are going to be interpreted differently by different verifiers. Feels like an interop problem?

[msporny]

@msporny wrote:

I'm a bit unsure about this PR, but not going to block it if we have a good use case.

@awoie, ping. Any response on the use case request and questions asked above?

Also, there are now merge conflicts that need to be resolved.

[awoie]

I'm a bit unsure about this PR, but not going to block it if we have a good use case. Curious to understand the use case where one can't specify a validFrom date? I'm not sure how we're supposed to interpret a VC that doesn't have a validFrom date.

IMO, it is unnecessary in a lot of cases. IMO, we have the chance to remove bloat and validFrom is bloat in a lot of cases. The question should be, what are the use cases that really need validFrom (as defined in the current VCDM definition)? In a lot of cases, credentials are valid immediately after they have been issued. If somebody really wants to know "when" the VC was issued, they could look at proof.created or iat.

If validFrom is not present, but the proof clearly has a date on which it was created, can the verifier presume that as the validFrom date? If they can't presume that, then is the VC valid for all time leading up to the validUntil date? If there is no validFrom or validUntil date, then the VC is valid for all time?

My interpretation would be if there is no validFrom and no validUntil, it is valid for all time.

Unless (and that is not specific to making validFrom OPTIONAL), an issuer decides to extend VCDM and include their own extra validity period info that is out-of-scope of this specification. For that reason, I like the approach that was proposed by @OR13 here: #1027 (comment), where the issuer defines critical properties that a verifier is required to validate to consider the credential valid.

If we have answers to the questions above, we should write them down in this PR. If we don't, then I'm a bit more concerned about the ecosystem issuing VCs that don't have any validity periods, or how those validity periods are going to be interpreted differently by different verifiers. Feels like an interop problem?

[awoie]

@msporny also updated the PR to reflect the case when valid from and valid until are both not present.

[TallTed]

IMO, we have the chance to remove bloat and validFrom is bloat in a lot of cases

But it's vital in other cases, e.g., coupons. validFrom should certainly be optional, but it should not be dropped, as the above suggests.

It is important, when considering features of this global standard, not to force one's own use cases onto the world. Just because you don't have any use for validFrom (for example) does not mean no-one has a use for it.

[awoie]

IMO, we have the chance to remove bloat and validFrom is bloat in a lot of cases

But it's vital in other cases, e.g., coupons. validFrom should certainly be optional, but it should not be dropped, as the above suggests.

It is important, when considering features of this global standard, not to force one's own use cases onto the world. Just because you don't have any use for validFrom (for example) does not mean no-one has a use for it.

I was not suggesting to drop validFrom. If it was understood this way then I was not clear enough. My apologies for that. As the title of the PR and the linked issue suggests, this PR makes validFrom optional, and therefore removes "bloat" for use cases that don't require it while allowing other use cases to use this feature.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.