14:21:50 RRSAgent has joined #vcwg 14:21:55 logging to https://www.w3.org/2024/07/10-vcwg-irc 14:21:56 RRSAgent, make logs Public 14:21:57 please title this meeting ("meeting: ..."), ivan 14:22:24 Meeting: Verifiable Credentials Working Group Telco 14:22:24 Date: 2024-07-10 14:22:24 Agenda: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240710T110000/ 14:22:24 chair: brent 14:22:25 ivan has changed the topic to: Meeting Agenda 2024-07-10: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240710T110000/ 14:57:36 present+ 14:58:02 brent has joined #vcwg 14:58:15 hsano has joined #vcwg 14:59:21 present+ 15:00:54 KevinDean has joined #vcwg 15:01:35 JoeAndrieu has joined #vcwg 15:01:37 DavidC has joined #vcwg 15:01:47 present+ KevinDean, hsano, davidc, will 15:02:20 Wip has joined #vcwg 15:02:26 present+ 15:02:34 present+ 15:02:39 bigbluehat has joined #vcwg 15:02:55 present+ bigbluehat, dmitriz 15:02:59 scribe: Wip 15:03:06 present+ joe 15:03:18 present+ 15:03:29 GregB has joined #VCWG 15:03:41 present+ gregb 15:03:43 present+ 15:03:46 present+ 15:03:51 q+ 15:03:56 brent: agenda possible convo with ebsi, converstion about media types and conversation about data integrity 15:04:00 ack bigbluehat 15:04:10 present+ dlongley 15:04:20 bigbluehat: Test suites nearing ready integration points. Hope to have test suite office hours next week 15:04:27 ... hope to get lots of people involved 15:04:28 q+ 15:04:37 ack GregB 15:04:52 GregB: update on BBS, base spec has been updated and released 15:04:58 ... awaiting cryptographic review 15:05:16 ... slight change in the ordering of things to do with the hash. Is a breaking change to the sigs 15:05:48 decentralgabe has joined #vcwg 15:05:51 present+ 15:05:54 manu: No word from ebsi 15:06:00 present+ decentralgabe 15:06:04 Topic: Media types for vc-jose-cose 15:06:13 present+ manu 15:06:34 subtopic: https://github.com/w3c/vc-jose-cose/issues/282 15:06:50 present+ smccown 15:06:51 brent: good news, vc data model has media types registered! 15:07:25 ... need to reconcile media types in vc jose cose with these media types in iana 15:07:36 q+ 15:07:50 ... do we need to do something about this 15:07:52 ack manu 15:07:58 mccown has joined #vcwg 15:08:20 manu: Strange for WG to register a different media type for jose cose. We should use the base media types 15:08:29 BBS signature scheme update: https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-06.html 15:08:56 ... expect application/vc+jwt and vc+sdjwt vc+cose 15:09:11 Blind BBS signatures update: https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-01.html# 15:09:11 JennieM has joined #vcwg 15:09:26 ... Request to avoid vc+sd-jwt 15:09:35 present+ 15:09:41 ... This is being used elsewhere 15:09:43 q+ 15:10:13 BBS Per Verifier Id (Pseudonyms) update: https://www.ietf.org/archive/id/draft-vasilis-bbs-per-verifier-linkability-01.html 15:10:22 ... it is confusing to hear the work verifiable credential in a spec if unsure if it is a W3C or IETF VC 15:10:30 +1 to everything Manu said, other groups shouldn't add confusion to VCs and we should register `application/vc+sd-jwt` and `application/vc+jwt` here 15:10:52 brent: use application/vc and /vp as the base media types. Extend as usual with +jwt +cose etc 15:10:54 https://github.com/w3c/vc-jose-cose/pull/283 15:10:55 ack decentralgabe 15:10:59 decentralgabe: I agree 15:11:05 ... Raise a PR to address this 15:11:17 brent: Thanks! 15:11:23 s|Request to avoid vc+sd-jwt|Requested to avoid application /vc+sd-jwt| 15:11:41 q+ 15:11:47 s| application /vc| application/vc| 15:11:48 PL-ASU has joined #vcwg 15:11:53 present+ 15:11:55 https://github.com/w3c/vc-jose-cose/pull/283 15:12:22 ivan: gabe, check the two diagrams in the VCDM for jwt and let me know what needs changing 15:12:26 q+ 15:12:29 ... there are media types there that need adapting 15:12:32 ack ivan 15:12:32 RRSAgent, draft minutes 15:12:34 I have made the request to generate https://www.w3.org/2024/07/10-vcwg-minutes.html TallTed 15:12:41 rrsagent, make logs public 15:12:42 ack manu 15:12:45 manu: supportive of the PR 15:13:25 ... searching for +cose and +cwt suffix in the registry and not seeing anything, we would be the first ones to register 15:13:33 ... sounds like +cose is the right thing to do 15:13:33 https://datatracker.ietf.org/doc/html/rfc9052#name-iana-considerations 15:13:44 ... wondering why we would be the first to register a media type with +cose 15:13:51 q+ 15:14:02 decentralgabe: believe +cose is registered in above link 15:14:06 q- 15:14:13 brent: cose is registered, but nothing with a +cose registered 15:14:14 yes, what Brent said... that's what's confusing to me. 15:14:32 brent: hearing no opposition to proposed change 15:14:43 ... please indicate approval on the PR 15:14:59 aniltj has joined #vcwg 15:15:13 present+ aniltj 15:15:13 ... moving into data integrity conversation 15:15:14 Topic: Data Integrity 15:15:25 subtopic: https://github.com/w3c/vc-data-integrity/issues/272#issuecomment-2212258255 15:15:49 brent: concerns about security implications of data integrity signatures 15:16:01 ... extensive conversation on the issue 15:16:29 decentralgabe -- RFC 9052 registered media type application/cose. It did not register structured suffix +cose. 15:16:53 yet, +cose is in the structured suffix registry :) ^ 15:17:24 ... Original poster of issue as signaled acceptance of the proposal to address the issue 15:17:30 +1 for Gabe to walk us through it 15:17:36 ... pending a P.R to address the issue 15:17:49 q+ 15:17:53 ... gabe could you walk us though the proposal 15:17:54 ack decentralgabe 15:18:11 decentralgabe: spent a long time trying to understand this issue 15:18:40 ... First proposal is adjustment to @vocab. This seems uncontroversial. P.R already open 15:19:08 present+ dlehn1 15:19:12 ... Second thing is we need some text about @context validation, we need to be very clear about how to handle untrusted contexts 15:19:40 ... There is some discussion around a proposal to add signatures to context to make them tamper evident 15:19:56 q+ 15:20:17 q+ to ask a dumb question 15:20:33 present+ 15:20:34 +1 to changes to `@vocab`, +1 to some clarifying text around validation requirements, +1 to some tests if we can make them make sense -- validation is application-level and maybe really for a "best practices doc" but fine if we can make it work 15:20:43 ack manu 15:20:47 -1 to locking contexts for all the reasons listed in the issue already 15:20:48 ... The outcome of ths proposal would be 2 or 3 issues to address these points and associated PRs 15:21:01 q+ to ask about context integrity 15:21:06 decentralgabe: Agree that 0,1,3,4 parts of the proposal are good ideas 15:21:15 +1 to Manu 15:21:39 s/decentralgabe/manu/ 15:21:57 ... 0 is easy, 1 will take some work 15:22:08 ... need to be careful not to pass into application space 15:22:09 +1 to 0,1,3,4 ... Have a question regarding 2. Will put myself on the queue to ask 15:22:11 +1 to Manu, important not to go into the application layer 15:22:15 ... will come back to 2, that one is controversial 15:22:17 q+ to ask about option 2 15:22:29 ... 3 is a variation of 1 should be fin 15:22:59 ... For test suites, we can improve them to check this. Need to tell implementers to check for bad contexts. 15:23:16 +1 that we're telling implementers to essentially create a special application-level rule, but it could work 15:23:16 ... Telling issuers and verifiers to implement bussines logic to pass the test suites 15:23:24 ... +1 to almost all of the things 15:23:39 ... we should not mix context integrity with signatures 15:23:47 ... it limist some usecases the people are relying on 15:23:55 ... Forces disclosure of all of the contexts 15:24:18 ... Forced to leak data if mix cryptographic hash with the context 15:24:28 +1 to not locking contexts for all those reasons and because it doesn't fix the problem :) 15:24:46 ... There are other ways to prevent this attack, would be a strong -1 for mandated context integrity protection 15:24:46 q+ 15:24:49 ack brent 15:24:49 brent, you wanted to ask a dumb question 15:25:18 brent: For number 2, the integrity of contexts. Is it sufficient to recommend people to use the related resource property 15:25:30 q+ 15:25:42 ... use related resource for context integrity for people who want it 15:25:46 ack JoeAndrieu 15:25:46 JoeAndrieu, you wanted to ask about context integrity 15:25:48 q+ 15:26:13 JoeAndrieu: When talking about context integrity, we are talking about some hash. Not that the context is signed over 15:26:18 q+ 15:26:33 for 2 I intended to mean a signature, for 1 I mean a hash 15:26:57 manu: I think they are the same. We aren't talking about signing over the property and the value. We are talking about including the hash of every context in the @context property 15:27:12 JoeAndrieu: We do not currently sign over the @context property 15:27:21 ack aniltj 15:27:21 aniltj, you wanted to ask about option 2 15:27:46 aniltj: Is option 2 not a secure meta data distribution problem 15:28:04 ... What is the problem we are solving here 15:28:16 q+ to note "secure metadata distribution" 15:28:21 ... Seems to be multiple options regarding trust registries, having pointers from DID documents 15:28:35 ack dlongley 15:28:42 dlongley: Let someone else speak to aniltj 15:29:02 ... Believe option 2 does not solve the problem raised in that issue. That issue is about a validation problem 15:29:10 ... where terms are read from a context that is not known 15:29:25 Is not (2) a secure metadata (@context files being such a thing) distribution problem? 15:29:33 ... even if contexts never changed and were integrity protected, you can still make these mistakes if you don't know the context 15:29:33 ack decentralgabe 15:29:44 decentralgabe: responding to aniltj, yes secure meta data is part of it 15:30:09 ... folks advocating for 2 are concerned that the issuer signed over the context and its properties so they remain untampered for any verifier 15:30:20 q+ to ask second dumb question 15:30:28 ... building on brent, wondering if we could have a new data integrity suite to includes signing over context 15:30:41 ack DavidC 15:30:44 ... still a discussion to be had about whether it addresses the concerns 15:31:16 DavidC: commenting on the idea of using the related resource property, that is signed over. Noting to stop issuer adding relatedResource property to any URI 15:31:24 +1 David is correct 15:31:25 DavidC is correct. 15:31:26 ... Cannot stop an issuer from using this 15:31:40 ack GregB 15:31:41 brent: quesetion is do wewant to encourage people to use this as a means of addressing this issue 15:31:53 -1 it does not address the issue for the reasons I stated, this is a validation issue, not a security issue 15:31:55 s/quesetion/question/ 15:32:08 GregB: part of this issue from a security point of view comes down to understanding who controls what inputs 15:32:25 ... When we talk about this context value, we dont secure the value of the context, we secure all the quads 15:32:32 ... do we want to secure the value of the context? 15:32:54 q+ to ask why isn't @context included in the signed JSON? 15:32:55 yes, +1 to Greg -- it's the verifier that controls the input wrt. @context. 15:32:56 +1 to GregB, with the rdfc cryptosuites, the underlying information is secured, not the specific expression, allowing alternative expressions 15:32:56 ... or do we accept that the context is under the control of the verifier. E.g. the verifier idicates the context values they accepts 15:33:06 ... Verifier says they wont take a context that they dont understand 15:33:27 q+ to ask yet another dumb question, this time about public keys 15:33:41 ... Don't protect the context value, because that isnt part of the inputs that need to be protected. The verifier controls the context 15:34:03 +1 to Greg regarding the Verifier doing due diligence on the @context's @did's it finds acceptable. In fact, that is what we are doing in practice 15:34:03 ack manu 15:34:03 manu, you wanted to note "secure metadata distribution" 15:34:30 manu: brent said could we just use relatedResource. We could, but how normative would we want to get with that 15:34:51 ... is it mandated that if you have a relatedResource with a context, the verifier must through an error if the hashes dont match 15:34:59 ... We would end up getting to a lot of the same issues 15:35:16 ... GregB is right, the verifier determines the contexts and the hashes of contexts that they accept 15:35:29 ... security model is different from the way jose cose do things 15:35:59 ... confusion in this thread. JCS does sign over the context values 15:36:22 q+ responsibility of verifier 15:36:25 ... but that in itself is not enough, verifier has to choose the contexts they accept. This is a validation layer. An application issue 15:36:40 q+ aniltj 15:36:43 ... if we try to solve this at the crypto layer, you make use cases not possible and it doesnt solve theproblem 15:37:25 you can't know how to interpret JSON from just reading its key names (a JSON key of "firstName" may as well say "asdf") 15:37:28 ... Things to consider. This can be viewed as a meta data distribution problem. 15:37:40 ... We tell people do not ever load contexts over the network 15:37:56 ... once a spec is published, verifiers and issuers can lock to very specific contexts if they want to do that. This is expected 15:38:05 you need to know context to properly interpret JSON (whether it's explicitly given like in JSON-LD via `@context` or you get it out of band somehow) 15:38:08 q+ 15:38:12 ... never have to go to the internet. You should not be doing that. Should have a local copy 15:38:29 ... When you get data in, you should check every context and know that you understand these 15:38:33 ... This addresses the attack 15:38:47 brent: Need to start transition to what the next steps are 15:38:47 ack brent 15:38:47 brent, you wanted to ask second dumb question and to ask yet another dumb question, this time about public keys 15:39:02 dmitriz has joined #vcwg 15:39:21 ... if relatedResource as a property doesnt fully address this, we did come up with a mechanism for providing tamper evident information. A VC 15:39:36 ... What if you are concerned about this, issuers can provide a VC of the context file 15:39:40 q+ to ask about verifiers checking VC from new issuer, so no previous relationship to have given context file, so must retrieve it *somehow* and have some way to know that the context document they retrieved has the right content 15:39:56 q+ to note what's signed in RDFC -- it's the NQuads... yes, it's similar to public key discovery. 15:40:11 ... Next, is concern about the context, the same as concern about the public key. Is this key related to this issuer 15:40:28 ack JoeAndrieu 15:40:28 JoeAndrieu, you wanted to ask why isn't @context included in the signed JSON? 15:41:01 JoeAndrieu: conflating issues between the integrity of the property. Not convinced data integrity does not secure the value of the context 15:41:19 q+ to say that DI does secure the `@context` property by using it to expand JSON-LD to RDF N-quads 15:41:27 ... If I can manipulate the context and still have the VC validate that feels like a huge problem with data integrity 15:41:33 Joe - please review the presentation which has examples to prove that if you manipulate the context verification can still succeed https://docs.google.com/presentation/d/1MxLMIjubCVykDux8fBWcisXLu9WeE0LxZzU_xlANUMc/edit 15:41:34 q+ to say "secure the property" is what is confusing language 15:41:35 and integrity of the file is addressed by the digest mechanism 15:41:36 ack aniltj 15:41:49 q- later 15:42:03 aniltj: not a tech provider or tool user. I am an user of this technology 15:42:10 ... We rely on the recommendations of this group 15:42:22 q+ 15:42:30 ... As a verifier, what we are doing is manually verifying and reviewing the context to ensure it is acceptable 15:42:51 ... Ensure it is coming from an entity whose attestations we want to use in our business procesess 15:43:15 ... Just signing the context itself, doesn't solve this problem for me. Just gives confidence that the context has not changes and is coming from an specific entity 15:43:30 +1 a signature on a context tells you nothing about what it is/what it means, context must be processed (at runtime or understood before that and coded against) 15:43:31 ... Struggling to reconcile what is important and relevant to what we are trying to do 15:43:44 ack TallTed 15:43:44 TallTed, you wanted to ask about verifiers checking VC from new issuer, so no previous relationship to have given context file, so must retrieve it *somehow* and have some way to 15:43:47 ... know that the context document they retrieved has the right content 15:44:02 The VC-DI-EdDSA and VC-DI-ECDSA specs allow two different canonicalization approaches. One (JCS) signs over the "JSON", the other (RDFC) signs over "quads" which include complete "term definitions" (URIs) expanded from context. 15:44:21 TallTed: First, data integrity signs over quads which is the result of applying the context to the json being signed over. 15:44:27 yes, exactly, TallTed is exactly right. 15:44:33 +1 to ted 15:44:46 +1 good summary, Ted 15:44:46 thanks, Ted. 15:44:50 q+ to ask about JCS 15:45:01 scribe+ 15:45:20 Wip has joined #vcwg 15:45:24 @decentralgabe - I missed the previous discussion of -- doesn't relatedResources securing the context address this concern? 15:46:00 TallTed: This is open world, VCs can go anywhere at any time, I've never verified a VC from issuer X... I need to get context file that's relevant for their VCs -- this is not the /default/ context, this is the Verifier X context, in addition -- I have to retrieve it and make use of it and have assurance that context file that I retrieve is the same as the context file that was used when generating the VC. 15:46:02 scribe+ 15:46:14 ack dlongley 15:46:14 dlongley, you wanted to say that DI does secure the `@context` property by using it to expand JSON-LD to RDF N-quads and to say "secure the property" is what is confusing language 15:46:30 dlongley: to respond to TallTed, I think it is the question around secure meta data delivery 15:46:51 ... Able to get some context from some source and have confidence it is the context you intended 15:46:52 q+ 15:47:25 ... on the queue to discuss whether to context value is secured 15:47:51 ... the original string of the context is not secured. The context property is fully processed to generate the nquads from jsonld 15:47:56 so the property is secured. It probably shouldn't be dropped. 15:47:58 ... These quads are secured 15:48:10 ack manu 15:48:10 manu, you wanted to note what's signed in RDFC -- it's the NQuads... yes, it's similar to public key discovery. 15:48:12 ... If you were to manipulate the context in any meaniful way the sig would fail 15:48:29 manu: happy to raise PRs for 0,1,3,4. Everything except context integrity protection 15:48:35 ... Think I have enough from the group for this 15:48:42 ... will take a week or two 15:49:34 ... On the queue to respond to brent, we provide an algorithm for how to retrieve the public key but someone could still say you didn't sign over the public key 15:49:49 ... This would be the same security disclosure we are discussing here 15:50:16 ... You have to as a verifier vet certain things. The context. The public key. Other types of meta data 15:50:22 ... This is a good analogy 15:50:38 ack ivan 15:50:50 ivan: related to manu around the PRs to come 15:51:09 ... manu said, you have to publish the hash of the contexts they create 15:51:27 ... Are we sure we really make it clear that authors of new contexts have to publically disclose the hash 15:51:27 q+ to note "MUST" disclose hash. 15:51:32 ack decentralgabe 15:51:32 decentralgabe, you wanted to ask about JCS 15:51:33 ... if this isnt there then it should be 15:51:40 decentralgabe: question about the use of JCS 15:51:50 ... This could be a way out if JCS is signing over the context value 15:51:55 ... How is this communicated 15:52:09 Its in the cryptosuite name... 15:52:13 ... What about nested contexts. Contexts that reference other contexts. How do we secure those 15:52:22 ... For 2 it may be worth continuing this in a new issue 15:52:31 gkellogg has joined #vcwg 15:52:34 ... Some people not present who might still need convincing 15:52:37 it seems that along with disclosure of context hashes, the context hash *should* (maybe *must*) be included in the VC, somehow 15:52:43 ack dmitriz 15:53:06 dmitriz: Main question is doesn't the relatedResource mechanism address a lot of these concerns 15:53:33 q+ to comment on related resource 15:53:49 See for example: ecdsa-jcs-2019 and ecdsa-rdfc-2019 in the VC-DI-ECDSA spec 15:53:53 brent: relatedResource exists inside of the data model. Would work only when data integrity is signing VC data models that include related resource 15:53:55 thanks, makes sense 15:53:58 ack manu 15:53:58 manu, you wanted to note "MUST" disclose hash. 15:54:17 manu: ivan asked if we should add language around providing hashes of finalized contexts 15:54:23 q- 15:54:30 ... Think it is fine to say they should. Concerns around using MUST 15:54:48 ... There are other reasons why you may not need to pubish a has 15:55:02 ... schema.org is well known. They don't need to publish hashes for there contexts 15:55:15 ... I might as a verifier, retrieve something and lock to a specific hash that I retrieved 15:55:39 schema.org is a canonical example of semantic drift 15:55:55 ... We need to think about the use cases deeply before saying MUST around providing context hashs 15:56:14 ... The text we have in the spec is enough to address the attack raised in the issue 15:56:15 note: if a context changes in a way that desyncs it from the originally signed information, the signature will fail -- because the original context contents are "baked into" the originally signed information. 15:56:41 q+ to suggest that we recommend context URLs include a hash. and be done. 15:56:42 ... A known bad context was included in the verifier as a good context. The end 15:56:52 ... it was misconfigured software 15:57:01 ... We already have that language in there 15:57:16 so if a dynamic context is used -- signatures on existing VCs will start to fail -- and that would need to be ok with people taking that approach 15:57:17 ... We can clean it up and clarify 15:58:05 ... many of these solutions are problematic. The relatedResource and including the hashes in the signature is not solving the problem 15:58:11 ack JoeAndrieu 15:58:11 JoeAndrieu, you wanted to suggest that we recommend context URLs include a hash. and be done. 15:58:23 fundamentally: you can't read a term defined by a context without understanding that context. 15:58:26 gkellogg_ has joined #vcwg 15:58:40 JoeAndrieu: I don't agree, I think today people defining contexts can create a URL for a context that has a hash in it 15:58:48 ... We don't have to change the VCDM to support that 15:59:17 +1 to Joe's use hashes in @contect files if you want them secured. 15:59:26 rrsagent, draft minutes 15:59:27 I have made the request to generate https://www.w3.org/2024/07/10-vcwg-minutes.html ivan 15:59:35 brent: we have a path forward. Thanks for that. look forward to seeing those PRs 15:59:35 +1 to Joe's suggestion as a layered way to do things people may want. 15:59:38 rrsagent, draft minutes 15:59:39 I have made the request to generate https://www.w3.org/2024/07/10-vcwg-minutes.html ivan 15:59:46 s/hashes in @contect files/hashes in @context files/ 16:00:25 rrsagent, bye 16:00:25 I see no action items