Verifiable Credentials Working Group Telco — Minutes

Date: 2024-08-21

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Gabe Cohen, Kevin Dean, Joe Andrieu, Wesley Smith, Brian Campbell, Dmitri Zagidulin, Hiroyuki Sano, Manu Sporny, Ted Thibodeau Jr., Dave Longley, Jennie Meier, Kaliya Young, Will Abramson, Phillip Long, Steve McCown, Michael Jones, Przemek Praszczalek, David Chadwick

Regrets: Brent Zundel

Guests:

Chair: Gabe Cohen

Scribe(s): Kevin Dean

Content:

1. Agenda Review.

Wesley Smith: wes-smith has joined #vcwg.

Gabe Cohen: Filling in for Brent today.

2. W3C administrivia.

Ivan Herman: Need a few seconds.
… 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.
… There are no new recommendations so there is no need to renew your application for the working group.

3. TPAC.

Gabe Cohen: https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?pli=1&gid=179611341#gid=179611341.

Gabe Cohen: There is a spreadsheet that Brent created to note your attendance at TPAC. See above. 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.
… Please note any topics you have for TPAC. I will create another tab.

Phillip Long: PL-ASU has joined #vcwg.

4. VCDM Wrap Up.

Gabe Cohen: https://github.com/w3c/vc-data-model/pulls.

Gabe Cohen: Looking at the PRs, we have four that are open.

Manu Sporny: : 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.
… 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.
… We’ll keep going through that until we’re done. We have issues that came up that we should discuss today.

4.1. Add reference to DID Core (issue vc-data-model#1552)

See github issue vc-data-model#1552.

Gabe Cohen: Looking at the issues… 1552, add reference to DID core.

Manu Sporny: 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.

Phillip Long: +1 to raise that informative reference re: DID core in the VCDM.

Dave Longley: +1.

Ivan Herman: +1.

4.2. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)

See github issue vc-data-model#1551.

Gabe Cohen: We have another new issue, 1551, rename VC Specifications Registry to VC Extensions.

Manu Sporny: 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.
… 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.
… Any objections? The only downside here is the pain that Ivan will go through to put redirects in place.

Will Abramson: +1 makes sense to me.

Kevin Dean: +1.

Joe Andrieu: +1.

Ivan Herman: 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.

Manu Sporny: 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.

Dave Longley: +1 to manu, VDR is totally different from VC Specification Registry, so good to make it clearer they are mostly unrelated.

Dave Longley: +1 to VC Extensions.

Manu Sporny: 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.

Ivan Herman: 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.

Manu Sporny: also, yes, we need to track down where we first defined VDR.

Manu Sporny: yes, +1 to clean up the terminology that we use.

