15:21:24 RRSAgent has joined #vcwg 15:21:28 logging to https://www.w3.org/2024/01/24-vcwg-irc 15:21:28 RRSAgent, make logs Public 15:21:29 please title this meeting ("meeting: ..."), ivan 15:22:06 Meeting: Verifiable Credentials Working Group Telco 15:22:06 Date: 2024-01-24 15:22:06 Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20240124T110000/ 15:22:06 chair: brent 15:22:07 ivan has changed the topic to: Meeting Agenda 2024-01-24: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20240124T110000/ 15:56:59 present+ 15:58:11 present+ brent 15:58:14 present+ 16:01:30 present+ gregb 16:02:00 GregB has joined #vcwg 16:02:09 present+ 16:02:28 present+ manu 16:02:44 present+ dlongley 16:02:52 present+ TallTed 16:03:17 present+ steele 16:03:29 present+ pauld 16:05:00 present+ kdean 16:05:03 Kevin_Dean_GS1 has joined #vcwg 16:05:16 scribe+ 16:05:17 present+ dmitriz 16:05:31 present+ will 16:05:35 q+ 16:05:48 brent: Agenda today is pretty straight forward, will go over vc-jose-cose PRs and then doing issue processing on the core data model. 16:06:07 Will has joined #vcwg 16:06:07 brent: We're in the #vcwg channel as usual, invite people to join us there and that's where we handle queue management. 16:06:11 ack ivan 16:06:12 present+ 16:06:13 present+ 16:06:14 ivan: Can I have a few minutes on current submissions for publication? 16:06:16 brent: Yes, thank you. 16:06:43 ivan: So I had a call yesterday (regular call with PLH), three docs awaiting his approval. 16:07:11 ivan: He did have a question on a github issue last week about the directory becoming a registry or not. Manu responded and he missed Manu's response and he missed it and apologizes for that. 16:07:12 q+ 16:07:40 ivan: He put a minor comment into the issue you may want to look Manu ... he said if it's not a registry that's fine we just need to make that clear in the status section and once approved can be published next Tuesday I presume. 16:08:20 cabernet has joined #vcwg 16:08:23 present+ 16:08:30 ivan: For VCDM ... there is a F2F meeting with VCDM on the agenda. Hopefully no blocking comments and then the approval will come on Friday. 16:09:01 ivan: I am hopeful we will get everything done for publication on next week Tuesday, the 30th of January. 16:09:24 decentralgabe has joined #vcwg 16:09:27 present+ 16:09:40 ivan: One more request for Manu, I am out tomorrow/Friday, please keep an eye on the issue for an approval so you can generate the two documents with the right dates and I'll take care of it on the weekend for publication on Tuesday. 16:09:47 ack manu 16:10:17 manu: Thanks for all that, Ivan. I will add the language that PLH wants to the vc-specs-dir status section and just preemptively cut two releases so they are ready as I will not be around this weekend. 16:10:49 ivan: The only possible problem is requiring an editorial change if we're unlucky. The other possibility is we bite the bullet and head for Feb 1. 16:11:01 manu: I'm fine either way. We'll have to regen anyway. 16:11:09 ivan: Ok, let's decide for Feb 1 then and save the effort. 16:11:12 manu: Ok, I will do that. 16:11:51 pauld_gs1 has joined #vcwg 16:11:52 brent: Moving forward with the agenda. 16:11:53 Topic: VC-JOSE-COSE PRs 16:12:05 https://github.com/w3c/vc-jose-cose/pulls 16:13:03 present+ selfissued 16:13:03 q+ 16:13:03 present+ decentralgabe 16:13:03 ack decentralgabe 16:13:03 present+ Wesley 16:13:04 decentralgabe: I don't know how much time there is for going through these, the first 3 can be closed I think. 16:13:23 decentralgabe: They are about renaming the spec to just focus on SD-JWT and the editors have decided to not go in that direction and include standard JWTs. 16:13:34 selfissued: They are already marked pending close so I think we can just close. 16:13:53 brent: For the record, this is 212-215 and they have been marked pending close for a while now and the spec is not going in that direction. Any objections? 16:14:06 selfissued: For the minutes the WG decided to reinclude JOSE and the editors concur. 16:14:20 brent: I'm hearing no objections so we should close those PRs after the meeting. 16:14:25 subtopic: https://github.com/w3c/vc-jose-cose/pull/219 16:15:20 brent: Ivan has suggested changes on this one that I believe have been addressed. There's a suggestion from Kristina about enhancing the description. It looks like a straightforward editorial change. 16:15:54 decentralgabe: I do agree with Kristina's comments that we need an additional example that shows a secured envelope's presentation and it's lacking some text. I will do that in this issue and I'll note that I'll add this information. 16:16:10 brent: Anything else on 219? 16:16:14 subtopic: https://github.com/w3c/vc-jose-cose/pull/220 16:16:25 brent: Adjust language in example 13 -- again an editorial change. 16:16:40 brent: Ted has reviewed and his change requests have been made. I encourage other folks to check out this PR. 16:16:57 q+ 16:17:04 ack manu 16:17:06 JoeAndrieu has joined #vcwg 16:17:19 present+ JoeAndrieu 16:17:20 manu: Just a question -- I approved the PR fine as is. There's this fully specified algorithm stuff that is making it's way through IETF. How does that spec involve the language here? 16:17:23 present+ 16:17:37 manu: I think this one doesn't make mention of fully specified algorithms or not ... it probably doesn't need to but do we need any updates around this? 16:17:47 present+ smccown 16:17:48 selfissued: For the language in example 13? 16:18:07 manu: Yeah. The PR also adds some normative text around the `alg` property. It says the `alg` property is optional and is recommended to be included. 16:18:14 manu: It says that `crv` and `kid` need to be specified. 16:18:19 q+ 16:18:28 selfissued: I need to review that then because `alg` is never optional. 16:18:43 manu: This PR says it is. I'll put your comment into it. 16:19:00 brent: Sorry, my understanding is that the normative bits have just been moved around, so it may be more normative than I expected. 16:19:05 ack decentralgabe 16:19:13 q+ 16:19:18 q+ 16:19:18 decentralgabe: Yeah, I was going to say what you said -- I think I made a mistake with that first sentence so I will adjust that after Mike gives it a review. 16:19:19 ack manu 16:19:43 manu: I don't think you made a mistake, it's confusing or wrong original text that you didn't add Gabe. 16:19:51 ack TallTed 16:20:09 TallTed: I added the all-caps OPTIONAL based on the following text -- it needs to be consistent whatever it is. 16:20:13 selfissued: JOSE requires `alg`. 16:20:34 brent: Good feedback on that PR, it's actionable, encourage folks to keep an eye on it as it is reviewed and updated. 16:20:39 subtopic: https://github.com/w3c/vc-jose-cose/pull/221 16:20:44 smccown has joined #vcwg 16:20:47 q+ 16:20:55 brent: Removes some language around `proof`. This PR does what it says. There is one approval. 16:20:58 ack manu 16:21:02 manu: I think this PR is great, thank you, Gabe. 16:21:14 manu: This PR would address the issue I raised, thank you, Gabe. 16:21:29 brent: This PR looks to be in a good spot. 16:21:39 subtopic: https://github.com/w3c/vc-jose-cose/pull/223 16:22:07 brent: Update COSE media types. It does what it says -- in addition to some whitespace changes that make it a little harder to read, it just adjusts the media type. 16:22:12 brent: Folks should review. 16:22:17 brent: Please chime in to the PR with feedbakc. 16:22:23 s/feedbakc/feedback/ 16:22:30 q+ 16:22:31 brent: Happy to take comments, this one does what it says. 16:22:37 ack manu 16:23:18 manu: This is fine. I think is where we are today. I just wanted to repeat the warning that I believe that in the mediaman WG in IETF, people objected to not registering every structured suffix last time which is why the multiple suffixes draft failed to go to last call last time. I think the way this is written would require us to register... 16:23:25 manu: +json +cose +[other thing]. 16:23:53 manu: I don't know how we would justify those registrations, we might be able to point to the vc-jose-cose spec and say we're registering all these suffixes -- and questions will be asked and we need a good response. 16:24:16 manu: Probably, the vc-jose-cose spec creates all these structured suffixes and that's why we're registering them because people wanted all of them registered. 16:24:59 brent: Thank you folks for your attention during that topic. 16:25:18 Topic: VCDM Issue Processing 16:25:19 brent: And for the review, we anticipate some additional PRs on vc-jose-cose as that spec approaches CR. Moving onto the final topic. 16:25:28 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 16:25:53 subtopic:https://github.com/w3c/vc-data-model/issues/1169 16:25:56 q+ 16:26:27 brent: Consider removing use cases summary from core data model. I raised this issue to suggest that ... now that the data model is on a version 2.0 we may not need all the use cases stuff in the core data model spec in addition to the use cases document which also is being refurbished this round. 16:26:37 ack manu 16:26:39 brent: The question to the group is: Do folks agree? 16:26:42 selfissued_ has joined #vcwg 16:26:45 present+ 16:26:58 manu: +1 I think this is ready for PR and we should remove it. One of the strongest arguments for removing it -- is we published 1.0 and 1.1 and it was in there. 16:27:17 manu: We can point back to those. It might be worth putting a link in there to those and another link to the use cases document in the PR you raise, Brent. 16:27:23 manu: So people can follow their nose to the content. 16:28:01 brent: Originally, the question was -- do we just get rid of it, do we move it wholesale to the use cases/requirements doc, no takers there -- so the plan for the PR is to remove the section and add links and clean up the language. 16:28:07 brent: If anyone feels the plan should be different, please speak now. 16:28:16 brent: And I will have to remember I have something on my plate. 16:28:21 brent: Ok, not hearing any objections. 16:28:24 subtopic: https://github.com/w3c/vc-data-model/issues/1192 16:28:46 brent: This is editorial, it is post CR and also i18n. This is assigned to you, can you give us an update on this issue? 16:28:51 brent: This looks editorial. 16:29:19 manu: I can take this, this came up during their pre-CR review. They want us to say "our examples are in English to make the spec easier to read". 16:29:42 manu: They would rather we have i18n everything in the specification, but understand that it's harder to read examples if we have every single human-readable text string have 15 different translations. 16:29:57 brent: Ok, that makes sense. This one is straightforward so if anyone wants to step forward and grab it. 16:30:18 subtopic: https://github.com/w3c/vc-data-model/issues/1210 16:30:26 brent: Document issuer-defined vocabulary and use of `@vocab`. 16:30:47 q+ 16:30:50 brent: This was raised by Manu in response to a comment by Gabe. I believe since this time we have made `@vocab` normative, what's the proposal? 16:30:50 ack manu 16:31:26 manu: We made vocab normative and we have this concept of issuer-defined vocabularies and we don't talk about it in the spec. The resolution would be to raise a PR to make it easier to get started and we might put it in the Getting Started section. 16:32:00 manu: We could say "by default" if you magic a term out of thin air in a VC it will automatically go into the issuer-defined vocabulary, which means the person that's creating it needs to do something about that eventually such as creating documentation, talking to your community, or eventually creating a context for it. 16:32:39 manu: The PR needs to say there's an issuer-defined vocab concept, it will help you get started, if you create new terms you should write docs so people can find information on your term or ideally, just create a context and a vocabulary file that defines your term formally. 16:32:43 manu: That's what the PR should probably say. 16:32:55 brent: Thank you, Manu, that sounds straightforward. 16:33:36 brent: Shout out to the group if anyone else wants to take this on. Generally all these PRs are non-normative and would have a less stressful PR creation experience and I encourage people on the call to jump in. 16:33:47 subtopic: https://github.com/w3c/vc-data-model/issues/1217 16:34:11 q+ 16:34:11 brent: This one was opened by Manu in response to a link from Oliver Terbu and says we should link back to best practices. 16:34:17 brent: For Linked Data best practices. 16:34:20 ack ivan 16:34:27 ivan: Isn't it very close to the previous issue? 16:34:39 brent: It could possibly be addressed in the same bit of text. 16:34:46 q+ 16:34:48 q- 16:34:49 q+ 16:34:55 ivan: I think it's very much the same thing -- what Manu proposed to say is what Linked Data best practices mean. 16:34:58 ack manu 16:35:23 manu: I think they are slightly different, Ivan. It is true that what we're going to write in this specification is a Linked Data best practice, but I think people were looking for language that was very specific to this spec. 16:35:46 q+ 16:35:47 manu: I don't know if there's anywhere we can point to ... to say that a default vocab is a best practice, it isn't one, I've said it's a bad idea but we've done it. 16:36:12 manu: I would hope that we would never in a Linked Data best practice document say use a default vocabulary. I wouldn't expect us to say that. I know it's a controversial thing to say we shouldn't have a default vocab. 16:36:15 ack ivan 16:36:41 ivan: I turn it a little bit around. If we start by finding a place somewhere what it means if you really add, properly, some vocabulary to a VC of your usage, which means you have to define the terms and put up a JSON-LD context, etc. what you said before, this is the best practices are. 16:36:47 ivan: This is what implementations should do. 16:37:01 q+ to ask about saying you can do this but best practices are 16:37:08 ivan: At that point, we can add "as an additional measure `@vocab` is there, but please do what is described above". 16:37:09 ack brent 16:37:09 brent, you wanted to ask about saying you can do this but best practices are 16:37:15 brent: I think exactly the same thing. 16:37:37 brent: I would be interested to hear if anyone is opposed to us saying "here's what our spec allows you to do to get started, but best practices, over there is what would be best". 16:37:41 +1 to the approach that ivan and brent are advocating for. 16:37:49 brent: I think that would hopefully allow the spec to articulate the concerns that Manu has raised. 16:37:59 brent: I'm seeing +1's to Ivan's recommended course of action. 16:38:16 brent: Now all we need is someone to put it into place -- or does Manu want to handle it in the PR for the last issue. 16:38:21 manu: I don't know for now. 16:38:32 present+ 16:39:04 brent: Manu is intending to raise a PR that says what we allow you to do with `@vocab` and this PR would say ... well, to do this work would require knowing a link to LD best practices and adding a link to the spec with language that includes that link. 16:39:14 brent: Whomever gets their PR in first would have to work around the other. 16:39:19 brent: No one is assigned to this one yet. 16:39:28 brent: I will see if anyone wants to pick this one up. 16:40:12 brent: Just a note that issues that do not end up with anyone assigned -- will go onto the list of "do we really want to do this, if not why is it open?". 16:40:37 subtopic: https://github.com/w3c/vc-data-model/issues/1176 16:40:54 brent: Define what a credential validity does mean. 16:41:05 brent: I'm not sure ... this is about validity periods. 16:41:17 brent: The last conversation happened in July of last year. 16:41:37 brent: What, if anything, is the action here? 16:41:49 q+ 16:41:55 ack JoeAndrieu 16:42:13 q+ 16:42:23 steele has joined #vcwg 16:42:30 steele has joined #vcwg 16:42:40 ack manu 16:42:40 JoeAndrieu: I think this is still tied up in the ambiguity around what should be in verification vs. validation. I don't know what to do with this issue ... that lingering delineation, I don't remember where the conversation is in github around this but there was some movement and I think I was convinced that other things that should be in verification weren't. 16:43:05 manu: I think Dave Longley had a good proposal somewhere on the Internet. Things can happen during verification that an extract information that can be used in a validation phase. 16:43:18 manu: There are things that are clearly in verification like checking the proofs. 16:43:36 manu: Then there are other things that can happen like checking the signature on a status list -- but the information in that list -- is up to the validation phase to use. 16:43:59 manu: We can still talk about these things ... getting the authentic information during verification and then handing it off for validation seems like it would help. 16:44:34 brent: I will note that we have a validation appendix on the data model currently and perhaps an action here would be to update that appendix to reflect what Dave said. 16:44:43 brent: I haven't heard anyone say that they disagree with that expression of things. 16:44:58 brent: Possible action here -- but now Joe is assigned. 16:45:11 JoeAndrieu: I will try and do this -- and reach out to you, Dave, for the language you proposed. 16:45:31 subtopic: https://github.com/w3c/vc-data-model/issues/995 16:45:41 brent: Current definition of claim. 16:46:01 brent: There was a decently long conversation last year. It was ultimately assigned to Mike Jones. 16:46:24 q+ 16:46:26 brent: I don't believe ... I'm not sure what to do here. I'm not sure if there is appetite with mucking about with our current definition of claim. 16:46:41 ack manu 16:46:41 brent: This was on our list of "if we have time and still care then then we can think about doing something". 16:46:51 manu: I don't know if we care at this point. We had a very long discussion and debate in the PR. 16:46:55 JoeAndrieu -- as I recall, the key bit relevant to 1176 is that Verification is crypto/technological which we can specify, while Validation is business logic which we cannot specify 16:46:58 q+ 16:47:28 manu: I believe Joe raised another PR that modified other things that did get in. This also had to do with adding more roles to the ecosystem like author and party -- and the PR just kept growing and changing core roles we didn't feel comfortable with. Personally, I think the spec is fine as-is. 16:47:34 q+ 16:47:34 manu: I don't think we need to modify it at this point. 16:47:51 ack selfissued_ 16:47:55 brent: Currently our terminology says: "claim: an assertion made about a subject". 16:48:05 q+ 16:48:22 selfissued_: It being assigned to me and having written the definition of in the JWT spec -- I will look into a change to match the understanding in the community or I will close it. 16:48:33 ack ivan 16:49:14 ivan: More formally, the issue was closed on June 27 -- and then it was reopened by you referring to a PR ... and then there was a discussion on the 15th of August which says "Fine to just to close it, waiting a week is probably polite." 16:49:30 ivan: That was Mike's last comment, I have the impression that this has already been discussed and decided to be closed and fell between the cracks. 16:49:41 brent: We were waiting on closing PR 1172 so the conversation could continue in this issue. 16:50:02 brent: If folks just want to close this ... I think right now Mike is going to look at this now vs. JOSE's and maybe recommend closing the issue. 16:50:05 ack TallTed 16:50:18 dlongley: A claim is importantly a triple in the VCDM, not just a property+value -- which might not be exactly like other specs. 16:50:28 TallTed: We resolved to close 1172 because we didn't find consensus there. 16:50:40 TallTed: Which also says to just close the issue because we didn't find consensus. 16:51:06 selfissued_: I should look at it because the claim definition is different than JWT. If I don't get to it, if I don't get to it in a couple of weeks I won't stand in the way. 16:51:12 brent: If this one rolls around in the queue again we will close it. 16:51:27 subtopic: https://github.com/w3c/vc-data-model/issues/1243 16:51:39 brent: This was raised by and assigned to Gabe. 16:51:49 q+ 16:51:56 ack ivan 16:51:58 q+ 16:52:00 brent: About recommending using DIDs. There was some pushback on both sides here. 16:52:06 q+ 16:52:24 ivan: The comment from Orie on August 16, in view of the formal objections to DID we should not do that -- but those formal objections are behind us, so that is moot now. 16:52:26 ack decentralgabe 16:52:47 q- 16:52:50 decentralgabe: I think this can and should be closed with the controller document spec up and coming. I'm happy to open a similar issue there to have some language around the usage of DIDs in the controller document. 16:52:56 q+ 16:53:01 ack manu 16:53:24 manu: Not necessarily opposed -- I think that might also fail because the controller document is supposed to be agnostic to DIDs as well. It might be useful saying that the vast majority of deployments use DIDs. 16:53:31 manu: We designed VCs to be compatible with DIDs. 16:53:48 manu: I don't know of many deployments that aren't using DIDs at all in their roll outs. 16:54:01 brent: Would you be opposed to marking it pending close? 16:54:03 manu: No. 16:54:14 brent: I will mark it pending close. 16:54:39 subtopic: https://github.com/w3c/vc-data-model/issues/1239 16:54:48 brent: Expires header for HTTPS credentials v1 is in the past. 16:54:58 q+ 16:55:00 brent: Something about caching ... I don't know what this means exactly. 16:55:03 ack manu 16:55:35 manu: I think this person is saying that the HTTP headers for the credentials/v1 context are wrong. Because of the way it's set, it always expires which forces implementations to always go to the Web. 16:55:55 manu: They can't cache -- and they shouldn't be going out to the Web at all for that context or the v2 one -- but we should make it do the right thing. 16:56:07 brent: Assigned to Ivan. 16:56:30 ivan: I was assigned because all this is happening via http access files which only I can change. But I have no idea what to change it to, so I need input. 16:56:32 q+ 16:56:38 ack manu 16:56:39 brent: If folks have clear and concise inputs? 16:56:46 manu: Cache time should be set to three months. 16:56:52 ivan: How do I do that in htaccess? 16:56:59 manu: Ping me and we'll figure it out together. 16:57:00 ivan: Ok. 16:57:05 brent: And we are done with the call today. 16:57:30 brent: The editors and chair and team contact have explored the possibility of a F2F meeting this spring and we're not feeling it necessary, but if you feel differently, please contact us. 16:58:15 brent: There will be other VC-related conversations at other conferences as well. Thanks for scribing, Dave! 16:58:21 dlongley: welcome! 16:58:24 rrsagent, draft minutes 16:58:25 I have made the request to generate https://www.w3.org/2024/01/24-vcwg-minutes.html ivan 16:58:42 scribe- 16:59:35 rrsagent, bye 16:59:35 I see no action items