15:15:05 RRSAgent has joined #vcwg 15:15:10 logging to https://www.w3.org/2023/11/15-vcwg-irc 15:15:11 RRSAgent, make logs Public 15:15:12 please title this meeting ("meeting: ..."), ivan 15:15:23 Meeting: Verifiable Credentials Working Group Telco 15:15:23 Date: 2023-11-15 15:15:23 Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231115T110000/ 15:15:23 chair: brent 15:15:24 ivan has changed the topic to: Meeting Agenda 2023-11-15: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20231115T110000/ 15:57:50 TallTed has joined #vcwg 15:58:23 present+ 16:00:03 present+ tallted 16:00:11 present+ seabass 16:00:57 przemek has joined #vcwg 16:01:06 sebastianelfors has joined #vcwg 16:01:18 pauld_gs1 has joined #vcwg 16:01:20 present+ elfors 16:01:23 present+ 16:01:31 dmitriz has joined #vcwg 16:01:55 present+ nsteele 16:02:05 DavidC has joined #vcwg 16:02:10 present+ 16:02:14 brent has joined #vcwg 16:02:16 present+ orie 16:02:22 present+ dlongley 16:02:26 present+ 16:02:49 present+ Przemek 16:02:54 present+ joe 16:03:48 present+ 16:04:00 present+ dmitriz 16:04:03 Orie has joined #vcwg 16:04:07 present+ 16:04:25 q+ to add to the agenda tiny item on poll results 16:04:26 scribe+ 16:04:59 andres has joined #vcwg 16:05:07 present+ 16:05:27 ack manu 16:05:27 manu, you wanted to add to the agenda tiny item on poll results 16:05:30 brent: We'll start with an introduction to related work that is beginning in the IETF, continue with work items, then finish with issues. We are on track for Candidate Recommendation for the core data model by mid-December. We'll be focusing on meeting that goal. 16:05:45 https://www.opavote.com/en/vote/5254957337935872 16:05:55 manu: We should review the results from the poll. 16:06:07 JoeAndrieu has joined #vcwg 16:06:09 manu: Perhaps people could emote here to add late votes? 16:06:35 Topic: poll results 16:06:41 present+ bigbluehat 16:07:35 what's the URL for the poll? 16:07:41 https://www.opavote.com/en/vote/5254957337935872 16:08:03 manu: The context is that we decided a few weeks ago to run a poll. We wanted to change the name of a certain aspect. It looks like we'll choose to 'Credential Type-specific' processing. 16:08:26 Of these options, "Credential Type" is probably the best, but it ommits the fact that the context can change information regardless of credential type. 16:08:34 q+ 16:08:37 q+ 16:08:37 manu: I have already created a PR. I suggest that we close the poll and I can modify the PR to show the chosen result. 16:08:44 Orie: we should mention immutable or "semantically immutable" contexts better in the section. 16:08:54 q- 16:08:55 ack ivan 16:09:00 ack JoeAndrieu 16:09:07 https://github.com/w3c/vc-data-model/pull/1351 16:09:11 There was also a thread in the W3C CCG on this topic recently... https://lists.w3.org/Archives/Public/public-credentials/2023Nov/0030.html 16:09:18 q+ 16:09:41 present+ will 16:09:45 ack manu 16:09:50 JoeAndrieu: I appreciate the term 'limited' but I don't like the term 'unlimited'. I think that could be a problem. 16:10:00 +1 to get us unstuck 16:10:03 manu: The poll is not a binding vote, so we can still take into account other views. 16:10:24 Will has joined #vcwg 16:10:25 present+ 16:11:13 cabernet has joined #vcwg 16:11:14 is there a link to the poll results (to date)? (having voted, I cannot even see the options any longer) 16:11:15 present+ 16:11:32 I'll add here (so the meeting can move on) that I also don't think the distinction is valid. It isn't a choice between applications that can work with any credential or those with specific credentials. =( 16:11:49 brent: It is OK to have a compromise, but I would like to avoid spending further time on the topic during this meeting. 16:11:52 TallTed, open the poll in incognito to see the options? (but please don't vote again if you've already voted) 16:12:01 is there a matching issue we could use for comments? 16:12:05 JoeAndrieu: i think it is that choice (or very close to it) 16:12:19 Yes, JoeAndrieu there is... finding it for you now... 16:12:24 thanks. I'll comment there 16:12:29 JoeAndrieu, this one: https://github.com/w3c/vc-data-model/issues/1290 16:12:35 Topic: FYI IETF credential work 16:13:21 https://datatracker.ietf.org/doc/html/rfc5755 16:13:40 https://datatracker.ietf.org/wg/privacypass/about/ 16:13:48 Orie: One of the interesting things is the different ways in which people process claims in the context of security. There has been similar work to ours in the IETF, for instance RFC5755, which has similar terminology like 'holder'. 16:14:10 Orie: There is also Privacy Pass, which can be FIPS compliant because it uses RSA. 16:14:30 Orie: JWTs and CWTs were developed in the IETF too. 16:15:27 Orie: I think there's interest within IETF about the architectural aspects of interoperability between these. There has been duplicated effort which sometimes relate in differences, for instance a feature added to CWT and later to JWT 16:15:39 incognito helps (as would, I guess, using a different browser), but doesn't show me what I submitted though it knows I submitted something. OpaVote is helpful, but needs more work :-/ 16:16:15 Orie: There is usually a draft charter that turns a 'birds of a feather' (BoF) into a working group. 16:16:41 Orie: COSE and JOSE have different features for credential use-cases, and some in the IETF would like to create a new credential format specifically to cater for these. 16:17:14 Orie: Originally we had VC-JWT (now VC JOSE-COSE). 16:17:55 Orie: We have RDF and JSON processing capabilities in the Verifiable Credentials specification. There was another third way which only used JSON web tokens. 16:18:32 Orie: JWTs can still be used. It isn't as friendly to the open-world model, and that is controversial, but there is interest in an IETF specification specifically for JWTs. 16:19:39 Orie: There were lots of people who attended the BoF about credentials in the IETF. There were people concerned about violation of civil liberties during the meeting. Others were interested in commercial uses including airline travel. 16:19:50 q+ 16:19:56 ack dlongley 16:20:22 https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md 16:20:38 seabass -- SPICE - Secure Patterns for Internet CrEdentials (SPICE) at IETF 16:20:48 ^ its a draft charter, and the working group did not form, the charter and deliverables will likely need to change 16:20:56 dlongely: I believe that the SPICE charter is the basis for what Orie was talking about. It uses the term 'Verifiable Credentials', and I would suggest avoiding using that specific term to avoid confusion. 16:21:14 q+ to comment on market confusion 16:23:05 dlongely: I believe that the VCWG has been addressing issues that came up in lots of different earlier IETF specifications. We created the three-party model which distinguishes our work. The 'shared registry' improves upon earlier work. We also introduced a data model for claims. 16:23:15 https://datatracker.ietf.org/doc/html/rfc5755#section-4.2.2 (Holder as defined by attribute certifcates in 2010) 16:23:15 s/dlongely/dlongley/ 16:24:23 dlongley: The fact that the VCWG re-used existing RDF functionality is irrelevant. I feel like the SPICE charter describes exactly what we are already doing. 16:24:39 the works is already being repeated in several different ways at IETF, for example privacy pass, oauth, and ace working groups. 16:25:26 I've certainly learned a lot of lessons from this group : ) 16:25:54 or better yet, raise them on the mailing list 16:25:56 q+ 16:26:02 brent: I am sure the authors would appreciate the feedback. 16:26:02 ack Orie 16:26:02 Orie, you wanted to comment on market confusion 16:26:33 Orie: the IETF does its business on their mailing list, so it is expected that your feedback will be addressed if left there. 16:27:15 From the charter: "Short list of lessons learned (from a VCWG work item): Expressive data models, such as RDF, are not necessarily suitable for all use-cases outside W3C", but the charter also says: "The working group will NOT address specific credential use cases" ... another lesson: "Reusing existing semantics that fit the domain well, such as provided by the JWT/CWT Claims registry, provide can improve interoperability, significantly" ... but 16:27:15 the charter says: "Retaining semantic interchangeability is not in-scope" 16:27:21 Orie: We didn't gain enough consensus at the BoF to consider starting a working group until further questions have been answered. 16:27:49 Orie: I think I agree with dlongley that the use of the term Verifiable Credential to refer to anything other than a JSON-LD claim is misleading. 16:28:09 +1 to another word being used in SPICE 16:28:10 Orie: Maybe 'Digital Credential' is a better term to use. 16:29:02 Orie: Privacy Pass takes a different approach to addressing the issues from earlier work. 16:29:04 if there's a core architecture document that can "fit in" and "describe all of these other specific work items in other places", +1, that could be useful. 16:29:27 Orie: I believe it was started after Attribute Certificates became a thing. 16:29:53 Orie: I think it's obvious that work has been continued in the IETF that doesn't use the conventional approaches. 16:30:13 ack manu 16:30:15 Orie: There's a big difference in privacy considerations been OAuth and Privacy Pass. 16:31:05 yes, -1 to yet another competitor in the space 16:31:24 manu: My biggest concern is that during the IETF meeting, I heard lots of people perceive the new charter to be a competitor to the W3C VCWG. This is partly due to aspects in the charter that explicitly noted flaws of the VCWG work. 16:32:15 When we moved the "pure JWT" approach out of VC-JWT, we were explicit that the work would probably be picked up elsewhere 16:32:31 imo we made the right move by dividing things like this. 16:32:34 Orie: that's just a securing mechanism. (that's what I believe this group thought) 16:32:43 manu: It was upsetting that the VCWG knew of this, but did not address it. What I have heard from the community at IETF was different from what was described here. 16:33:08 https://datatracker.ietf.org/group/spice/about/ 16:33:15 This raises a bunch of questions around vc-jose-cose. 16:33:38 brent: We'll move on to GitHub issue discussion. 16:33:45 subtopic: Issue Discussion 16:33:47 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+-label%3A%22pr+exists%22+sort%3Aupdated-asc 16:33:56 manu: I agree, it raises the question of if its worth doing that work at W3C.... and I have been clear before, I am not sure W3C is the right place to do that work. 16:33:58 s/subtopic/topic/ 16:34:49 q+ 16:34:54 brent: The question that we will tackle today is what steps need to be taken to obtain a proposal for each issue before mid-December. 16:35:02 subtopic: https://github.com/w3c/vc-data-model/issues/1247 16:35:09 ack manu 16:35:43 manu: This came from the PING review, and I'll work with Sebastian on it. 16:36:10 subtopic: https://github.com/w3c/vc-data-model/issues/1244 16:36:29 q+ 16:36:36 brent: Who can take this work? 16:36:36 ack manu 16:36:42 q+ 16:36:59 scribe+ 16:37:02 ack seabass 16:37:56 seabass: I think these ones from the PING review seem to be very similar and I think they should be addressed in a cohesive manner. In the security world one often has faux attacks to gauge the security of a system. Privacy can be different, especially because of aggregate data concerns. Having some kind of mock attack would be good for showing correlating data issues, but the fully extent won't be known until production. 16:38:07 seabass: Lots of academic papers about correlating data and we could apply the work here. 16:38:16 scribe- 16:38:22 scribe+ 16:38:36 s/fully extent/full extent/ 16:38:40 subtopic: https://github.com/w3c/vc-data-model/issues/1265 16:38:47 q+ 16:39:04 brent: I don't believe we have consensus on this, so let's discuss it now. 16:39:13 ack ivan 16:39:50 q+ 16:39:56 ivan: I don't believe we'll get to agreement on this issue, so I would suggest marking it 'prepare to close'. 16:40:02 ack dlongley 16:40:04 q+ 16:40:52 q- 16:41:22 q+ to say the JSON-LD works fine 16:41:25 dlongley: There is no way to put a VC that's secured with JOSE into a Verifiable Presentation. 16:42:09 q+ 16:42:13 ack Orie 16:42:13 Orie, you wanted to say the JSON-LD works fine 16:42:20 dlongley: I'm concerned that if we don't have a property for it, implementers will invent new ones. 16:43:09 Orie: When you see nested JSON structures it's easy to seem them as a whole, but the RDF graph is clear that they are separate entities. 16:43:19 q+ to say if what we need is a property to pass a JWT as proof, let's add that 16:43:25 q+ 16:43:26 Orie: If the N-quads don't reflect reality, the solution is to update the JSON-LD context. 16:43:29 ack dmitriz 16:43:56 to be clear, you can.... go ahead and test it. 16:44:39 whether the information is "correct" with respec to RDF data model is a separate question. 16:44:50 Orie: using a URL in `verifiableCredential` will just drop it. 16:45:08 dmitriz: I think it's surprising to many that you can't include JOSE-secured credentials in a Verifiable Presentation. I agree with dlongley that if we don't include our own mechanism, either people will invent new methods or use JOSE version of VCs. We know that the ecosystem is divided between JSON-LD support and JOSE support. 16:45:10 dlongley: not in the security format we use 16:45:14 ack JoeAndrieu 16:45:14 JoeAndrieu, you wanted to say if what we need is a property to pass a JWT as proof, let's add that 16:46:15 q+ 16:46:15 +1 to "property that lets you do that", the more specific the better. 16:46:21 JoeAndrieu: The fact that we can't include JOSE-secured credentials in a VP is an issue. I think we could create a new property for 'external proof' so that there's a semantic link. 16:46:23 ack dlongley 16:47:05 dlongley: I would prefer there to be a specific property for it too, but that didn't get consensus. Therefore 'related resource' was used as a fallback. 16:47:06 q+ to comment on related resource 16:47:27 q+ 16:47:45 You can use related resource to serve a context, that doesn't drop credentials by reference from the graph. 16:48:17 q- 16:48:20 dlongley: If we added a new property, we would need much more effort and more properties to support it. I think we need Related Resource anyway, and if we need a property for JOSE support add that too. 16:48:35 ack ivan 16:48:42 what are the objections to adding 'relatedResource' to a VP? 16:49:15 +1 ivan 16:49:24 "relatedResource" was proposed by Mike Prorock / Orie to express context hashes in VCs 16:49:28 VP can also have custom contexts. 16:49:37 ivan: The Related Resource is very loosely defined at the moment for external data with integrity, and I think it would be a mistake to use that for the specific purpose of supporting JOSE-secured VCs in VPs. 16:49:47 its different thing to secure context, or include credentials by reference. 16:49:53 +1 to well-defined property for the use case we're trying to solve... relatedResource doesn't sound like it? 16:50:21 @manu - we still need relatedResources to hash-secure @contexts on the VP 16:50:34 "relatedResource" was good enought for context hash information in VCs, why not in VPs? ... if we want yet another property for JOSE-secured/other-envelope/external-secured VCs, that's good too. 16:50:46 ivan: I would support a specific new structure for JOSE support. I recall that Joe had strong opposition to Related Resource/ 16:50:48 ack dmitriz 16:50:55 dmitriz, who is doing that right now? What implementer is shipping that feature? 16:51:13 including properties that are specific to a securing format, is a layer violation imo 16:51:30 q+ 16:51:38 VC-JOSE-COSE could add context hashes to its format 16:51:42 Orie^ 16:51:43 dmitriz: First question we have is what to do with JOSE-secured credentials. The second question though is what to do with SRI digests. 16:51:59 ack manu 16:52:03 dmitriz: What are the objections to adding the property to the VP. 16:52:16 I did specifically highlight that it IS two separate issues 16:52:22 +1 to dmitri 16:52:24 q+ to say securing contexts doesn't need arbitrary related resources 16:52:37 dlongley: security best practices seems to imply securing bytes, when they are JSON-LD bytes representing a conforming document, thats all that is needed, imo. 16:52:55 Orie: non-three-party model best securing practices do that. 16:52:55 +1 manu 16:53:01 +1 manu 16:53:08 manu: I believe that the two use-cases can be described as 1: support for JOSE-secured VCs in VPs, and 2: to support secured contexts. 16:53:16 q? 16:53:26 ack JoeAndrieu 16:53:26 JoeAndrieu, you wanted to say securing contexts doesn't need arbitrary related resources 16:53:27 manu: If we can use the same property for both, that would be great. 16:54:13 JoeAndrieu: I agree with what manu said. I don't believe we need an arbitrary integrity facility, and that could open up vulnerabilities with unknown binary content. 16:54:41 brent: I'll close the Related Resource issue so two new issues can replace it. 16:55:17 subtopic: https://github.com/w3c/vc-data-model/issues/1319 16:55:17 q+ 16:55:21 ack manu 16:55:22 @JoeAndrieu - what vulnerabilities are you referring to? digest hashing /anything/ is safe 16:55:36 manu: I was able to review Ivan's changes; thank you Ivan. 16:56:15 brent: I expect that the results of the conversation will lead to a pull request with changes. 16:56:40 @dmitriz yes, but you are trusting the untrustable. This isn't about trusting an issuer, it's trusting the holder. 16:56:57 rrsagent, draft minutes 16:56:59 I have made the request to generate https://www.w3.org/2023/11/15-vcwg-minutes.html ivan 16:57:27 +1 to what JoeAndrieu said above -- that's the problem w/ relatedResource in presentations. 16:57:36 (well, one of them) :) 16:57:41 rrsagent, draft minutes 16:58:12 I have made the request to generate https://www.w3.org/2023/11/15-vcwg-minutes.html manu 16:58:19 rrsagent, draft minutes 16:58:20 I have made the request to generate https://www.w3.org/2023/11/15-vcwg-minutes.html ivan 16:58:47 gkellogg has joined #vcwg 16:58:52 rrsagent, bye 16:58:52 I see no action items