5. Detached payloads can be used (pr vc-jose-cose#292)

See github pull request vc-jose-cose#292.

Gabe Cohen: It came to my attention that there’s a PR in JOSE-COSE that we should discuss.

Michael Jones: 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.

Manu Sporny: The reason this surprised me is because I don’t think we use detached signatures anywhere else in the ecosystem.
… We see a very large payload followed by a very small signature payload without reference to the original.
… I don’t understand what the use case for that is.
… If we’re going to support this, we probably need to talk about how that signature is associated with the payload.
… It feels like it could lead to a number of security concerns. I want to know what the concrete use case is.
… 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?

Michael Jones: 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.
… 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.

Joe Andrieu: 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?

Ivan Herman: Without going technical, it’s a procedural thing. My understanding is that the fact of having the detached signature is something that the standard allows.
… 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.

Michael Jones: That’s correct, and likewise COSE defines the mechanism for detached signature.

Manu Sporny: 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.

Kevin Dean: associate it with the original payload.

Manu Sporny: 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.
… I’m fine with staying silent on it, not with putting examples throughout the specifications.

Michael Jones: 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 of what we specify. We get the size savings of not doing the encoding. That is a use case.

Joe Andrieu: seems like Mike’s payload is not a VC, as in application/vc, but something else.

Manu Sporny: I would be find with us staying silent on it. Someone out there that is implementing this would be good to hear from.
… It raises a whole bunch of other questions that have not been answered.

Gabe Cohen: We do use detached payloads. We haven’t explored COSE yet, but will ask my team.

6. Controller Document Issue & PR Processing.

6.1. Remove references to “proof purpose”. (pr controller-document#41)

See github pull request controller-document#41.

Manu Sporny: 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.

Michael Jones: Dave Longley has a textual change request. It has been addressed.

6.2. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Joe Andrieu: 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.
… There are some URIs where you cannot specify the controller, and we need a way to explain that conundrum.

Will Abramson: 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.

Phillip Long: Doesn’t did:tdw update controller docs?

Dave Longley: +1 to Manu, VDR is root of control, it consents to setting controller (or not).

Manu Sporny: 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.

Joe Andrieu: 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.

Manu Sporny: 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.

Dave Longley: https://github.com/w3c/controller-document/issues/33#issuecomment-2299498954 <– i wrote comments here on my thoughts.

Manu Sporny: It will check the values in the document, but it won’t merge it with the controller document itself.
… The controller field tells you which entities have the right to update the document, and those rules are enforced by the VBR.

Joe Andrieu: 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.

Will Abramson: 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?

Dave Longley: 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 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,.

Joe Andrieu: 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.

Manu Sporny: Joe, you said that the controller must be used. I don’t think we’re saying that.

Joe Andrieu: If it’s there, it’s a breaking change.

Manu Sporny: If you use the feature, you must use it this way.
… Will asked about did:ion, did:web, did:key, etc.
… did:key doesn’t need this property.

Joe Andrieu: breaking for did:web, did:key, did:btcr.

Dave Longley: 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.

Manu Sporny: In did:web, the controller is the controller of the website.
… There is a change log that goes along with the DID document as it changes with time, and that is signed by entities.
… 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.

Joe Andrieu: but did:key does have this property.

Dave Longley: but if a VDR provides such a feature, it SHOULD allow specified controllers to use that feature.

Joe Andrieu: 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.

Manu Sporny: hmm, I just checked the did:key spec and it doesn’t use controller.

Joe Andrieu: which was my point: specs today do not use the controller property in this way. they use it differently.

Joe Andrieu: https://w3c-ccg.github.io/did-method-key/#example-2-an-example-of-a-did-key-did-document.

Joe Andrieu: it is on the did:key spec.

Gabe Cohen: We’ll come back to it next week.

6.3. Context section consistency issue 10 (pr controller-document#43)

See github pull request controller-document#43.

Ivan Herman: 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.
… It says in a non-normative note that various applications use this term in their own way.
… It’s a relatively large surgery by removing things.

6.4. Other controller document issues/pr-s.

Gabe Cohen: see https://github.com/w3c/controller-document/pull/44.

Gabe Cohen: see https://github.com/w3c/controller-document/issues/21 Data model reference.

Gabe Cohen: see https://github.com/w3c/controller-document/issues/37.

Gabe Cohen: see https://github.com/w3c/controller-document/issues/35 – all need PRs.

Ivan Herman: For issue 21, it’s up to Manu. He’s supposed to come up with a PR to solve it.

Gabe Cohen: I will reassign it.

Manu Sporny: I noted that we have Brian on the call today and we’re having a discussion on media types.
… We’ve got two proposals. Brian, I need clarification on potential formal objection status.

7. reconcile media types with VCDM media types (issue vc-jose-cose#282)

See github issue vc-jose-cose#282.

Manu Sporny: See in particular https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2296998704.

Gabe Cohen: Brent asked that we not spend time on it on this call but happy to take a minute.

Manu Sporny: Mike, it would be good to get your feedback on proposal 1 vs. proposal 2.
… Brian, the thing I need from you is that you said you would formally object to proposal 2, but I need clarification on that.

Kevin Dean: 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.

Manu Sporny: Your question in the PR was about objecting to media type registrations within the IETF. That’s a different forum.
… That’s the clarity I was looking for.

Dave Longley: selfissued: https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2296998704 <– these proposals.

Michael Jones: 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.

Gabe Cohen: https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?pli=1&gid=179611341#gid=179611341.