issuanceDate/expirationDate and validFrom/validUntil

[msporny]

We had added a warning to the VCDM spec that we were eventually going to deprecate issuanceDate/expirationDate and replace it with validFrom/validUntil.

https://www.w3.org/TR/vc-data-model/#issue-container-generatedID-13
https://www.w3.org/TR/vc-data-model/#issue-container-generatedID-15

The "date the credential was issued" is represented by the created property on the proof if using a DataIntegrityProof and iat if used in a JWT. The "validity period" for a VC used to be from issuanceDate to expirationDate, but then some reviewers confused those terms for "the date the credential was issued", so the group came to consensus on renaming these properties to validFrom and validUntil to make it more clear what was going on -- as well as moving away from the "Date" language since the value range was a date-time.

There was an attempt at applying this change in the v2 context, but there were objections to the deprecation of issuanceDate and expirationDate.

The purpose of this issue is to determine if we are going to deprecate issuanceDate/expirationDate and rename to validFrom/validUntil or if we are going to do something else.

[selfissued]

As described in issued #918, I believe this would move us in the wrong direction - towards unnecessary and useless complexity.

[awoie]

I would be ok with the following two options:

Option 1: keep a property in the VC data model that represents the time of issuance and expiration:

• deprecate issuanceDate since the semantical definition is a bit misleading.
• keep expirationDate since it is less controversial and it maps onto exp JWT claim.
• add issued that is semantically the same as the iat JWT claim.
• add validFrom that is semantically the same as nbf JWT claim.

Option 2: move issuance and expiration dates to Data Integrity and VC-JWT specs

• deprecate issuanceDate
• deprecate expirationDate
• define iat and nbf and exp in VC-JWT spec
• define created in Data Integrity spec (already commonly used)
• define expirationDate in Data Integrity spec (to my knowledge this is not always used)

I prefer Option 1 since I see both expiration and issuance part of the core VC Data Model. From an implementers perspective, it would be also easier since it is a common use case to understand when a VC was issued and when it does expire and it should work across proof formats.

Option 1:

VC vc1 = fromJwt(jwt); // JWT proof
VC vc2 = fromJsonLd(jsonld); // Data Integrity proof

process(vc1);
process(vc2);

function process(VC vc) {
  if (v.issued < Date.now())
    console.log("error");
}

Option 2:

VC vc1 = fromJwt(jwt);
VC vc2 = fromJsonLd(jsonld);

process(vc1);
process(vc2);

function process(VC vc) {
  if (vc.jwt && vc.jwt.iat < Date.now().getTime())
    console.log("error");
  if (vc.proof && Date(vc.proof.created) < Date.now())
    console.log("error");
}

Option 2 just makes it harder to compare issuance and expiration time across proof formats.

[awoie]

There is also a consideration that relates to BBS+ and derived proofs. To my knowledge, the derived proof would be generated by the holder at the time of presentation. IMO, including expiration and issuance only in the derived proof would lead to some semantic confusion but I'm not an expert in BBS+. It would be great if @tplooker could comment on that.

If this is the case, then one more reason for Option 1 I proposed.

[TallTed]

As described in issued #918

