14:05:29 RRSAgent has joined #vcwg 14:05:33 logging to https://www.w3.org/2024/08/07-vcwg-irc 14:05:33 RRSAgent, make logs Public 14:05:34 please title this meeting ("meeting: ..."), ivan 14:05:42 Meeting: Verifiable Credentials Working Group Telco 14:05:42 Date: 2024-08-06 14:05:42 Agenda: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240807T110000/ 14:05:42 chair: brent 14:05:58 TallTed has joined #vcwg 14:12:30 bigbluehat has joined #vcwg 14:43:20 brent has joined #vcwg 14:44:23 brent has changed the topic to: Meeting Agenda 2024-08-07: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240807T110000/ 14:58:53 hsano has joined #vcwg 14:59:45 decentralgabe has joined #vcwg 14:59:59 present+ 15:00:07 present+ tallted, brent 15:00:23 present+ 15:00:51 DavidC has joined #vcwg 15:01:02 present+ 15:01:17 KevinDean has joined #vcwg 15:01:17 present+ 15:01:34 present+ 15:02:13 present+ selfissued, manu, KevinDean, wip, joeandrieu 15:02:26 JoeAndrieu has joined #vcwg 15:02:41 present+ 15:02:45 Wip has joined #vcwg 15:02:50 present+ 15:03:05 present+ dlongley 15:04:17 scribe+ 15:05:19 brent: Welcome to the VC telecon. Our agenda today is talking a bit more about wrapping up the VCDM. Then we'll talk about media types for VC jose-cose and then finish up a meeting talking about the controller document because that's the next one we have that we need to try to transition, ideally, by the end of the month. 15:05:26 brent: Any changes or additions to the agenda? 15:05:58 selfissued has joined #vcwg 15:06:03 Topic: VCDM Wrap Up 15:06:05 present+ 15:06:16 subtopic: https://github.com/w3c/vc-data-model/pull/1536 15:06:16 brent: We have a PR we should look at. 15:06:44 JennieM has joined #vcwg 15:06:44 q+ 15:06:49 brent: There are a number of requests for changes here, Ivan can you give us a summary of what the PR does? 15:06:51 present+ 15:06:56 ack ivan 15:06:57 brent: I encourage folks who would like changes to also jump in. 15:07:21 ivan: Just to say what you said here a little differently. There were a number of comments, so they have all been incorporated, so as far as I know, no more open comments. 15:07:59 ivan: What it does is -- following up on the PR(s) which changed the place for the `@vocab` term and now there is a separate undefined term that has to be done properly and this PR handles that. 15:08:11 ivan: There is one part of the PR that isn't in there which is for htaccess file changes I have to do externally. 15:08:32 ivan: This will handle redirections, etc. it's not on github, won't be subject to PR, but I put a verbatim copy of the htaccess file. 15:08:49 ivan: There were some small comments incorporated on that as well, as far as I am concerned this can be merged and then I will change the htaccess file after that. 15:08:59 brent: Thanks for that summary, Ivan. 15:09:25 brent: To add a little bit more context, I believe three weeks ago this group came to consensus on and merged two PRs to make changes to add the undefined terms context and remove the `@vocab` from the core context. 15:09:35 brent: This PR just does administrative work to finish up those things that were done nearly a month ago. 15:09:38 ivan: That is correct. 15:10:11 brent: Ted and Mike Jones, your reviews are still showing requests for changes, Ted your changes have been merged, Mike if you'd like to jump on the queue you can do so. 15:10:33 https://github.com/w3c/vc-data-model/pull/1536 15:11:24 selfissued: Alright, I still think it's a mistake but I think the ship has sailed and I'll approve it. 15:11:28 brent: Thank you Mike, I appreciate that. 15:11:39 brent: Ok, if there are no more comments on this PR, then we can look briefly at our set of issues. 15:11:46 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc 15:11:51 q+ 15:12:03 brent: There are two remaining issues on the VCDM. 15:12:12 brent: I think the first issue will be addressed by the PR we just looked at. 15:12:20 brent: I think the final issue here is 1538. 15:12:21 subtopic: https://github.com/w3c/vc-data-model/issues/1538 15:12:28 brent: This is about respec plugin not working. 15:12:43 q? 15:12:50 ack manu 15:12:59 manu: It's just a bug that needs to be fixed. We are going to fix it because the spec is bad without it. 15:13:18 q+ 15:13:23 manu: This has to do with all the autogeneration of the code examples, and echnida is not waiting for the auto-generation to finish, we need to just figure out how to stop it from doing that and wait for the examples to generate. 15:13:27 manu: Just some code to be written. 15:13:28 ack ivan 15:14:00 ivan: If this is solved, I will have to fix the overview document too -- if you see a commit over there it's for the same reason to get the respec plugin working over there too. 15:14:07 brent: Thanks, Ivan. 15:14:29 brent: Benjamin, do you have an estimate ... when can we get an estimate for getting an estimate for fixing it? 15:14:55 bigbluehat: I think we have already merged in changes to disable the async generation -- I can give you another estimation after we check on that. 15:14:55 q+ to speak to "last editorial pass" on vc-data-model. 15:15:19 brent: I know that Manu, wearing his editor hat is doing a full sweep of the spec, I encourage others to do so as well. 15:15:22 subtopic: editorial pass 15:15:47 q+ 15:15:55 ack manu 15:15:55 manu, you wanted to speak to "last editorial pass" on vc-data-model. 15:15:55 manu: I am about 30% of the way through the data model spec -- I expect to have to do a little more clean up in the advanced concepts area because we made more changes there. 15:16:01 manu: A lot of the spec is considerations. 15:16:33 manu: It would be awesome if someone would step forward if someone would step forward to do the editorial pass on privacy and security considerations. Ted, I don't know if you any spare cycles, that would speed things along, I understand if people don't have cycles. 15:16:55 manu: If someone could take security considerations on in parallel -- that would help. It's going pretty quickly, but once I'm done with this pass, it's ready to go into CR2. 15:17:04 manu: Arguably it could be ready to go to PR if those go smoothly. 15:17:45 manu: We're still trying to get implementers to implement enveloped presentations and credentials, I don't think we have any implementers there yet, and that would be a reason not to go into CR2 until we have implementers for those features. Now's the time for people that really wanted it to step forward and do it. 15:17:49 q+ 15:18:06 manu: Those are not marked as at-risk, because we were fairly certain people would implement, but I think it's just that people haven't known to implement yet, that's the long pole. 15:18:12 brent: Thanks, Manu. 15:18:12 ack ivan 15:18:38 ivan: Minor things related to this editorial thing, do I understand well that the `termsOfUse` is a full-blown property now? Not just reserved? 15:18:47 manu: Correct, there's an error in the spec, I have to fix that. 15:18:57 ivan: It has to be removed from the vocabulary as reserved as well. 15:19:04 manu: Can you do that, Ivan? 15:19:08 ivan: Can I do it now? 15:19:10 manu: Yes. 15:19:16 ivan: I know that this came up some time ago -- another thing. 15:19:19 q+ 15:19:43 ivan: I haven't followed all the details the discussion on vc-jose-cose, I would like someone to look at the diagrams to make sure the right media types and whatnot are set in the diagrams. I want a check on that again. 15:19:49 ivan: So someone can tell me what has to be changed. 15:19:58 selfissued: I don't understand the question, the media types are in the spec. 15:20:22 ivan: There are diagrams in the VCDM that provide oversight of vc-jose-cose and there are some JSON web terms things there and I want to make sure they are correct. 15:20:36 selfissued: This may pertain the subsequent discussion, but this isn't about text in vc-jose-cose? 15:20:37 ack decentralgabe 15:20:41 ivan: No, this is in the diagrams in VCDM. 15:20:55 decentralgabe: I'll review those diagrams. I wanted to respond to enveloped VPs and VCs. 15:21:11 ack brent 15:21:11 decentralgabe: I'll be implementing over the next week, so I'll be an implementer. 15:21:48 brent: Chair hat off, as a representative of a company that is also implementing JOSE-signed VCs using the enveloped format, our hold up has been the lack of test suite, but the implementations are there and I know of at least two companies that could supply implementation evidence if they so desire. 15:21:58 brent: I am not concerned about that feature being at-risk. 15:22:04 Topic: VC JOSE COSE Media Types 15:22:07 brent: Next topic is vc-jose-cose media types. 15:22:42 brent: In our group there was media type confusion ... we had media types that we wanted and we tried to get them registered for quite a long time -- or get the group into a state where we could get them registered. 15:23:14 brent: The IETF registrations dragged on for years, but what it came down to was that we could not register the media types that we wished to, but due to some quirks of our process, consensus fell in different places in different specs in different ways. 15:23:30 brent: The way consensus worked out was that our core spec uses `application/vc` and `application/vp`. 15:23:45 brent: The vc-jose-cose spec were different. 15:23:55 brent: The mismatch in media types between the two specification might be bad. 15:24:05 brent: I have learned since then, that it's actually not that big of a deal. 15:24:45 brent: I talked to a bunch of folks at IETF and learned a lot more about how they are interpreted -- the way the media types are used and how they are seen and interpreted, plus signs don't mean what we thought they meant which is related to why our multiple plus signs didn't go through. 15:25:02 brent: As the person that raised the issue about making the media types align -- I'm now saying it doesn't matter, it might not be awesome, but it doesn't matter. 15:25:45 brent: However, another thing I learned at IETF last month, the inconsistency across media types handling things at different levels in different specs, isn't a big deal, but in the same spec could lead to confusion. 15:25:53 q+ to provide some input on media types for VC-JOSE-COSE. 15:26:09 brent: So the conversation right now with doing `application/vc+jwt` but then `application/vc-ld+sd-jwt` would be bad. 15:26:57 brent: Why does this matter? There's a specification at IETF called SD-JWT-VC and they have been using the media type `application/vc+sd-jwt` in production over there. We could talk about the appropriateness of them doing that if we want, but I think them using a media type that wasn't in conflict with our group's media types at the time doesn't really matter. 15:27:17 q+ to ask for clarification 15:27:43 q+ 15:27:43 brent: There are a lot of cans of worms we could open here -- that is where the conflict lies. If we were to go forward and assert that we should have `application/vc-sd+jwt` to mean something else, out from underneath that group that was using it for something else, that would be the kind of move I wouldn't be proud to make. 15:27:53 brent: I'm going to go to the queue we can talk about this for about 15 minutes. 15:27:55 ack manu 15:27:55 manu, you wanted to provide some input on media types for VC-JOSE-COSE. 15:28:06 manu: Thanks for that summary, Brent, I agree with most of it, except potentially the last bit. 15:28:24 manu: My interpretation of the way this unfolded between people that knew we were working on things in this WG is different. 15:28:37 manu: You said that there are production deployments using `vc+sd-jwt` -- I'd like to know what those are. 15:28:52 q- 15:29:15 manu: We need to understand at what level it's deployed in production because the core issue here is that we are going to put the entire ecosystem into a situation where all of the `application/vc` media types except for one is going to use the W3C VC data model. 15:29:20 manu: Just one of them is going to specifically not use that. 15:29:57 manu: Anyone looking at this without this deep understanding of the text strings not meaning anything -- which is new -- which is where we could get to consensus, but even that isn't quite right, having been the one that has had to tease apart the plus signs and their meaning. But that one plus sign still means something. 15:30:19 manu: What it means is that there is a base subtype -- and I know there's a difference of opinion at IETF -- and the expectation that most developers have is that you're using something remotely the same. 15:30:35 manu: Most of those media types that use the W3C VC data model, you will be surprised when just one doesn't. 15:30:59 manu: I agree there's a consistency problem here, where vc-jose-cose isn't going to be consistent. And, it's going to create confusion in a way that is at IETF that doesn't use the W3C data model, there will be confusion there as well. 15:31:19 manu: People are using this non-W3C VC data model -- they will be very surprised that it's not W3C VC. 15:32:06 manu: We can pick a different media type -- the people in that process at IETF are also involved in this group. We cannot say they didn't see it coming. We told them it would create a problem, and they did it anyway. 15:32:40 manu: I also Brent for us to say that if we prevent the registration of that media type ... that it's something we should not be proud of doing. I think there are a number of anti-social things that have happened during this process and that is not on this group. 15:33:06 manu: I think we can take the higher road maybe with someone threading the needle with different data models sharing the base part of the media type, but it's highly problematic. 15:33:36 q+ 15:33:36 ack selfissued 15:33:42 manu: I think the way that some groups have been operating and it's created a problem now. We should potentially have that group come in here and talk about what the best path forward is. I don't think we should confuse developers with media types that look like the same thing but they are different. 15:33:53 selfissued: On the editors call I was asked to prepare some remarks. 15:34:06 https://github.com/w3c/vc-jose-cose/pull/283 15:34:07 selfissued: I will paste into the minutes to save the scribe. 15:34:10 Level set 15:34:20 The VCDM media types are application/{vc,vp} 15:34:24 selfissued: I am not going to cover the politics, just the engineering. 15:34:29 The VC-JOSE-COSE media types are application/{vc-ld,vp-ld}+{jwt,sd-jwt,cose} 15:34:40 The VCDM and VC-JOSE-COSE media types are used in different places 15:34:53 The VCDM types are used in the "cty" (content type) header parameter to describe the type of the payload 15:35:06 The VC-JOSE-COSE media types are used in the "typ" (type) header parameter to describe the type of the entire secured object 15:35:18 They are not in the same logical or semantic namespace 15:35:30 The VC-JOSE-COSE media types do not reference the VCDM media types in their definitions 15:35:39 Rather, they reference the data types defined by the VCDM 15:35:59 There is no syntactic relationship between the VCDM and VC-JOSE-COSE media types 15:36:27 There is no concept of "Base Media Type" 15:37:01 There is a concept of Structured Suffix, which is different 15:37:09 As David Waite commented, there is no concept of a base media type; application/foo, application/foo+bar and application/foo+baz are entirely different concepts. In particular, you don't extract application/foo as a commonality between the three on a programmatic level and do something with it. 15:37:46 Therefore, while it would be nice for the name components across the specs to be similar (which they already are), they needn't be identical 15:38:03 Practicalities 15:38:14 We're not going to get consensus to merge https://github.com/w3c/vc-jose-cose/pull/283 15:38:24 We're not going to get consensus to change application/{vc,vp} to application/{vc-ld,vp-ld} 15:38:40 We're not going to get consensus to make the VC-JOSE-COSE media types inconsistent with one another 15:38:51 We could keep beating our head against this or solve it now 15:39:06 Recommendations 15:39:13 1. Close https://github.com/w3c/vc-jose-cose/pull/283 15:39:21 2. Request registration of the VC-JOSE-COSE media types with IANA 15:39:31 q+ 15:39:47 ack dlongley 15:39:57 q+ dlongley 15:40:01 ack decentralgabe 15:40:19 q+ to note that "the semantics of the base subtypes are unrelated" is NOT where consensus landed in the MEDIAMAN group 15:40:32 decentralgabe: Thanks, Mike for laying that out. I think I reached the same conclusion through different reasoning. The editors of vc-jose-cose have tried to talk to the sd-jwt-vc group but haven't been able to find common ground. 15:40:49 decentralgabe: I don't think it's worth this group's time to invite them here because I don't think things will change. 15:41:16 scribe+ 15:41:18 decentralgabe: I don't see a better path, I think we should keep the `-ld` types, I think that's the best we can get. 15:41:18 ack dlongley 15:42:20 dlongley: I can make comments about how I think that other group is going to continue to have problems because they're using VC terminology and there is already a stake in the group what VCs mean and that other group is going to continue to confuse people related to prohibiting the use of VCs... but we don't have control over that group or if we can't convince them to do something different. 15:42:58 q+ 15:43:01 dlongley: For the concept of enveloped VCs, maybe we can solve them in a way to do enveloped-vc? Maybe because of the way we express media types and information, maybe we don't need to have additional media types for this case. Those are two other options we can put on the table. 15:43:07 ack manu 15:43:07 manu, you wanted to note that "the semantics of the base subtypes are unrelated" is NOT where consensus landed in the MEDIAMAN group 15:43:21 https://datatracker.ietf.org/doc/html/rfc6838#section-3 15:43:59 manu: I'm taking issue with some of the assertions that are being said. Subtype names do mean things. This section does says that subtype names can be registered to accommodate the ... [missed see link]. 15:44:21 manu: This was revisited during the subtype discussions and many people stepped up to the mic to say that the subtype matters and it should match. 15:44:39 manu: The discussions in that WG have said that they do matter. Item two -- huge strong -1 to vc-ld as the core mechanism. 15:45:04 manu: The problem here is anti-social behavior in another group that has been requested multiple times -- asking them to not do what they are doing. This has been happening for 18 months. 15:46:10 manu: They have been asked multiple times, that group continues to not do it, there have been technical, process, social arguments and that group continues to not do that. I think there is a problem with us making invalid technical arguments, I think that someone rushed forward and used the media type in production and then tell others it can't be changed -- don't do that, people who work on standards don't do that. 15:46:39 manu: I think we need to make decisions based on technical rational decisions based on what's in the specs, if we don't do that, it's a problem -- we can't go against what's said in the RFCs and specs. All that said. I think maybe Dave's enveloping thing might work. 15:46:57 manu: Or we can just do with `application/sd-jwt` and say you don't need the media type on there. But huge -1 to just going forward with what's in the spec right now. 15:47:04 manu: We need to do something better. 15:47:31 brent: Dave has made a suggestion -- Manu says he could live with it, if we changed the media types to `application/enveloped-vc+whatever` -- could you live with that? 15:47:45 brent: From my perspective as chair, that's the closest thing we have for consensus. 15:47:47 Responding to Dave Longley's suggestion that we don't need VC-JOSE-COSE media types, Explicit Typing of JWTs, etc. is a best practice defined at https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing 15:47:59 brent has joined #vcwg 15:48:07 q? 15:48:11 ack selfissued 15:48:12 selfissued: One is long -- responding to Dave Longley's suggestion that we don't need vc-jose-cose media types, it's a best practice to do it. 15:48:19 selfissued: Following best practices we don't have an option to not do that. 15:48:56 selfissued: The whole enveloped thing is superclunky -- and never in plain human language describe things that way, just in the spec. It's an explicit goal for JWTs to be compact and that goes against that engineering design principle. 15:48:57 "best practice" is not a standard in the sense of SDO. it's a *practice* and can be changed. 15:49:14 q+ 15:49:24 ack brent 15:49:28 q+ to say -1 to be compact, JWTs are already huge compared to non-base64-encoded formats 15:49:39 brent: What about `env-vc+jwt`? 15:49:48 q+ to ask about the BCP -- doesn't the attacker control the media type? 15:49:55 +1 brent 15:50:40 ack dlongley 15:50:40 dlongley, you wanted to say -1 to be compact, JWTs are already huge compared to non-base64-encoded formats 15:50:58 We don't talk verbally about "Enveloped Verifiable Credentials". So we shouldn't put that in the names. 15:51:15 dlongley: I think env-vc+jwt would be ok. 15:52:07 dlongley: Saying vc-ld is redundant 15:52:20 selfissued: No, it's not, there are other formats for VCs. 15:52:40 dlongley: No, VC is JSON-LD, that's what this group created and established. 15:53:14 q? 15:53:15 q? 15:53:19 ack manu 15:53:19 manu, you wanted to ask about the BCP -- doesn't the attacker control the media type? 15:53:36 q+ 15:53:40 dlongley: I'm ok with `env-vc+jwt`, I don't think a few extra characters matter since the JWT enveloped VCs are already quite large because they base64-encode everything anyway. 15:54:18 qq+ to be a chair 15:54:38 manu: The attacker generally controls the media type -- and there's a part of that that can be signed over though. But if we're talking about the media type inside, then that is an `application/vc` or an `application/enveloped-vc` -- it's not actually a JWT that is inside, isn't that correct? I'm ok with `env-vc` thing. 15:55:26 manu: I forgot about version 1.1 that does have VC-JWTs, and we use a media type there. That is also something in production in a big way that we may need to pay attention to. I don't think we need to pay attention to it so much that we establish it as the only way things can be done before the media types were decided and they will have to live with changing it to whatever we say here. 15:55:40 manu: But that's another consideration -- and we might want to think about that. 15:56:04 brent: Can we live with `env-vc` `env-vp` for JOSE/COSE. 15:56:13 ack brent 15:56:13 brent, you wanted to react to manu to be a chair 15:56:16 +1 for living with env-vc and env-vp 15:56:17 ack selfissued 15:56:20 The VC-JOSE-COSE media types are used in the "typ" (type) header parameter to describe the type of the entire secured object. This is in the cryptographically secured JWT Header Parameter. It is not subject to control of the attacker. 15:56:22 brent: I believe everyone has nodded to live with it except Mike. 15:56:30 +1 to evn-vc and env-vp 15:56:31 selfissued: No, I think it's not verbally how we talk about it. 15:56:49 zakim, close the queue 15:56:49 ok, brent, the speaker queue is closed 15:57:00 selfissued: The vc-jose-cose types are used in the header parameter to define the entire cryptographic object, it's not subject to control of the attacker. 15:57:01 q+ 15:57:45 brent: I suppose we will try again next week, thanks for scribing, Dave, the meeting is done. 15:58:10 gkellogg has joined #vcwg 15:58:39 rrsagent, draft minutes 15:58:40 I have made the request to generate https://www.w3.org/2024/08/07-vcwg-minutes.html ivan 15:59:09 rrsagent, bye 15:59:09 I see no action items