21:55:25 RRSAgent has joined #vcwg-special 21:55:29 logging to https://www.w3.org/2023/03/14-vcwg-special-irc 21:59:01 Aisp has joined #vcwg-special 21:59:16 Aisp_ has joined #vcwg-special 22:00:16 zakim, start the meeting 22:00:16 RRSAgent, make logs Public 22:00:18 please title this meeting ("meeting: ..."), brent 22:00:31 meeting: VCWG Special Topic Call 22:00:31 TallTed has joined #vcwg-special 22:00:38 chair: Brent Zundel 22:00:43 present+ 22:00:55 present+ 22:01:00 Kerri_Lemoie has joined #vcwg-special 22:01:05 present+ 22:02:23 present+ 22:02:23 kristina has joined #vcwg-special 22:02:32 present+ 22:02:51 scribe+ 22:03:15 present+ 22:03:16 brent: We are going to talk PRs today - wondering how we can also talk about VC specifications directory. 22:03:26 Phil-ASU has joined #vcwg-special 22:03:26 Orie has joined #vcwg-special 22:03:37 brent: Talking about wanting to expand the scope as it's initially been defined, want to hear feedback on that. 22:03:46 q+ to request that we tackle media types first. 22:03:48 decentralgabe has joined #vcwg-special 22:03:52 present+ 22:03:53 present+ 22:03:57 ack manu 22:03:57 manu, you wanted to request that we tackle media types first. 22:03:59 scribe+ 22:04:05 selfissued has joined #vcwg-special 22:04:21 q+ 22:04:23 manu: Could we tackle the PRs about media type first? And I ask because there are about five PRs we could potentially resolve if we get to a conclusion there and we are maybe close. 22:04:28 present+ 22:04:29 ack TallTed 22:04:45 TallTed: I'm hesitant to go along w/ special topic on the special topic call -- might have shown up if another topic is discussed. 22:04:54 brent: With those comments, let's stick w/ PRs 22:05:00 q+ to provide some background on media types. 22:05:10 ack manu 22:05:10 manu, you wanted to provide some background on media types. 22:05:13 s| w/ special| w/ changing special| 22:05:20 manu: I'm wondering -- So I've got a proposal for the group and wanting to see if we can get to consensus... seeking feedback on it. 22:05:33 manu: We have been talking about ... we have decided that there will be one base media type for the VC data model. That's super good and useful. 22:05:34 present+ 22:06:31 manu: Then, we started talking about ... that was `application/credential+ld+json` as the base media type, unsecured, our base media type. Then we have a number of media types around `application/vc+something` for secured things but there has been disagreement around the requirement of `proof` and we were trying to figure out how to do that through media types. We now have a section in the spec for the media types. 22:07:12 manu: Then Orie raised a really good question -- about how these two media types `application/credential+ld+json` and `application/vc+ld+json` ... people are arguing that `proof` is optional in both and we have two media types that describe the same thing. Skipping past a lot of the back and forth. 22:07:38 manu: I wonder if we can make the base media type `application/vc+ld+json` and `proof` is optional in that. Then in the media types section we make internal/external proofs clear and so on. 22:07:40 q+ 22:07:41 q+ 22:08:05 q+ 22:08:09 ack TallTed 22:08:10 manu: The proposal would be for the base media type to be `application/vc+ld+json`, `proof` is optional, but we don't say that in the media type registration but in the spec. What do people think? 22:08:15 TallTed: Yes, in general theory, I'm with you. 22:08:32 shawnb has joined #vcwg-special 22:08:37 TallTed: The media type for a zip archive doesn't change whether it's password protected, or one or a hundred files, or anything, really. You deal with it as a zip archive. 22:08:38 +1 to TallTed 22:09:01 TallTed: In our case, we are dealing w/ credentials which are verifiable, and the failure could be that proof is missing, or proof fails (but you messed up the crypto), or something along those lines. 22:09:27 q+ to say the explicit difference 22:09:28 TallTed: It's taken a while to reach that point as a group, we might be a step away where we out to be. That might just be ld+json. I want there to be an explicit difference between vc+ld+json and ld+json 22:09:46 TallTed: There has to be something that a ld+json loses when it doesn't process as vc+ld+json. 22:09:51 ack kristina 22:10:53 kristina: I'm not with you yet, Manu. The proposal I think I made in previous call was well received -- can we completely remove proof property from VC Data Model so only media type in main becomes credential+ld+json, so we don't talk about proof property. Then vc+jwt and data integrity can define their own media types vc+??? if needed, is that an option, is that on the table still? 22:10:57 ack selfissued 22:11:04 selfissued: I'm going to try to react to all three comments. 22:11:06 q+ to talk about the presence of the proof property and its term definition https://w3id.org/security#proof 22:11:08 q+ to say we'll just be back where we are today with kristina's suggestion... with `application/credential+ld+json` with an optional proof 22:11:32 selfissued: I agree with Manu that defacto, the WG hasn't been able to, for JSON-LD data model, been able to make any distinctions between credential and verifiable credential in the media type. 22:12:03 selfissued: The attempts to say that proof must not be present for credential+ld+json have not succeeded, and in order to make progress, I'm willing to see single VC data model be application/vc+ld+json. 22:12:36 selfissued: To Ted's comment, I agree that there is and should be a meaningful distinction between ld+json and vc+ld+json, the difference is the required members of VC data model are present and are used in ways specified. 22:12:42 manu: Yes, MikeJ, exactly! 22:12:48 selfissued: I think we can agree to that. 22:13:30 selfissued: I agree with you that proof property should be moved into securing spec, that's what defines its properties, I don't think that Kristina's comment blocks us from registering the media type, and from brent's earlier comments, if we can unblock the media type registrations, we'll be a good bit further forward today. 22:13:36 ack dlongley 22:13:36 dlongley, you wanted to say the explicit difference and to say we'll just be back where we are today with kristina's suggestion... with `application/credential+ld+json` with an 22:13:39 ... optional proof 22:14:07 +1 to compact form being a constraint. 22:14:15 dlongley: I got on queue to agree w/ MikeJ -- the constraints are the data model -- and compact form must be used... any one of those things establishes a specific new contraint, that's the difference. 22:14:40 q+ 22:15:01 q+ to ask what then prevents a cascade of {abc,xyz,lmnop,mnahmnah}+ld+json media types that each have their own set of required members that must be present and used in ways specified? 22:15:06 dlongley: with respect to Kristina's comment -- if we move proof back into another spec, doesn't resolve particular matter at hand, proof being optional, we'd end up in that situation, those issues are orthogonal. That's a different question from what we're trying to resolve here. We want the base media type to be application/vc+ld+json as everyone else has spoken to. 22:15:07 ack Orie 22:15:07 Orie, you wanted to talk about the presence of the proof property and its term definition https://w3id.org/security#proof 22:15:33 +1 that moving the proof to data integrity is a different question and not the one that we're talking about here. 22:15:48 Orie: I agree with the comments from Manu and Mike Jones about application/vc+ld+json media type. I also am not sure that proof predicate should be removed from core data model context. I want to talk about what's in v1.1 spec, if we can't achieve consensus to change it, it's goin gto stay the same. 22:17:16 Orie: In v1.1, proof is a predicate that exists. There is no definition of Credential (in RDF sense), only Verifiable Credential. The proof types are the RDF classes that the securing formats tended to define. A proof type example would be Ed25519Signature2018. In v1.1 we shipped proof property in core context. In v2.0, we cleaned some stuff up and avoided having to talk about types. If we say base media type is application/vc+ld+json, we commit 22:17:16 ourselves to have conversations about proof being in media type. 22:17:49 Orie: It would be good to get agreement on the base media type on what we see in v1.1, there is a higher chance of doing that with application/vc+ld+json, vs coming to consensus on what application/credential+ld+json. 22:17:50 ack kristina 22:18:38 q+ to say that that separation may not be via syntax 22:18:46 kristina: If you are talking about media type for v1.1, vc+ld+json might be ok, but to use that for v2.0, I'd be against that. To v2.0 is to separate payload from how it's being secured. Saying the base media type is "vc+" -- what is the verifiable part of that payload if that's the base media type? 22:19:07 q+ to say that that separation may not be via *incompatible* syntax 22:19:35 kristina: Does that mean now we'd only have one media type per signed credential that has to express both what is a payload and what is signed? To be more specific, one example I can think of, in SD-JWT, with current separateion of application/credential+ld+json -- use that as a payload, use SD-JWT to secure it. 22:20:04 kristina: when you're signing, apply digest as defined in SD-JWT and you're good to go. I don't know what that means when we say application/vc+ld+json. 22:20:11 ack TallTed 22:20:11 TallTed, you wanted to ask what then prevents a cascade of {abc,xyz,lmnop,mnahmnah}+ld+json media types that each have their own set of required members that must be present and 22:20:14 ... used in ways specified? 22:20:49 q+ 22:21:04 TallTed: First, assuming we continue down this road, how are we going to convince IANA that there will not be a cascade of special definitions of ABC/xyz+ld+json each with their own set of members and usages? I don't have a concrete differentiator, we could say "you have to have these members in order to be a VC". 22:21:28 partial answer to Ted's question, IANA expects registration for types that use registered suffixes... That is why we define structured suffixes. 22:22:26 TallTed: Consider RFC822 messages and attachments, where media types came from, there is an envelope and a payload and metadata, these things are separate, signature on signed mail, on unsigned main no signature, not mentioned... these are things that didn't require new media types, media types for those things existed in other usages, those media types are applied in enclosures... we're using media types in a way that's not intended to be used, 22:22:26 it'll bite us if it's not already doing so. 22:22:27 ack dlongley 22:22:27 dlongley, you wanted to say that that separation may not be via syntax and to say that that separation may not be via *incompatible* syntax 22:23:22 My response to Ted will reference https://www.rfc-editor.org/rfc/rfc8725.html#use-typ 22:23:33 dlongley: I wanted to respond to Kristina, differentiating between credentials and verifiable crednetials -- to a certain extend, we've made a number of things more complicated than before in ways we didn't get more value out of that complication. The difference might not come through an incomatible syntax... data integrity adds proof, which adds types to a proof property... that fits in w/ existing data model. That other syntaxes might have 22:23:33 incompatible syntax, but when that happens, you need a new media type. I think all that's ok. 22:23:43 dlongley: I think Mike's on the queue to respond to what Ted said, I'll end my comments there. 22:23:44 ack selfissued 22:23:57 i was also going to say ... i don't think SD-JWT will have to change. 22:24:54 selfissued: I did want to respond to TallTed's comment... hwo are we going to convince IANA to say there's not going to be a multiplication of mediatypes *+ld+json, by analogy, there was an RFC written 8725 -- JWT best practices, and one of the best practices listed was "Use an explicit media type for every type of JWT object" -- explicit typing and that can prevent a confusion for one type of JWT for another. That's part of a more general move 22:24:54 in security community. 22:25:23 +1 selfissued 22:25:35 selfissued: "Use explicit typing" to prevent confusion, not a bug that there might be a multiplication of JSON-LD subtypes, it's a feature, because it enables explicit typing. Using vc+ld+json is an example for explicit typing, that's a good thing. 22:26:23 brent: Initial round was prompted by a proposal, folks spoke up for certain aspects, resolve the media type aspects first then continue conversation where it needs to go. 22:26:23 q+ 22:26:39 q- 22:26:47 brent: How would we need to change that proposal to move forward? 22:26:52 q+ to say keep proof where it is right now -- that can come up later if people want to move it 22:26:59 ack dlongley 22:26:59 dlongley, you wanted to say keep proof where it is right now -- that can come up later if people want to move it 22:27:16 dlongley: This might be a slight tweak, keep proof where it is right now and figure out if we move it later. 22:27:16 +1 dlongley 22:27:28 q+ 22:27:34 ack kristina 22:27:42 kristina: I still haven't heard an answer 22:27:47 q+ to provide some thoughts. 22:27:50 q+ 22:27:53 q- 22:28:00 ack manu 22:28:04 ack Orie 22:28:09 kristina: How do we know if it's signe dor not? 22:29:29 +1 to Orie 22:29:43 Orie: In case signing is used -- proof is used, RDF says the type... if external is used, then proof isn't there or is ignored and external signign mechanism applies information necessary for signature. So, for JWT, alg secures content type for application/vc+ld+json -- and if you look at that content type, youg et back JSON, verify signature in external proof case. If you see proof in data model, and you don't understand it, you ignore it. 22:30:46 Orie: People might profile away proof property, but there are scenarios where they want it to be present and might want to tunnel secured data in proof. and add external proof format. Short answer is in case of external proof, you're going to verify the external proof and then you get payload... if payload contains internal proof, you might ignore it, or if you do understand it, you verify according to proof type. 22:30:49 +1 to Orie 22:31:01 q? 22:31:04 =1 22:31:12 JoeAndrieu has joined #vcwg-special 22:31:30 For the record, I don't really care to "block" the "credential tunneling" feature. 22:31:32 +1 22:31:58 kristina: Thanks Orie, that makes sense, I think. I'll be ok given that is clearly stated in VCDM. I don't know what concrete proposal language should be, someone could point me to that? I think what I heard was base media type says this is a signed credential using JSON-LD and how to determine how it's signed is specific to signign mechanism, which is fine. 22:32:14 kristina: Make sure that's loud and clear, you have to depend on checking mechanism. 22:32:15 And the current "proof" section essentially says this already.... it says "at least one, proof format"... https://w3c.github.io/vc-data-model/#proofs-signatures 22:32:20 +1 to kristina to provide clear guidance 22:32:37 kristina: For VC-JWT, for example, other specifications can define their content type, credential is signed ... if my understanding is correct, I'm ok w/ direction. 22:33:41 Brent deftly composes a proposal, much like Beethoven writes a symphony. 22:34:51 q+ 22:35:07 ack Orie 22:35:30 Orie: media type vc+ld+json might have external proof, you won't see evidence in internal content type, because external proof is external. 22:36:06 Orie: You could have internal proof, and that would say you have an internal proof. I would avoid trying to smith proof related changes into resolution. We will have to address proof related issues as a group, don't see need to add more language to this particular proposal. 22:36:25 brent: Kristina, are you ok w/ moving forward noting that we need to have proof conversation separately? 22:36:36 q+ to try to restate it 22:36:48 Kristina makes noises of disapproval. 22:36:56 brent: Or we could add... 22:37:06 kristina: The media type does not dictate how credential is signed? 22:37:06 +1 to Kristina 22:37:08 q+ 22:37:15 +1 to the "media type does not dictate how the credential is signed" 22:37:16 +1 Kristina 22:37:18 +1 22:37:34 that is what I was trying to say regarding the current proof section of the spec 22:37:37 q- 22:38:08 q? 22:38:38 dlongley: we should say "to use as the base media type" 22:38:38 +1 to Dave's suggestion 22:38:51 PROPOSAL: We will change credential+ld+json to vc+ld+json to use as the media type for verifiable credentials and add language to the spec that indicates the media type does not signal how the VC has been signed. 22:38:57 +1 22:39:02 +1 22:39:02 +1 22:39:03 +1 22:39:05 +1 22:39:06 +1 22:39:08 +1 22:39:08 +1 22:39:09 +1 22:39:09 +1 `application/` prefix is presumed :) 22:39:12 manu: +1 22:39:16 0 22:39:19 dlongley: +1 22:39:32 +1 with application/ :-) 22:39:51 brent: This will go out for review before it's officially resolved. 22:40:02 RESOLUTION: We will change application/credential+ld+json to application/vc+ld+json to use as the media type for verifiable credentials and add language to the spec that indicates the media type does not signal how the VC has been signed. 22:40:05 brent: I'm going to add application/ to be clear that that's what we resolved 22:40:17 q+ 22:40:20 q- 22:40:27 ack dlongley 22:40:29 ack manu 22:40:38 q+ 22:40:39 manu: With that, I think we can merge Orie's 1034 PR. 22:40:57 manu: We may / want to modify that PR to just remove the `application/credential+ld+json` to make it clear there's just one base media type. 22:41:13 manu: We should do that and that will be 1034. Then 1050 can refer to `application/vc+ld+json` and we can pull in 1050. 22:41:24 manu: 1014 I believe gets addressed by this. 22:41:35 manu: We're going very far towards resolving it at least. 22:41:53 manu: That's three PRs that are knocked down and we can talk about PR #1032 next. It might be easier to address now. 22:42:00 ack Orie 22:43:11 Orie: We had previously merged the section that allowed us to talk about media types. I'd prefer to close PRs that I have opened that I authored and to make a single PR that implements the resolution that we took today. We can open other PRs to media types section. That's what I prefer to go forward. I don't want to retain all the arguments that are no longer relevant. 22:43:32 Orie: I'd like to open new PRs to address content in PRs I opened. 22:44:02 +1 to Orie closing his pull requests 22:44:06 Orie: The same thing would go for presentations, we'd have the same conversation on vp+ld+json, I'd rather have that conversation on an issue. Manu you mentioned that PR 1032 -- either we continue to discuss, or we can move to issue to discuss. 22:44:53 brent: To be clear, what's being suggested is closing 1014, and 1034, in favor of new PR that captures resolution we just made. Other PRs might be open for other language related to media type to be placed in the media types section. 22:45:19 brent: https://github.com/w3c/vc-data-model/pull/1030 22:45:20 q+ 22:45:25 subtopic: https://github.com/w3c/vc-data-model/pull/1030 22:45:30 ack manu 22:45:36 manu: I think we're ready to merge this. 22:45:50 manu: There are some changes that Kristina and Ted have suggested, but I think those are good to go unless someone here objects. 22:46:16 +1 to merge with whatever editorial fixes 22:46:31 brent: ok, I'll apply language and merge. 22:46:50 subtopic: https://github.com/w3c/vc-data-model/pull/1050 22:47:08 manu: This one, PR 1050, was just waiting on what we decided today. I'm not worried about this PR. 22:47:14 manu: We can merge this based on our conversation today. 22:47:27 subtopic: https://github.com/w3c/vc-data-model/pull/1051 22:47:43 manu: This one ... people gave comments on the PR and in issues and in my email inbox... I have to reconcile all that first. 22:47:47 manu: For PR 1051. 22:48:01 manu: I'll deal with all the various inputs. 22:48:16 subtopic: https://github.com/w3c/vc-data-model/pull/1057 22:48:18 q+ 22:48:26 ack Orie 22:48:52 Orie: This issue 1057 is a tarpit, it probably won't go anywhere, I don't think we will succeed in adding RDF language of Credential as a class. 22:49:02 q+ 22:49:06 ack dlongley 22:49:07 brent: If folks want to jump on the queue, please do so. 22:49:56 dlongley: I'm more optimistic, given decision, some of the things we were pushing to create explicit separations, vs. conceptual differences that we discuss in spec. If we tlak about these things in spec, instead of making them explicity in RDF vocabularies, thre is a good amount of support for that approach. 22:50:08 dlongley: Which would mean, we don't need to add these additional things to RDF Vocabulary. 22:50:12 q+ 22:50:15 subtopic: https://github.com/w3c/vc-data-model/pull/1062 22:50:17 q- 22:50:41 manu: This can be merged, I just haven't done it. 22:50:47 +1 to merging, after the call 22:50:54 for ivan's notes thing... 22:51:10 q+ 22:51:28 ack manu 22:51:40 manu: I'm concerned that we may be talking past each other. Just to clarify, you mean change the media type to the new one. 22:51:43 manu: And then we're good to go? 22:51:49 JoeAndrieu: Yes, that's what I meant. 22:51:58 manu: Kristina, are you talking about stop talking about "credentials" in the spec? 22:52:22 kristina: There's a sentence in there that needs clarification. 22:52:29 s/in the spec/in the media types 22:52:35 q+ we do not make a clear distinction. 22:52:37 manu: In the spec we make a clear distinction, conceptually between credentials and verifiable credentials. 22:52:40 q+ to say we do not make a clear distinction. 22:52:50 manu: In theory, we're careful in the spec where we are careful with that -- but sometimes we're using the wrong term in the spec. 22:53:06 manu: We need to go through the spec and clean that up and make it clear where we are talking about a credential vs. a verifiable credential. 22:53:23 manu: Other people are suggesting that we should stop talking about credentials entirely and we should only talk about verifiable credentials and that's where things get problematic. 22:53:29 q+ 22:54:07 manu: The other issue is that some people have taken issue with the definitions for the two terms and are calling it vague. And talking about those things in terms of securing mechanisms is a new thing in 2.0. There may need to be clarity in terminology definitions. I'm wary, until then, when people say "this should be a credential vs. a verifiable credential". 22:54:14 ack Orie 22:54:14 Orie, you wanted to say we do not make a clear distinction. 22:54:20 manu: I think we need to get to a point where people are happy with the definitions and distinctions and then clean it all up. 22:54:58 ack kristina 22:55:06 Orie: Mostly agree w/ Manu -- described the challenges in front of us... people are very confused by text in current spec, and we have to do better in some of the ways Manu said and further discussion on utility of word "credential" is in order. We should improve language around them that there is a meaningful distinction, if there is one, and I remain dubious about it. 22:55:29 kristina: I was reacting to text in PR, editorial PR, happy to open an issue... there is text that says "if you use crednetial vs. verifiable crednetial" -- what each of them mean. 22:56:00 kristina: Same philosophy applies to signed thing, we should be consistent, I'll make a comment to that effect. 22:56:06 +1 kristina 22:56:17 brent: Thanks kristina, thanks everyone, pleasure working with you all, see you all tomorrow! 22:56:20 rrsagent, draft minutes 22:56:21 I have made the request to generate https://www.w3.org/2023/03/14-vcwg-special-minutes.html manu 22:56:28 zakim, who is here? 22:56:28 Present: brent, shigeya_, Kerri_Lemoie, dlongley, kristina, TallTed, decentralgabe, Phil-ASU, selfissued, dlehn 22:56:28 On IRC I see JoeAndrieu, shawnb, selfissued, Orie, Phil-ASU, kristina, Kerri_Lemoie, TallTed, Aisp, RRSAgent, Zakim, brent, dlehn, shigeya_, manu, csarven, dlongley, stenr 22:56:29 rrsagent, make minutes public 22:56:29 I'm logging. I don't understand 'make minutes public', manu. Try /msg RRSAgent help 22:56:44 present+ JoeAndrieu 22:57:21 zakim, end the meeting 22:57:21 As of this point the attendees have been brent, shigeya_, Kerri_Lemoie, dlongley, kristina, TallTed, decentralgabe, Phil-ASU, selfissued, dlehn, JoeAndrieu 22:57:24 RRSAgent, please draft minutes 22:57:26 I have made the request to generate https://www.w3.org/2023/03/14-vcwg-special-minutes.html Zakim 22:57:32 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 22:57:32 Zakim has left #vcwg-special 22:57:35 rrsagent, bye 22:57:35 I see no action items