14:37:14 <RRSAgent> RRSAgent has joined #vcwg
14:37:18 <RRSAgent> logging to https://www.w3.org/2024/08/21-vcwg-irc
14:37:18 <Zakim> RRSAgent, make logs Public
14:37:19 <Zakim> please title this meeting ("meeting: ..."), ivan
14:37:50 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:37:50 <ivan> Date: 2024-08-21
14:37:50 <ivan> Agenda: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240821T110000/
14:37:50 <ivan> chair: brent
14:37:51 <ivan> ivan has changed the topic to: Meeting Agenda 2024-08-21: https://www.w3.org/events/meetings/326e4693-22a7-48ba-b083-3e74e79e6088/20240821T110000/
14:59:12 <ivan> present+
15:00:41 <hsano> hsano has joined #vcwg
15:00:51 <decentralgabe> decentralgabe has joined #vcwg
15:00:58 <ivan> present+ Gabe
15:00:59 <hsano> hsano has joined #vcwg
15:01:09 <KevinDean> KevinDean has joined #vcwg
15:01:12 <KevinDean> present+
15:01:12 <ivan> present+ KevinDean
15:01:44 <decentralgabe> Meeting: Verifiable Credentials Working Group
15:01:51 <decentralgabe> Chair: Gabe Cohen
15:01:55 <decentralgabe> Topic: Agenda Review
15:02:01 <wes-smith> wes-smith has joined #vcwg
15:02:38 <ivan> present+ joe, wes-smith , campbell
15:02:53 <ivan> present+ dmitriz
15:03:05 <ivan> present+ hsano
15:03:09 <hsano> present+
15:03:10 <ivan> present+ manu
15:03:39 <ivan>     present+ TallTed
15:03:42 <TallTed> present+
15:03:43 <KevinDean> scribe+
15:04:04 <ivan> present+ dlongley
15:04:05 <KevinDean> decentralgabe Filling in for Brent today.
15:04:12 <ivan> q+
15:04:23 <decentralgabe> ack ivan
15:04:35 <KevinDean> Ivan Need a few seconds.
15:04:49 <decentralgabe> Topic: W3C administrivia (Ivan)
15:04:51 <Wip> Wip has joined #vcwg
15:04:51 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:05:21 <KevinDean> ...The announcement went out about the proposed new charter. If you're an AC rep, please vote. It is the charter we have discussed and if it is accepted then we will smoothly transfer right away.
15:05:42 <KevinDean> ...There are no new recommendations so there is no need to renew your application for the working group.
15:05:52 <decentralgabe> Topic: TPAC
15:06:01 <decentralgabe> https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?pli=1&gid=179611341#gid=179611341
15:06:02 <ivan> present+ jennie
15:06:11 <ivan> regrets+ brent
15:06:28 <ivan> present+ identitywoman
15:06:31 <Wip> present+
15:06:40 <KevinDean> decentralgabe There is a spreadsheet that Brent created to note your attendance at TPAC. Please note your attendance for the working group. We're hoping to have a dinner that Thursday night, with sponsor if available or pay-for-yourself if not.
15:06:52 <ivan> present+ phil
15:06:58 <KevinDean> ...Please note any topics you have for TPAC. I will create another tab.
15:07:04 <PL-ASU> PL-ASU has joined #vcwg
15:07:11 <JennieM> JennieM has joined #vcwg
15:07:13 <PL-ASU> present+
15:07:13 <ivan> present+ will
15:07:19 <JennieM> present+
15:07:21 <decentralgabe> Topic: VCDM Wrap Up
15:07:22 <manu> q+
15:07:27 <decentralgabe> https://github.com/w3c/vc-data-model/pulls
15:07:33 <decentralgabe> ack manu
15:07:33 <KevinDean> ...Looking at the PRs, we have four that are open.
15:07:42 <hsano> ]
15:08:14 <KevinDean> manu I just merged three of them because GitHub was broken earlier. They were editorial fixes. There is one open, 1550, that has broad review and will be merged after the Sunday review.
15:08:23 <ivan> s/manu/manu:/
15:08:41 <KevinDean> ...We're doing really well on the reviews, did another editorial pass on sections 1-4, I've done one on section 5, hopefully we'll get to section 6 shortly.
15:08:55 <Przemek> Przemek has joined #vcwg
15:08:58 <ivan> present+ mccown
15:09:04 <KevinDean> ...We'll keep going through that until we're done. We have issues that came up that we should discuss today.
15:09:18 <decentralgabe> Sub topic: https://github.com/w3c/vc-data-model/issues/1552
15:09:22 <KevinDean> decentralgabe: Looking at the issues... 1552, add reference to DID core.
15:09:27 <manu> q+
15:09:27 <ivan> s/sub topic/subtopic/
15:09:37 <decentralgabe> ack manu
15:09:43 <selfissued> selfissued has joined #vcwg
15:09:53 <smccown> smccown has joined #vcwg
15:09:53 <selfissued> present+
15:09:58 <smccown> present+
15:10:08 <ivan> present+ Przemek
15:10:26 <KevinDean> manu: I just noted that we do not depend normatively on DID Core in the VC Data Model so we should not add it as a normative reference. At some point during the editorial process we removed all references. We should add an informal reference. I can raise a PR to do so.
15:10:47 <PL-ASU> +1 to raise that informative reference re: DID core in the VCDM
15:10:51 <dlongley> +1
15:10:54 <ivan> +1
15:10:56 <dmitriz> dmitriz has joined #vcwg
15:11:09 <decentralgabe> Subtopic: https://github.com/w3c/vc-data-model/issues/1551 Rename VC Specifications Registry to VC Extensions
15:11:10 <manu> q+
15:11:14 <decentralgabe> ack manu
15:11:14 <KevinDean> decentralgabe: We have another new issue, 1551, rename VC Specifications Registry to VC Extensions.
15:12:15 <KevinDean> manu: In the DID WG, there was a resolution made to split the DID Registry to DID Extensions (unofficial, just a list of things we know about) and DID Methods into its own registry. It's more of a directory than a registry, it's just the ones that we know of.
15:13:04 <KevinDean> ...Does this group want to do something similar? I think we have consensus about it being not an official list of all available extensions. Proposal is to rename VC Specifications Registry to VC-Extensions.
15:13:28 <KevinDean> ...Any objections? The only downside here is the pain that Ivan will go through to put redirects in place.
15:13:31 <Wip> +1 makes sense to me
15:13:34 <KevinDean> +1
15:13:36 <ivan> q+
15:13:40 <JoeAndrieu> +1
15:13:40 <decentralgabe> ack ivan
15:14:20 <manu> q+
15:14:34 <decentralgabe> ack manu
15:14:36 <KevinDean> Ivan: I'm not against it, the only consequence is that many of the papers and even within some diagrams we use the term Verifiable Data Registry or similar term which is a generic term for all kinds of data we store in this ecosystem. We may have to change that as well, which means a lot of small places in our presentations etc. to be updated.
15:15:02 <dlongley> +1 to manu, VDR is totally different from VC Specification Registry, so good to make it clearer they are mostly unrelated
15:15:12 <KevinDean> manu: That's another good reason to change the name. Verifiable data registries are something different, they can be blockchains, websites, centralized or decentralized, etc., as opposed to a list of specifications.
15:15:27 <dlongley> +1 to VC Extensions
15:15:44 <ivan> q+
15:15:50 <KevinDean> ...Those should stay the same in the spec. The reason it's an issue in the VCDM is that we talk about them in multiple places in the document in slightly different ways, so renaming to VC-Extensions will remove some of that ambiguity.
15:15:50 <decentralgabe> ack ivan
15:16:08 <manu> yes, +1 to clean up the terminology that we use.
15:16:35 <KevinDean> Ivan: I am fine with the way that we refer to the verifiable data registry. I don't know if it's tribal knowledge or more formal, but your proposal of changing is very welcome.
15:16:46 <manu> also, yes, we need to track down where we first defined VDR.
15:17:05 <decentralgabe> Topic: VC JOSE COSE PR Review https://github.com/w3c/vc-jose-cose/pull/292
15:17:07 <KevinDean> decentralgabe: It came to my attention that there's a PR in JOSE-COSE that we should discuss.
15:17:20 <manu> q+
15:17:44 <ivan> present+ selfissued
15:18:32 <decentralgabe> ack manu
15:18:35 <KevinDean> selfissued: Ambiguity around using detached signatures. If we do nothing, we can use detached signatures. That said, readers would be better served for us to repeat what's in the underlying specifications. It's not normative, because it doesn't change the meaning of the spec.
15:19:06 <KevinDean> manu: The reason this surprised me is because I don't think we use detached signatures anywhere else in the ecosystem.
15:19:32 <KevinDean> ...We see a very large payload followed by a very small signature payload without reference to the original.
15:19:41 <KevinDean> ...I don't understand what the use case for that is.
15:20:01 <KevinDean> ...If we're going to support this, we probably need to talk about how that signature is associated with the payload.
15:20:07 <selfissued> q+
15:20:26 <KevinDean> ...It feels like it could lead to a number of security concerns. I want to know what the concrete use case is.
15:20:44 <JoeAndrieu> q+ to ask if this means that what is going over the wire does not contain an application/vc?
15:20:56 <KevinDean> ...If there is a valid use case, then we need to make sure that we have thought about the implications of just doing a detached signature. Are we going to provide any guidance at all?
15:21:06 <decentralgabe> ack selfissued
15:22:03 <KevinDean> selfissued: I also answered the security question in the issue that it's no less secure than including it in the payload, because if it doesn't validate, detached or not, we can't proceed. How do we associate the payload with the container? We don't do protocols, and that's a protocol feature.
15:22:18 <ivan> q+
15:22:40 <manu> q+ to explain why "no less secure" doesn't seem to hold water -- how do you bind it to the original payload? I didn't hear a use case for VCs yet.
15:22:44 <decentralgabe> ack JoeAndrieu
15:22:44 <Zakim> JoeAndrieu, you wanted to ask if this means that what is going over the wire does not contain an application/vc?
15:22:45 <KevinDean> ...There are plenty of cases in the real world where there is data in various channels and you want to validate that it's correct. It's out of scope for us to say how a signature is transmitted or checked against a piece of data.
15:23:03 <selfissued> q+
15:23:33 <KevinDean> JoeAndrieu: In the way that we're using the detached payload, what's going over the wire has a media type of application/vc, but because it's detached, it's not going with the payload. What do we call that thing that's securing that data, that is not a VC?
15:23:44 <decentralgabe> ack ivan
15:24:15 <KevinDean> Ivan: Without going into the technical, it's a procedural thing. My understanding is that the fact of having the detached signature is something that the standard allows.
15:24:53 <KevinDean> ...If we do not want that, we have to actively in the standard disallow it, which I think would be a heavy thing from our side to do. It's out there, it's the user's business to make sure it's secure, it's not our responsibility.
15:25:03 <decentralgabe> ack manu
15:25:03 <Zakim> manu, you wanted to explain why "no less secure" doesn't seem to hold water -- how do you bind it to the original payload? I didn't hear a use case for VCs yet.
15:25:15 <KevinDean> selfissued: That's correct, and likewise COSE defines the mechanism for detached signature.
15:26:20 <KevinDean> manu: I haven't yet heard a use case where we need to use detached signatures. It's really hard to analyze the usefulness until we have them. I have concerns, because in our COSE examples, we're going to be showing how to secure things, and we will be showing detached signatures, but we don't have a media type for it and we don't know how to
15:26:20 <KevinDean> associate it with the original payload.
15:27:23 <KevinDean> ...There are a number of questions. We shouldn't put a number of examples if the group isn't using it. Others can use it and other mechanisms, but we don't have examples in the spec because we haven't got concrete use cases.
15:27:37 <KevinDean> ...I'm fine with staying silent on it, not with putting examples throughout the specifications.
15:27:38 <decentralgabe> ack selfissued
15:28:52 <manu> q+
15:28:53 <KevinDean> selfissued: This PR doesn't change the examples, nor am I proposing to do so. One of the technical reasons in JOSE for using detached signatures is that you can use the unencoded payload option, which means you never have to Base64 encode the payload. If you have an authenticated way to transmit the payload between parties, that's outside the scope
15:28:54 <KevinDean> of what we specify. We get the size savings of not doing the encoding. That is a use case.
15:29:03 <decentralgabe> ack manu
15:29:08 <manu> q-
15:29:19 <JoeAndrieu> seems like Mike's payload is not a VC, as in application/vc, but something else
15:29:42 <KevinDean> manu: I would be find with us staying silent on it. Someone out there that is implementing this would be good to hear from.
15:29:54 <KevinDean> ...It raises a whole bunch of other questions that have not been answered.
15:30:14 <decentralgabe> Topic: Controller Document Issue & PR Processing
15:30:15 <KevinDean> decentralgabe: We do use detached payloads. We haven't explored COSE yet, but will ask my team.
15:30:43 <decentralgabe> Subtopic: https://github.com/w3c/controller-document/pull/41
15:30:48 <manu> q+
15:30:53 <decentralgabe> ack manu
15:31:21 <KevinDean> manu: I think this is probably ready to go in. I don't think it has any objections left. There's one outstanding change request that I thought was addressed.
15:31:52 <KevinDean> selfissued: Dave Longley has a textual change request. It has been addressed.
15:32:17 <decentralgabe> Subtopic: https://github.com/w3c/controller-document/pull/42 Specify that controller overrides subject control
15:33:14 <KevinDean> JoeAndrieu: The root confusion is the term controller as a property does not identify the controller in the role. I think Manu's attempt to respond reified that confusion.
15:33:40 <Wip> q+
15:33:41 <KevinDean> ...There are some URIs where you cannot specify the controller, and we need a way to explain that conundrum.
15:33:45 <decentralgabe> ack Wip
15:34:09 <manu> q+
15:34:26 <JoeAndrieu> q+
15:34:26 <KevinDean> wip: It does say in the controller section that a controller is authorized etc. In practice, is that happening? How is that authorization enforced in DID methods today? It's misleading, as I don't know if that is actually happening.
15:34:30 <decentralgabe> ack manu
15:34:54 <JoeAndrieu> q+ to say the Controller is by fact, who can update the VDR. the "controller" property is a bit of data in a JSON object
15:34:58 <PL-ASU> Doesn't  did:tdw update controller docs?
15:35:16 <dlongley> +1 to Manu, VDR is root of control, it consents to setting `controller` (or not)
15:35:36 <KevinDean> manu: It's supposed to be that the VDR checks that. If the VDR does check the value, that's what the property is used for. The expectation is that if the property is used, then it is enforced by the VDR.
15:35:45 <decentralgabe> ack JoeAndrieu
15:35:45 <Zakim> JoeAndrieu, you wanted to say the Controller is by fact, who can update the VDR. the "controller" property is a bit of data in a JSON object
15:36:46 <manu> q+
15:36:49 <KevinDean> JoeAndrieu: I think this conflation is really hard. The controller is, by definition, who creates or controls the entry in the VDR. The controller property doesn't do so. The algorithm that's actually applied, you need to dereference the controller property to bring in data that's not in the document. I think it creates a semantic confusion gap.
15:36:51 <decentralgabe> ack manu
15:37:37 <JoeAndrieu> q+ to say then the property currently has zero meaning and we should remove it
15:37:37 <KevinDean> manu: I think Joe is presuming a certain way of doing the information. I don't think that people are going to the document to merge those entries with those in the DID document. Depending on the VDR, it will enforce the rules that go with the controller document.
15:37:49 <dlongley> https://github.com/w3c/controller-document/issues/33#issuecomment-2299498954 <-- i wrote comments here on my thoughts
15:38:03 <KevinDean> ...It will check the values in the document, but it won't merge it with the controller document itself.
15:38:27 <KevinDean> ...The controller field tells you which entities have the right to update the document, and those rules are enforced by the VBR.
15:38:28 <decentralgabe> ack JoeAndrieu
15:38:28 <Zakim> JoeAndrieu, you wanted to say then the property currently has zero meaning and we should remove it
15:39:12 <Wip> q+ to ask about other methods like ion and tdw
15:39:12 <dlongley> q+
15:39:20 <KevinDean> JoeAndrieu: The controller property is currently used in a way that does not do what Manu says it does. When we use the property in did:key, did:web, etc., it does not work the way it's expected to work.
15:39:26 <decentralgabe> ack Wip
15:39:26 <Zakim> Wip, you wanted to ask about other methods like ion and tdw
15:39:51 <DavidC> DavidC has joined #vcwg
15:39:58 <DavidC> present+
15:40:00 <JoeAndrieu> q+ to mentiond did:btc1 and how it deals with updates.
15:40:02 <decentralgabe> ack dlongley
15:40:05 <KevinDean> wip: Other DID methods like did:ion are using things in the DID document for their updates, e.g., the keys in the DID document. What should go in the controller property there?
15:41:03 <manu> q+ to speak to did:tdw
15:41:53 <decentralgabe> ack JoeAndrieu
15:41:53 <Zakim> JoeAndrieu, you wanted to mentiond did:btc1 and how it deals with updates.
15:41:57 <KevinDean> dlongley: I think the fact that a number of DID methods use the value in the controller field and honour it as the entities permitted to update the DID document, if the changes to the document align with the attribute, the changes should be honoured. The fact that someone may not be able to do that is not relevant to the VDR. Applications are going
15:41:57 <KevinDean> to work wth the DID document layer. We should be able to say that if the VDR allows those fields to be expressed and allowed updates to happen, they would honour what's in the DID document,.
15:43:11 <KevinDean> JoeAndrieu: I think that would be a breaking change. That doesn't get to the root of what the VDR does. We use a capability invocation that dictates who can update the VDR, so it feels weird that there's another mechanism that can do so.
15:43:12 <decentralgabe> ack manu
15:43:12 <Zakim> manu, you wanted to speak to did:tdw
15:43:33 <KevinDean> manu: Joe, you said that the controller must be used. I don't think we're saying that.
15:43:35 <dlongley> q+ to say i did not
15:43:49 <KevinDean> JoeAndrieu: If it's there, it's a breaking change.
15:44:04 <KevinDean> KevinDean has joined #vcwg
15:44:04 <JoeAndrieu> q+ to say, that is a breaking change
15:44:13 <KevinDean> manu: If you use the feature, you must use it this way.
15:44:17 <dlongley> q-
15:44:19 <JoeAndrieu> breaking for did:web, did:key, did:btcr
15:44:37 <KevinDean> ...Will asked about did:ion, did:web, did:key, etc.
15:44:46 <KevinDean> ...did:key doesn't need this property.
15:44:54 <dlongley> if controller is present *and if* the VDR has a mechanism to allow stated controllers to perform updates, it should honor those controllers, *however* it's ok for VDRs to not have such features.
15:44:57 <KevinDean> ...In did:web, the controller is the controller of the website.
15:45:00 <JoeAndrieu> but did:key does have this property
15:45:26 <dlongley> but if a VDR provides such a feature, it SHOULD allow specified controllers to use that feature.
15:45:28 <KevinDean> ...There is a change log that goes along with the DID document as it changes with time, and that is signed by entities.
15:45:54 <KevinDean> ...Control is important, even though the document is on a website. Any place where there are digital signatures, it is important to specify who is the controller.
15:46:01 <decentralgabe> ack JoeAndrieu
15:46:01 <Zakim> JoeAndrieu, you wanted to say, that is a breaking change
15:46:35 <KevinDean> JoeAndrieu: Manu, the way the spec is using this property is not as you're describing. did:key does specify the controller, and so to use this in the way you describe is a breaking change.
15:46:52 <KevinDean> decentralgabe: We'll come back to it next week.
15:46:58 <decentralgabe> Subtopic: Remaining Controller Doc Issues
15:47:00 <manu> hmm, I just checked the did:key spec and it doesn't use controller
15:47:04 <decentralgabe> https://github.com/w3c/controller-document/pull/43
15:47:33 <JoeAndrieu> https://w3c-ccg.github.io/did-method-key/#example-2-an-example-of-a-did-key-did-document
15:47:55 <KevinDean> Ivan: It removes quite a lot of things from the controller document. Essentially what it does is remove everything that is JSON-LD specific because this document should not depend on JSON-LD.
15:48:18 <KevinDean> ...It says in a non-normative note that various applications use this term in their own way.
15:48:40 <KevinDean> ...It's a relatively large surgery by removing things.
15:48:42 <JoeAndrieu> it is on the did:key spec
15:49:01 <JoeAndrieu> which was my point: specs today do not use the controller property in this way. they use it differently.
15:49:08 <decentralgabe> https://github.com/w3c/controller-document/pull/44
15:50:22 <decentralgabe> https://github.com/w3c/controller-document/issues/21 Data model reference
15:50:35 <decentralgabe> https://github.com/w3c/controller-document/issues/37 https://github.com/w3c/controller-document/issues/35 -- all need PRs
15:51:16 <KevinDean> Ivan: For issue 21, it's up to Manu. He's supposed to come up with a PR to solve it.
15:51:26 <KevinDean> decentralgabe: I will reassign it.
15:51:41 <manu> q+
15:51:47 <decentralgabe> ack manu
15:52:04 <KevinDean> manu: I noted that we have Brian on the call today and we're having a discussion on media types.
15:52:27 <KevinDean> ...We've got two proposals. Brian, I need clarification on potential formal objection status.
15:52:28 <decentralgabe> Subtopic: vc jose cose media types
15:52:38 <dlongley> https://github.com/w3c/vc-jose-cose/issues/282
15:52:38 <decentralgabe> https://github.com/w3c/vc-jose-cose/issues/282
15:53:10 <manu> https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2296998704
15:53:11 <KevinDean> decentralgabe: Brent asked that we not spend time on it on this call but happy to take a minute.
15:53:25 <KevinDean> manu: Mike, it would be good to get your feedback on proposal 1 vs. proposal 2.
15:53:54 <KevinDean> ...Brian, the thing I need from you is that you said you would formally object to proposal 2, but I need clarification on that.
15:54:04 <selfissued> selfissued has joined #vcwg
15:54:23 <selfissued> Which issue?  I had been kicked out if IRC.
15:54:30 <decentralgabe> https://github.com/w3c/vc-jose-cose/issues/282
15:55:25 <KevinDean> Brian Campbell: I don't understand what the misunderstanding in the issue. I mean to object to the second proposal by way of requesting changes in a PR.
15:55:43 <KevinDean> ...Your question in the PR was about objecting to media type registrations within the IETF. That's a different forum.
15:56:01 <KevinDean> manu: That's the clarity I was looking for.
15:56:05 <dlongley> selfissued: https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2296998704 <-- these proposals
15:56:24 <ivan> present+ campbell
15:56:34 <KevinDean> selfissued: I'm about three days behind on this and there has been substantial traffic on it, so I'm not going to state opinions at this time.
15:57:02 <decentralgabe> https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?pli=1&gid=179611341#gid=179611341
15:57:22 <ivan> rrsagent, draft minutes
15:57:23 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/21-vcwg-minutes.html ivan
15:58:26 <ivan> rrsagent, bye
15:58:26 <RRSAgent> I see no action items