15:48:48 RRSAgent has joined #vcwg-special 15:48:53 logging to https://www.w3.org/2023/03/07-vcwg-special-irc 15:48:53 RRSAgent, make logs Public 15:48:54 please title this meeting ("meeting: ..."), ivan 15:49:24 Meeting: Verifiable Credentials Working Group Special Topic Call 15:49:24 Date: 2023-03-07 15:49:24 chair: kristina 15:49:24 Agenda: https://www.w3.org/events/meetings/e88d30bd-4099-49d1-b769-1d8cd39a1b28/20230307T110000 15:49:24 ivan has changed the topic to: Meeting Agenda 2023-03-07: https://www.w3.org/events/meetings/e88d30bd-4099-49d1-b769-1d8cd39a1b28/20230307T110000 15:50:05 brentz has joined #vcwg-special 15:54:51 present+ 16:00:53 present+ 16:00:55 present+ brent 16:01:05 dwaite has joined #vcwg-special 16:01:08 present+ 16:01:13 present+ dwaite 16:02:00 present+ manu 16:02:18 present+ samsmith 16:02:40 TallTed has joined #vcwg-special 16:02:53 manu has joined #vcwg-special 16:02:54 dmitriz has joined #vcwg-special 16:02:56 present+ yanzhang 16:03:04 present+ orie 16:03:04 present+ 16:03:13 present+ tallted 16:03:37 chair: brent 16:03:41 cabernet has joined #vcwg-special 16:03:44 present+ 16:04:14 Kerri_Lemoie has joined #vcwg-special 16:04:18 present+ kerri 16:04:18 present+ 16:04:24 scribe+ 16:04:55 brentz: Agenda is straightforward, we'll be covering as many PRs as we can. Goal is to identify what changes need to be made in order to merge the PR. 16:05:08 present+ 16:05:20 brentz: If the PR has been around long enough we can consider merging it on the call but I don't expect that. Identifying what needs to change to move things forward is the goal. We'll start with the VCDM. 16:05:28 present+ 16:05:42 present+ JoeAndrieu 16:05:43 q+ 16:05:53 brentz: Starting with PR #1056. 16:05:59 present+ davidc 16:06:00 I believe Mike has a conflict today 16:06:02 subtopic: https://github.com/w3c/vc-data-model/pull/1056 16:06:09 ack manu 16:06:21 will has joined #vcwg-special 16:06:26 present+ 16:06:38 Orie has joined #vcwg-special 16:06:38 present+ 16:06:52 manu: So this is an editorial fix to the spec. A number of people have been asking us to separate the definitions of Verifiable Credential and Credential into different entries. It has multiple reviews, it didn't change any content, it's been out there for a week, I think we can merge this with no objections. 16:07:08 brentz: I take back not merging anything today, this one is ready. Nothing but approvals, been out for a week, editorial. 16:07:14 q+ 16:07:34 brentz: Are there any objections to merging this PR? This PR is just taking existing definitions and breaking them into two, no new language, just shifting. 16:07:55 ack ivan 16:08:02 ivan: A minor thing, Manu can you wait about an hour to merge -- because my scripts go mad when I try to get content from a PR that has been closed. That's all. 16:08:18 brentz: Not hearing any objections. 16:08:49 DavidC: One of the things that came up with myself and TallTed, but a Verifiable Credential is not necessarily Verifiable because the verification could fail for all kinds of reasons, only one good path and hundreds to fail. 16:08:56 brentz: You're talking about a different PR. 16:08:58 present+ smccown 16:09:05 q+ to suggest an issue for this. 16:09:12 smccown has joined #vcwg-special 16:09:15 DavidC: Yes, but we should change the "can" to MAY on verifiable. 16:09:16 q- 16:09:22 brentz: This isn't normative, this is an editorial PR. 16:09:28 +1 brent 16:09:31 brentz: We aren't adding normative language to this PR. 16:09:52 present+ PhilLong 16:09:53 TallTed: I hear the concern, there might be some further text massaging. 16:09:54 +1 Brent 16:10:02 TallTed: That verification may fail. 16:10:15 brentz: That's a great suggestion for another PR. I don't want to open that can of worms on this PR. 16:10:23 DavidC: Ok, we can do subsequent PRs for that change. 16:10:24 Phil_ASU has joined #vcwg-special 16:10:28 brentz: Yes, very much encouraged. 16:10:33 present+ 16:10:41 subtopic: https://github.com/w3c/vc-data-model/pull/1055 16:10:42 brentz: I don't hear merging on this PR, when Ivan's script is ready we can merge it. 16:10:52 q+ 16:11:15 DavidC has joined #vcwg-special 16:11:18 brentz: In PR #1055, it adds a section describing the use of media types. There's some conversation, a little back and forth, but in general, this adds some normative guidance around media types in generla. 16:11:22 present+ 16:11:22 s/generla/general/ 16:11:22 q+ 16:11:32 ack manu 16:11:34 brentz: I encourage people to get on the queue to say what needs to be changed in this PR to move it forward. 16:12:18 manu: Generally supportive of this PR. One of the good things it does, before we were making normative statements in the IANA registration section, that was dicey and this is better. This just talks in general of what's expected of certain media types. I think we can more easily put normative statements in here and there are some arguments around what's testable or not. 16:12:55 ack Orie 16:12:56 manu: I'm +1 on merging the PR because they aren't just doing MUST do this or that. In general +1 for what this PR is doing which is moving normative language from the media type registrations to the core of the document which allows us to speak more freely about expectations in using media types. 16:13:21 JoeAndrieu has joined #vcwg-special 16:13:25 JoeAndrieu has left #vcwg-special 16:13:27 Orie: I'm supportive of merging the PR. I'm several others that I'm the author of that I would close and I would move content from them into a new section or open new PRs to do that. Merging this will unblock several PRs that are currently blocked in my opinion. 16:13:47 brentz: I will note that this PR has been open for a week. I will note that there is one request for changes from TallTed, I believe those changes have been made. 16:13:55 brentz: Ted, could you speak to that? 16:14:20 TallTed: I don't think there's anything remaining, this PR makes substantial improvements from what was there before and even if I need to make a new PR to adjust, I'm good. 16:14:43 present+ bengo 16:14:48 Joe: How is this related to the single base media type? The language I'm reading doesn't clarify that one of those two is the base media type and one of those should be transformable into the base. 16:14:48 q+ 16:14:57 ack Orie 16:14:59 Joe: I'm concerned we're losing some of what we talked about in Miami. 16:15:30 JoeAndrieu has joined #vcwg-special 16:15:37 present+ 16:15:45 Orie: I don't think this PR addresses what happened at the F2F in Miami, but it opens the door for it. It does mention the base media type by name. I think there are so many other PRs open about this topic of media types that I think it would be better to merge this PR and open a new one that's dedicated to summarizing the outcome from the F2F. 16:16:03 Orie: I am supportive of getting text of what we discussed in Miami, but subsequent to merging this. 16:16:39 q+ 16:16:39 +1 Brent 16:16:39 present+ oliver 16:16:41 oliver has joined #vcwg-special 16:16:41 brentz: This PR creates a media type section, it moves some text from IANA registrations into this section and seeks to begin the normative guidance for use of media types. I think Mike Prorock did a pretty good job of avoiding normative statements -- setting the stage for those without making them so much yet. 16:16:43 present+ 16:16:45 brentz: From my perspective. 16:16:45 q+ 16:16:54 ack TallTed 16:17:38 TallTed: Yeah, I just want to voice that I've typed a few times now. There was and there often is a substantial push to "make decisions" at a F2F, because theoretically having people in the room means better decisions. I disagree with that that is always the case and I think blind adherence to those sessions can be to the detriment of the spec and all of us. 16:18:03 TallTed: I do think we resolved to a base media type and it was X, but we shouldn't necessarily be bound to that forever, we may hit things that indicate that was the wrong decision and we need to be able to revise it. 16:18:09 Q+ 16:18:27 ack JoeAndrieu 16:18:28 TallTed: I think all decisions in all calls -- are not final, I forget the right wording there, until a week later. The idea is the same with F2F. 16:18:59 q+ 16:19:03 ack Phil_ASU 16:19:05 JoeAndrieu: Politely, I want to push back on that. I think we need to make decisions and move forward. I think as a group we have the base media type `application/credential+ld+json`. I don't think this other media type is something we agreed to -- because of this date we haven't agreed to it. 16:19:54 +1 to adding media types as we get consensus on what they would be and mean 16:20:08 Phil_ASU: The way I heard TallTed talking about the issue was relevant to a comment he made in the PR a few days ago. He reminded us that media types aren't actively prescriptive or restrictive. I think adding a media type doesn't preclude us from adding or removing another one later. I think this is better as it moves the text from the IANA registration to the spec. And I think, as Orie said, this frees up more PR work to move forward. 16:20:15 ack manu 16:20:21 I like Joe's suggestion, if there are no objections to it, I would like to see it merged. 16:20:21 Phil_ASU: As long as we're clear that we can add/remove/change media types, this is a good step forward. 16:20:36 +1 Manu 16:20:52 manu: I think Joe's correct, I think it's totally appropriate to just list the one we decided on in the WG call and we're just having the second media type discussion shortly. 16:21:10 brentz: Ok, we wouldn't pull it in now, I think it's appropriate for MikeP to see Joe's comments on the PR. 16:21:20 brentz: Anyone else objecting to merging this PR with Joe's change? 16:21:28 No objections to Joe's change from here 16:21:31 Yan_ has joined #vcwg-special 16:21:46 brentz: I'm not hearing any objections to merging the PR with Joe's change. 16:22:04 subtopic: https://github.com/w3c/vc-data-model/pull/1034 16:22:23 q+ 16:22:29 q+ 16:22:36 q- later 16:22:37 brentz: This PR proposes `application/verifiable-credential+ld+json` as a new media type. This PR is older than MikeP's. 16:22:45 present+ shawnb 16:22:54 ack Orie 16:22:57 brentz: I want to get Orie to talk about this PR and what the set of proposed changes is and we can go to the queue to see what changes are needed to make this acceptable. 16:23:11 Yan__ has joined #vcwg-special 16:23:22 Orie: This PR, 1034, is just a request to register a media type. It doesn't describe normative constraints on the media type, it just says, "Hey, IANA, when our doc is complete we request this". 16:24:09 q+ to say we should define it before we commit to the term 16:24:31 Orie: It's also related to RDF classes like Credential types, there's other stuff out there. I agree with Manu's suggestion to shorten the media type, I'd like to merge those. I think this also opens the door for us to use this as the base media type instead of the one we agreed to at the F2F. What is the base media type -- is it `application/credential+ld+json` or `application/vc+ld+json`? 16:24:40 Orie: This PR just gives us a named media type to refer to when we're arguing. 16:24:42 Orie: That's it. 16:25:30 +1 Manu 16:25:40 manu: I'm in favor of pulling this in with the modification I suggested, even without it I'm supportive. I spoke out against this PR in the beginning, but I'm ok with now primarily because it feels to me that the group can get to agreement on what is required/not required for a VC and getting to agreement on just `application/credential+ld+json` has been illusive thus far. 16:25:57 manu: I think if we make `application/vc+ld+json` as the base media type I think we can all agree that this thing can be secured in general, maybe not all the time. 16:26:14 q+ 16:26:18 manu: This PR takes out all the normative language as well, so this just says there's a media type and there's less to object to. 16:26:27 ack manu 16:26:37 This PR never had normative language, it was always just a way to give a name to a concept we have discussed in other issues / PRs. 16:26:44 manu: This PR doesn't get into the controversy. To summarize, if we can only get to one media type in the data model this one will be easier, I think. 16:27:13 brentz: I want to note that these PRs have been well structured to do small simple changes to move us in a general direction. It doesn't say what this thing is, it doesn't say what it is. 16:27:28 brent has joined #vcwg-special 16:27:34 q? 16:27:38 ack JoeAndrieu 16:27:38 JoeAndrieu, you wanted to say we should define it before we commit to the term 16:27:53 JoeAndrieu: Yeah, I think this is a not well-thought through PR. I think we need to know what we're naming before we settle on the name. There is a possibility that this media type might become the base media type. That's a totally different conversation from one that will transform to the base one. 16:28:14 q+ to suggest a definition for this media type. 16:28:16 q 16:28:23 +1 to Joe 16:28:28 ack TallTed 16:28:29 JoeAndrieu: These conversations will depend on defining the media type and then the name. I think a PR should have some notion of consensus that we think represents our best current understanding of what the spec is which we don't have and I don't think we should specify it until we know what it means. 16:28:31 q+ to note that this media type is already referred to in several other issues and PRs 16:28:42 TallTed: I want to highlight that there was a difference in what Manu spoke and what was typed in as logged. 16:29:11 +1 TallTed 16:29:14 TallTed: That difference is important and the written log is closer to what I would be ok with. This potentially defined media type allows for the possibility of securing the content as opposed to indicating that it is secured. 16:29:35 TallTed: I think that's part of the largest back and forth between VC vs. C -- and I'm going to start using those terms because that's what we have been discussing. 16:30:00 TallTed: I think this is a good reason why abbreviations aren't necessarily good, VC = Verifiable Credential, C = Credential and one may not necessarily be the other. 16:30:14 ack manu 16:30:14 manu, you wanted to suggest a definition for this media type. 16:30:17 TallTed: The data structure doesn't need to include proofs it just needs to have a slot that can be filled. 16:30:42 manu: This PR doesn't include the definition and I think that's a good thing, because I think we'll have a long walk before this PR can get in. 16:31:04 manu: This suggestion isn't picking `vc` vs. `c` vs. `verifiable-credential` whatever -- that's a separate discussion. 16:31:36 manu: This media type, signals that it is a mechanism that can be used to secure a credential. That thing may or may not have a proof, but in the media type section we recommend or outright say that it has to have such a proof / is secured in some way. 16:31:56 q? 16:31:56 q? 16:31:58 manu: It's not a may / may not have an internal / external proof. It is expected that you have either an external or an internal proof that is securing this document. 16:31:59 q+ 16:32:06 ack Orie 16:32:06 Orie, you wanted to note that this media type is already referred to in several other issues and PRs 16:32:10 manu: I don't know if that meets your bar, Joe. 16:32:44 Orie: This PR just gives a name to a concept. There are so many things discussing this -- it's reasonable to say there are two concepts and you give names to them to refer to them. 16:32:55 Orie: We already have a media type for one thing and this will give a name to the other concept. 16:32:58 -1 to "this means you're expected to have put a proof in there somewhere" unless that proof could be "null" 16:33:21 Orie: In all the discussions, we can continue to evolve and we can new constraints and relationships between these things, in every argument I've seen in the WG people are assuming these media types exist. 16:33:44 Orie: I think it's ok for us to merge this and continue in that journey. We can remove things later if necessary. 16:34:00 +1 to verifiable credential (however you say it) must have a proof associated with it of some kind. To me, at least that's what verifiable means. 16:34:20 Orie: I think it's a mistake to bring in term definitions for RDF classes or term definitions for spec texts into registration for this concept. I don't think it helps achieve the objectives of making the arguments clearer -- in a way that will comingle things and make it harder to get to clarity in the WG. 16:34:30 Is "[unverifiable] credential" a subtype of "verifiable credential"? 16:34:32 q+ 16:34:58 ack JoeAndrieu 16:35:01 Orie: I would just like to acknowledge that folks in the WG are arguing as if this is a distinct media type from the other one that we've registered. Those arguments are attempting to distinguish between them and we might find out there is no such need to distinguish, but having this name around is helpful to those arguments. 16:35:02 TallTed, that's a debate we'll need to have. 16:35:41 https://w3c.github.io/vc-data-model/#dfn-credential 16:35:49 JoeAndrieu: The evidence you cited actually makes me even more opposed. People are using this term as if it has consensus and that gives it even more imprimatur that we need it. I think the problem is what you're highlighting as your reason for merging the PR. 16:35:55 "A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects." 16:36:05 JoeAndrieu: I'm trying to push back on these slippery slope adjustments where someone says "we already made that decisions it's in the spec". 16:36:08 ack ivan 16:36:10 q+ to ask Joe of what he thinks about my definition :) 16:36:14 JoeAndrieu: People don't yet agree on what this means. 16:36:30 ivan is correct, we have "requested registration". 16:36:43 in a document that has not yet advanced. 16:36:56 ivan: Just a word of warning -- Orie, you said we've registered things and we haven't registered anything yet. That will only happen when we go to CR when we request for registration. We haven't registered, we have just documented our thoughts, no registration has been done. 16:37:00 ivan: We have to be careful about those words. 16:37:05 brent: That's correct. 16:37:09 ack manu 16:37:09 manu, you wanted to ask Joe of what he thinks about my definition :) 16:37:17 "proposing requesting registration" 16:37:23 ^ that 16:37:42 manu: Just to outline the potential paths forward that I think Ted and Joe are asking for. One of those is to clearly define what the media type does and is used for. I tried to do that before. My request is for Joe to put himself back on the queue to respond. 16:37:52 JoeAndrieu: Is that in writing or verbally? 16:38:08 q+ 16:38:13 q+ to ask about vc-jwt 16:38:15 manu: Verbally, the vc media type is used when you have an expression of the data model that is secure; that is the expectation. You use that media type when you have a credential that's secured. 16:38:21 manu: That's it for this PR. 16:38:29 ack TallTed 16:38:30 manu: Won't say more to try and get feedback on that. 16:38:38 q+ to answer re vc-jwt question 16:38:49 q+ to "type that describes the other half of the puzzle". 16:39:08 TallTed: I would not be in favor of that unless we have a type that addresses the other half of the puzzle. You've just described the secured chunk, there is an unsecured chunk that should just as well be expressible in roughly the same format. The only difference between them is the securing part. 16:39:08 +1 TallTed 16:39:44 TallTed: If the only way that's defined to express the secured ones -- then we can't express the unsecured ones. Some will be secured and others will not be. We might need a distinct type for the secured or the unsecured. Either we need a super class or two disjoint subclasses. 16:39:50 +1 to TallTed framing again. 16:40:10 ack JoeAndrieu 16:40:10 JoeAndrieu, you wanted to ask about vc-jwt 16:40:31 JoeAndrieu: Quick note for TallTed, my understanding is the base media type is the unsecured thing. My sense is that we had that agreement in Miami and this was an additional secured media type. Your definition seems ok, but it triggers for me, what about VC-JWT, is this for any mechanism that has secured a VC? 16:40:33 ack Orie 16:40:33 Orie, you wanted to answer re vc-jwt question 16:41:03 Orie: I queued to hopefully answer Joe's question. We're in the core data model spec, the core model is JSON-LD. Both of these have `+ld+json` at the end and they could be used in the `cty` header in a VC-JWT. 16:41:32 Orie: There was a slide for it -- there was a question "is proof expected / allowed to be present?" when you see `cty` with `+ld+json`. There's no decisions about allowed or forbidden yet. 16:41:59 Orie: The current 1.1 spec says `vc+ld+json`, proof would be allowed there, you'd expect it to be there if secured with a DI proof and expect it to maybe not be there if using an external proof. 16:42:18 Orie: The spec text says "at least one proof". My interpretation of 1.1, if you had a VC and it could include or not include a proof. 16:42:37 Orie: That's my interpretation of the text today, that's assuming that it would go along with this media type. 16:43:00 ack manu 16:43:00 manu, you wanted to "type that describes the other half of the puzzle". 16:43:04 Orie: Since this WG can't agree on mechanisms for proofing a credential or 'proof' in a credential, it seems that the group could more easily come to a conclusion on the vc media type requirements. 16:43:11 +1 to Orie 16:43:43 q+ to say that the base media type suggests a mapping. if this is going to map to the base, that should be part of the definition 16:43:46 manu: +1 to that on how we go about processing that. It's fine if we don't do that we will have to open the can of worms on hierarchy, the relationships between the media types, the `+` subclass concept, and so on -- that will take a while to unpack. 16:44:20 q? 16:44:22 manu: It sounds like Joe and Ted, you're asking to move to unpack that. Before I jump into doing that -- I expect that will eat up the rest of this call and a number of other calls, I want to make sure that there will be objections to pulling in any variations of this PR before settling those questions. 16:44:26 ack JoeAndrieu 16:44:26 JoeAndrieu, you wanted to say that the base media type suggests a mapping. if this is going to map to the base, that should be part of the definition 16:44:37 JoeAndrieu: Yeah, I think that's right. What this media type means is important to whether or not we should add it. 16:44:56 q+ to ask about concrete changes to this PR 16:45:23 JoeAndrieu: The essence of the question I asked about VC-JWT -- is, is the media type that you're proposing here, for `vc+ld+json`, you said that would be used for secured credentials and I would anticipate that it would include VC-JWT. I talked about a parameterized version of the media type where we parameterize the proof type. 16:45:44 q+ to note that parameterized media types don't have consensus. 16:45:45 JoeAndrieu, that's not what I'm talking about :) 16:45:52 JoeAndrieu: We could have that or not -- if what we're talking about is a single media type with no params, then a definition seems to conflate different forms of securing credentials. Is it for just one form or multiple forms? 16:45:53 q? 16:45:55 ack brent 16:45:55 brent, you wanted to ask about concrete changes to this PR 16:46:14 q- 16:46:21 brent: I'm wondering if -- speaking ... this PR has concrete text, what concrete changes would need to be made to make it acceptable to merge? 16:46:37 q+ to repeat myself 16:46:39 q+ 16:46:46 ack JoeAndrieu 16:46:46 JoeAndrieu, you wanted to repeat myself 16:46:48 brent: If you are objecting to pulling in this PR, is there a concrete change that would remove your objection? 16:47:05 q+ to unpack non-parameterized application/credential+ld+json and how it relates to application/verifiable+credential+ld+json 16:47:15 JoeAndrieu: I think we need a definition, until we have a definition, I can't support this PR. If we pull this in, I think we're moving away from where we had consensus with a converging solution. I think we need that definition. 16:47:30 brent: Is there a definition you would support? 16:47:46 JoeAndrieu: I don't have a definition, it doesn't exist, the PR is too early, we need to have the conversation to generate the definition. 16:47:48 ack TallTed 16:48:15 TallTed: I'm not far off from Joe, not a surprise for many of you. It seems clear to me that Manu's expectations that this media type entail the inclusion of a proof are not the same expectations of everyone who is looking at this media type. 16:48:42 TallTed: I'm ok with this media type to have box for this proof to go into, maybe that includes something that says the proof is external, maybe it says it has the proof itself. 16:48:43 This PR DOES NOT constrain the media type, and yet... people are objecting based on "hypothetical future constraints". 16:49:00 TallTed: The requirement that it be the bytes that make this proof happen is not ok. Then we don't have the whole expressible, just the proven one. 16:49:06 ack manu 16:49:06 manu, you wanted to unpack non-parameterized application/credential+ld+json and how it relates to application/verifiable+credential+ld+json 16:49:52 Another note on paramterized media types, they don't play well with reuse in HTTP responses. 16:49:52 manu: Let me try and propose some concrete changes. So, Joe, you asked about params -- the answer is that this does not include media type params, so no. That would lead to a lot of objections, it makes parsing harder, etc. those things exist and we can call that question, but I expect people to object. 16:49:58 manu: This approach is a non-param one. 16:50:17 q+ to say whether or not is parameterized is less of an issue than whether or not it is meant to be used for all secured credentials, or just for a particular securing mechanism 16:50:26 manu: I think there is a desire by some WG members to have two potential serializations -- it may be two different media types, I will pretend it's two right now for discussion. 16:50:42 manu: One is `application/credential+ld+json` and the other layers on top that is a vc one. 16:50:54 the dash vs the plus matters... 16:50:58 manu: There is a difference between them. I am proposing that the difference between them is the expectation in how they are used. 16:51:29 manu: `credential+ld+json` is expected to not have a proof on it. And some people said it could, but does it forbide proofs or can it be on there? That's a question. 16:52:02 q? 16:52:02 manu: For `vc+ld+json` is expected to have an internal or external proof. That's the difference between the expectations around the media type. The debate we're having is about whether `proof` should absolutely be forbidden but it's really strongly suggested that you don't. 16:52:21 +1 Manu. 16:52:32 manu: For `credential+ld+json`. For `vc+ld+json`, I think it's not controversial to say a proof is expected but you don't have to use the `proof` field. 16:52:36 q+ 16:53:00 q+ to say that we're not using media types properly when we're talking about expectations of the meaning of something vs. its syntax 16:53:15 manu: It sounds like we're saying we want to have two media types -- if we do that, what's the difference between them? 16:53:23 manu: I think that's a question to you, Ted, and Joe. 16:53:27 ack JoeAndrieu 16:53:27 JoeAndrieu, you wanted to say whether or not is parameterized is less of an issue than whether or not it is meant to be used for all secured credentials, or just for a particular 16:53:30 ... securing mechanism 16:53:55 I don't think that is what Manu is proposing. 16:53:56 JoeAndrieu: I'll try and be short. I think what you're proposing Manu is that this is the DI interpretation that can transform back to the base media type. It's not for all secured VCs and it's just one class of them. 16:54:01 JoeAndrieu, unfortunately, that's not what I'm proposing :) 16:54:10 JoeAndrieu: I think the class you care about is just the DI version. That would free up this conversation quite a bit. 16:54:26 JoeAndrieu: How would we know if it's some other securing mechanism? 16:54:33 ack dlongley 16:54:33 dlongley, you wanted to say that we're not using media types properly when we're talking about expectations of the meaning of something vs. its syntax 16:54:34 JoeAndrieu: The lines are kind of blurry. 16:54:39 scribe+ 16:54:43 I do agree with Joe's comment that there is confusiong regarding the relationship between `proof` and data integrity... in the core spec. 16:55:06 s/confusiong/confusion/ 16:55:37 dlongley: It's been challenging to participate and scribe... short thing I want to say, slightly concerned that we might not be using media types properly wrt. expectations for meaning vs. concrete serialization. What media types are meant to do is to express concrete serialization. Whether or not proof field is present, syntactical element, but conceptually, that's a different conversation and doesn't have anything to do with media types. 16:55:59 dlongley: We might be able to get to one media type that captures all syntactic elements and then move discussion on how something is secured out of media type space. 16:56:19 rrsagent, draft minutes 16:56:21 I have made the request to generate https://www.w3.org/2023/03/07-vcwg-special-minutes.html ivan 16:56:28 brent: I think we got much closer on this one -- we had some good discussion, some concrete ideas on the table. 16:56:32 brent: Thanks for scribing, challenging scribe day. We'll talk tomorrow. 16:56:36 zakim, end meeting 16:56:36 As of this point the attendees have been ivan, dlongley, brent, dwaite, manu, samsmith, yanzhang, orie, tallted, cabernet, kerri, Kerri_Lemoie, dmitriz, JoeAndrieu, davidc, will, 16:56:37 brent: Thanks everybody! 16:56:39 ... smccown, PhilLong, Phil_ASU, bengo, oliver, shawnb 16:56:39 RRSAgent, please draft minutes 16:57:10 I have made the request to generate https://www.w3.org/2023/03/07-vcwg-special-minutes.html Zakim 16:57:16 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:57:16 Zakim has left #vcwg-special 16:57:36 rrsagent, bye 16:57:36 I see no action items