Verifiable Credentials Working Group Telco — Minutes

Date: 2023-12-06

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Gabe Cohen, David Chadwick, Manu Sporny, Kaliya Young, Paul Dietrich, Sebastian Crane, Joe Andrieu, Dave Longley, Przemek Praszczalek, Will Abramson, Dmitri Zagidulin, Andres Uribe, Orie Steele, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Sebastian Crane, Dave Longley

Content:

Brent Zundel: Is there anyone who would like to suggest changes/additions to the agenda?
… No changes requested. I think we’ve met each other so we’ll skip introductions and start our first topic.

1. Work Item status updates/PRs.

1.1. Adds a “Securing Mechanisms” section to the directory (pr vc-specs-dir#30)

See github pull request vc-specs-dir#30.

Manu Sporny: This pull request to vc-specs-dir isn’t controversial; we’re going to call them ‘securing mechanisms’ rather than ‘proofs’. This is to address some of jyasskin’s concerns.
… We’ll probably merge it after this call.

1.2. Data Model PRs.

Manu Sporny: See current PRs.

Manu Sporny: We made good progress on the call yesterday, but many pull requests are probably not going to get consensus.
… I don’t think the “RelatedResource for Verifiable Presentations” PR has any blocking issues, so that will probably move forward.

Dave Longley: enveloped seemed ok, but “watermark” did not.

Orie Steele: its ok for status checking to go in, as long as its clearly labeled “validation” and clearly happens after securing mechanism “verification” succeeds.

Manu Sporny: “Enveloped Verifiable Credential” to refer to VCs with external proofs will probably not gain consensus.
… We’re working with implementers to get vc-data-integrity changes through.

Brent Zundel: Any updates on ‘controller documents’?

Manu Sporny: No update yet.

Brent Zundel: How is the JOSE/COSE work going?

1.3. JOSE/COSE PRs.

Brent Zundel: See current PRs.

Orie Steele: There are two open pull requests. One of them is a placeholder PR in case we need to remove registry entries with multiple suffixes. I imagine we’ll close pull request #186 soon if people continue to object to it.
… The other PR #190 should probably be broken up because it’s a little too big. We need to know how it will be related to the verification algorithm of the main data model.

Manu Sporny: I would suggest adding an ‘at risk’ marker on the verification algorithm.

Orie Steele: +1 to at risk marker, and file any specific issues that need to be resolved.

Orie Steele: it not going to be reviewable for much longer :).

Manu Sporny: We could say that ‘we are working on changes’, and because we have hundreds of comments on the issue thread it’s difficult to contribute.
… We could ask people to request changes on the GitHub PR review.

Brent Zundel: I’m seeing change requests from TallTed, Orie and Oliver Terbu.

Manu Sporny: I will raise issues based on Oliver’s feedback.

Brent Zundel: TallTed, you’re one of the people who requested changes on the JOSE/COSE pull request.
… TallTed, if you have changes beyond editorial merely ones, please open a new issue.

Ted Thibodeau Jr.: I am fairly certain that everything that I have requested is editorial.

2. Issue Triage.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3Apost-CR+sort%3Aupdated-asc.

