22:52:39 <RRSAgent> RRSAgent has joined #vcwg-special
22:52:43 <RRSAgent> logging to https://www.w3.org/2023/12/05-vcwg-special-irc
22:52:51 <Zakim> Zakim has joined #vcwg-special
22:53:01 <brent> zakim, start the meeting
22:53:02 <Zakim> RRSAgent, make logs Public
22:53:04 <Zakim> please title this meeting ("meeting: ..."), brent
22:53:23 <brent> meeting: Verifiable Credentials Working Group Special Topic Call
22:53:33 <brent> chair: Brent Zundel
22:54:11 <brent> brent has changed the topic to: Meeting Agenda 2023-12-05: https://www.w3.org/events/meetings/eaf86734-c2f9-410e-86b9-1cca18d0d6c9/20231205T180000/
22:59:40 <hsano> hsano has joined #vcwg-special
23:00:10 <TallTed> present+
23:01:28 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
23:03:35 <dlongley> present+
23:03:59 <manu> present+
23:04:01 <JoeAndrieu> present+
23:04:03 <JoeAndrieu> scribe+
23:04:30 <JoeAndrieu> brent: todays' agenda: open pull requests followed by issue triage
23:04:31 <seabass> present+
23:04:34 <andres> andres has joined #vcwg-special
23:04:49 <brent> present+
23:04:52 <andres> present+
23:04:52 <dlehn> present+
23:04:54 <selfissued> selfissued has joined #vcwg-special
23:04:55 <hsano> present+
23:04:56 <selfissued> present+
23:04:59 <seabass> present+ manu
23:05:10 <brent> Topic: PR Review
23:05:11 <identitywoman> identitywoman has joined #vcwg-special
23:05:13 <JoeAndrieu> ... ok. let's dive in to pull requests
23:05:21 <decentralgabe> decentralgabe has joined #vcwg-special
23:05:22 <brent> https://github.com/w3c/vc-data-model/pulls
23:05:24 <decentralgabe> present+
23:05:27 <manu> present+ identitywoman
23:05:51 <JoeAndrieu> ... we'll start at the top
23:05:54 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1372
23:06:08 <JoeAndrieu> ... not that one
23:06:09 <will> will has joined #vcwg-special
23:06:11 <will> present+
23:06:12 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1370
23:06:46 <JoeAndrieu> ... only has approvals
23:06:55 <JoeAndrieu> ... likely to get merged within the week
23:07:30 <JoeAndrieu> q+
23:07:36 <manu> scribe+
23:07:40 <brent> ack JoeAndrieu
23:08:19 <manu> JoeAndrieu: I still think this is a layering error. I don't know why Verifier would know how to interpret related resource, they didn't ask for it, it's not a VC, I think most use cases could be handled w/ a VC or how to secure contexts for ... generic mechanism seems wrong.
23:08:24 <manu> q+
23:08:29 <brent> ack manu
23:08:46 <JoeAndrieu> manu: I largely agree with Joe on his use cases. We should probably have a context securing mechanism.
23:08:55 <JoeAndrieu> ... and have something for enveloped VCs
23:09:16 <JoeAndrieu> ... a fear is that some implementers are going to use related resources as a dumping ground for all sorts of things
23:09:24 <JoeAndrieu> ... I want to express XYZ, I'm going to put that in there.
23:09:31 <JoeAndrieu> ... All that to say, Joe has a point
23:09:46 <JoeAndrieu> ... But if folks want to use the data model in that way, they can.
23:09:47 <JoeAndrieu> q+
23:09:48 <brent> q+
23:09:58 <brent> ack JoeAndrieu
23:10:27 <manu> JoeAndrieu: I want to note that anyone can add to the context and they can add properties. What we're talking about here is that everyone has to respect... we aren't preventing people that want to use relatedResource. I don't see reason for extensibility in this way.
23:10:35 <brent> ack brent
23:10:57 <JoeAndrieu> brent: I see the benefit of having more specific mechanisms for the different things
23:11:14 <JoeAndrieu> ... would the related resource be seen as a stepping stone?
23:11:16 <JoeAndrieu> q+
23:11:40 <brent> ack brent
23:11:46 <brent> ack JoeAndrieu
23:12:28 <manu> JoeAndrieu: I think a lot of it is lessons learned from extensible HTTP headers, which was "X-something"... if people start using it, they won't stop using it. If burden is you have your own context that does something specific. That's the path towards getting new things into VCDM. I'm afraid of setting the wrong direction here.
23:12:43 <dlongley> +1 to Joe that once people start using things they won't stop ... there are advantages for putting slight speed bumps in the way to make people do things in better ways
23:12:52 <JoeAndrieu> brent: this PR has nothing but approvals
23:13:11 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1369
23:13:40 <JoeAndrieu> ... incorporate status checking into the verification algorithm
23:14:04 <manu> q+
23:14:04 <JoeAndrieu> ... this was in part in response to a threatened FO from Google
23:14:15 <brent> ack manu
23:14:21 <JoeAndrieu> manu: I think Joe requested this
23:14:39 <JoeAndrieu> ... Andres also had some good things to say
23:14:55 <JoeAndrieu> ... It's an extension to the existing algorithm, but there is quite a bit of conversation
23:15:02 <JoeAndrieu> ... maybe some of this should be under verification
23:15:27 <JoeAndrieu> ... It does pull us into validation land, more-so than other algorithms
23:15:42 <JoeAndrieu> brent: this one is not as clear cut. one approval one request for changes
23:16:03 <manu> q+
23:16:10 <JoeAndrieu>  ... please indicate your approval or commentary
23:16:11 <brent> ack manu
23:16:30 <JoeAndrieu> manu: I will note that Orie is objecting because this is about validation not verification
23:16:48 <JoeAndrieu> ... but elsewhere Orie has said that verifiers are doing validation, so the waters have gotten muddied
23:17:04 <JoeAndrieu> ... It's safe to say that some of the things we are doing is debatable as validation.
23:17:23 <JoeAndrieu> ... If you're reading "validation" it may not mean what we've traditionally meant.
23:17:32 <JoeAndrieu> ... That makes it a bit challenging to read.
23:17:44 <manu> q+
23:17:49 <JoeAndrieu> ... Likely closed in the week without further support
23:17:55 <brent> ack manu
23:17:57 <andres> q+
23:18:02 <JoeAndrieu> manu: Andres, could you vocalize your comment?
23:18:08 <manu> https://github.com/w3c/vc-data-model/pull/1369#issuecomment-1838964960
23:18:14 <brent> ack andres
23:18:38 <JoeAndrieu> andres: We have two terms we are defining, verification (securing and currency)
23:18:46 <JoeAndrieu> ... Does the issuer stand by what they said?
23:19:00 <JoeAndrieu> ... I think we should modify and update that term so that it does not include currency
23:19:24 <JoeAndrieu> ... because cryptographic verification is well understood in the industry and does not include currency
23:19:40 <manu> FWIW, I agree with andres' take on what we could do to make this cleaner in the spec.
23:19:51 <JoeAndrieu> ... So, I think it would be better to remove currency from verification
23:19:58 <JoeAndrieu> q+
23:20:04 <brent> ack JoeAndrieu
23:20:55 <TallTed> business logic!
23:21:07 <TallTed> q+
23:21:23 <brent> q+
23:21:28 <manu> JoeAndrieu: It's a compelling argument, we are not just doing cryptographic securing, we're doing semantic securing. If we were just cryptographically securing, we'd just use a JWT. We are doing more here... knowing issuer stands by statement is in nature of whether or not statement is attributable to the author. That is different from timliness about expiry. That the issuer is committed to this is what we're doing that's different than other
23:21:28 <manu> cryptographic based mechanisms for verification.
23:21:29 <brent> ack TallTed
23:21:54 <JoeAndrieu> TallTed: VCs are defined to say anything about the issuer standing by the statement
23:22:03 <JoeAndrieu> ... rather "they said this about Pat"
23:22:12 <JoeAndrieu> q+ to say "they *say* this about Pat"
23:22:23 <JoeAndrieu> ... forcing them together is not going to help
23:22:29 <manu> q+ to ask if the distinction makes a difference, ultimately verifiers WILL check status and if they don't, they're in for a world of trouble. I don't think we need to spell this out in the verification algorithm.
23:22:31 <brent> ack brent
23:22:36 <andres> q+ to say that semantic verification is a blurry line that's difficult to define
23:22:52 <JoeAndrieu> brent: TallTed's definition matches my definition
23:23:04 <JoeAndrieu> ... that the VC is something said at some point.
23:23:15 <JoeAndrieu> ... the status property might not even be there
23:23:24 <JoeAndrieu> ... so that doesn't seem wholly involved so far
23:23:30 <dlongley> q+ it seems that we also do more than cryptographic verification during "verification" (even modulo status check validation)
23:23:34 <dlongley> q+ to say it seems that we also do more than cryptographic verification during "verification" (even modulo status check validation)
23:23:34 <brent> ack JoeAndrieu
23:23:35 <Zakim> JoeAndrieu, you wanted to say "they *say* this about Pat"
23:23:35 <JoeAndrieu> ... otherwise, wouldn't we have made status a require
23:24:20 <manu> JoeAndrieu: What VCs say are not about "that they said it" that "they DO say it" -- present tense -- that's important. Verifier is in present tense, am I going to rely on the information, but if issuer no longer stands by it, why would I rely on it?
23:24:20 <TallTed> "said" is not in the present "say" tense in any of our documents, to date
23:24:26 <brent> ack manu
23:24:26 <Zakim> manu, you wanted to ask if the distinction makes a difference, ultimately verifiers WILL check status and if they don't, they're in for a world of trouble. I don't think we need to
23:24:29 <Zakim> ... spell this out in the verification algorithm.
23:24:46 <JoeAndrieu> manu: knowing someone had a valid driver's license, even if they don't stand by it right now, might be useful
23:25:04 <JoeAndrieu> ... so there are use cases where you would ignore the currency
23:25:27 <JoeAndrieu> ... but I think the main point is that verifiers should apply their business logic, without restriction
23:25:49 <JoeAndrieu> ... so if you don't care about currency, then we're saying that you can't use VCs?
23:25:50 <dlongley> i think, when acting as a verifier, "now" is itself an input parameter to some algorithm
23:26:13 <JoeAndrieu> ... verifiers will check if its important, I don't think we need to instruct them
23:26:41 <JoeAndrieu> ... maybe a separate validation algorithm in the future
23:26:42 <brent> ack andres
23:26:42 <Zakim> andres, you wanted to say that semantic verification is a blurry line that's difficult to define
23:27:26 <JoeAndrieu> andres: answering Joe's point about semantic verification. That's a blurry line that is difficult to define. Who is to say that status is part of that or not?
23:27:34 <JoeAndrieu> ... if you care about it, you do it
23:27:54 <JoeAndrieu> ... We should make verification as clear as possible
23:28:12 <JoeAndrieu> ... These need to be secure. So we need clear verification.
23:28:23 <brent> ack dlongley
23:28:23 <Zakim> dlongley, you wanted to say it seems that we also do more than cryptographic verification during "verification" (even modulo status check validation)
23:28:58 <JoeAndrieu> dlongley: I'm sympathetic with tightening up what verification means. Modulo status check, there are other things that we do during verification, such as formedness.
23:29:14 <JoeAndrieu> ... the real question we've used is about business rules.
23:29:33 <JoeAndrieu> ... There are certain things that need to be done to gather the information needed to validate
23:30:08 <JoeAndrieu> ... So, some part of verification requires you to go out an check a list. Then you should do that.
23:30:15 <JoeAndrieu> q?
23:30:37 <JoeAndrieu> ... If we say it's just checking cryptography, that's not going to work.
23:30:45 <JoeAndrieu> ... The business rules get to are we going to accept something
23:31:01 <JoeAndrieu> brent: this conversation will go into the PR
23:31:10 <JoeAndrieu> ... this one is not as cut and dried.
23:31:27 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1367
23:31:30 <manu> q+
23:31:38 <manu> q-
23:31:42 <JoeAndrieu> brent: update context to match spec
23:31:51 <JoeAndrieu> ... lots of approvals. does what it advertises
23:32:06 <JoeAndrieu> ... I anticipate this will be merged soon
23:32:31 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1361
23:32:33 <JoeAndrieu> ... moving to 1361
23:32:55 <JoeAndrieu> ... remove comments. nothing but approvals. does what it says.
23:33:34 <JoeAndrieu> q?
23:33:42 <seabass> q+
23:33:46 <JoeAndrieu> ... 1358
23:33:50 <seabass> q-
23:33:53 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1358
23:34:06 <JoeAndrieu> ... enveloped VCs
23:34:40 <JoeAndrieu> ... raised to enable externally proofed VCs in VPs
23:34:40 <manu> q+
23:34:48 <brent> ack manu
23:35:23 <JoeAndrieu> manu: originally had a concept to introduce related resource. group said "no" we have two different cases, securing contexts and expressing JWT-protected VCs in VP
23:35:44 <JoeAndrieu> ... This is an attempt to do that
23:36:04 <JoeAndrieu> ... we know people want to embed "enveloped VCs" JWTs, Gordian, AC/DC, etc.
23:36:24 <JoeAndrieu> ... This PR creates a new attribute called "envelopeVerifiableCredential"
23:36:56 <JoeAndrieu> ... Orie is objecting, I believe based on expressing it directly as a VC (which seems to blow up current processors)
23:37:27 <JoeAndrieu> ...The argument is don't do this specific thing, we can shove it into related resources, which is exactly what Joe and I are concerned about
23:37:39 <JoeAndrieu> ... Mike also objected to the terminology? Not the feature?
23:37:44 <selfissued> q+
23:37:49 <seabass> q+
23:37:51 <brent> ack selfissued
23:37:55 <JoeAndrieu> ... Unless Orie changes his mind, I don't think we'll be able to get this in there.
23:38:18 <JoeAndrieu> mike: This seemed to be changing established terminology for not commensurate benefit. No proportional benefit.
23:38:29 <manu> q+ to note the terminology change.
23:38:29 <brent> ack seabass
23:38:37 <dlongley> "envelopedVerifiableCredential" is better than "externallySecuredVerifiableCredential" based on length alone :)
23:38:56 <JoeAndrieu> seabass: Manu, can you provide a link to the original discussion that brought up the idea of an enveloped VC, which seems like a radical new concept from what we have already.
23:39:04 <manu> https://github.com/w3c/vc-data-model/issues/1265
23:39:13 <JoeAndrieu> manu: it's 1265. It's a long thread.
23:39:14 <manu> https://github.com/w3c/vc-data-model/issues/1265#issuecomment-1824796746
23:39:29 <brent> ack manu
23:39:29 <Zakim> manu, you wanted to note the terminology change.
23:39:42 <JoeAndrieu> responding to Mike, yes. This PR tried to do two things at once.
23:40:05 <JoeAndrieu> ... one was changing the terminology, embedded proof / external proofs
23:40:16 <JoeAndrieu> ... some subset of people get confused by those terms
23:40:32 <JoeAndrieu> ... tried "watermarking proofs" v "external proofs"
23:41:01 <JoeAndrieu> ... "envelope" is that the secured thing goes inside. "watermark" is that you amend the thing
23:41:27 <brent> q+
23:41:30 <JoeAndrieu> ... that was the thought, but if that isn't resonating, that's ok.
23:41:31 <dlongley> we can keep embedded and use enveloped as a compromise there
23:41:37 <JoeAndrieu> mike: watermarking doesn't work for me
23:42:05 <JoeAndrieu> brent: I think I understand the reasoning behind this mechanism, that the way VC property is defined makes is so you can't just shove a JWT in there
23:42:12 <dlongley> q+
23:42:16 <brent> ack brent
23:42:20 <brent> ack dlongley
23:42:20 <JoeAndrieu> ... would another possible path be that we adjust that property so it matches the likely behavior?
23:42:27 <brent> q+
23:42:37 <JoeAndrieu> dlongley: this comes down to the fact that we have two different proof mechanisms
23:42:46 <JoeAndrieu> ... because of that, we need two different properties
23:43:13 <JoeAndrieu> ... because we need to keep the statements from the VC graph separate.
23:43:49 <JoeAndrieu> ... The envelope mechanism functions differently. To reference one, the envelope itself has a different data format.
23:44:03 <JoeAndrieu> ... It's not expressed in JSON-LD, so we need a place to express that
23:44:43 <brent> ack brent
23:44:43 <JoeAndrieu> ... We need two things. Either related resource or this enveloped property or we can't put VCs into a VP
23:44:58 <JoeAndrieu> brent: I think I tracked most of that.
23:45:10 <JoeAndrieu> ... note: you said you can't put this in JSON-LD
23:45:24 <TallTed> all JSON-LD is JSON, but some JSON is not JSON-LD.
23:45:37 <JoeAndrieu> dlongley: JSON-LD is a subset of JSON, so you *can* put anything in a JSON and so you CAN add that to JSON LD
23:46:17 <JoeAndrieu> ... We either have two properties of we say this property "has JSON" and nothing more (just a blob) or we can have a property where JSON-LD processors know what to do with the information.
23:46:31 <JoeAndrieu> ... Are the values in the term going to be JSON or JSON-LD?
23:46:40 <brent> q+
23:46:41 <andres> q+ to propose embeddedVerifiableCredential & externalVerifiableCredential
23:46:45 <brent> ack brent
23:47:13 <JoeAndrieu> brent: in other properties, we had a type property to say how you handle different variations
23:47:15 <dlongley> q+
23:47:20 <JoeAndrieu> ... why can't we do that here?
23:47:48 <brent> ack andres
23:47:48 <Zakim> andres, you wanted to propose embeddedVerifiableCredential & externalVerifiableCredential
23:47:49 <JoeAndrieu> ... Related Q: if we need a different property for embedded v enveloped, are we going to need more properties for other securing mechanisms?
23:48:09 <JoeAndrieu> andres: I propose we separate these into two terms (whatever those are).
23:48:36 <JoeAndrieu> ... my main concern is that its confusing from the previous version of the data model was interpreted to put the JWT in that property
23:49:04 <JoeAndrieu> ... So, if we are keeping the name but saying you can't put a JWT in there, that's going to confuse.
23:49:05 <brent> ack dlongley
23:49:35 <JoeAndrieu> dlongley: so you never were able to put a JWT into that property. That was never conformant.
23:49:35 <manu> q+ to note we /could/ put a type in there, that would work, but I'm not sure folks would like that?
23:49:53 <JoeAndrieu> ... so you're not putting a VC in that field, because they aren't VCs
23:50:47 <JoeAndrieu> ... We could adjust the spec where you have terms for enveloped credentials
23:51:30 <JoeAndrieu> ... Brent was suggesting we keep verifiableCredential they way it is, and allow it to also have a typed value.
23:51:46 <JoeAndrieu> ... or we have a different property, which is where you would put the envelop
23:52:00 <brent> q+
23:52:10 <JoeAndrieu> ... I think both ways could work, but we'll still need a new term to put this other thing into some place.
23:52:16 <brent> ack manu
23:52:16 <Zakim> manu, you wanted to note we /could/ put a type in there, that would work, but I'm not sure folks would like that?
23:52:27 <dlongley> q+ to say that won't work
23:52:33 <JoeAndrieu> manu: if this is a data URL can we just use an ID property to slap type on it?
23:52:51 <dlongley> q+ to say that won't work unless the type is also present
23:52:56 <JoeAndrieu> q+ to say I'm not sure how "type" works with arrays
23:53:21 <JoeAndrieu> manu: the data url includes the type in the URL itself. So this could be used for any future securing mechanisms.
23:53:27 <dlongley> `{"id": "data:...", "type": "EnvelopedVerifiableCredential"}` <-- this would work i think.
23:53:36 <dlongley> q-
23:53:55 <JoeAndrieu> manu: this would be a better design than using relatedResource
23:53:56 <brent> ack brent
23:54:13 <manu> ^ yes, that should work.
23:54:22 <dlongley> q+ to say we have a context problem :)
23:54:32 <JoeAndrieu> brent: if I'm understanding, then we keep verifiableCredential as an array of objects.
23:54:51 <dlongley> q+ to say we're really close ... `{"@context": "<vc v2 context>", "id": "data:...", "type": "EnvelopedVerifiableCredential"}` <-- this would work.
23:55:07 <JoeAndrieu> ... each object would have a type. in that array of objects, you could have either type embedded or otherwise
23:55:23 <brent> ack JoeAndrieu
23:55:23 <Zakim> JoeAndrieu, you wanted to say I'm not sure how "type" works with arrays
23:56:14 <manu> JoeAndrieu: For the object in the array, for a JSON-LD credential, would have A property that is the credential and a type. That object isn't directly a VC, it's a new thing that's wrapping around the VC as JSON-LD, not as a new data format.
23:56:20 <brent> ack dlongley
23:56:20 <Zakim> dlongley, you wanted to say we have a context problem :) and to say we're really close ... `{"@context": "<vc v2 context>", "id": "data:...", "type":
23:56:22 <Zakim> ... "EnvelopedVerifiableCredential"}` <-- this would work.
23:56:33 <JoeAndrieu> dlongley: I think we also need to put the context back onto that object.
23:56:52 <JoeAndrieu> .. in the VC work we have cleared the context so that V2 presentations can work with V1 VCs.
23:57:07 <JoeAndrieu> ... technically, we are going to need three things on those objects: id, type, context
23:57:43 <JoeAndrieu> brent: we have a few more PRs open. any that have only approvals will be merged on a 7 day window
23:57:58 <brent> zakim, who is here?
23:57:58 <Zakim> Present: TallTed, dlongley, manu, JoeAndrieu, seabass, brent, andres, dlehn, hsano, selfissued, decentralgabe, identitywoman, will
23:58:00 <Zakim> On IRC I see identitywoman, selfissued, andres, JoeAndrieu, hsano, Zakim, RRSAgent, brent, dmitriz, TallTed, manu, seabass, joraboi445, SintayewGashaw, dlehn, ivan, dlongley,
23:58:00 <Zakim> ... stenr, shigeya, bigbluehat, csarven
23:58:15 <brent> zakim, end the meeting
23:58:16 <Zakim> As of this point the attendees have been TallTed, dlongley, manu, JoeAndrieu, seabass, brent, andres, dlehn, hsano, selfissued, decentralgabe, identitywoman, will
23:58:18 <Zakim> RRSAgent, please draft minutes
23:58:20 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/05-vcwg-special-minutes.html Zakim
23:58:27 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
23:58:27 <Zakim> Zakim has left #vcwg-special
23:58:29 <brent> rrsagent, bye
23:58:29 <RRSAgent> I see no action items