18:58:59 RRSAgent has joined #vcwg 18:58:59 logging to https://www.w3.org/2022/10/26-vcwg-irc 18:59:10 Zakim has joined #vcwg 19:00:25 brentz has changed the topic to: Meeting Agenda 2022-10-26: https://www.w3.org/events/meetings/c5abcc63-337b-4ebb-97af-7cc2fb63de11/20221026T15000 19:00:48 zakim, start the meeting 19:00:48 RRSAgent, make logs Public 19:00:49 please title this meeting ("meeting: ..."), brentz 19:01:08 meeting: Verifiable Credentials Working Group teleconference 19:01:15 kristina has joined #vcwg 19:01:18 chair: Kristina Yasuda 19:01:18 present+ 19:01:26 present+ 19:02:54 Steve_C has joined #vcwg 19:03:37 present+ 19:04:03 DavidC has joined #vcwg 19:04:09 present+ 19:04:11 present+ 19:04:12 q+ 19:04:19 ack manu 19:05:01 scribe+ 19:05:20 q+ to note on canceled calls. 19:05:31 David_Waite has joined #vcwg 19:05:47 present+ 19:05:51 kdeangs1 has joined #vcwg 19:05:51 ack manu 19:05:51 manu, you wanted to note on canceled calls. 19:05:52 decentralgabe has joined #vcwg 19:05:54 selfissued has joined #vcwg 19:06:01 present+ 19:06:02 oliver has joined #vcwg 19:06:04 I agree that the call would be pretty late during IETF for those of us in London 19:06:12 manu: The special topic call -- +1 to cancel during IIW, I think a lot of will be there. +1 to cancel the special topic call that happens really late at 6pm. 19:06:20 manu: But ok to keep the other meetings. 19:06:37 kristina: Anyone else opposed to canceling? 19:06:38 kristina: Ok, we'll cancel those. 19:06:47 kristina: Any introductions / re-introductions? 19:07:01 kristina: None, cool, next on the agenda is work item status updates and PRs. 19:07:02 q+ on status updates. 19:07:07 Topic: Work Item status updates/PRs 19:07:08 ack manu 19:07:08 manu, you wanted to comment on status updates. 19:07:21 https://github.com/w3c/vc-data-model/pulls 19:07:23 Orie has joined #vcwg 19:07:26 manu: I don't think we have any open PRs ... nevermind, we have two open PRs on VCDM. 19:07:29 present+ 19:07:30 subtopic: https://github.com/w3c/vc-data-model/pull/954 19:07:37 manu: #954, which Ivan has raised. 19:08:02 manu: To use a great new tool that he wrote, it allows you to take a YAML file and convert it to a vocabulary file. So the credential vocabulary is just generated from a really easy to use file, it's a great PR that will help us keep things up to date. 19:08:09 manu: Please take a look at it. 19:08:15 subtopic: https://github.com/w3c/vc-data-model/pull/955 19:08:16 manu: Next one, Richard opened a PR to open editorial issues. 19:08:22 shawnb has joined #vcwg 19:08:22 manu: That's great too. 19:08:27 present+ 19:08:42 manu: The other thing people should note is that the VC v2 context with the DI proof stuff went in and that's it for the data model spec. 19:08:45 subtopic: https://github.com/w3c/vc-data-integrity/pull/67 19:08:46 manu: Moving over to the DI spec. 19:09:11 manu: Last week we said we'd talk about doing FWPD this week and proposals and voting on them. This is a PR to do FPWD for the DI spec. 19:09:30 mkhraisha has joined #vcwg 19:09:40 manu: I believe it has much of what we agreed to in it, when we take up that proposal, Ivan mentioned that we need to ideally pick a publication date into the future like 2-3 weeks. 19:10:04 manu: That we also need to specify the kind of doc we intend to publish and any editorial changes to do that and we need to specify that we want to use Echidna to auto-publish editor's drafts going forward. 19:10:08 and we need to choose the shortname 19:10:09 manu: The proposal needs all of those things in there. 19:10:20 manu: I think that's it for updates on VCDM and DI specs. 19:10:28 q+ 19:10:37 kristina: Fantastic, thank you do so much. For VC-JWT and JsonWebSignature2020...? 19:10:37 ack Orie 19:10:54 Orie: For VC JWS2020, we have one with changes requested regarding the IANA context. 19:10:58 https://github.com/w3c/vc-jws-2020/pull/26 19:11:04 Orie: I'm going to skip over that one, it's a long discussion. 19:11:26 Orie: PR #26 is the FPWD for JsonWebSignature2020. It's the same kind of PR that Manu just commented on. 19:11:27 https://github.com/w3c/verifiable-credentials/pull/26 : add agenda link 19:11:37 Orie: And that's it for JsonWebSignature2020, please look at those PRs. 19:11:44 Orie: On VC-JWT, there is one PR remaining. 19:11:53 https://github.com/w3c/vc-jwt/pull/11 19:11:55 Steve_McCown has joined #vcwg 19:11:56 Orie: That had comments / changes requested by Mike Jones, I believe I addressed them. 19:12:11 present+ oliver 19:12:20 Orie: I did request a re-review. TallTed had some editorial comments that I accepted, I am just requesting Mike Jones to re-review. 19:12:23 q? 19:12:25 Orie: That's it for VC-JWT PRs. 19:12:31 selfissued: Do you want to talk about the issues? 19:12:35 Orie: I was just doing PRs. 19:12:45 selfissued: Thank you, that's fine, that's to TallTed for the recent approval. 19:13:23 kristina: Thank you Orie, I sent out an email with calendar invitations for the special topic calls, alternating on Europe/US friendly times on Tuesdays/ 19:13:59 kristina: We're starting Nov. 1 on issue #947 regarding making the `@context` optional, we have more than 100 comments on that issue. 19:14:24 kristina: Please try to catch up but we realize it's a lot to read. We hope to summarize the arguments / discussion in the start of the special topic call next week. 19:14:24 q+ 19:14:43 kristina: After issue #947, we want to continue with #948 and #953 around `@vocab` usage in `@context`. 19:14:52 ack selfissued 19:15:12 selfissued: I'm looking at my calendar and the special topic call doesn't appear. Now, if there's an email that just says when it will be, but I would expect ical links to be included. 19:15:19 q+ 19:15:27 kristina: There is an email with an ical attachment that should be in your mailbox, you will have to manually add it I think to make it show in your calendar, I think. 19:15:36 ack DavidC 19:15:37 selfissued: Oh, ok, I'll search for it. 19:15:40 q+ to mention topic call 19:16:11 DavidC: I sent an email to Brent about the email and when I clicked on the details it didn't work for me and the URL has a `/edit` on the end of it and the message needs updating before we do new special topic calls because you'll get an unauthorized response when clicking. 19:16:11 ack brentz 19:16:11 brentz, you wanted to mention topic call 19:16:43 brentz: It looks like, in creating the special topic call calendar event in the W3C system, I neglected to change it from tentative to confirmed and that's probably why it's not showing up for people subscribed to the W3C calendar, I'll get that fixed. 19:16:46 kristina: Ok, thanks brent. 19:16:57 q? 19:17:01 q+ to run proposals 19:17:16 kristina: Let's move to the issues conversation, and before we start that, there's one head's up from the chairs and editors, I'll paste a link in the chat. 19:17:24 kristina: Brent do you want to go first? 19:17:29 brentz: I have the draft proposals for FPWD. 19:17:33 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22 19:17:36 kristina: Ok, let me finish on this and we'll get back to that. 19:18:06 kristina: Heads up from the chairs and editors that there is a "ready for PR" tag in the issues and we would like to encourage WG members to actively pick those up and help out by creating PRs. 19:18:13 kristina: Many of those are editorial and straightforward. 19:18:42 kristina: The reason they have the tag is because there is a complete and concrete solution for solving the issue in the issue, so doing a PR should be straightforward. So please, if you are willing to contribute, even if you aren't an editor, please do a PR. 19:18:56 kristina: We have 76 issues left on the VCDM alone, we really need a lot of participation. 19:19:02 i/brentz: I have the draft/Topic: Contributing PRs ('ready for PR')/ 19:19:21 kristina: If you need help learning how to contribute reach out to editors / chairs. We really want folks to contribute with these low-hanging fruit issues. 19:19:33 ack brentz 19:19:33 brentz, you wanted to run proposals 19:19:44 kristina: Ok, brentz, proposals? 19:19:57 Topic: Publishing First Public Working Drafts 19:20:01 brentz: I think I have everything we need in this proposal -- I chose all the things like date and so on. 19:20:08 brentz: Any recommendations for changes before we run it? 19:20:26 kristina: Any changes? I think this should be straightforward. 19:20:26 PROPOSAL: The WG will publish as a FPWD the document at https://w3c.github.io/vc-data-integrity/, inclusive of https://github.com/w3c/vc-data-integrity/pull/67 on 2022-11-10 under the shortname vc-data-integrity, and will use echidna to automatically update the working draft when PRs are merged. 19:20:31 +1 19:20:33 +1 19:20:35 +1 19:20:49 +1 19:20:57 +1 19:21:32 +1 19:21:34 +1 19:21:35 0 19:21:37 0 19:21:38 +1 19:21:40 +1 19:21:56 kristina: Thank you everyone, there are no -1s, this proposal has passed. 19:22:12 RESOLVED: The WG will publish as a FPWD the document at https://w3c.github.io/vc-data-integrity/, inclusive of https://github.com/w3c/vc-data-integrity/pull/67 on 2022-11-10 under the shortname vc-data-integrity, and will use echidna to automatically update the working draft when PRs are merged. 19:22:39 brentz: We have one more proposal for JsonWebSignature2020. 19:23:10 present+ 19:23:37 kristina: Any comments / suggestions / changes? 19:24:06 logan_porter has joined #vcwg 19:24:18 present+ 19:24:24 PROPOSAL: The WG will publish as a FPWD the document at https://w3c.github.io/vc-jws-2020/, on 2022-11-10 under the shortname vc-jws-2020, and will use echidna to automatically update the working draft when PRs are merged. 19:24:26 +1 19:24:33 +1 19:24:35 +1 19:24:35 +1 19:24:36 +1 19:24:38 +1 19:24:39 +1 19:24:42 +1 19:24:43 +1 19:24:43 +1 19:24:45 +1 19:24:45 +1 19:24:47 +1 19:25:01 RESOLVED: The WG will publish as a FPWD the document at https://w3c.github.io/vc-jws-2020/, on 2022-11-10 under the shortname vc-jws-2020, and will use echidna to automatically update the working draft when PRs are merged. 19:25:07 kristina: Ok, great, see lots of +1s, no -1s, this proposal has passed. 19:25:14 kristina: We passed two proposals, any others to run, Brent? 19:25:19 brentz: Not that I'm aware of. 19:25:21 kristina: Great. 19:25:23 kristina: Thank you. 19:25:28 zakim, who is here? 19:25:28 Present: kristina, brentz, dlongley, DavidC, manu, David_Waite, decentralgabe, Orie, shawnb, oliver, TallTed, logan_porter 19:25:29 kristina: Now going to the issues. 19:25:31 On IRC I see logan_porter, Steve_McCown, mkhraisha, shawnb, Orie, oliver, selfissued, decentralgabe, kdeangs1, David_Waite, DavidC, Steve_C, kristina, Zakim, RRSAgent, brentz, 19:25:31 ... dmitriz, TallTed, tzviya, npd, cel, bumblefudge, Github, cel[m], shigeya, dlehn1, dlehn, dlongley, manu, stonematt, Dongwoo, bigbluehat, hadleybeeman, rhiaro 19:25:33 Topic: issues 19:25:36 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc 19:25:51 present+ nadalin 19:25:54 kristina: We're going through the issues labeled discussed. 19:26:03 present+ selfissued 19:26:07 kristina: There hasn't been activity after we discussed issue #887. 19:26:14 kristina: I would encourage folks to keep commenting on that issue. 19:26:16 present+ dmitriz 19:26:29 subtopic: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc 19:26:30 present+ kdeangs1 19:26:37 kristina: Issue #913, about valid from / until. 19:26:39 q+ 19:26:43 kristina: Can anyone give an overview of this issue? 19:26:46 subtopic: https://github.com/w3c/vc-data-model/issues/913 19:26:47 present+ Steve_C 19:26:56 q+ 19:26:57 ack selfissued 19:27:00 present+ mkhraisha 19:27:16 selfissued: In the big picture, this is about what representations of what dates to include in our spec. There is some history ... 19:27:24 present+ Steve_McCown 19:27:29 selfissued: Let me try to divide the different pieces this is talking about and then I'll defer to Manu to also give context. 19:27:47 present+ shawnb 19:28:01 selfissued: 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. 19:28:19 selfissued: 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`). 19:28:23 selfissued: There are some more issues in this issue. 19:28:40 -1 to what is being said... validity period and signature date are different. 19:28:46 selfissued: One is having a `validFrom` claim, which is the equivalent of the JWT "not before" claim. 19:28:56 yes, -1, I think this is confusing what was being proposed. 19:28:58 selfissued: There's discussion about it being optional or not, I see that it could be optional. 19:29:17 interesting point, on making validFrom optional though... wonder about the use cases for that. 19:29:21 selfissued: 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. 19:29:25 q? 19:29:52 @Orie - the usecase for validFrom being optional seems straightforward enough. if missing, then it's "at the time of issuance" 19:30:05 selfissued: 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. 19:30:12 selfissued: Manu, what have I left out? 19:30:17 q+ 19:30:17 ack manu 19:30:33 manu: 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?". 19:30:49 manu: 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. 19:31:00 manu: So we suggested that we change this from "validFrom" to "validUntil". 19:31:13 +1, what is the validity period for the credential? and when was the signature applied are VERY different things. 19:31:23 manu: 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. 19:31:45 manu: 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. 19:32:02 manu: 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. 19:32:18 ack Orie 19:32:18 manu: 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. 19:32:27 Orie: I agree with pretty much everything Manu just said. 19:32:51 Orie: I would say that in educating new devs about these properties, and I've commented to them about "validFrom" and "validUntil" and they were very supportive of using those. 19:33:01 Orie: I think the reaction already to change to those properties is a good move. 19:33:28 Orie: 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. 19:33:35 q+ 19:34:21 Orie: 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. 19:34:29 q+ 19:34:32 ack DavidC 19:34:42 Orie: So I'm very in favor of using validFrom / validUntil for the VC validity period instead of issuanceDate/expirationDate. 19:35:01 q- 19:35:21 DavidC: 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. 19:35:43 DavidC: 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. 19:35:46 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. 19:35:51 kristina: Thank you, David. 19:36:09 kristina: I would propose running a proposal to rename "issuanceDate" to "validFrom" and rename "expirationDate" to "validUntil" both separately. 19:36:09 q+ 19:36:15 kristina: And then talk about optionality. 19:36:37 kristina: I see support for people to separate VC validity from proof / signature validity. 19:36:37 ack selfissued 19:36:51 selfissued: The specs that I've worked on that have succeeded, we try to keep simple things simple. 19:37:02 selfissued: In the vast majority of the cases, the credential becomes valid at the time it's issued. 19:37:17 q+ 19:37:17 q+ 19:37:26 selfissued: 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. 19:37:28 There are lots of cases, where the cryptographic proofs have different dates than knowledge or claims. 19:37:31 University degrees don't become valid at the time they're digitally signed... coupons don't... discounts don't... 19:37:33 They're not the same. 19:37:38 citation needed for 99% 19:37:38 selfissued: I think it's an unnecessary duplication in 99% of the use cases. 19:37:51 selfissued: I think in this case, breaking changes don't appear to be a good cost / benefit trade off. 19:37:53 yeah, citation for 99% claim... : ) 19:38:04 q+ we don't have to break everything. 19:38:07 q+ to note we don't have to break everything. 19:38:07 ack oliver 19:38:07 kristina: So you're suggesting let's keep "issuanceDate". 19:38:40 oliver: 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. 19:39:10 oliver: 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. 19:39:20 ack DavidC 19:39:21 kristina: I agree, that's the separation we need. 19:39:22 +1 to what Oliver said about separation. 19:39:26 DavidC: Totally agree with Oliver. 19:40:02 +1 to separation 19:40:07 DavidC: 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. 19:40:07 q- 19:40:23 +1 David 19:40:27 ack manu 19:40:27 manu, you wanted to note we don't have to break everything. 19:40:27 DavidC: There's no way the JWT would have been valid that long -- for credentials the periods are very clearly different. 19:40:49 +1 Manu, this isn't a breaking change. 19:40:58 manu: 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. 19:41:04 manu: And the things handling VC 1.0 will continue to work. 19:41:08 +1, v1 context will still support the existing implementation 19:41:45 q+ 19:41:46 manu: 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. 19:42:06 manu: I hesitate to do that because of the complexity -- it's not difficult to do an `if` statement, but better to be avoided. 19:42:19 ack selfissued 19:42:23 manu: It's not a breaking change in the way that things usually happen because of the versioning we have with the context. 19:42:41 selfissued: 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. 19:42:43 q+ 19:42:49 selfissued: And what the mapping to the CBOR claims will be, etc. 19:43:32 selfissued: 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. 19:43:38 q+ 19:43:43 selfissued: And we use IAT or NBF or you allow the duplication. 19:44:16 selfissued: 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. 19:44:28 Most of what Mike is saying, is for a different issue, imo, but since he has said it, I am q'd to reply. 19:44:35 selfissued: 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. 19:44:49 kristina: Thank you, Mike, I'm thinking of a straw poll. 19:45:06 kristina: Do we want to have 4 separate claims, "issuanceDate", "expirationDate", "validFrom", "validUntil". 19:45:06 ack TallTed 19:45:12 q+ 19:45:37 TallTed: 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. 19:45:55 ack Orie 19:45:56 TallTed: 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. 19:46:19 Orie: 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. 19:46:45 Orie: 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. 19:46:53 q+ to suggest some proposals. 19:46:54 Orie: We can address those issues on the repo that defines that mapping. 19:47:22 Orie: 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. 19:47:38 +1 Orie 19:47:39 Orie: The proposal is just to rename issuance/expirationDate => validFrom/Until and let's not get confused with other issues. 19:47:42 +1 Orie 19:47:43 +1 Orie 19:47:49 +1 Orie 19:47:56 ack selfissued 19:48:00 selfissued: I am often in favor of separation of issues as well. 19:48:11 q+ 19:48:28 selfissued: 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. 19:48:32 q- later 19:48:53 selfissued: 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. 19:48:54 ack Orie 19:49:14 Orie: 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. 19:49:45 q+ 19:49:47 validity period seems to be what we are talking about with validFrom and validUntil 19:49:51 +1 Orie 19:49:57 +1 brent 19:50:03 Orie: 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. 19:50:07 +1 Orie 19:50:52 q+ to say "There is what the issuer is saying -- and the security around the authenticity of those statements and how long you can trust the issuer said them" 19:51:11 selfissued: I thought I was agreeing with Orie. 19:51:11 That was how I interpreted it... I'm a +1 on VCDM owning claim validity - not security envelope expiry... Two different things. 19:51:18 ack manu 19:51:18 manu, you wanted to suggest some proposals. 19:51:22 Then issuanceDate and expirationDate would be a concern of securing VCs 19:51:22 Orie: There are dedicated issues to those issues. 19:51:38 manu: Maybe I just misunderstood Mike, but maybe we have consensus. 19:51:56 q+ 19:51:57 manu: I'd like to run the proposals before the end of the call. 19:51:58 q- 19:52:14 ack DavidC 19:52:40 DavidC: 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. 19:52:55 DavidC: For having validFrom/validUntil for the whole VC is perhaps the wrong model because each claim could have its own model. 19:52:56 q+ 19:52:58 dmitriz has joined #vcwg 19:52:59 new issue! distinct convo! 19:53:07 that does seem like the drivers license could stand to be separate credentials :) 19:53:12 ack brentz 19:53:16 * lols @Orie 19:53:38 brentz: I think a validFrom/validUntil would not at all prohibit from an issuer using validFrom/validUntil for each and every claim that they make. 19:53:39 ack manu 19:53:44 +1 brent 19:53:48 PROPOSAL: Rename issuanceDate in the VC Data Model to validFrom. 19:53:53 +1 19:53:53 +1 19:53:54 +1 19:53:54 +1 19:53:55 +1 19:53:55 +1 19:53:55 +1 19:53:56 +1 19:53:56 +1 19:53:57 +1 19:53:57 +1 19:54:23 RESOLVED: Rename issuanceDate in the VC Data Model to validFrom. 19:54:25 0 19:54:28 kristina: Ok, I don't see any -1s, this proposal has passed. 19:54:32 PROPOSAL: Rename expirationDate in the VC Data Model to validUntil. 19:54:36 +1 19:54:38 +1 19:54:38 +1 19:54:39 +1 19:54:39 +1 19:54:40 +1 19:54:40 +1 19:54:40 +1 19:54:42 +1 19:54:42 +1 19:54:44 +1 19:54:48 +1 19:54:56 +1 19:55:05 RESOLVED: Rename expirationDate in the VC Data Model to validUntil. 19:55:08 kristina: Thank you everyone, no -1s, this proposal has also passed. 19:55:31 kristina: I think this issue is now ready for PR. 19:56:13 q+ validFrom vs issued 19:56:15 q? 19:56:18 q+ 19:56:22 q+ to ask about validFrom vs issued 19:56:24 ack Orie 19:56:46 dmitriz: I just didn't understand why people were confused about "issuanceDate" but not why "expirationDate". 19:57:17 Orie: 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. 19:57:25 thanks Orie 19:57:31 makes sense. 19:57:37 Orie: 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. 19:57:37 ack David_Waite 19:57:37 David_Waite, you wanted to ask about validFrom vs issued 19:58:04 q+ to comment on `issued` vs `iat` vs `proof.created` 19:58:31 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? 19:58:54 David_Waite: 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. 19:58:57 ack Orie 19:58:57 Orie, you wanted to comment on `issued` vs `iat` vs `proof.created` 19:59:31 Orie: 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. 19:59:45 Orie: 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. 20:00:09 Orie: There are some that let you set it. I haven't seen "issued". The JWT iat maps to the proof.created in DI. 20:00:21 Orie: That has to do with when the proof was created and the security was applied. 20:00:28 +1 Orie 20:00:35 Orie: Which is to be distinguished from when the VC / claims validity period applies. 20:00:36 fwiw, issued property is from the note in https://www.w3.org/TR/vc-data-model/#issuance-date 20:00:36 +1 Orie 20:01:25 kristina: Please read over issues and link as needed, see you on the special topic call and thanks to everyone! 20:01:32 rrsagent, draft minutes 20:01:32 I have made the request to generate https://www.w3.org/2022/10/26-vcwg-minutes.html kristina 20:01:40 zakim, end meeting 20:01:40 As of this point the attendees have been kristina, brentz, dlongley, DavidC, manu, David_Waite, decentralgabe, Orie, shawnb, oliver, TallTed, logan_porter, nadalin, selfissued, 20:01:43 ... dmitriz, kdeangs1, Steve_C, mkhraisha, Steve_McCown 20:01:43 RRSAgent, please draft minutes 20:01:43 I have made the request to generate https://www.w3.org/2022/10/26-vcwg-minutes.html Zakim 20:01:45 I am happy to have been of service, kristina; please remember to excuse RRSAgent. Goodbye 20:01:49 rrsagent, bye 20:01:49 I see no action items