23:00:59 RRSAgent has joined #vcwg-special 23:01:03 logging to https://www.w3.org/2023/02/28-vcwg-special-irc 23:01:03 RRSAgent, make logs Public 23:01:04 please title this meeting ("meeting: ..."), kristina 23:01:14 Meeting: Verifiable Credentials Working Group Special Topic Call Telco 23:01:20 Chair: Brent 23:02:08 brent has joined #vcwg-special 23:02:17 present+ 23:02:25 Paul_Dietrich_GS1 has joined #vcwg-special 23:03:17 present+ 23:03:20 dwaite has joined #vcwg-special 23:03:22 present+ 23:03:52 present+ 23:04:17 scribe+ 23:04:39 Kerri_Lemoie has joined #vcwg-special 23:04:43 present+ 23:05:26 brent: Our topic for today, straightforward, PR 1014, conversation on proof property in core VC data model -- more specifically, should credential+ld+json media type require a proof property or allow one or forbid one? 23:05:33 subtopic: https://github.com/w3c/vc-data-model/pull/1014 23:06:03 brent: There is a long conversation in the PR, goal of this meeting is to hash out what different sides of debate are, and can then try to come to proposals, recommendations on how to move forward. 23:06:13 q+ to summarize 23:06:19 scribe+ 23:06:24 ack manu 23:06:24 manu, you wanted to summarize 23:06:56 manu: There are a couple of threads for this discussion. One of the threads is "hey, we should have a media type for unsecured credentials and we should have one for secured ones. Those are the two classes we should have." 23:07:29 manu: "If we are going to do that then the unsecured credentials should have no securing mechanism in them." That's the argument for `application/credential+ld+json` MUST NOT or SHOULD NOT have a `proof` property in it. 23:08:12 manu: The other argument is `application/credential+ld+json` has an extension mechanism and one of those might add a securing mechanism in it and we can't predict what mechanisms other people do, there might be new ones people define in the future and the language can't stop that from happening even if we put text in the spec. 23:08:57 manu: Even if we say you can't put `proof` in there, we can't know all the different mechanisms that might happen in the future. The other part of that argument is, "well, you can have very deeply nested and structured VCs and we already have examples of things that learner records and transcripts that might have badges, workforce skills credentials, things that have embedded proofs in them and that's a valid use case." 23:09:08 manu: Potentially the outer envelope is not secured but the inner ones are. 23:09:17 manu: So that's kind of the argument for "they may contain proofs". 23:09:45 manu: So we're looking at `application/credential+ld+json` either: "MUST NOT/SHOULD NOT have proof" or "MAY HAVE proof". 23:09:49 q+ to ask if we as a group can define what a credential is (data type wise) before it becomes a verifiable credential 23:09:50 q? 23:09:56 ack mprorock 23:09:56 mprorock, you wanted to ask if we as a group can define what a credential is (data type wise) before it becomes a verifiable credential 23:10:18 mprorock: I think that's a reasonably good summary, in my mind, it's a more fundamental question. What is a credential? What makes it a verifiable credential? 23:10:25 q+ to talk about subclasses 23:10:44 mprorock: The way I think of it, once you add a signature, it goes from credential to verifiable credential. Once I see application/credential+ld+json, that's a credential, is an input type. 23:11:25 mprorock: once you sign it... it becomes a verifiable credential. We can define what goes into the process, what makes something a VC, and if we can drive that line, we should do that. We can't cover non-compliant stuff w/ the spec, but we should cover cases that we know of. 23:11:28 ack dlongley 23:11:28 dlongley, you wanted to talk about subclasses 23:12:14 dlongley: I think it's good to avoid confusion where we can, we have to be careful about avoiding confusion when we're talking about secured vs. unsecured or trusted vs. untrusted data... the recipient of the data needs to have an expectation about what they're receiving. They can't just accept whatever the sender sends, that opens the door to protential vulnrabilities. 23:12:56 dlongley: Another thing to consider around type is that a VC can be seen as a subtype of credentials, that concept allows for different use cases. Different partieis might care about different types of credentials or not. If you have a VC or a credential, a digital wallet can display both. 23:13:46 q+ to talk about multiple proofs 23:13:55 ack dwaite 23:13:55 dwaite, you wanted to talk about multiple proofs 23:14:03 dlongley: People might want to accept things that accept VCs or credentials and add proofs -- so proof chaining, timestamp proofs, and we should be careful to not close the door to innovation, but we should be careful to think that we /can/ close that door. If we put in prohibitive statements, someone will figure out a way to get around it if it gets in the way. For example, someone could do a 'proof2' field to get around something that says that 23:14:03 'proof' isn't allowed. 23:14:17 q+ to ask why we would not use `verifiable-credential+ld+json` or similar for things with proofs embedded 23:14:31 dwaite: Some of this may be defining the behaviour when you have multiple proofs by default, I can remove one of the proofs and it's still verifiable, just with less mechanisms. 23:15:28 dwaite: The guidance on what to do when there are multiple proofs -- pick your favorite one, do them all for higher assurance, that would be helpful for this discussion, proofs can be dependent on other proofs as well. I have a proof that is protecting other existing proofs, those can't be removed. So some of the assumptions about difference between VC and credential and having proofs, really are in the eye of the verifier. 23:15:29 q+ 23:16:02 dwaite: Some of the idea here is "if I have something like a JWS wrapping an external proof, and the proofs inside, what are the semantics that people should assume?" If we can't provide semantics that have value, maybe it's not legal in that case. 23:16:03 ack mprorock 23:16:03 mprorock, you wanted to ask why we would not use `verifiable-credential+ld+json` or similar for things with proofs embedded 23:16:07 present+ 23:16:32 tplooker has joined #vcwg-special 23:16:33 present+ 23:16:35 present+ 23:17:30 q+ to say media types don't work that way "this is an input" 23:18:14 mprorock: The PR here is explicit around one line related to application/credential+ld+json media type. Those of us that are planning on using that tend to feel strongly, either this is input into something that gets linked data signature, or have external signature... not sure why we would application/verifiable-credential* or some structure that signifies that you have proof there, additional semantics, etc. Avoiding the fact that we can be 23:18:14 clear here bothers me, frustrating to me that we can't be explicitly clear about desire to just have credential format w/o proof in it. There are representations that have proof block in there, media type used in cty/typ or other use cases. 23:18:24 ack manu 23:18:33 manu: So I want to agree with what David Waite was saying. 23:19:15 manu: That the difference between a VC and a credential is in the eye of the verifier. I think that's interesting there, I don't know how I feel with that as an absolute statement, but that resonates with me. There could be a VC with multiple proofs on it, but the verifier only wants to check 2 of them. 23:19:22 manu: Maybe one is BBS, one is post quantum, one is ECDSA. 23:19:34 q? 23:19:38 q+ 23:19:39 manu: The verifier in that case may only case about ECDSA. They may choose to ignore the other proofs ... or they may choose to look at a proof further down the tree. 23:20:21 manu: Mike, to look at the use case that you highlighted. ... Here's a concrete use case. If I have a learner record in the education space. The outer thing has no proof, but the inner one has all the classes I took this year and there are class descriptions and skillsets all with proofs. 23:20:39 manu: Is that thing with 50 proofs at the second level ... is that top level thing a credential or a verifiable credential? 23:20:44 cabernet has joined #vcwg-special 23:20:48 present+ 23:20:53 manu: You could argue this. I think it's problematic ... I think the PR language doesn't seem to give us an answer for that use case. 23:21:11 manu: I think it doesn't give us an answer for that use case or use cases where there are other securing mechanisms used. And ultimately, it's up to the verifier to figure out which proofs it cares about. 23:21:52 manu: It might be then that sometimes different mechanisms determine whether it's viewed as verifiable or not. It's the compound / complex objects that have signatures at the leaves that could be impacted negatively by this language. If we can be more specific we should be. 23:22:15 manu: Mike's argument for having two different media types for verifiable vs. credentials resonates with me to communicate more specific media types for what I mean. 23:22:37 manu: Remember, we have `application/credential+ld+json` which means you can process as JSON, JSON-LD, or as a credential in the VCDM. 23:22:40 manu: We have that concept. 23:22:55 ack dlongley 23:22:55 dlongley, you wanted to say media types don't work that way "this is an input" 23:22:59 q+ to suggest the model of core data model defines the credential media type (and likely presentation) and then data integrity suggest a media type for their use cases as JWTs have done 23:23:49 dlongley: media types are not necessarily the right tool to make sure that something is an input to an API. The media type is a way to identify the type of content and how it would be parsed and used, regardless of what API you're using it in. It's a more encompassing thing, not for just one particular use case, one particular API, it's not the right tool for accomplishing that. 23:24:14 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept etc. of course multiple use cases 23:24:17 dlongley: That said, APIs have their own shape, can provide their own restrictions, you can do that, that's not a problem and that might be the right way to define that, you can do that via API schemas to accomplish that goal. 23:24:25 ack kristina 23:25:10 kristina: Manu's comment confused me. I do not understand the concept of top level, secondary level proofs, one of the things we did in data model v2 is we separated data model in how we sign/secure it. The notion that something that conceptually is not supposed to be signed can have this proof is very confusing to me. 23:25:22 q+ to provide more data on "multiple nested signatures" 23:25:56 kristina: That's a use case we need to pay attention to -- is that a valid use case? We have `proof` in data model, we should move it down to proof formats. I don't think anything related to signatures belongs there. 23:26:00 ack mprorock 23:26:00 mprorock, you wanted to suggest the model of core data model defines the credential media type (and likely presentation) and then data integrity suggest a media type for their use 23:26:03 ... cases as JWTs have done 23:27:02 mprorock: Big +1 to what Kristina said, building on that, we have a good model if we accept this PR, core data model defines what a credential is, and how different specifications might process that... what's expected, in VC-JWT there is a clean way of specifying media types, what to expect when, JWS, or something COSE related, since we have a nice data integrity spec, perhaps we should put media types w/ proofs in a credential, people know how 23:27:02 to deal with that information. 23:27:13 q+ to say even if that were true (DI spec thing mike said), that would not support restricting `application/credential+ld+json` 23:27:43 manu: To address Kristina's concern. We have a concept here -- and JWTs deal with it differently. With Data Integrity proofs, you can have documents that nest other documents and each can nest proofs at every layer. 23:28:00 ack manu 23:28:00 manu, you wanted to provide more data on "multiple nested signatures" 23:28:07 q+ 23:28:17 manu: We have examples like learner records where that's a reality. Talking about it like "are we going to allow it or not" isn't the right framing because it's already a reality today. It doesn't matter if this group says that structure is illegal, people already find it useful and do it. 23:28:26 manu: They don't have to base64 at each level and things of that nature. 23:28:27 Is w3c.github.io down? or is it just me? 23:28:46 manu: We do need to get to the bottom of that and making stuff like that illegal would be a much bigger issue than just this PR. 23:28:49 q+ 23:29:19 manu: The other thing we should consider is that people might use a VP proof and then put a JWT on top of that. I know some people don't want to see that happen, but others might. Given the way things are going in the ecosystem it's probably inevitable that we'll see things like that. 23:29:31 Learner record spec from 1EdTech doing the embedded VCs that Manu described: http://www.imsglobal.org/spec/clr/v2p0/ 23:29:43 q+ to state that "making it illegal" is not what is being requested - what is being requested is to use a unique media type for something that has a proof 23:29:53 manu: Saying "proof" doesn't belong in the core data model and we should put it in Data Integrity, etc. then we shouldn't be making it illegal to include a `proof` either. That would be a weird layering violation. 23:30:26 q+ to ellaborate on chained proofs and JWT guidance 23:30:35 manu: I think this is us thinking that we have the ability to use a media type to enforce something that people will probably ignore if we write the wrong thing here. I think if we say that the `application/credential+ld+json` must not have any securing mechanism in it, people will ignore that, the use cases are valid. 23:30:45 ack dlongley 23:30:45 dlongley, you wanted to say even if that were true (DI spec thing mike said), that would not support restricting `application/credential+ld+json` 23:31:14 q- 23:32:21 dlongley: big +1 to what manu said... if we moved proof into data integrity, it would further undercut case for restricting credential+ld+json in this PR, you wouldn't have anything to point to to do it. We should embrace the subclass concept. I'm tagging media type that's specific... another thing to have a less restrictive media type. To provide an analogy -- you can have applications that have rectangles, application accepts it... squares are 23:32:21 a more specific type of rectangles... you should be able to use your rectangle library on a square. That's ok, that's what subclass mechanism gives us. 23:32:50 ack kristina 23:32:51 dlongley: We have an extensible data model, people will want to know why we added prohibitive statements about use cases they want to do in the future. 23:33:46 kristina: To clarify -- not questioning legitimacy of use case where there are nested data integrity proofs -- what I'm not understanding is credential that is conceptually not supposed to be signed, including a proof property? That's what clearly separates credential from verifiable credential. Let's not completely remove proof from data model, remove it from section 4 to section 6. 23:33:48 +1 Kristina 23:34:16 q+ to say accepting a credential that is "not supposed to be signed" is not a problem for many applications -- they will accept either, what's the media type that supports that ... do people have to add if/else statements and complexity to work with this? 23:34:46 kristina: Imagine a JSON structure that includes proof property... and that is signed by JWS... if that enters JWS processor, that doesn't understand proof claim, it'll ignore it. In which case, signature is entirely being ignored, which I'm concerned about. Is there a way to resolve that? Happy to hear solutions. 23:34:53 ack mprorock 23:34:53 mprorock, you wanted to state that "making it illegal" is not what is being requested - what is being requested is to use a unique media type for something that has a proof 23:35:13 mprorock: No one is saying these are not valid use cases, we want a clear and valid media type 23:35:14 q+ 23:35:23 q+ to note "media type for vc" 23:35:37 ack dwaite 23:35:37 dwaite, you wanted to ellaborate on chained proofs and JWT guidance 23:35:39 mprorock: Wanting a media type that doesn't have an embedded proof in it, that's a valid use case as well. 23:37:28 dwaite: In the spec we talk about embedded proofs and external proofs, way to state the same thing... embedded proof is a way to extract proof and recanonicalize to create an external proof over the document. It comes down to giving recommendations --- if one proof is chaining, pointing into another, you cannot express outer proof w/o inner one, but you can strip off outer proof, so when people embed a data integrity protected VC inside a JWT, 23:37:28 they need to understand that they're requiring twice as much security processing logic... that may affect full stack decisions, or they could just discard the JWT and send credential and data integrity around and they need to decide if it's appropriate or not. If we do have it, we should have a SHOULD NOT with guidance. 23:37:32 ack dlongley 23:37:32 dlongley, you wanted to say accepting a credential that is "not supposed to be signed" is not a problem for many applications -- they will accept either, what's the media type that 23:37:35 ... supports that ... do people have to add if/else statements and complexity to work with this? 23:38:30 +1 23:38:45 sorry +1 dlongley 23:38:48 dlongley: There are going to be many applications that can accept a credential whther or not it has a proof attached to it, important that base media type supports that... if there are other applications that want to have a media type that specifically says "this property is not allowed in this media type" - I think we can do that, but I recommend against it, I don't think it's a good idea. I don't think we should call that out on the base media 23:38:48 type. Maybe have base media type to be superclass of other things, someone could create a media type for their other applications, can't have specific property. 23:39:13 dlongley: I don't think anyone would want to create 10 diffrent media types for data they don't want their applications to accept, media type isn't the right tool for that. 23:40:01 q+ to state that proof is a pretty special damn type of property, so presence of that proof along side other types of proofs is highly confusing at minimum 23:40:34 ack manu 23:40:34 manu, you wanted to note "media type for vc" 23:40:35 dlongley: "What if this verifier receives something where a signature has been stripped?" -- verifiers need to know what to expect from a holder. They will know what proofs they need to look for, they need to know which issuers to trust, how many signatures to expect, etc... we should remember that we're defining a base data model here, there are things that people don't necessarily process in a credential... base media type that's a super class 23:40:35 allows that to happen, I don't think there's a problem there. 23:40:37 interesting - i though in the open world model, any proof type can enter verifier's system 23:40:52 kristina: yes, but what they accept is up to them 23:41:17 manu: I think we need to look at the PR. The PR is specifically talking about the `application/credential+ld+json` and saying that it can't have `proof` in it. 23:41:20 present+ 23:41:35 q+ 23:41:53 manu: Mike, I think you're talking about something else, a media type for a verifiable credential and at this moment in time I agree with you. I definitely agree with JWTs there because it's a base64-encoded dotted string, not JSON. 23:41:54 q_ to ask MediaType: What Is It Good For? 23:42:05 manu: That's not true of the Data Integrity secured VCs though. 23:42:25 @dlongley if verifier only supports JWS it will not know it accepted DI proof signed as JWS, so they can't even make a decision whether to accept or not 23:42:30 manu: So I think the thing you mentioned is a different conversation and that I agree with you more over there, than on this PR. This PR says, we're going to single out this one property and makes it illegal. 23:42:44 TallTed q+ to ask MediaType: What Is It Good For? 23:42:47 q? 23:43:02 q+ to ask MediaType: What Is It Good For? 23:43:02 manu: David Waite's SHOULD NOT makes it a little closer, maybe we can do that, but lots people in the ecosystem might just ignore it. I think a lot of people will want to back into what Dave Longley is talking about and that the verifier is going to know what it's expecting. 23:43:08 q+ TallTed 23:43:31 manu: Otherwise you're allowing the attacker to choose the attack on your system. You can't trust the media type that the attacker is sending to you. You can't trust that the attack is peeling off a proof, etc. You have to know what you accept. 23:43:59 manu: You can't trust the incoming media type, the attacker gets to choose it, you can't trust that the thing has the right number of signatures on it, because you can't trust that as well. This goes back to David Waite's comment that the verifier gets to decide what the valid thing is. 23:44:08 +1 manu 23:44:11 manu: I think we're trying to use media types to signal things that we shouldn't rely on, it gives power to the attacker. 23:44:14 +1 manu 23:44:37 ack mprorock 23:44:37 mprorock, you wanted to state that proof is a pretty special damn type of property, so presence of that proof along side other types of proofs is highly confusing at minimum 23:44:47 kristina: if the verifier supports JWS then if the JWS proof verifies, they are happy, they don't have to care about the DI proof. 23:44:58 mprorock: I don't think anyone is disagreeing on the multiple layers on security checks, not trusting inputs, I would hope all of us in this group are familiar with those concepts. 23:45:59 dlongley: i don't agree.. not validating proof/signature is one of the biggest attack vectors (ignoring == not validating here). security analysis needed to say "they don't need to care" 23:46:43 dlongley: proof by the issuer has a very important meaning in VC ecosystem - verifier ignoring it undermines trust model of three party model 23:46:49 kristina: that's the two-party model :) ... verifier needs to know what they accept and what they don't 23:46:50 mprorock: What I'm concerned about is saying that something should not have a proof in any way shape or form, perhaps from a consensus standpoint we end up in SHOULD NOT. If we want to think about a variety of things, no one here wants a proliferation of media types for every options, No one is asking for a prolifration of business rules defined in the spec. If it is implicitly confusing that receives a proof in it, or embedded in a VC-JWT, what 23:46:50 proof type comes first. If we don't have a clear way of saying: "Don't do this, you're going to confuse the user"... it's highly concerning to me. If we leave it up to verifier, certain issuers are going to assume one type of security model might be required w/o clean mechaism to know that they're doing that. Let's try to get explicitly clear about what a credential is before it becomes a VC and then be very clear abou tthat as well. 23:46:53 ack tplooker 23:48:06 tplooker: I'm still catching up on this issue, so migth have perspective that's invalid -- my interpretation of text in PR doesn't insinuate that it makes embedded proofs illegal, media type doesn't establish any semantics around inclusion of property of what it means. If I sent application/json, and data is customer record, that is at a different layer semantically. Embedded proof might have something secured, media type isn't going to 23:48:06 communicate presence or processing logic to do anything w/ that. 23:48:07 +1 tplooker 23:48:09 ack TallTed 23:48:09 TallTed, you wanted to ask MediaType: What Is It Good For? and to 23:48:12 dlongley: nope, not two party model :) 23:48:52 +1 i think i agree with tplooker too, but also that it doesn't support the prohibition statement 23:48:52 TallTed: Media types don't do these things... media types don't say "in this structure of file you can only have X field name". Media types give you the structure of the file so you can deal w/ it's contents. If you feed a .zip archive to Excel, it's going to choke because it doesn't know how to deal w/ that content. 23:49:02 +1 to TallTed 23:49:28 q+ 23:49:52 TallTed: Vice versa, unzip cannot do anything for you with the contents of an excel file... it's not the structure of the document it works on, the structure is the thing that matters here. Subtypes in the mediatype universe are limited not in what fields they can have and the contents of what they could be... bigger type might allow larger number of rearrangements, smaller more focused might allow less. 23:49:55 +1 to TallTed 23:50:18 q+ 23:50:19 TallTed: Media types don't care about proofs, or business logic, or anything like that. Trying to make them do that job, we're going to break all sorts of security models. It don't work that way. 23:50:21 +1 to TallTed 23:50:56 TallTed: I've said in a number of times, a number of places, people don't seem to understand how media types work, if you don't understand how this stuff works, and we try to spec with it, we're going to break something. 23:50:56 ack tplooker 23:51:40 q+ to discuss extensibility and criticality 23:51:48 tplooker: Further the point that I'm making, don't think media type should rule out in an extensible data model technology whether or not the member of an element should /shouldn't make something illegal. I don't think media type should reach into the data representation technology and says "this should never exist". I think that messes w/ data extensibility model in JSON. 23:51:52 +1 to tplooker and TallTed, media type is the wrong tool for this 23:51:56 qq+ dwaite 23:52:32 tplooker: The media type doesn't convey that, media type doesn't tell you anything about what the media type tells you that... it could just be a string w/ some other meaning attached to it. That's all I take the language to mean in this PR. It doesn't communicate anything about the presence of an embedded proof or not. 23:52:36 ack dwaite 23:52:36 dwaite, you wanted to react to tplooker 23:52:39 manu: +1 to tplooker, Tallted. 23:53:17 dwaite: One of the ongoing concerns, we're trying to define an extensible data model to use it in ways that we haven't imagined... even extension points we have, like termsOfUse, if there are extensions that you don't understand, what are you supposed to do as a holder or verifier when you see those? 23:53:32 q+ to ask if "If this media type is used any embedded proof must be ignored by the processor." would work? 23:54:00 dwaite: In Holder Binding, one of the big concerns is if I have an outer proof of VC-JWT, and I have an inner data integrity proof of the same object/document, what does that mean, what does it imply in terms of issuer instructions of understanding that? 23:54:39 ack dwaite 23:54:39 dwaite, you wanted to discuss extensibility and criticality 23:54:48 q- 23:54:49 q+ 23:54:52 zakim, close the queue 23:54:52 ok, brent, the speaker queue is closed 23:54:55 dwaite: To manu's point, you have to define what sort of verification is expected that issuer expects you to do for verifier to trust that information hasn't been modified. So chained proofs, if that's there, with external proofs and chained proofs, we really need to define behaviour of all of those extension points so people know how to act even if they don't understand what that extension is. 23:55:02 ack mprorock 23:55:02 mprorock, you wanted to ask if "If this media type is used any embedded proof must be ignored by the processor." would work? 23:55:31 can't force that business rule on the verifier 23:55:35 mprorock: Is there an approach that might work? If media type is used, embedded proof must be ignored by processor by verifier? This is a reasonably complex thing we're trying to say. 23:55:41 ack kristina 23:56:38 kristina: I think we double clicked on statements meant by tobias and tallted -- JWT registered application/jwt -- in header, but you can also use application/jwt in HTTP response to indicate that's the thing being returned... I thought we dug into that at F2F? That seems to be misaligned as well. 23:56:46 kristina: maybe we can discuss thing from Mike Prorock 23:56:52 -1 to telling verifiers that the *have* to ignore a proof 23:56:58 brent: Jump on PR and try to refine some language. 23:57:08 dlongley: that's more violation of the three party model, IMO 23:57:10 brent: See everyone on the call tomorrow. 23:57:23 rrsagent, draft minutes 23:57:24 I have made the request to generate https://www.w3.org/2023/02/28-vcwg-special-minutes.html manu 23:58:00 present+ Paul_Dietrich_GS1 23:58:13 present+ kristina 23:58:25 present+ TallTed 23:58:28 present+ ToddSnyder 23:58:32 present+ tplooker 23:58:42 rrsagent, draft minutes 23:58:43 I have made the request to generate https://www.w3.org/2023/02/28-vcwg-special-minutes.html manu 05:24:44 Zakim has left #vcwg-special