@selfissued, why create another issue (#918) for one side of the discussion already framed to be held here (#913)? I'm going to keep my responses here, and I strongly suggest that #918 be closed as a duplicate of #913.

towards unnecessary and useless complexity

@selfissued, you have a pattern of speaking of anything you dislike or do not need as if it is utterly worthless and without any redemptive value, and as if anyone who is in favor of such features are clearly idiots. Please moderate your tone in future.

The fact that this ability is not part of your particular use case(s) does not render it either "esoteric" or "useless".

Some use cases we discussed in arriving at the stated plan for VC DM 2.0 (i.e., converting validity periods to be stated in validFrom and validUntil properties; while converting the issuanceDate [which really should be issuanceDatetime] to be when the VC was created/issued/signed, for which its lexical value clearly indicates it was originally intended) included event tickets (might only be valid on the date of the event, though issued/sold weeks or months before — or even only for a few hours on that date) and merchandise coupons (similarly, might only be valid for a specific window of dates, though issued months or even years before, depending on the promotion), among others.

Please provide at least one clear example of how the above and similar use cases would be satisfied following your proposed elimination of the distinction between validFrom and issuanceDate.

Please also demonstrate how simplicity is served by blocking the clear lexical and semantic bookends of validFrom and validUntil in favor of the lexically and semantically imbalanced issuanceDate and expirationDate.

[David-Chadwick]

What we need semanically is the cryptographic validity time of the VC, which is independent from the validity time of the underlying credential (claims). So 4 date/times are potentially needed. e.g. a degree claim is valid from the graduation date and does not expire. A UK driving license is valid from when the driver passes their driving test until the driver's age of 65. Multiple VCs with shorter cryptographic validity times could be issued during the claim lifetimes of both of these.
What we currently have is a bit of a mess.
We should define these 4 date/times and only make the 2 cryptographic ones mandatory, with the 2 claim ones being optional. The names of these 4 date/times is less important than clear semantic definitions of them.

[selfissued]

@TallTed thanks for explaining the future-dated coupon use case. That motivates why issuanceDate and validFrom would sometimes be different. I can't see it motivating why expirationDate and validUntil would ever need to be different, however.

You wrote:

@selfissued, you have a pattern of speaking of anything you dislike or do not need as if it is utterly worthless and without any redemptive value, and as if anyone who is in favor of such features are clearly idiots.

Please accept my apology if my remarks came off that way. That wasn't my intent.

My intent was to advocate for "keeping simple things simple". It's virtually certain that the dominant pattern will be VCs that are valid when issued and invalid upon expiration. Yes, future- or past-dating may need to be possible. But I'd do that by making validFrom/nbf optional and only including them when different from issuanceDate/iat. That favors the common case, rather than expressing everything with the full generality of what I believe will be the unusual case.

[TallTed]

[@selfissued] Please accept my apology if my remarks came off that way. That wasn't my intent.

Thank you. As a concrete suggestion for the future, "I can't see the use" constructs (as you used here) come across very differently from "that's useless", and invite presentation of such use case rather than asserting it doesn't exist.

I'd do that by making validFrom/nbf optional and only including them when different from issuanceDate/iat.

I think someone had a reason that this optionality would be problematic, but I cannot immediately recall what that reason was. Hopefully they will notice this thread and speak up again. I'll also try to dig up the relevant past thread(s), as I don't think silence here should be taken as an indication that such reason was nonexistent.

I will also try to dig up the thread(s) and/or use case(s) that had differing expirationDate and validUntil.

I invite comment from anyone reading this who has ready access to the thread(s) and/or use case(s) I'll be searching for!

[selfissued]

For context, w3c/vc-jose-cose#9 (Represent issuance time with "iat" rather than "nbf") is related.

[awoie]

Please correct me if I was wrong, but it seems nobody is arguing for removing any of these dates from the VC Core Data Model entirely and only representing them in the proof-format specific serialisation, e.g., data integrity proof property, JWT claims, right? @msporny @selfissued @TallTed

If this is the case, I'd propose the following:

• deprecate issuanceDate since the current (v1.1) definition is semantically misleading.
• keep OPTIONAL expirationDate since there are no issues with the semantic definition in the spec.
• add REQUIRED issued that is semantically the same as the iat JWT claim.
• add OPTIONAL validFrom that is semantically the same as nbf JWT claim.
• specific proof-formats would still be able to use their standard data model, e.g., iat for VC-JWT, created for data integrity proofs.

Since issuanceDate was a REQUIRED property, we should keep in mind, that this proposal is a breaking change.

I personally don't understand why renaming expirationDate into validUntil is needed, since the definition seems to be fine and deprecation would introduce another breaking change.

Any thoughts?

[selfissued]

deprecate issuanceDate since the current (v1.1) definition is semantically misleading.
add REQUIRED issued that is semantically the same as the iat JWT claim.

I'd prefer fixing the misleading definition than changing which claim name people use to represent when the VC was issued. Then it wouldn't be a breaking change.

add OPTIONAL validFrom that is semantically the same as nbf JWT claim.

I'm find adding this as long as it's optional. If not present, we would define that the VC is valid starting when it was issued.

I personally don't understand why renaming expirationDate into validUntil is needed, since the definition seems to be fine and deprecation would introduce another breaking change.

I agree that I don't understand this. I'd prefer leaving expirationDate as is.

[RieksJ]

Here's a case that might be worth considering in this discussion. We all have passports, with two dates, one of which is related to the point in time where it was issued, and the other is related to a point in time several years in the future. To avoid getting dragged into the discussion in ways I do not want to, let me call them T1 and T2 respectively.

When a non TNO-employee wants to enter one of the TNO buildings, she must show her passport, and one of the conditions that must be satisfied for her to enter is that T2 + 5 years is a future date. In other words: the passport may have expired, but for no more than 5 years.

When I went to China a few years ago, one of the conditions that had to be satisfied for successfully obtaining a tourist visa was that T2 - 6 months + date-of-entry is a future date. In other words: my passport had to be valid 6 months after I would enter China.

This clearly illustrates that regardless of what the passport issuer thinks about passport validity, it is the relying party that ultimately decides whether it is or not.

[OR13]

Another part of this is the lack of definition regarding proof.created... which is what actually maps to iat.

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

2.2. issuanceDate/expirationDate and validFrom/validUntil (issue vc-data-model#913)

See github issue vc-data-model#913.

Kristina Yasuda: validFrom ... validUntil.

Michael Jones: There's a discussion, which I understand predates my involvement about possibly deprecating issuedDate and replacing it with validFrom and possibly deprecating expirationDate and replacing it with validUntil.

See github pull request vc-data-model#927.

Michael Jones: There was a useful discussion on the issue about what use cases might exist for having a validFrom period that differs from the issuanceDate. In particular, the example was given of a future-dated coupon which starts being valid on maybe July 4th 2023 and is valid through July 4th 2024 but you could hand that out to people now. I understand that and it's a reasonable thing to do.
… That said, I believe the predominant case is that stuff is valid when issued and that's what we should optimize for. That's the same that we did in JWTs.
… There's typically always an issued at (iat) time and an expiration time. If you want it to be valid from a different time from the issuance then you add the optional claim to indicate that.
… If it ever valuable to have a valid until that is different from the expiration date -- and no one has given a use case so I'd be happy to just leave expirationDate alone and not have that.

Manu Sporny: There are a couple of things wrapped up in this issue.
… Manu said that people thought that people couldn't include a time.
… We put in a deprecation warning because of that.
… We said that we were going to rename it.
… The first issue is that we named these properties in a misleading way.
… The second issue is that there's a strict difference between the validity period of a credential and when it was signed.

Orie Steele: +1 manu, we also want to separate "the data model" from "securing it".

Manu Sporny: As Mike said, when a coupon was signed and when it becomes valid are different.
… Retailers need to distribute digital coupons before they come into play.
… This is a real retail use case.
… The other side of that is that the validity period of a credential can be different from the validity period of a digital signature.
… A passport or driver's license has a validity period independent of the signature validity period.
… A driver's license that has expired doesn't change a person's birthday.
… We shouldn't conflate them.

David Chadwick: A UK driver's license expires when you become 65.
… Whereas the signature will expire well before that.
… Some of these pertain to the claims and some pertain to the cryptography.

Orie Steele: The validity period for a credential is different from the validity period for crypto.

Orie Steele: +1 DavidC, all cryptography has a shelf life that does not match always match the life of the claims the issuer is making.

Michael Jones: I was going to advertise Orie's presentation at TPAC, which is, I believe he's going to explicitly talk about clear semantic distinctions between properties of the Verifiable Credential and properties of the signatures used to secure them.

Orie Steele: I will attempt to cover this in my TPAC talk, I make not promises for success.

Michael Jones: I think some of this discussion would be well informed by a clear separation of those two concerns. There may be relationships between the two sets of dates but we should be clear about them.

Manu Sporny: we have been clear in the textual description, some developers don't have time to read specs. :).

Michael Jones: Also responding to a comment Manu made a few minutes ago -- the fact that it's called issuanceDate and that you couldn't put a time, is a documentation time. We should just be clear in the definition what it means. That's not sufficient for making a breaking change, we should just fix the documentation, not change the property name.

Ted Thibodeau Jr.: It's not a documentation error. The documentation was quite clear.
… The humans will still make the mistakes.

Manu Sporny: +1 to what TallTed is saying, we have to take the human element into consideration here.

Ted Thibodeau Jr.: Documentation does not fix issues like this.

Michael Jones: If implementers aren't using our specifications, there's not much point in us writing them.

Ted Thibodeau Jr.: Humans are fallible. They do not recall everything they read.
… We are writing the spec for humans to implement them.
… What we can fix, we should fix.

Justin Richer: Naming things is hard. Really hard.

Ted Thibodeau Jr.: We can fix things by using better names.

Kristina Yasuda: It seems like people care a lot about this.
… Please read the specs and suggest ways to make things clearer.

[msporny]

Based on the call on 2022-10-26:

RESOLVED: Rename issuanceDate in the VC Data Model to validFrom.
RESOLVED: Rename expirationDate in the VC Data Model to validUntil.

[iherman]

The issue was discussed in a meeting on 2022-10-26

List of resolutions:

• Resolution No. 3: Rename issuanceDate in the VC Data Model to validFrom..
• Resolution No. 4: Rename expirationDate in the VC Data Model to validUntil..

View the transcript

4.1. issuanceDate/expirationDate and validFrom/validUntil (issue vc-data-model#913)

See github issue vc-data-model#913.

Kristina Yasuda: Can anyone give an overview of this issue?.

Michael Jones: In the big picture, this is about what representations of what dates to include in our spec. There is some history ....
… Let me try to divide the different pieces this is talking about and then I'll defer to Manu to also give context..
… Some developers apparently found "issuanceDate" to be confusing, because it's not just a date it's a date-time. So one proposal in this issue is to rename it to "issued" with the same semantics as the JWT issued at iat claim..
… I would note that the semantics wouldn't change but it would be a breaking change to give it a new name (from issuanceDate to issued)..
… There are some more issues in this issue..

Orie Steele: -1 to what is being said... validity period and signature date are different..

Michael Jones: One is having a validFrom claim, which is the equivalent of the JWT "not before" claim..

Manu Sporny: yes, -1, I think this is confusing what was being proposed..

Michael Jones: There's discussion about it being optional or not, I see that it could be optional..

Orie Steele: interesting point, on making validFrom optional though... wonder about the use cases for that..

Michael Jones: We could refer to the SAML / JWT usage -- where you only include "valid from" or "not before" if the value differs from "issued at", but we could discuss that..

Dmitri Zagidulin: @orie - the use case for validFrom being optional seems straightforward enough. if missing, then it's "at the time of issuance".

Michael Jones: There is also a proposal to rename expirationDate to validUntil which would be a breaking change again with just a new name. I could see us wanting to break each of these into its own issue to deal with one at a time..
… Manu, what have I left out?.

Manu Sporny: I would characterize it quite differently. There are broad categories of what's being discussed. One is "what's the validity period for the credential?"..
… Way back in the VC 1.0 days, we set the validity period between "issuanceDate" and "expirationDate" and that confused people because of date vs. date-time..
… So we suggested that we change this from "validFrom" to "validUntil"..

Orie Steele: +1, what is the validity period for the credential? and when was the signature applied are VERY different things..

Manu Sporny: The issue itself was very focused on those things. Mike rightly brought up the signature date and time and that's about securing the VC as opposed to the VC itself..
… So what I want to make sure is that we don't conflate those things there -- this issue is not supposed to be talking about the signature just the validity period for the credential..
… We did talk about this in the 1.1 work and we did come to consensus that we would be renaming it to "validFrom" and "validUntil" and we set that expectation..
… What is Mike is bringing up are interesting things to discuss but this issue was just supposed to be about the validity period for the VC..

Orie Steele: I agree with pretty much everything Manu just said..
… I would say that in educating new developers about these properties, and I've commented to them about "validFrom" and "validUntil" and they were very supportive of using those..
… I think the reaction already to change to those properties is a good move..
… I think what Mike and Manu were saying -- and that people are often confused between these and the dates/times used in the securing representations and we need to keep those separate..
… Attacking timestamps is something attackers really love to do -- especially for credentials that are delicious and valuable. We should be very careful to not confuse the validity period in the VC and the timestamp/format in the securing format. Keeping those separate lets us be more secure and we can talk about the securing times and so on in those other specs..
… So I'm very in favor of using validFrom/validUntil for the VC validity period instead of issuanceDate/expirationDate..

David Chadwick: It's clear people have confused the VC validity period and the crypto dates. Now it's very clear that those are not the same thing. The dates that are used in a JWT should not have any mappings to the VC -- because these things are clearly separate..
… I think the rules that Orie is producing right now, the two dates are not related at all (those in the JWT vs. those in the VC) are not related at all..

Orie Steele: David, well not sure I fully agree... but I am happy to discuss.... in the "mapping from the core data model" section of the "vc-jwt" spec..

Kristina Yasuda: Thank you, David..
… I would propose running a proposal to rename "issuanceDate" to "validFrom" and rename "expirationDate" to "validUntil" both separately..
… And then talk about optionality..
… I see support for people to separate VC validity from proof/signature validity..

Michael Jones: The specs that I've worked on that have succeeded, we try to keep simple things simple..
… In the vast majority of the cases, the credential becomes valid at the time it's issued..
… Yes, there is a use case for future-dated coupons, which is fine, in which case you can have an optional / "not before" or "valid from". But let's not have two representations of the same thing..

Orie Steele: There are lots of cases, where the cryptographic proofs have different dates than knowledge or claims..

Manu Sporny: University degrees don't become valid at the time they're digitally signed... coupons don't... discounts don't....

Manu Sporny: They're not the same..

Ted Thibodeau Jr.: citation needed for 99%.

Michael Jones: I think it's an unnecessary duplication in 99% of the use cases..
… I think in this case, breaking changes don't appear to be a good cost/benefit trade off..

Orie Steele: yeah, citation for 99% claim... : ).

Kristina Yasuda: So you're suggesting let's keep "issuanceDate"..

Oliver Terbu: I think there are two different issues. One is the semantic meaning/naming of those properties in the core data model. I think that might be errata/controversial ... the other issue is whether or not to map those properties onto JWT VCs..
… Specifically onto JWT claims. I think these are two different issues. One relates to the VC data model and is about renaming those properties, the other is about whether or not to map those onto standard JWT claims or standard DI claims/proof properties..

Kristina Yasuda: I agree, that's the separation we need..

Manu Sporny: +1 to what Oliver said about separation..

David Chadwick: Totally agree with Oliver..

Kevin Dean: +1 to separation.

David Chadwick: Degrees that were issued to people 10-20 years ago, that's the VC issuance date. That's got nothing to do with the JWT. It will still have 1970 as the date of issuance. We have to clearly separate these. My driving license was valid until I was 65 and I got it when I was 16..

Orie Steele: +1 David.

David Chadwick: There's no way the JWT would have been valid that long -- for credentials the periods are very clearly different..

Orie Steele: +1 Manu, this isn't a breaking change..

Manu Sporny: I wanted to speak to the breaking change that might happen. So this would happen in the VC 2.0 context and I'd argue that isn't a breaking change and new implementations that pull that context in will never know that there was this VC 1.0 thing..
… And the things handling VC 1.0 will continue to work..

Mahmoud Alkhraishi: +1, v1 context will still support the existing implementation.

Manu Sporny: It's not a breaking change. We have warned people in the spec for years now that we're going to make this change for years now and it's not a surprising thing. If we're really concerned about this, we could say that "issuanceDate" and "expirationDate" are still allowed, you have to use validFrom/Until but if you see those you can use them..
… I hesitate to do that because of the complexity -- it's not difficult to do an if statement, but better to be avoided..
… It's not a breaking change in the way that things usually happen because of the versioning we have with the context..

Michael Jones: You can call it a breaking change or not but it's still a code change if you want to use the new specification. I agree that it's a separate thing, the mapping to the JWT claims..
… And what the mapping to the CBOR claims will be, etc..
… And Orie talked about this and he's right. Do you only have one representation of dates or do you have two? One in the body and one in the container. I think that's another highly-related issue which we haven't resolved. It could be very well that we rename these things to validFrom/validUntil but in the JWT mapping we don't use those properties at all..
… And we use IAT or NBF or you allow the duplication..
… I think the duplication is problematic. What I'm saying probably isn't directly actionable, but I think the whole date representations in signed containers vs. representations in the VC data model are distinct but very interrelated..

Orie Steele: Most of what Mike is saying, is for a different issue, imo, but since he has said it, I am q'd to reply..

Michael Jones: I know Tony Nadalin who is on the call and he would like the VC data model not use anything duplicative that's already in JWTs..

Kristina Yasuda: Thank you, Mike, I'm thinking of a straw poll..
… Do we want to have 4 separate claims, "issuanceDate", "expirationDate", "validFrom", "validUntil"..

Ted Thibodeau Jr.: I'm more than a little frustrated that the most significant argument that's put forth -- one of the reasons to go from 1.1 to 2.0 is to make a fix in what most of us consider to be a bug that we did in 1.1..
… I was here for all of it. Those people arguing against that change were not. You might want to consider that in formulating your arguments..

Orie Steele: I know Mike Jones raised a bunch of issues related to the mapping from the core data model to the security proof formats and he made a number of statements about how you can legally do that in 1.1 and how we might change that in 2.0..
… I want to say again that mixing those issues together is a huge mistake and we shouldn't be doing that. We should have this issue focus on the core data model only. Bringing those other security items in here is confusing the issue..
… We can address those issues on the repo that defines that mapping..
… We can define that mapping elsewhere in other issues. I'd like to ask us to focus on the labels we're providing on the labels for these fields in just the VCDM..

David Chadwick: +1 Orie.

Orie Steele: The proposal is just to rename issuance/expirationDate => validFrom/Until and let's not get confused with other issues..

Shawn Butterfield: +1 Orie.

Manu Sporny: +1 Orie.

Dave Longley: +1 Orie.

Michael Jones: I am often in favor of separation of issues as well..
… If we can agree that the core data model will not talk about issuance at all, but you leave that to the formats of the security tokens that secure the data model members, then I'm ok with the renaming..
… We need to be clear then that the VCDM doesn't have issuance and expiration, that's something at the security level. If that's the separation we can agree to then maybe there's a path forward..

Orie Steele: I'm not sure we're going to agree to that. I don't agree with the idea that the core data model can't have the issue make claims about the validity period..

Brent Zundel: validity period seems to be what we are talking about with validFrom and validUntil.

Manu Sporny: +1 Orie.

Manu Sporny: +1 brent.

Orie Steele: The VCDM has a responsibility to allow the issuer to provide clear definitions for the validity period -- and we should improve the definitions and provide clarity and I'm strongly opposed to any idea that we'd move the VC validity period into the security assertions format. I think that's a violation of layers..

Dave Longley: +1 Orie.

Michael Jones: I thought I was agreeing with Orie..

Shawn Butterfield: That was how I interpreted it... I'm a +1 on VCDM owning claim validity - not security envelope expiry... Two different things..

Brent Zundel: Then issuanceDate and expirationDate would be a concern of securing VCs.

Orie Steele: There are dedicated issues to those issues..

Manu Sporny: Maybe I just misunderstood Mike, but maybe we have consensus..
… I'd like to run the proposals before the end of the call..

David Chadwick: To muddy the waters a bit, my driving's license, it had my date of birth... didn't have an expiration date but my classification of vehicles to drive did..
… For having validFrom/validUntil for the whole VC is perhaps the wrong model because each claim could have its own model..

Ted Thibodeau Jr.: new issue! distinct convo!.

Dmitri Zagidulin: that does seem like the drivers license could stand to be separate credentials :).

Shawn Butterfield: * lols @orie.

Brent Zundel: I think a validFrom/validUntil would not at all prohibit from an issuer using validFrom/validUntil for each and every claim that they make..

Manu Sporny: +1 brent.

Proposed resolution: Rename issuanceDate in the VC Data Model to validFrom.. (Manu Sporny)

Orie Steele: +1.

Ted Thibodeau Jr.: +1.

Oliver Terbu: +1.

Brent Zundel: +1.

Logan Porter: +1.

Manu Sporny: +1.

Dave Longley: +1.

David Chadwick: +1.

Dmitri Zagidulin: +1.

Shawn Butterfield: +1.

Mahmoud Alkhraishi: +1.

Resolution #3: Rename issuanceDate in the VC Data Model to validFrom..

Michael Jones: 0.

Kristina Yasuda: Ok, I don't see any -1s, this proposal has passed..

Proposed resolution: Rename expirationDate in the VC Data Model to validUntil.. (Manu Sporny)

Orie Steele: +1.

David Chadwick: +1.

Oliver Terbu: +1.

Dave Longley: +1.

Brent Zundel: +1.

Steve McCown: +1.

Manu Sporny: +1.

Logan Porter: +1.

David Waite: +1.

Mahmoud Alkhraishi: +1.

Shawn Butterfield: +1.

Ted Thibodeau Jr.: +1.

Dmitri Zagidulin: +1.

Resolution #4: Rename expirationDate in the VC Data Model to validUntil..

Kristina Yasuda: Thank you everyone, no -1s, this proposal has also passed..
… I think this issue is now ready for PR..

Dmitri Zagidulin: I just didn't understand why people were confused about "issuanceDate" but not why "expirationDate"..

Orie Steele: The confusion is around VC validity vs. security representation. Both require mappings in order to be secured in JWT -- vs. Data Integrity which doesn't transform the JSON..

Dmitri Zagidulin: thanks Orie.

Dmitri Zagidulin: makes sense..

Orie Steele: Any security format that has to handle those mappings on both sides it can be confusing and there's where the confusion is coming from..

David Waite: My confusion about the rename is about also having an issued property -- but from a validity perspective, I don't know what that means. It seems like "issued" was proposed because "issuanceDate" might serve a different purpose as well as a granularity ... will this be a breaking change for people who thought they were using "issuanceDate" correctly but weren't?.
… In addition to the rename, I think there's also a new parameter being proposed and it's not clear if it has a security context or if it's just a new thing the issuer claims about the VC itself..

Orie Steele: I don't know about the "issued" term or where that's coming from. I can only speak to the software implementations I've reviewed -- with distinguishing between the VC validity and the signature period..
… In most JWT implementations you can't even set the implementation to move the date around and that's hard if you have a mapping..
… There are some that let you set it. I haven't seen "issued". The JWT iat maps to the proof.created in DI..
… That has to do with when the proof was created and the security was applied..

Manu Sporny: +1 Orie.

Orie Steele: Which is to be distinguished from when the VC / claims validity period applies..

David Waite: fwiw, issued property is from the note in https://www.w3.org/TR/vc-data-model/#issuance-date.

Dave Longley: +1 Orie.

Kristina Yasuda: Please read over issues and link as needed, see you on the special topic call and thanks to everyone!.

---

[msporny]

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

[msporny]

PR #992 has been merged, closing.