21:04:44 RRSAgent has joined #vcwg-special 21:04:49 logging to https://www.w3.org/2024/09/05-vcwg-special-irc 21:04:51 zakim, start the meeting 21:04:52 RRSAgent, make logs Public 21:04:53 please title this meeting ("meeting: ..."), brent 21:04:56 present+ anilj 21:05:01 present+ 21:05:03 selfissued has joined #vcwg-special 21:05:06 meeting: VCWG Special Topic Call 21:05:08 present+ 21:05:11 cahir: Brent Zundel 21:05:19 chair: Brent Zundel 21:05:20 present+ Kdean 21:05:28 present+ 21:05:37 present+ GregBernstein 21:05:41 present+ bigbluehat 21:05:47 present+ 21:05:50 present+ dezell 21:05:50 GregB has joined #vcwg-special 21:06:17 present + 21:06:31 scribe+ 21:06:33 scribe+ 21:06:36 aniltj has joined #vcwg-special 21:06:59 brent: Welcome everyone to the special topic call - topic today is Data Integrity issue 272 21:07:00 KevinDean has joined #vcwg-special 21:07:04 present+ 21:07:50 brent: Concerns about security vulnerabilities in design of data integrity, well discussed issue, lots of good proposals and solutions, to my understanding, everything was agreed on (adjustments to vocabulary, enhancements to context validation, clarifying data model, lots of changes made as response to this issue). 21:08:25 brent: There is a particular ask that will likely be the primary topic of conversation today, but turning over to Tobias to present the issue. Tobias, the time is yours to present and then we'll go to discussion. 21:08:54 tplooker: Thanks for holding the special topic call. I won't spend too much time going back through the issue... 144 comments, I think we're all well versed into conversation that has gone in attempt to resolve the issue. 21:09:18 subtopic: https://github.com/w3c/vc-data-integrity/issues/272 21:09:41 tplooker: To summarize, from my point of view, there has been a lot of conversation and proposals raised, the biggest one that remains to ensure this cannot occur, is around integrity protection around @context issues. I've tried to highlight that I do believe that alone is the most important proposal to discuss in more detail. 21:10:49 tplooker: Even with adjustements to @vocab, and non-normative guidance, leaving the context values open to manipulation is still a significant issue in my opion. While I appreciate text around relatedResource feature, I'm not convinced it goes large enough. It's largely an optional feature. I could not see test coverage for that feature. I guess I'm wary of the liklihood that implementations would support such an optional feature. Protection 21:10:49 wouldn't exist in most impleemntations. 21:11:33 tplooker: I think we should go stronger, require protection of @cotnext values. I know tehre were discussions around trade-offs, or doing context transformations. I don't want to limit context transformations. I debate whther or not they're useful in data signing and verification laery. I think it's useful AFTER things have been verified. 21:12:05 tplooker: Verification should be done on data used by issuer. 21:12:17 q? 21:12:19 q+ 21:12:33 brent: I'm happy to presume that everyone is up to speed on this discussion. 21:13:10 I believe it is a MAY brent? 21:13:12 brent: The proposal on the table is to strengthen the protection on @context in Data Integrity, let's have a discussion. 21:13:13 ack dlongley 21:13:43 q+ 21:13:45 I'm curious if @tplooker would be ok with changing the MAY to a SHOULD. or if MUST is required. 21:13:56 > To extend integrity protection to a related resource, an issuer of a verifiable credential MAY include the relatedResource property: 21:13:57 https://w3c.github.io/vc-data-model/#integrity-of-related-resources:~:text=To%20extend%20integrity%20protection%20to%20a%20related%20resource%2C%20an%20issuer%20of%20a%20verifiable%20credential%20MAY%20include%20the%20relatedResource%20property%3A 21:14:16 SHOULD is better but I believe MUST is required 21:14:18 dlongley: I think SHOULD is strong enough, we have a number of use cases and things we've discussed on that issue. Reasons to allow different contexts to be used that are different from issuer wants to use. IWe've talked about design around flexibility on those cases. Individual uses on the spec in different areas, different verifiers, can profile the spec and require related resource to be used if it suits that ecosystem. At base layer of spec, 21:14:18 we should have ability of other uses to work. 21:14:31 ack brent 21:15:01 q+ 21:15:04 brent: An assertion was made by Tobias that, specifically, the set of use cases that would require additional context switching would still be possible and should be done after issuer context as provided has been part of verification process. Can you talk about those lines? 21:15:24 ack dlongley 21:15:25 brent: What use cases would be prohibited on that model. What would be drawbacks of requiring that verifier checks before doing context manipulation. 21:15:53 dlongley: This doesn't actually solve the problem, the recipient has to understand what context is, even if it is from a context that is trusted, terms definitions, doesn't funadmentally solve the problem. 21:16:25 q+ 21:16:33 dlongley: There are use cases where selective disclosure, omit context issuers use -- where a verifier might accept international license, but license might have issued by different countries and you just want to selectively disclose only international propreties and international contexts. 21:17:20 hsano has joined #vcwg-special 21:17:53 dlongley: Take a VC and express as CBOR-LD and transmit to a verifier that can accept it, doing that might require context from issuer used. You should not have to go back to issuer to ask for their permission to request format for same information. Key to data integrity design, where holders can be independent in what they do. They don't have to keep going back to issuer to request different formats. None of those things should be happening. 21:17:53 Privacy and liberty considerations. Fundamentally, you can't do all of those thing is if you're forced to use issuer-provided context. 21:17:59 ack tplooker 21:18:02 present+ 21:19:45 q+ 21:20:40 tplooker: What I was trying to say is -- from a selective disclosure perspective, it still works, but some of the context values don't expand to terms. I don't think SD is prohibited. The same with CBOR-LD. One of the overarching points is issuers fundamentally comfortable w/ data transformations after data is signed that might misconstrue or misconvey information that was originally signed. Most document issuers of major credentials don't want 21:20:40 that level of manipulation to occur. They don't want holders to manipulate credentials to misconstrue credential, come to rely on informatio. It's issuers reputation on the line at end of day, just like w/ physical documents today, we don't let holders allow changes. It's issuers reputation on the line, they should have a say on how much document can be modified after issuance. Leaving document to be manipulated leads to issues. Tradeoff is 21:20:41 difficult for issuers to be able to adopt the technology if it is allowed to persist. 21:20:43 ack dlongley 21:20:59 q+ 21:21:25 ack aniltj 21:21:26 dlongley: That we're having a philosophical debate on extend of three party model and who gets to have control indicates that this is what profiles are for. Spec has flexibility, that is good, I don't think we should be too prescriptive. We should allow separate ecosytems, let the ecosystems have the choices they'd like to make. 21:22:47 aniltj: Speaking on behalf of a high value credential issuer, resonate with some of the things Tobias noted, issuers have a perspective on credentials that we issue. I also think that there has to be a balance. We as an issuer are interested in providing ability to verify information that we provide and also allow credentials to be used via CBOR-LD, rendering mechanisms, and the like. We as an issuer won't be silent on it, spec as it is written, 21:22:47 if we feel strongly about certain aspects of it, we can profile the standard itself to make sure other credentials we issue follow a path that conforms to our belief. 21:22:50 q+ 21:23:22 aniltj: The question I ask in general, if we as an issuer wanted to mandate the requirement of using the feature in order to sign the context itself, that's simply a matter of us articulating that in our profile, are we prohibited form doing that? 21:23:27 +1 you can say you must use related resource 21:23:29 brent: Short answer is no, you're not prohibited from doing that. 21:23:31 ack tplooker 21:23:44 tplooker: That is a good point, the text today is optional 21:23:45 q+ 21:23:49 q+ 21:24:00 tplooker: even if you do that, relying parties can ignore it. 21:24:04 q+ to ask a dumb question 21:24:12 I thought the 'relatedResources' mechanism was required, not opitonal? 21:25:19 @bigbluehat - in the sense that, IF the 'relatedResources' property is present, THEN it must be validated 21:25:22 tplooker: If I'm an issuer, and VCs today under this assumption, these @context values are left not integrity protected, I have to trust that relying parties trust document loader, how they've held context in storage, how they've allowed those not to be manipulated, if any of that fails, if this is not mandatory, all bets are off. That is what is difficult to square here. Document issuers are going to look at that, and huge amount of new trust in 21:25:22 RP implementations that my documents are being verified suitably. 21:25:31 q+ 21:25:35 (and if that's not the case, my proposal is to constraint 'relatedResources' that way. 21:25:40 ack manu 21:25:46 manu: to respond to one comment 21:25:53 ... the comment about things can be ignored 21:26:08 ... the spec today can be profiled and be made more strict--that is true 21:26:28 ... you can in a profile state those things as MUSTs written into a profile 21:26:42 ... I'm pushing back on the notion that it's optional and people can ignore it 21:27:07 ... people always need to trust the issuer and the verifier 21:27:23 ... in this model there's a certain amount of trust in the verifier that they will do a good job 21:27:42 ... and the verifier has an obligation to do the correct amount of verification to get the result they require 21:28:01 ... not doing that, means the verifier is to blame for any fraud 21:28:19 ... they are required by the market to follow the expectations of the issuer 21:28:25 q+ 21:28:29 ... it's not purely the issuer's reputation at stake 21:28:50 ... the issuer can point to the verifier and show where the verifier failed--just as they do today 21:29:04 ... if you accept a fake Driver's License, that's on you 21:29:27 ... the issue here is that we provide mechanisms that can content integrity protect the issuer if the issuer really strongly requires that 21:29:36 ... any vertical can profile it to mandate that 21:29:46 ... we already have profile examples that are similar 21:30:05 ... if a verifier chooses to ignore that profile, there are plenty of negative results 21:30:11 q+ 21:30:15 ack dmitriz 21:30:15 ... we don't have to mandate it at the VCDM layer 21:30:20 ... but can in a profile 21:31:03 +1 brent that was the point I was trying to make 21:31:12 Sorry dmitriz :) 21:31:27 ack brent 21:31:27 brent, you wanted to ask a dumb question 21:31:32 dmitriz: The conversation on the call so far, Anil mentioned that while requiring context verification might be too far, he'd like to see ability for issuer to say "verifiers MUST do this". At the moment, relatedResource - we don't have normative language if related resource is present, they must be enforced, if they fail, the VC verification fails. Adding the normative language, making relatedResource normative and ensuring issuers enforce 21:31:32 context integrity. 21:31:43 q? 21:32:38 q+ 21:32:58 brent: I got on the queue to suggest something along similar lines. We have two conformance classes, conforming producer and conforming consumer. If I'm understanding use cases property, we do not want to prohibit the producer to do things that require context integrity protection, what if we do what Dmitri just said -- it is a MAY to include context integrity protection using relatedResoruce, but if that is used to protect context. Conforming 21:32:58 consumer must validate that context integrity protection. Is that crazy? Does that work? 21:33:01 ack aniltj 21:34:28 aniltj: I am curious to hear answer to your question. I wanted to correct one thing that Dmitri said -- verification and issuance side, my point is that I, as an issuer, can control my issuance infrastructure. Profiling allows me to say whether or not to use relatedResoruce to sign context information or not. If I'm acting as a verifier, this is where I live in the real world, at end of the road, just because I'm issuing a high-value credential, 21:34:29 significant realtime identity verification and usage, doesn't mean that credential isn't being used as a flash pass. 21:34:51 +1 to anil ... issuers do not control what verifiers do ... so we need to avoid an illusion of control here 21:35:04 aniltj: Ultimately, verifiers don't have to follow our guidance. They might have a different risk tolerance. We issue multifactor smartcards, 2nd factor pins, but there are many cases where people look at photo and verify as valid. 21:35:51 aniltj: The belief that I, as an issuer suffers when a verifier doesn't do a proper verification, is false. We point the finger at the verifier as the problem. 21:36:12 ack selfissued 21:36:14 aniltj: There is no guarantee that someone will follow our guidance other than us. I'd like to hear reaction to brent's proposal. 21:36:24 +1 to aniltj's framing 21:36:51 -1 the effective is not the same at all 21:36:59 selfissued: What puzzles me is that we're talking about this as if it's a garden variety optional feature that people can do it or not, given that it's a security feature, and it will be abused ... should we even give people that option. 21:37:15 q? 21:37:24 selfissued: Given it's a security feature, we should say it's mandatory on both sides and if you don't do it, you fail the conformance tests. 21:37:27 ack tplooker 21:38:05 tplooker: A similar point, we have to see that this is not an integrity protected portion of the VC, at best, not like unprotected headers, effects entire part of processing of VC. It effects everything that's not integrity protected. 21:38:11 q+ 21:38:13 q+ 21:38:17 q- 21:39:53 tplooker: reputational issue to verifiers, do agree with Manu -- more plausible deniability you create for verifier "that's not clear, that's not optional, guidance wasn't clear" the industry around fake DLs is evidence of that, document security features of DLs are too difficult to verify. RPs get away with poorly validating those documents because it wasn't reasonable, too hard to do. That's what I fear we're doing here, opening up issues that 21:39:53 create issues w/ ... maybe reputational damage doesn't happen at issuer, undermines system as a whole. 21:40:31 tplooker: I did want to come back to brent's point, that would at least be an improvement on the text today. If there was a way to require that relatedResources context entries are used are integrity protected must be checked/verified by RPs downstream, that signal would be useful. 21:41:03 ack dlongley 21:41:05 tplooker: You will have RP that doesn't support feature and they will simply ignore. Unless we have normative text that says you should fail verification that you don't support validating related reousrces in credential, then you have a downgrade attack. 21:41:51 dlongley: I largely don't agree with the analogy, a lot of this is coming from , we're talking about even if you do it and don't understand form and terms, your application is invalid. It fundamentally does not matter, if you receive a context you don't understand, you need to reject. 21:41:53 understanding the context and verifying its integrity are completely separate though 21:42:22 +1 dmitriz 21:42:45 dlongley: ALl of that being said, I don't think I'd have a problem saying that if relatedResoruce appears and context is expressed in that valud that is need to be checked. I will note that will eliminate use cases where issuers don't want to force a check like that, I don't know of many that will have that requirement. If context URL, you check that value. 21:42:51 q+ 21:43:15 q+ 21:43:35 brent: Seems like proposal on the table is that it will not be required, MAY or SHOULD, some issuer MAY use context integrity protection, however, if that has been done, verifier MUST fail verification if that fails. 21:43:53 ack manu 21:44:11 q+ to say that you can make it mandatory or non-mandatory 21:44:14 q+ to mention verification isneed not be binary 21:44:17 manu: I'm trying to think through that as applied to selective disclosure and the BBS use cases--unlinkability 21:44:44 ... for selective disclosure you would eliminate the ability to do the international drivers license vs. a local drivers license. 21:44:56 ... if it's a MAY, then perhaps we avoid that problem 21:44:59 I don't think you would, the context would just be transmitted to the verifier and un-used in the JSON-LD expansion 21:45:26 q- 21:45:36 ... we would need matching language that if you do that you must make the disclosure of the related resources--at least the context files (as there could be other resources) 21:45:38 that complexity is the domain of the Selective Disclosure spec. 21:45:43 q+ 21:45:50 ... there's a great deal of new complications if we do this 21:46:10 ... and I still don't think an attack has been demonstrated for this situation 21:46:24 ... things like RDF canonilcalziation do protect the terms 21:46:38 "dont know what the context is" is way ambiguous phrasing. 21:46:41 ... if you get any context in that you don't understand, you're supposed to stop processing 21:46:53 ... so we're left with only contexts that one knows about 21:46:56 verifiers can know what the context is, but still use the wrong digest context 21:47:06 ... so I don't know of any attacks that are left at that piont 21:47:07 dmitriz: signature won't verify 21:47:12 dmitriz: that's a separate issue. 21:47:17 ... JOSE/COSE doesn't provide those protections 21:47:35 ... so I don't think it's necessary. 21:47:55 ... it has not been demonstrated that this is a workable attack based on the text as written today 21:47:58 q+ 21:48:02 ... I think profiling this is sufficient 21:48:18 ... even adding a "verifiers must..." text doesn't change anything 21:48:35 ... based on the text in the spec today, there has yet to be a proven attack based on this request 21:48:42 ... but I could hold my nose 21:48:45 fundamentally: you cannot read the properties of a context that you don't understand, you must reject or transform to a context you do understand, before using the properties. 21:48:48 to me, the issue with 'relatedResources' is now unrelated to @context integrity. Instead, it's a spec clarity issue. The whole point of adding a 'relatedResource' is that the contents MUST be verified 21:48:54 so resource integrity is irrelevant. 21:48:57 ... but frankly that's going to happen in production anyway 21:49:18 brent: I'm all for requiring people to do stuff 21:49:20 @dlongley - "understand"ing a context is at worst a meaningless term, and at best is overloaded 21:49:21 ack selfissued 21:49:26 manu: yeah...funny, but that's not what I was saying 21:49:32 dmitriz: agreed, it's hard to get clear language 21:50:02 ack JoeAndrieu 21:50:02 JoeAndrieu, you wanted to mention verification isneed not be binary 21:50:02 selfissued: I will object to the proposal because it fails to secure the context, if you don't secure it, context substitution doesn't occur, it needs to be compulsory on both sides. Knowing contexts, doesn't prevent attack, it can happen w/ other contexts that you can accept. 21:50:05 -1 to mike jones, that's inaccurate, and a misunderstanding of data integrity. 21:50:08 manu: That's not how it works selfissued 21:50:36 +1 to JoeAndrieu 21:50:40 JoeAndrieu: I agree with Manu, I dont' think a successful attack has been proven. I'm not understanding where this attack shows up. 21:50:43 +1 to JoeAndrieu 21:50:49 JoeAndrieu: I think we're also conflating verification and validation. 21:51:39 +1 to JoeAndrieu 21:51:50 JoeAndrieu: People are talking about securing context, and string and context is secured. Historical notion might be what is being confused, context that is returned as a resource should be different, but should be different any time... context doesn't have hash to do it, trying to cobble one after the fact might be useful, but doesn't have credibility for verification. 21:51:55 ack dmitriz 21:52:30 q+ 21:52:43 dmitriz: At this point, the relatedResoruce language issue is unrelated to context integrity, now it's a clarity of the spec issue. The whole point is if issuer puts it there, validation has to fail if checks don't apply. If that's not clear from spec, we need to fix spec language. If we do, we gain spec backed ability to mandate signature be checked. 21:52:47 q+ 21:52:51 ack tplooker 21:53:00 q- 21:53:29 @bigbluehat - digest validation does not *require* fetching. you can cache as usual. 21:53:57 -1 the signature will fail 21:54:09 tplooker: I'll try and reply a practical attack when you follow all the guidance, malicious party, RP validates a government identity credential and I know schema and ontology, corrupt RP in some way to manipulate credential presentations. Problem is known context values are not issuer specific, implementations have one document load, contexts I trust, not related to issuers, so if I can get a context value trusted for a different VC that somehow 21:54:09 changes or subtitutes ontology I can use trusted context to 21:54:15 manu: -1 nope, signature will fail. 21:54:19 -1 not true, the signature will fail 21:54:22 -1 the context property is secured. 21:54:24 @tplooker - what does "trusted" mean here? And yes, signature will fail 21:54:48 q? 21:54:55 tplooker: These could be conflicting, general purpose bucket of context values, as RP, if I know what context values you trust, I might be able to manipulate those in a way that allows me to do the attack. 21:54:57 ack manu 21:55:17 manu: tplooker that is not how a secure implementation is going to work 21:55:23 ... you should never do what you described 21:55:28 q+ to say it doesn't matter what you do, the signature won't match in that case. 21:55:39 ... one typically validates the incoming JSON with JSON Schema or similar 21:55:50 ... we've also discussed use case specific verifiers 21:56:01 ... so the attack you're describing just doesn't happen 21:56:19 ... you check an inbound schema for the JSON 21:56:31 ... so the attack you just highlighted does not happen in a good implementation 21:56:52 ... responding to dmitriz the relatedResource feature was never meant to be a verification component 21:57:01 ... you only verify the ones for your use case 21:57:16 ... let's say you listed every single image related to your credential 21:57:16 q- 21:57:26 ... but the verifier only wants one of those 21:57:28 @manu -1 to that interpretation. there's no flag that an issuer can set, in the relatedResources image, to mark which ones are required. 21:57:49 ... if the spec required every relatedResource to be verified, then you broke that use case 21:58:03 ... so big -1 to making relatedResource enforced in that way 21:58:11 ... that was not the intention of that term 21:58:17 @manu would you be open to adding a 'required' flag, to each relatedResource object? 21:58:19 short on time, i will just type: to respond to tobias's example, the signature would fail in that case, you can't do that attack (where you use some other trusted context to confuse the verifier) ... and it further highlights point that the verifier needs to understand the contexts it is using to read documents. 21:58:21 ... and there would be big minus ones for that position 21:58:28 ... it's a question of layering 21:58:28 Just to replay what I was trying to say, context values are shared across all credentials an RP verify's, generally that means if I have conflicting context values that redefine terms in different ways across issuers I can perform context manipulation within the bounds of the trust context values of an RP to maliciously modify a credential 21:58:28 q+ if the intention is to MUST dereference *anything* is not going to work 21:59:04 q+ 21:59:05 q+ 21:59:09 JoeAndrieu: At any point we have to dereference, we're creating a security concern... relatedResources, don't dereference if you need to... we can't mandate it. 21:59:21 q- 21:59:23 ack dmitriz 21:59:38 to just say -- it's fine to dereference a context -- so long as you're transforming to one that you don't have to dereference before you read the document :) 21:59:45 I mean I agree with JoeAndrieu but @context values are HTTPS URLS so lets be practical people can and will dereference these 21:59:46 I believe that I can get what I need out of this by profiling the current text. 21:59:48 dmitriz: At the moment we don't have capability to fulfill Anil's requirement, issuer flag what resources must be secured. My proposal is true/false to related resource for signal from issuer. 22:00:00 tobias, please see my point ^ you do transformation in that case. 22:00:19 tplooker yes, that should give a good response for a human. but verifiers should not do so in production 22:00:30 brent: Thank you, this was a great conversation, appreciate the civility, consideration of different viewpoints. This conversation will go into the issue. We continue to explore the possibilities that are on the table. Hpefully we can move this forward in a way that is amenable to folks and find some consensus. 22:00:42 brent: Thanks to all for the special topic call, we'll chat next week. 22:00:50 zakim, who is here? 22:00:50 Present: manu, tplooker, shigeya, JoeAndrieu, dmitriz, anilj, bigbluehat, selfissued, Kdean, brent, GregBernstein, dlongley, dezell, KevinDean, hsano 22:00:52 On IRC I see hsano, aniltj, selfissued, RRSAgent, bigbluehat, Zakim, dezell, brent, tplooker, dmitriz, TallTed, dlongley, dlehn, csarven, shigeya, manu, ivan 22:01:08 zakim, end the meeting 22:01:08 As of this point the attendees have been manu, tplooker, shigeya, JoeAndrieu, dmitriz, anilj, bigbluehat, selfissued, Kdean, brent, GregBernstein, dlongley, dezell, KevinDean, 22:01:11 ... hsano 22:01:11 RRSAgent, please draft minutes 22:01:12 I have made the request to generate https://www.w3.org/2024/09/05-vcwg-special-minutes.html Zakim 22:01:19 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 22:01:19 Zakim has left #vcwg-special 22:01:45 rrsagent, bye 22:01:45 I see no action items