2.1. Update 4.9 Securing Verifiable Credentials (issue vc-data-model#1316)

See github issue vc-data-model#1316.

Brent Zundel: Orie, you opened this issue.
… Is this before or post-CR?

Orie Steele: If all of the issues related to the verification algorithm are resolved, this would be resolved too. I think for now it should be cross-linked and perhaps close it once the verification algorithm discussions have concluded.

Brent Zundel: Course of action is to label it as ‘before CR’ and link it to the other pull requests.

Orie Steele: Yes, that’s correct.
… I’m going to assign this to Mike Jones because of conversations we’ve had about this.

2.2. Default context contains terms outside of the spec (issue vc-data-model#1314)

See github issue vc-data-model#1314.

Brent Zundel: Do we have a sense for whether this issue has been addressed?

Orie Steele: I don’t think we were able to establish consensus to resolve this previously, so I suggest it be closed.

Sebastian Crane: I’m not familiar with this issue, but even if we don’t have consensus to resolve the core essence of what’s being asked. We perhaps have a responsibility to document this within the spec anyway, these issues might be experienced by multiple people until they understand the reasoning for it.

Manu Sporny: We could add some text into the specification explaining how and why the v2 data model includes more helpful properties.

Sebastian Crane: Ok, I’ll raise an issue to add some text.

2.3. Authorized Presenters (issue vc-data-model#1359)

See github issue vc-data-model#1359.

Gabe Cohen: I would like to explore the question of who is authorized to present a credential. I recollect that we discussed this in the past but did not come up with a solution. I would be interested to know what others are doing in this regard.

Dave Longley: +1 that more semantics are needed and should use confidence method.

Manu Sporny: Digital Bazaar aren’t doing this. I imagine that ConfidenceMethod would meet this requirement.

Orie Steele: SD-JWT currently requires you to do this in a special way: you are required to implement support for Confirmation Method, which is the IETF way of doing this.
… If ConfidenceMethod was in the core model, there might be conflicting or redundant ways to express this.
… This is built-in to SD-JWT, so we can’t contradict what’s already the case in SD-JWT’s specification.

Orie Steele: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2.

Dave Longley: to say i’m not sure what SD-JWT does, but i would not expect cnf to cover this use case, more semantics are needed.

Dmitri Zagidulin: The CNF property used to identify the current presenter in SD-JWT, not to list authorized presenters - is this correct ?

Gabe Cohen: sd-jwt-vc has cnf as well https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html.

Orie Steele: We’ve updated the specification so that won’t be up to date any longer.

Orie Steele: also, sd-jwt is still a wg adopted draft…. so… this might all change.

Dmitri Zagidulin: @Orie - looking at https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-01.html , I still see no wording on how an issuer specifies authorized presenters. Only wording on how to use cnf in the DPoP sense.

Orie Steele: not correct summary of what SD-JWT….

David Chadwick: I think it’s probably a bit different with SD-JWT, because the issuer is given unblinded data to a specific entry. Anyone else who gets the credential will be blind to who is presenting it. What the SD-JWT does is ‘blind’ data, but makes disclosures in the clear. The holder is getting the information in the clear.
… It’s not the same as normal Verifiable Credentials because only Holders are able to see the unblinded data. Therefore only the holder is able to present it.

Orie Steele: dmitriz, I am not talking about that draft, I am talking about https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#section-5.1.2.

Dmitri Zagidulin: @Orie - got it, thanks.

Orie Steele: I acknowledge the authors of draft oauth-sd-jwt-vc have a lot of work still to do : ).

Dmitri Zagidulin: @Orie in draft 06, it seems like it’s using the ‘cnf’ property in a way that’s not intended by the DPoP rfc, it should probably be the ‘aud’ claim. But anyways, that’s a discussion for the ietf spec.

Dave Longley: @dmitriz: yup, also note that the current SD-JWT mechanism does not say which person the cnf claims applies to (for multiple holders, etc.).

Orie Steele: We have an entire TR track document.

Brent Zundel: Did that help, decentralgabe?

Gabe Cohen: A little; I’m happy for it to be closed now.

Brent Zundel: I’ll leave this to you decentralgabe.

2.4. Do we need an SD-JWT profile for W3C VCs? (issue vc-jose-cose#191)

See github issue vc-jose-cose#191.

Brent Zundel: I do believe that VC JOSE/COSE is the closest thing that this group will be able to produce in order to address this issue. I’m not sure what else this issue is asking for. We probably wouldn’t have the capacity to create a new document to address this use-case.

David Chadwick: It’s really a hot topic at the moment. It will be implemented in the EU Digital Identity Wallet. It will be demonstrated in the GAIN hot group.
… We don’t have any guidelines at the moment about how this would be used.

Orie Steele: David, please read: https://w3c.github.io/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose.

DavidD: It specifically says that SD-JWT aren’t W3C Verifiable Credentials, which isn’t a good situation.

Brent Zundel: https://w3c.github.io/vc-jose-cose/#with-jose.

Orie Steele: David: https://w3c.github.io/vc-jose-cose/#securing-json-ld-verifiable-presentations-with-jose.

David Chadwick: There is an example for SD-JWTs in VCs, but not in VPs.

Orie Steele: please file issues, or PRs if you want the text to change.

Brent Zundel: It may be that a full specification would be the best option, but we don’t have the capacity to do that at this stage in our Working Group.

Orie Steele: If your customer wants help, feel free to put me in touch.

Manu Sporny: VC-JOSE-COSE is the document that expresses this. I spoke with a customer who was very confused about IETF defining how to make credentials. I agree therefore that there’s confusion. I think we should make sure that they also know there is confusion, and there is an opportunity to clarify things in the IETF specications.

Orie Steele: I would in general, not assume that IETF documents are “done” until they are RFCs.

David Chadwick: Would the editors of the VC-JOSE-COSE be happy to add more description in the specification?
… I think that would be appreciated.

Brent Zundel: Should we move the issue to vc-jose-cose repository?

Manu Sporny: +1 to move to vc-jose-cose.

Orie Steele: Yes, you can do that.

Brent Zundel: I see support in the IRC, so that’s what I’ll do.

2.5. Clarify section on verifiable credential graph (issue vc-data-model#1365)

See github issue vc-data-model#1365.

Manu Sporny: (but not support for ignoring the fact that it’s not clear to readers that vc-jose-cose is THE specification that outlines how to use SD-JWT with VCDM).

Brent Zundel: andres, is this before or post-CR?

Andres Uribe: I think this should be before CR.

Brent Zundel: Who’s willing to be assigned?

Manu Sporny: I am willing to be assigned.

2.6. Clarify the domain and range of the verifiablePresentation.verifiableCredential property (issue vc-data-model#1366)

See github issue vc-data-model#1366.

Andres Uribe: I think that if the clarifications are made in #1365, then I think the point made in this issue is moot. It will also be addressed by the solution that was suggested yesterday of adding a type property.

Manu Sporny: +1 to what andres just said, agree with that direction.

Brent Zundel: Do we need both issues to track the concern?

Andres Uribe: I think one builds upon the other. One would be automatically closed.

Manu Sporny: Maybe changing the title would help. You’re not asking for a rename of the property now, only asking for clarification. So we can change the title of the issue.

Orie Steele: People have been putting Verifiable Credentials in the verifiableCredential property of Verifiable Presentations already.
… Changing this now will be unacceptable to Transmute.
… I suggest allowing either using IRIs or the VCs directly. That’s also consistent with the RDF here.

Orie Steele: I read the minutes.

Brent Zundel: I’ll make this before CR. Who’s willing to be assigned?

Dave Longley: I think Orie is referring to a specific JSON-LD property that has a bug, and once this has been fixed there won’t be an issue.

Orie Steele: dlongley, confirming you are disclosing that https://json-ld.org/playground/ produces invalid N-Quads?

Sebastian Crane: Personally, is this a clarification on whether you can embed the definition of a VC within a VP? Or is this something different?

Brent Zundel: It is related to that. There are RDF concerns about whether … you put the VC thing instead VP.verifiableCredential and that’s ok, a VC that’s been externally secured using a mechanism that uses an envelope, it creates a new data structure so it no longer fits within that property.

Sebastian Crane: So this is an uncontroversial change in the mechanics to our RDF data model.

Brent Zundel: I don’t think I’m comfortable with saying uncontroversial here.

Sebastian Crane: Thank you for the clarification.

2.7. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)

See github issue vc-data-model#1364.

Orie Steele: I would suggest keeping this issue open. We need to know if our registration will be accepted or not.

Brent Zundel: I’m interpreting that as before CR.

Ted Thibodeau Jr.: There’s nothing prohibiting making registrations with multiple suffixes. The question is about how those are going to be interpreted.

2.8. Bug in the context file? (issue vc-data-model#1373)

See github issue vc-data-model#1373.

Brent Zundel: I think this one is before CR.

Manu Sporny: It’s before CR.

Dave Longley: +1 to before CR.

Orie Steele: I would like some elaboration to be in the minutes: could someone explain the essence of the bug?

Dave Longley: It’s not that we have a bug in our context file. It’s that we added terms to make v1 VCs compatible with v2 Verifiable Presentations.
… We needed to make sure that context files for v1 VCs didn’t affect the context files for v2 VPs.
… Some implementations had bugs, some didn’t.
… We should be able to resolve this by nullifying the context as part of these implementations.
… We don’t need to do anything in this WG.

Orie Steele: Sounds like there is no bug in our context, and this issue should be closed. It also sounds like there are buggy JSON-LD processors, that produce inconsistencies, that cause credentials to not verify.

Dave Longley: Orie: It is a reasonable expectation for any software is that there will be bugs from time to time.

Orie Steele: the complicated the software, the more reasonable it is to expect bugs.

Dave Longley: Orie: sometimes! :) … i would say that it’s not a good idea to assume simple software is less likely to be buggy (as this may lead to more likely bugs in such software).

Manu Sporny: You’re coming across as trolling, Orie. Please stop. You asked us to explain something. We did, and now you’re expressing what comes across as mock surprise.

3. Issue Discussion.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+sort%3Aupdated-asc.

3.1. Add mechanism to embed externally secured VCs in a VP (issue vc-data-model#1352)

See github issue vc-data-model#1352.

Brent Zundel: This issue is being addressed by the PR we discussed yesterday.
… I believe that yesterday we decided that the verifiableCredential property should be expanded to allow each object in the array to express its type: whether it is a normal VC or an enveloped VC (actual name yet to be decided).

… We’ve got eleven before-CR issues.
… We have seven still needing discussion.
… If you’re assigned to one of these PRs, we need action: if nothing is in the pipeline to address the issue, we’ll have to postpone it.