14:43:43 RRSAgent has joined #vcwg 14:43:48 logging to https://www.w3.org/2024/05/01-vcwg-irc 14:43:48 RRSAgent, make logs Public 14:43:49 please title this meeting ("meeting: ..."), ivan 14:43:54 Meeting: Verifiable Credentials Working Group Telco 14:43:59 chair: brent 14:44:07 Date: 2024-05-01 14:44:27 Agenda: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240501T110000/ 14:44:47 ivan has changed the topic to: Meeting Agenda 2024-05-01: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240501T110000/ 14:59:22 bigbluehat has joined #vcwg 14:59:54 present+ 15:00:03 present+ bigbluehat, selfissued 15:00:05 brent has joined #vcwg 15:00:20 present+ brent 15:00:48 hsano has joined #vcwg 15:00:52 present+ davidc 15:01:25 present+ hsano, dmitriz 15:01:41 present+ 15:02:11 present+ 15:02:50 present+ mahmoud 15:03:14 scribe+ 15:03:30 present+ jennie 15:03:36 JennieM has joined #vcwg 15:03:52 present+ pl_asu 15:03:57 brent: Agenda today is we're going to look at work item status updates and do issue processing, etc. 15:04:01 brent: Anything additional for the agenda? 15:04:13 selfissued: We should talk about the controller document work. 15:04:22 brent: Yes, we should, we can cover that during status updates. 15:04:29 brent: We can make that the first topic of the day. 15:04:35 Topic: Controller Document 15:04:36 DavidC has joined #vcwg 15:04:42 present+ will 15:04:45 present+ 15:04:51 Phil_Te has joined #vcwg 15:05:04 present+ 15:05:04 brent: Quick intro. There are references to controller documents that, if I remember correctly, were originally references to DID documents. Folks in the group realized that a more general notion was needed for what we were looking for. 15:05:16 JoeAndrieu has joined #vcwg 15:05:22 present+ pauld 15:05:31 present+ dlehn 15:05:36 brent: Those words about controller documents were written up separately in VC-JOSE-COSE and VC-DI, with the intention that at some point we could take out those portions from each spec and put them in a single unified controller document specification. 15:05:40 present+ JoeAndrieu 15:05:59 q+ 15:06:03 brent: Last we spoke about it, consensus was that was a fine idea and Manu and Mike agreed to be editors on that document. The question now is: do we still need to do that as a group? We can have a brief conversation about it today. 15:06:11 brent: Let us know your thoughts on this. 15:06:11 ack ivan 15:06:17 pauld_gs1 has joined #vcwg 15:06:30 decentralgabe has joined #vcwg 15:06:34 present+ 15:06:36 ivan: Is this document ... was this document meant as a REC track doc or something else? 15:06:40 brent: Yes, a REC track document. 15:06:42 ivan: Ok. 15:07:01 mkhraisha has joined #vcwg 15:07:40 selfissued has joined #vcwg 15:07:44 q+ 15:07:51 present+ 15:07:52 ack selfissued 15:08:37 selfissued: So I think, to the extent that our securing specs are using the controller document terminology, it would be better if it was in one place, which is why Manu and I volunteered to do this. As part of the background, the DID controller document notion only supports DIDs, whereas the more general controller document syntax used by this WG also supports Web URLs. 15:08:47 selfissued: Which is why we have our own notion of controller document that is more general in the first place. 15:08:48 aniltj has joined #vcwg 15:09:05 present+ aniltj 15:09:19 selfissued: That said, while Brent's characterization is accurate, I'll also note that it's expected that the different securing specs will profile the general controller document exposition saying which parts we want you to use and which parts we don't want you to use. 15:09:28 brent: Thanks, Mike, that's helpful. 15:09:35 present+ steele 15:10:12 brent: Since VC-JOSE-COSE and VC-DI are both in CR right now, and these changes would officially be normative changes to those documents now and we would be shifting language around, it would be very important that the controller document be roughly settled relatively soon before those documents go into a second candidate recommendation phase. 15:10:19 q+ 15:10:20 brent: Timing wise, the sooner it can come together the better. 15:10:34 brent: I'm not hearing anyone on the call opposed to those proceeding with drafting a controller document. 15:10:38 q+ 15:10:42 brent: As far as I'm concerned, I think we should proceed. 15:10:42 ack selfissued 15:11:03 q+ to point to https://w3c.github.io/vc-controller-document/ 15:11:28 selfissued: I agree. Timing wise, we had agreed some months ago, that once the two docs were in CR stage then would be the time to do this. Manu did check something into a repository which was a copy of the controller document section from the DI spec at that time, I believe. So the onus is on me to create PRs against that to do what may be necessary to make it general purpose. 15:11:36 selfissued: Unless anyone else tells me not to, I'm going to do that. 15:11:37 ack ivan 15:12:22 ivan: There is one thing that we should check -- I don't remember the details off the top of my head -- there are some non-compressible times in the process in terms of how long something should stay a CR but also a WG, etc. I'm a little bit worried that time wise, this will clash with our plans on the current REC track doc at publication but we can check that soon. 15:12:27 brent: Yes, you and I can look at that. 15:12:55 ivan: Let's try to do that on Friday, because the dependency is very strong, and we cannot publish VC-JOSE-COSE and the other documents at Recommendations only if this one is a Recommendation, so we can publish together but not any other way. 15:13:35 brent: So what Ivan and I will be calculating is the go/no-go, or absolute last date that we can publish the controller document if we're going to make those equivalent modifications to the securing specs. If the controller document doesn't get done on that schedule we'll have to revert and just wish it a good day. 15:13:42 https://github.com/w3c/vc-controller-document/ 15:13:43 ack JoeAndrieu 15:13:43 JoeAndrieu, you wanted to point to https://w3c.github.io/vc-controller-document/ 15:14:07 JoeAndrieu: The repo that has Manu's draft, it looks pretty good. I think we're in a place where we're wordsmithing, but to Mike's point, let's dive in and do that work. 15:14:09 brent: Any other comments? 15:14:16 Topic: Work Item Status Updates/PRs 15:14:19 selfissued: Thanks all. 15:14:45 brent: I'll pause for a moment if there are any updates from work item editors or PRs they want to look at, please jump on the queue otherwise, there are a couple in the data model to look at. 15:15:04 subtopic: https://github.com/w3c/vc-data-model/pull/1478 15:16:04 brent: The group had a conversation about media types and the difficulty in trying to register the media types we were hoping to register which were `application/vc+ld+json` -- the attempt to register multiple suffixes in the DID WG the registration was denied, since then a lot more work has gone into defining what multiple suffixes mean and conversation with mediaman, the group working on those things at IETF and at IANA. 15:16:11 brent: We still don't have a clear direction from IETF on what we should do. 15:16:27 q+ 15:16:35 brent: The last time we discussed, we said, let's just proceed with `application/vc` and `application/vp` and then we can add the multiple suffixes stuff later once it gets sorted out. 15:17:02 brent: Mike suggested that perhaps we don't abandon our hopes and put forth both options to IANA instead and see what they say. 15:17:06 ack selfissued 15:17:27 selfissued: The essence of what I had written in the comments is that I'd rather us not proceed based on informed speculation, but to try to call the question, with IANA. 15:17:32 selfissued: To try and register what's in our documents now. 15:18:16 selfissued: I volunteered to do so with the motivation that -- or explanation to the designated experts and that while discussions are ongoing, we have timelines to publish REC track docs. 15:18:40 selfissued: And we'll encourage that they proceed with the registrations, and we'll get a "yes" or "no" and they only have two weeks to decide so it doesn't impinge on our timelines. 15:18:41 very sensible proposal 15:19:04 brent: Any objections to that approach -- any feedback on that? 15:19:10 +1 that sounds like a viable approach. I don't see a downside 15:19:11 +1 to proposal 15:19:15 +1 15:19:17 q+ to suggest "We want to register one of these, which one will you allow right now?" 15:19:45 selfissued: The group decided to proceed with whats in our spec, and I'm looking to proceed to make what's in our spec a reality. 15:19:56 q+ to ask about attempting registration of variations: `application/vc`, `application/vc+ld+json`, `application/vc+ld+json+jwt`, `application/vc-jwt` 15:20:00 scribe+ 15:20:07 ack dlongley 15:20:07 dlongley, you wanted to suggest "We want to register one of these, which one will you allow right now?" 15:20:36 q+ 15:20:49 dlongley: my comment would be that agree that doing this would be what the group decided earlier--pre-Brisbane--but I'm concerned we're headed into opposition knowingly 15:21:04 q+ 15:21:08 ... but I'd prefer we attempt both variations, to see which they prefer 15:21:16 ack bigbluehat 15:21:16 bigbluehat, you wanted to ask about attempting registration of variations: `application/vc`, `application/vc+ld+json`, `application/vc+ld+json+jwt`, `application/vc-jwt` 15:21:42 bigbluehat: Yeah, I think what I was proposing is probably very similar to what Dave said -- I think we want to attempt multiple variations at once. 15:22:03 bigbluehat: The idea of putting these singular things up vs. multiple suffixes at the same time, it would give them a way to pick a lane. 15:22:34 bigbluehat: And I think that not doing both approachs at wouldn't give us enough information nor wrestle them in public -- we don't want to do things one at a time, we won't get new information, getting compare/contrast would be more helpful. 15:22:37 ack selfissued 15:23:16 selfissued: Yeah, I was in Brisbane, my characterization of what happened in Brisbane, there was a lot of talk about a lot of parties on what we could do. Decision making hats weren't on, but more like talking about multiple possibilities. It even digressed into maybe single suffixes was a bad idea. 15:23:43 selfissued: That ship sailed most of a decade ago. This is one of the dysfunctions that can happen in a WG, discuss mode and not decision mode. That was in broad evidence in Brisbane. 15:24:18 selfissued: I think suggesting multiple things at once is bad tactics. If we give them the easy option and the one we decided on, they will pick the easy one, we will never find out what they think. 15:24:24 selfissued: It's not a discussion just a request to register. 15:24:34 +1 to selfissued 15:24:40 selfissued: They either will or will not. If we frame it as endless discussion, then we won't get the data we need, so I won't do that. 15:25:02 brent: This was attempted and failed three years ago for the DID WG. A lot has changed since then, so we'll see what happens. 15:25:06 ack TallTed 15:25:39 TallTed: Approximately what Mike said. If we ask for the thing that looks the most like the thing that looks most like what has been registered most recently, we won't get what we really want. If we ask for what we really want, we might get it or we might not. 15:26:06 TallTed: I really dislike the idea of repeating the exercise of three years ago with little difference. I don't think any of the decision maker decisions have changed. No different decision makers. I don't have high hopes of approval. 15:26:22 TallTed: I think given everything in the picture, I think asking for what we really want, is the way to go, then we can use the fallback. 15:26:22 q+ 15:26:52 ack ivan 15:26:55 brent: The course of action we will take is to register `application/vc+ld+json` and `application/vp+ld+json` as written in the spec today and we'll see what happens. 15:27:08 ivan: Just a question -- Mike, what about the media types that are in the VC-JOSE-COSE documents? 15:27:13 selfissued: Yes, we'll do those too. 15:27:31 selfissued: It is a liaison request from W3C to IETF for what we've defined. 15:27:33 q+ to express concern about getting in as a bad example 15:27:44 brent: So it will be all of the media types that we have in all of our specs that we would attempt to register. 15:27:48 ack bigbluehat 15:27:48 bigbluehat, you wanted to express concern about getting in as a bad example 15:28:32 q+ 15:28:38 bigbluehat: I wasn't at the IETF meeting, but I rewatched it. There was a lot of microphone time spent talking about letting multiple suffix stuff in so it can be weeded out as a bad idea. I'm concerned that would be an outcome -- and then our spec would be pointed at as a bad example. 15:28:46 ack selfissued 15:29:21 selfissued: Maybe I'm a little too hard-nosed. But I'm not worried about the optics, it's apparently to me that different people in the mediaman group have different views and people who think it's a good idea won't change and neither will those who think it's a bad idea. 15:29:23 +1 to what Mike just said 15:29:27 selfissued: I think the outcome is inevitable either way. 15:29:44 brent: If we have multiple suffixes and we succeed -- then multiple suffixes only ever means what we want it to mean. 15:29:52 +1 to applying to see if our concerns are real, rather than not applying out of concern 15:29:54 brent: I haven't heard anybody say: Don't do this. 15:30:04 Wanted to close the loop that I checked internally with the implementation teams that are working with us on using JOSE for securing our trade focused VCDM credentials, and they noted that they will be contributing to the relevant portions of the test suite for "W3C Securing Verifiable Credentials using JOSE and COSE" 15:30:26 subtopic: https://github.com/w3c/vc-data-model/pull/1464 15:30:47 brent: This is Manu's healthy response to a very thorough review from Google's AC rep, Jeffrey Yaskin. 15:30:56 dmitriz has joined #vcwg 15:31:37 brent: The impetus for the review is that we wanted Google to say all the things they wanted fixed to avoid any formal objections from them. That was the gist of the request -- and he provided an acceptable thorough review, the normative changes have already been made, and this is the editorial requests. 15:32:09 brent: This is someone who is very versed in Web specs in general and the Web in particular, but not so versed in VCs and he requested clarifications where he thought clarifications would result in a better spec. 15:32:18 brent: Some other changes are in a PR from David Chadwick. 15:32:26 brent: This PR is quite long and has some requests for changes and some approvals. 15:32:31 brent: Timeboxing this one to 7 minutes. 15:32:41 brent: Please jump on the queue to talk about 1464. 15:33:17 q+ 15:33:24 ack TallTed 15:33:30 TallTed: I believe all of my stuff is editorial. 15:33:40 brent: Mike you were perhaps saying "don't do this at all"? 15:34:04 q+ 15:34:04 selfissued: I am ok with the vast majority of this. I'm requesting that the text elevates multihash into normative usage be struck because that's not appropriate in an editorial PR. 15:34:21 selfissued: Manu's tried to say it's already in the context so it doesn't matter. The specification defines what people normatively do, not the context. 15:34:44 q+ to say that the multihash things already have consensus to be there and the goal was for implementers to work with both or either 15:34:53 q+ 15:35:39 brent: The one issue I'm running into -- with the additional commits and changes ... trying to find the comments. Down in line 3155, if folks want to read along. That's a conversation we want to have. 15:35:42 ack decentralgabe 15:36:01 q+ 15:36:09 q+ to note that multihash doesn't exist in the doc; maybe digestMultibase is what Mike's objecting to? 15:36:15 decentralgabe: I believe it would be more neutral to say that you can use a digest property defined by the securing mechanisms. `digestSRI` isn't defined by either of our securing mechanisms. 15:37:05 decentralgabe: Manu's suggestion was to move it into VC-JOSE-COSE, but I think on further reflection we shouldn't move it, I think it's in another spec already and neutral. I think a possible way forward is to say you can use either `digestSRI` or a method from another securing spec without saying which spec. 15:37:14 ack dlongley 15:37:14 dlongley, you wanted to say that the multihash things already have consensus to be there and the goal was for implementers to work with both or either 15:37:34 dlongley: my memory of consensus was that implementers could use either, and we'd see how that goes 15:38:10 ... in terms of how digestSRI being in a different spec, that's not quite right...there's lots of work in our spec to shape it as a property and value for VCs. 15:38:16 qq+ 15:38:26 ... this PR seems to aim at the previous consensus 15:38:57 brent: the digestMultibase in the Data Model does not point to an unspecified thing, but to something we have published 15:39:13 brent: Before going back to the queue -- the `digestMultibase` as referenced, does not point to an unpublished spec somewhere at IETF, it points to the DI spec that our group has published as CR that defines the particular things it is concerned with. In my understanding, there is no normative pointing to something that isn't a spec, except that we're pointing at the DI spec which is underway in becoming a spec. 15:39:13 ... so there is no normative pointing to something that cannot be normatively pointed to 15:39:18 ack ivan 15:39:18 ivan, you wanted to react to dlongley 15:39:29 dlongley: +1 to brent 15:39:32 q+ to say we have to define that 15:39:39 q+ to say that's our vocab 15:39:41 ack TallTed 15:39:41 TallTed, you wanted to note that multihash doesn't exist in the doc; maybe digestMultibase is what Mike's objecting to? 15:40:01 TallTed: Mike, you are objecting to a thing called multihash which isn't in this document. 15:40:05 selfissued: `digestMultibase` sorry. 15:40:17 TallTed: That appears to not be as significant a change as you're making it be. 15:40:21 TallTed: My eyes are different than yours. 15:40:26 ack selfissued 15:41:12 selfissued: Gabe, thank you, you are correct, I have no objection to `digestSRI` because that's in a W3C REC that defines or largely defines what we would need. Largely for the record, my objections to the whole multihash family is that they fail to make a choice. 15:41:17 selfissued: That's my primary objection to using that at all. 15:42:00 I think 'multihash family' may be somewhat confusing. I think Mike's main objection is to multiBASE. 15:42:01 selfissued: With respect to using that at all, with respect to DI standardizing `digestMultibase`, that's fine, but we went through an exercise six months ago or so of making sure that the data model didn't have any normative dependencies on either security spec -- it has informative references. 15:42:36 selfissued: Part of the reasons for doing the controller document work -- an alternative was expressed that maybe we can just reference the controller document section from the data model and call it good. Orie and I and others felt like that was turning things on their heads and the data model should stand on its own. 15:42:44 selfissued: I don't want to change it to have dependencies on either securing spec. 15:42:51 ack dlongley 15:42:53 dlongley, you wanted to say we have to define that and to say that's our vocab 15:43:34 dlongley: just a clarification, there are pieces of the SRI spec did have to be added to our vocabulary earlier 15:44:00 ... I did not mean to imply that it was yet to be done, but to point out that we could not simply point to someone else's specification 15:44:03 q+ 15:44:06 +1 Brent 15:44:12 brent: Since the changes to section 5.3 of related resources is the piece under contention, and I will reach out to Manu here too, the suggestion is that the changes to this section be removed from this PR and made a separate PR that can be further discussed so it doesn't hold up all of the other myriad changes that do not have opposition. 15:44:13 ack ivan 15:44:50 brent: Mike, would that alleviate your concerns with the PR? 15:44:57 selfissued: Absolutely, once that text is gone, I'll approve. 15:45:08 brent: I'll let Manu know we can put those changes in a separate PR. 15:45:16 brent: Any other comments on this PR before we move on? 15:45:47 brent: I think we covered the main big things we wanted to talk about and maybe we can move to issue processing now. 15:46:12 Topic: Issue Processing 15:46:14 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc 15:46:45 brent: A number of these are that we know have to happen, others we will look at now. 15:46:48 subtopic: https://github.com/w3c/vc-data-model/issues/1457 15:47:00 s/are that we know/are those we know/ 15:47:11 brent: David Lehn, can you talk to us about this issue? 15:47:42 q+ 15:48:16 brent: There are some cryptosuites that are being referred to specifically -- which should be updated. 15:48:22 q- 15:48:36 dlehn: This is related to the respec vc plugin, I haven't had time to work on it -- and I know Benjamin was making some changes to it and we had movement on it. 15:48:54 dlehn: There were some general ideas where we wanted to improve the generation of the output and improve auto-generation. 15:49:09 dlehn: I just need to reprioritize things and get it done quickly, it's not a lot of work, I just need to spend some time on it. 15:49:17 brent: Would it be possible by next week for you to let us know when you can get it done? 15:49:22 dlehn: Yes, excellent. 15:49:31 dlehn: I'll probably just be doing it by then. 15:49:36 brent: Ok, thank you for that feedback. 15:49:41 subtopic: https://github.com/w3c/vc-data-model/issues/1475 15:50:16 brent: Ted, could you jump on the queue and walk us through this -- and to the group, who would be willing to be assigned to make it happen? 15:50:18 q+ 15:50:23 ack TallTed 15:51:07 TallTed: One item here is a quick search and replace PR, another is rephrasing a sentence, the third is rationalizing some competing definition of things. Ecosystem and terminology do the same thing partly -- but with different definitions. 15:51:16 TallTed: That one I hadn't resolved at all. That's not in the comment from Manu either. 15:51:32 brent: Is this something you could begin to address in a PR? 15:51:40 TallTed: I don't think it needs discussion, just heads down. 15:51:43 brent: Can I assign you? 15:51:45 TallTed: Sure. 15:52:06 subtopic: https://github.com/w3c/vc-data-model/issues/1479 15:52:27 brent: This was raised a couple of weeks ago -- consider explicitly allowing / recommending language maps. 15:52:48 brent: This was read by someone outside the group who wanted more clarity on the i18n text -- they are making a concrete request for more text. 15:53:02 q+ 15:53:13 brent: We did ask for specific language that they'd perhaps find acceptable -- would like to hear from folks on this in the group. 15:53:16 ack aniltj 15:54:01 aniltj: The ability to do language translations automatically for the credentials and attestations that we have would be good. I saw the feedback from Manu on the issue. Just a clarification question -- it sounds like basically having JSON-LD compact form, you have the ability to do that. Does anything in the current spec prevent the use of language maps in anyway shape or form? 15:54:06 aniltj: For people who want to use that for translation? 15:54:15 q+ 15:54:15 q+ 15:54:21 ack ivan 15:54:47 ivan: I think the problem is that there a section -- I don't know from the top of my head -- that shows how a pure JSON processor can handle JSON-LD credentials and that is not describing anything about language maps the way they are done in JSON-LD. 15:54:50 q- 15:55:23 q+ 15:55:40 aniltj: Understand Ivan's point -- I'm glad the flexibility exists that allows someone who wants to use a JSON-LD API to get functionality that is unique to JSON-LD and obviously in a context-specific processing love the flexibility to avoid doing that using static contexts and JSON schemas. 15:56:19 aniltj: The question I would ask is -- if you wanted to use the features that are unique to JSON-LD, you would need to use a JSON processing capability. Great. If you choose to go down that path, does anything prevent you from doing that -- with the full understanding that you're going to be treating the credentials that way, you won't have access to that functionality? 15:56:19 q+ 15:56:30 q+ 15:56:40 brent: Nothing in the spec prevents you from using JSON-LD to use its full capabilities to my knowledge. 15:56:41 ack bigbluehat 15:56:47 would just more examples (of multi-language VCs) help? 15:56:49 q+ 15:57:12 ack dlongley 15:57:44 q+ 15:57:59 q- 15:58:03 This isn't about JSON-LD processing being required. The spec simply says "shape the JSON like JSON-LD does." 15:58:04 Isn't the issue here simply that there isn't a comparable set of paragraphs that describe using JSON-LD specific language processing? Implication is that it would be good to have both explanations. 15:58:05 ack ivan 15:58:08 ack decentralgabe 15:58:15 Thank you. that is very helpful dlongley 15:58:32 ack dmitriz 15:58:38 decentralgabe: It seems there is a JSON-LD language map solution -- is there another one if they don't want to use it? 15:58:42 brent: Thanks Gabe. 15:59:24 dmitriz: Reading this issue from Anthony, he does a lot of advising to the EU commission on the learning data model, etc. lots of skin in the game. The way he phrases the issue is that he would like it to clarify whether only the subset of i18n is supported or if multiple methods are supported. 15:59:53 dmitriz: JSON-LD has several methods, we support and recommend a subset, so I am reading the issue as "our subset vs. all options". 16:00:21 brent: Perhaps this issue could be resolved with a sentence that says "Additional JSON-LD capabilities could be utilitized -- but if the recipient doesn't do JSON-LD processing they may not be received". 16:00:36 dlongley: It's not a JSON-LD processing issue but a type-specific VC one. 16:00:50 brent: We'll get back on timing issues for the controller docs, thanks all! 16:00:54 brent: Thanks for scribing, Dave. 16:00:56 rrsagent, draft minutes 16:00:58 I have made the request to generate https://www.w3.org/2024/05/01-vcwg-minutes.html ivan 16:01:05 dlongley: Sure! 16:02:10 rrsagent, bye 16:02:10 I see no action items