19:42:52 RRSAgent has joined #vcwg 19:42:56 logging to https://www.w3.org/2023/12/06-vcwg-irc 19:42:59 Zakim has joined #vcwg 19:43:33 brent has changed the topic to: Meeting Agenda 2023-12-06: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20231206T150000/ 19:56:54 zakim, start the meeting 19:56:54 RRSAgent, make logs Public 19:56:56 please title this meeting ("meeting: ..."), brent 19:57:14 meeting: Verifiable Credentials Working Group Weekly Teleconference 19:57:22 chair: Brent Zundel 19:59:53 present+ 20:00:46 decentralgabe has joined #vcwg 20:00:49 present+ 20:01:24 DavidC has joined #vcwg 20:01:28 present+ 20:01:29 present+ 20:01:33 present+ identitywoman 20:01:45 pauld_gs1 has joined #vcwg 20:01:49 present+ 20:02:19 present+ 20:03:08 scribe+ 20:03:17 JoeAndrieu has joined #vcwg 20:03:24 present+ 20:03:47 present+ 20:03:48 dmitriz has joined #vcwg 20:04:06 przemek has joined #vcwg 20:04:06 gkellogg has joined #vcwg 20:04:08 Will has joined #vcwg 20:04:10 present+ 20:04:10 brent: Is there anyone who would like to suggest changes/additions to the agenda? 20:04:19 present+ 20:04:27 andres has joined #vcwg 20:04:29 present+ 20:04:44 Topic: Work Item status updates/PRs 20:04:46 brent: No changes requested. I think we've met each other so we'll skip introductions and start our first topic. 20:04:48 q+ 20:05:05 ack manu 20:05:13 subtopic: https://github.com/w3c/vc-specs-dir/pull/30 20:06:11 manu: This pull request to vc-specs-dir isn't controversial; we're going to call them 'securing mechanisms' rather than 'proofs'. This is to address some of jyasskin's concerns. 20:06:20 manu: We'll probably merge it after this call. 20:06:21 https://github.com/w3c/vc-data-model/pulls 20:06:53 Orie has joined #vcwg 20:06:56 present+ 20:06:59 manu: We made good progress on the call yesterday, but many pull requests are probably not going to get consensus. 20:07:43 manu: I don't think the 'RelatedResource for Verifiable Presentations' PR has any blocking issues, so that will probably move forward. 20:07:45 smccown has joined #vcwg 20:08:04 enveloped seemed ok, but "watermark" did not 20:08:13 its ok for status checking to go in, as long as its clearly labeled "validation" and clearly happens after securing mechanism "verification" succeeds. 20:08:15 manu: 'Enveloped Verifiable Credential' to refer to VCs with external proofs will probably not gain consensus. 20:08:50 manu: We're working with implementers to get vc-data-integrity changes through. 20:09:09 q? 20:09:10 brent: Any updates on 'controller documents'? 20:09:26 manu: No update yet. 20:09:35 q+ 20:09:39 brent: How is the JOSE/COSE work going? 20:09:40 ack Orie 20:10:25 https://github.com/w3c/vc-jose-cose/pull/186 20:10:34 Orie: There are two open pull requests. One of them is a placeholder PR in case we need to remove registry entries with multiple suffixes. I imagine we'll close pull request #186 soon if people continue to object to it. 20:11:17 q+ to agree with Orie. 20:11:32 ack manu 20:11:32 manu, you wanted to agree with Orie. 20:11:39 Orie: The other PR (#190) should probably be broken up because it's a little too big. We need to know how it will be related to the verification algorithm of the main data model. 20:11:57 manu: I would suggest adding an 'at risk' marker on the verification algorithm. 20:12:06 +1 to at risk marker, and file any specific issues that need to be resolved 20:12:18 it not going to be reviewable for much longer : ) 20:12:30 manu: We could say that 'we are working on changes', and because we have hundreds of comments on the issue thread it's difficult to contribute. 20:12:47 manu: We could ask people to request changes on the GitHub PR review. 20:13:43 brent: I'm seeing change requests from TallTed, Orie and Oliver Terbu. 20:14:12 TallTed has joined #vcwg 20:14:23 I will raise issues based on Oliver's feedback. 20:14:35 brent: TallTed, you're one of the people who requested changes on the JOSE/COSE pull request. 20:14:52 brent: TallTed, if you have changes beyond editorial merely ones, please open a new issue. 20:15:09 TallTed, I am fairly certain that everything that I have requested is editorial. 20:15:18 TallTed: I am fairly certain that everything that I have requested is editorial. 20:15:31 present+ TallTed 20:15:37 Topic: Issue Triage 20:15:46 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3Apost-CR+sort%3Aupdated-asc 20:16:46 subtopic: https://github.com/w3c/vc-data-model/issues/1316 20:17:17 brent: Orie, you opened this issue. 20:17:26 brent: Is this before or post-CR? 20:17:30 q+ 20:17:35 ack Orie 20:18:15 Orie: If all of the issues related to the verification algorithm are resolved, this would be resolved too. I think for now it should be cross-linked and perhaps close it once the verification algorithm discussions have concluded. 20:18:45 brent: Course of action is to label it as 'before CR' and link it to the other pull requests. 20:19:06 Orie: Yes, that's correct. 20:20:23 Orie: I'm going to assign this to Mike Jones because of conversations we've had about this 20:20:48 subtopic: https://github.com/w3c/vc-data-model/issues/1314 20:21:45 q+ 20:21:49 brent: Do we have a sense for whether this issue has been addressed? 20:21:52 ack Orie 20:22:23 Orie: I don't think we were able to establish consensus to resolve this previously, so I suggest it be closed. 20:22:24 q+ 20:22:36 scribe+ 20:22:39 ack seabass 20:23:11 q+ 20:23:11 q+ 20:23:16 seabass: I'm not familiar with this issue, but even if we don't have consensus to resolve the core essence of what's being asked. We perhaps have a responsibility to document this within the spec anyway, these issues might be experienced by multiple people until they understand the reasoning for it. 20:23:19 ack manu 20:23:51 manu: We could add some text into the specification explaining how and why the v2 data model includes more helpful properties. 20:24:08 q- 20:24:42 seabass: Ok, I'll raise an issue to add some text. 20:24:48 scribe- 20:25:07 subtopic: https://github.com/w3c/vc-data-model/issues/1359 20:26:05 q+ 20:26:17 decentralgabe: I would like to explore the question of who is authorized to present a credential. I recollect that we discussed this in the past but did not come up with a solution. I would be interested to know what others are doing in this regard. 20:26:24 q+ 20:26:26 ack manu 20:27:10 +1 that more semantics are needed and should use confidence method 20:27:17 manu: Digital Bazaar aren't doing this. I imagine that ConfidenceMethod would meet this requirement. 20:27:19 ack Orie 20:28:02 Orie: SD-JWT currently requires you to do this in a special way: you are required to implement support for Confirmation Method, which is the IETF way of doing this. 20:28:04 q+ 20:28:17 Orie: If ConfidenceMethod was in the core model, there might be conflicting or redundant ways to express this. 20:28:50 ack dmitriz 20:28:52 Orie: This is built-in to SD-JWT, so we can't contradict what's already the case in SD-JWT's specification. 20:29:14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2 20:29:26 to say i'm not sure what SD-JWT does, but i would not expect `cnf` to cover this use case, more semantics are needed 20:29:30 dmitriz: The CNF property used to identify the current presenter in SD-JWT, not to list authorised presenters - is this correct ? 20:29:41 q+ 20:29:51 sd-jwt-vc has cnf as well https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html 20:29:52 Orie: We've updated the specification so that won't be up to date any longer. 20:30:06 ack DavidC 20:30:23 also, sd-jwt is still a wg adopted draft.... so... this might all change. 20:30:34 q+ to ask gabe and then move on 20:31:17 @Orie - looking at https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html , I still see no wording on how an issuer _specifies_ authorized presenters. Only wording on how to use cnf in the DPoP sense 20:31:17 not correct summary of what SD-JWT.... 20:31:24 DavidC: I think it's probably a bit different with SD-JWT, because the issuer is given unblinded data to a specific entry. Anyone else who gets the credential will be blind to who is presenting it. What the SD-JWT does is 'blind' data, but makes disclosures in the clear. The holder is getting the information in the clear. 20:31:50 dmitriz I am not talking about that draft, I am talking about https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2 20:31:54 DavidC: It's not the same as normal Verifiable Credentials because only Holders are able to see the unblinded data. Therefore only the holder is able to present it. 20:32:02 ack brent 20:32:02 brent, you wanted to ask gabe and then move on 20:32:04 @Orie - got it, thanks. 20:32:18 brent: Did that help, decentralgabe? 20:32:34 I acknowledge the authors of draft oauth-sd-jwt-vc have a lot of work still to do : ) 20:32:39 decentralgabe: A little; I'm happy for it to be closed now. 20:32:48 brent: I'll leave this to you decentralgabe. 20:32:51 subtopic: https://github.com/w3c/vc-data-model/issues/1371 20:33:25 @Orie in draft 06, it seems like it's using the 'cnf' property in a way that's not intended by the DPoP rfc, it should probably be the 'aud' claim. But anyways, that's a discussion for the ietf spec 20:33:50 brent: I do believe that VC JOSE/COSE is the closest thing that this group will be able to produce in order to address this issue. I'm not sure what else this issue is asking for. We probably wouldn't have the capacity to create a new document to address this use-caes. 20:33:53 q+ 20:33:55 s/caes/case/ 20:33:57 ack DavidC 20:34:18 @dmitriz: yup, also note that the current SD-JWT mechanism does not say which person the `cnf` claims applies to (for multiple holders, etc.) 20:34:23 DavidC: It's really a hot topic at the moment. It will be implemented in the EU Digital Identity Wallet. It will be demonstrated in the game hot group. 20:34:34 s/game/GAIN 20:34:41 We have an entire TR track document 20:34:46 DavidC: We don't have any guidelines at the moment about how this would be used. 20:34:59 David, please read: https://w3c.github.io/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose 20:35:04 q+ 20:35:27 DavidD: It specifically says that SD-JWT aren't W3C Verifiable Credentials, which isn't a good situation. 20:35:46 https://w3c.github.io/vc-jose-cose/#with-jose 20:35:51 David: https://w3c.github.io/vc-jose-cose/#securing-json-ld-verifiable-presentations-with-jose 20:35:51 DavidC: There is an example for SD-JWTs in VCs, but not in VPs. 20:36:13 please file issues, or PRs if you want the text to change. 20:36:24 ack manu 20:36:31 brent: It may be that a full specification would be the best option, but we don't have the capacity to do that at this stage in our Working Group. 20:37:01 If your customer wants help, feel free to put me in touch. 20:37:33 manu: VC-JOSE-COSE is the document that expresses this. I spoke with a customer who was very confused about IETF defining how to make credentials. I agree therefore that there's confusion. I think we should make sure that they also know there is confusion, and there is an opportunity to clarify things in the IETF specications. 20:38:05 I would in general, not assume that IETF documents are "done" until they are RFCs 20:38:13 q+ 20:38:19 DavidC: Would the editors of the VC-JOSE-COSE be happy to add more description in the specification? 20:38:24 ack Orie 20:38:27 DavidC: I think that would be appreciated. 20:38:30 +1 to move to vc-jose-cose 20:38:45 brent: Should we move the issue to vc-jose-cose repository? 20:38:50 Orie: Yes, you can do that. 20:39:24 brent: I see support in the IRC, so that's what I'll do. 20:39:30 subtopic: https://github.com/w3c/vc-data-model/issues/1365 20:39:32 (but not support for ignoring the fact that it's not clear to readers that vc-jose-cose is THE specification that outlines how to use SD-JWT with VCDM) 20:39:53 brent: andres, is this before or post-CR? 20:40:04 andres: I think this should be before CR. 20:40:10 brent: Who's willing to be assigned? 20:40:17 manu: I am willing to be assigned. 20:40:29 subtopic: https://github.com/w3c/vc-data-model/issues/1366 20:41:16 andres: I think that if the clarifications are made in #1365, then I think the point made in this issue is moot. It will also be addressed by the solution that was suggested yesterday of adding a type property. 20:41:18 +1 to what andres just said, agree with that direction. 20:41:56 brent: Do we need both issues to track the concern? 20:42:00 q+ 20:42:13 ack manu 20:42:15 andres: I think one builds upon the other. One would be automatically closed. 20:42:39 q+ 20:42:45 manu: Maybe changing the title would help. You're not asking for a rename of the property now, only asking for clarification. So we can change the title of the issue. 20:42:46 ack Orie 20:43:23 Orie: People have been putting Verifiable Credentials in the verifiableCredential property of Verifiable Presentations already. 20:43:37 Orie: Changing this now will be unacceptable to Transmute. 20:44:04 Orie: I suggest allowing either using IRIs or the VCs directly. That's also consistent with the RDF here. 20:44:22 q+ 20:44:28 ack dlongley 20:44:38 I read the minutes 20:44:38 brent: I'll make this before CR. Who's willing to be assigned? 20:45:06 dlongley: I think Orie is referring to a specific JSON-LD property that has a bug, and once this has been fixed there won't be an issue. 20:45:15 q+ 20:45:23 scribe+ 20:45:26 dlongley, confirming you are disclosing that https://json-ld.org/playground/ produces invalid N-Quads? 20:45:28 ack seabass 20:45:46 seabass: Personally, is this a clarification on whether you can embed the definition of a VC within a VP? Or is this something different? 20:46:29 brent: It is related to that. There are RDF concerns about whether ... you put the VC thing instead VP.verifiableCredential and that's ok, a VC that's been externally secured using a mechanism that uses an envelope, it creates a new data structure so it no longer fits within that property. 20:46:42 seabass: So this is an uncontroversial change in the mechanics to our RDF data model. 20:46:56 brent: I don't think I'm comfortable with saying uncontroversial here. 20:46:58 scribe- 20:47:10 subtopic: https://github.com/w3c/vc-data-model/issues/1364 20:47:11 seabass: Thank you for the clarification. 20:47:38 q+ 20:47:43 ack Orie 20:48:05 Orie: I would suggest keeping this issue open. We need to know if our registration will be accepted or not. 20:48:07 q+ 20:48:21 ack TallTed 20:48:21 brent: I'm interpreting that as before CR. 20:49:00 TallTed: There's nothing prohibiting making registrations with multiple suffixes. The question is about how those are going to be interpreted. 20:50:02 subtopic: https://github.com/w3c/vc-data-model/issues/1373 20:50:22 brent: I think this one is before CR. 20:50:31 It's before CR. 20:50:35 +1 to before CR 20:50:38 q+ 20:50:47 ack Orie 20:50:49 q+ 20:51:04 Orie: I would like some elaboration to be in the minutes: could someone explain the essence of the bug? 20:51:04 ack dlongley 20:51:35 dlongley: It's not that we have a bug in our context file. It's that we added terms to make v1 VCs compatible with v2 Verifiable Presentations. 20:52:02 dlongley: We needed to make sure that context files for v1 VCs didn't affect the context files for v2 VPs. 20:52:12 dlongley: Some implementations had bugs, some didn't. 20:52:35 dlongley: We should be able to resolve this by nullifying the context as part of these implementations. 20:52:44 dlongley: We don't need to do anything in this WG. 20:53:07 Topic: Issue Discussion 20:53:15 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+sort%3Aupdated-asc 20:53:16 Sounds like there is no bug in our context, and this issue should be closed. It also sounds like there are buggy JSON-LD processors, that produce inconsistencies, that cause credentials to not verify. 20:53:43 subtopic: https://github.com/w3c/vc-data-model/issues/1352 20:53:47 Orie: It is a reasonable expectation for any software is that there will be bugs from time to time. 20:54:01 brent: This issue is being addressed by the PR we discussed yesterday. 20:54:12 the complicated the software, the more reasonable it is to expect bugs 20:54:40 brent: I believe that yesterday we decided that the verifiableCredential property should be expanded to allow each object in the array to express its type: whether it is a normal VC or an enveloped VC (actual name yet to be decided). 20:55:15 Orie: sometimes! :) ... i would say that it's not a good idea to assume simple software is less likely to be buggy (as this may lead to more likely bugs in such software) 20:55:20 You're coming across as trolling, Orie. Please stop. You asked us to explain something. We did, and now you're expressing what comes across as mock surprise. 20:55:33 q? 20:56:04 brent: We've got eleven before-CR issues. 20:56:13 brent: We have seven still needing discussion. 20:56:54 brent: If you're assigned to one of these PRs, we need access: if nothing is in the pipeline to address the issue, we'll have to postpone it. 20:57:11 s/we need access/we need action/ 20:58:00 zakim, who is here? 20:58:00 Present: brent, decentralgabe, DavidC, manu, identitywoman, pauld_gs, seabass, JoeAndrieu, dlongley, Will, dmitriz, andres, Orie, TallTed 20:58:02 On IRC I see TallTed, smccown, Orie, andres, Will, gkellogg, przemek, dmitriz, JoeAndrieu, pauld_gs1, DavidC, Zakim, RRSAgent, brent, manu, Github, npd, bumblefudge1, seabass, 20:58:02 ... MojGraph, saysaywhat, bumblefudge, ounfacdo, cel[m], joraboi445, SintayewGashaw, cel[h], w3c_modbot, dlehn, ivan, rbyers, cel, dlongley, hadleybeeman, stenr, shigeya, 20:58:02 ... cbiesinger, bigbluehat, csarven, rhiaro 20:58:12 present+ andres 20:58:31 zakim, end the meeting 20:58:32 As of this point the attendees have been brent, decentralgabe, DavidC, manu, identitywoman, pauld_gs, seabass, JoeAndrieu, dlongley, Will, dmitriz, andres, Orie, TallTed 20:58:34 RRSAgent, please draft minutes 20:58:35 I have made the request to generate https://www.w3.org/2023/12/06-vcwg-minutes.html Zakim 20:58:42 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 20:58:42 Zakim has left #vcwg 20:58:46 rrsagent, bye 20:58:46 I see no action items