Verifiable Credentials Working Group Telco — Minutes

Date: 2023-11-15

Attendees

Present: Ivan Herman, Ted Thibodeau Jr., Sebastian Crane, Sebastian Elfors, Paul Dietrich, Nicholas Steele, David Chadwick, Orie Steele, Dave Longley, Brent Zundel, Przemek Praszczalek, Joe Andrieu, Dmitri Zagidulin, Andres Uribe, Benjamin Young, Will Abramson, Chris Abernethy

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Sebastian Crane, Dave Longley

Brent Zundel: We’ll start with an introduction to related work that is beginning in the IETF, continue with work items, then finish with issues. We are on track for Candidate Recommendation for the core data model by mid-December. We’ll be focusing on meeting that goal.

1. poll results.

Manu Sporny: We should review the results from the poll.
… Perhaps people could emote here to add late votes?

Joe Andrieu: what’s the URL for the poll?

Dave Longley: https://www.opavote.com/en/vote/5254957337935872.

Manu Sporny: The context is that we decided a few weeks ago to run a poll. We wanted to change the name of a certain aspect. It looks like we’ll choose to ‘Credential Type-specific’ processing.

Orie Steele: Of these options, “Credential Type” is probably the best, but it omits the fact that the context can change information regardless of credential type.

Manu Sporny: I have already created a PR. I suggest that we close the poll and I can modify the PR to show the chosen result.

Dave Longley: Orie: we should mention immutable or “semantically immutable” contexts better in the section.

See github pull request vc-data-model#1351.

See github issue vc-data-model#1290.

Orie Steele: There was also a thread in the W3C CCG on this topic recently… https://lists.w3.org/Archives/Public/public-credentials/2023Nov/0030.html.

Joe Andrieu: I appreciate the term ‘limited’ but I don’t like the term ‘unlimited’. I think that could be a problem.

Joe Andrieu: +1 to get us unstuck.

Manu Sporny: The poll is not a binding vote, so we can still take into account other views.

Joe Andrieu: I’ll add here (so the meeting can move on) that I also don’t think the distinction is valid. It isn’t a choice between applications that can work with any credential or those with specific credentials. =(.

Brent Zundel: It is OK to have a compromise, but I would like to avoid spending further time on the topic during this meeting.

2. FYI IETF credential work.

Orie Steele: https://datatracker.ietf.org/doc/html/rfc5755.

Orie Steele: https://datatracker.ietf.org/wg/privacypass/about/.

Orie Steele: One of the interesting things is the different ways in which people process claims in the context of security. There has been similar work to ours in the IETF, for instance RFC5755, which has similar terminology like ‘holder’.
… There is also Privacy Pass, which can be FIPS compliant because it uses RSA.
… JWTs and CWTs were developed in the IETF too.
… I think there’s interest within IETF about the architectural aspects of interoperability between these. There has been duplicated effort which sometimes relate in differences, for instance a feature added to CWT and later to JWT.
… There is usually a draft charter that turns a ‘birds of a feather’ (BoF) into a working group.
… COSE and JOSE have different features for credential use-cases, and some in the IETF would like to create a new credential format specifically to cater for these.
… Originally we had VC-JWT (now VC JOSE-COSE).
… We have RDF and JSON processing capabilities in the Verifiable Credentials specification. There was another third way which only used JSON web tokens.
… JWTs can still be used. It isn’t as friendly to the open-world model, and that is controversial, but there is interest in an IETF specification specifically for JWTs.
… There were lots of people who attended the BoF about credentials in the IETF. There were people concerned about violation of civil liberties during the meeting. Others were interested in commercial uses including airline travel.

Dave Longley: https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md.

Manu Sporny: SPICE - Secure Patterns for Internet CrEdentials (SPICE) at IETF.

Orie Steele: ^ its a draft charter, and the working group did not form, the charter and deliverables will likely need to change.

Dave Longley: I believe that the SPICE charter is the basis for what Orie was talking about. It uses the term ‘Verifiable Credentials’, and I would suggest avoiding using that specific term to avoid confusion.
… I believe that the VCWG has been addressing issues that came up in lots of different earlier IETF specifications. We created the three-party model which distinguishes our work. The ‘shared registry’ improves upon earlier work. We also introduced a data model for claims.

Orie Steele: https://datatracker.ietf.org/doc/html/rfc5755#section-4.2.2 (Holder as defined by attribute certifcates in 2010).

Dave Longley: The fact that the VCWG re-used existing RDF functionality is irrelevant. I feel like the SPICE charter describes exactly what we are already doing.
… From the charter: “Short list of lessons learned (from a VCWG work item): Expressive data models, such as RDF, are not necessarily suitable for all use-cases outside W3C”, but the charter also says: “The working group will NOT address specific credential use cases” … another lesson: “Reusing existing semantics that fit the domain well, such as provided by the JWT/CWT Claims registry, provide can improve interoperability, significantly” … but the charter says: “Retaining semantic interchangeability is not in-scope”.

Orie Steele: the works is already being repeated in several different ways at IETF, for example privacy pass, oauth, and ace working groups.
I’ve certainly learned a lot of lessons from this group : ).
or better yet, raise them on the mailing list.

Brent Zundel: I am sure the authors would appreciate the feedback.

Orie Steele: the IETF does its business on their mailing list, so it is expected that your feedback will be addressed if left there.
… We didn’t gain enough consensus at the BoF to consider starting a working group until further questions have been answered.
… I think I agree with dlongley that the use of the term Verifiable Credential to refer to anything other than a JSON-LD claim is misleading.

Dave Longley: +1 to another word being used in SPICE.

Orie Steele: Maybe ‘Digital Credential’ is a better term to use.
… Privacy Pass takes a different approach to addressing the issues from earlier work.

Dave Longley: if there’s a core architecture document that can “fit in” and “describe all of these other specific work items in other places”, +1, that could be useful.

Orie Steele: I believe it was started after Attribute Certificates became a thing.
… I think it’s obvious that work has been continued in the IETF that doesn’t use the conventional approaches.
… There’s a big difference in privacy considerations been OAuth and Privacy Pass.

Dave Longley: yes, -1 to yet another competitor in the space.

Manu Sporny: My biggest concern is that during the IETF meeting, I heard lots of people perceive the new charter to be a competitor to the W3C VCWG. This is partly due to aspects in the charter that explicitly noted flaws of the VCWG work.

Orie Steele: When we moved the “pure JWT” approach out of VC-JWT, we were explicit that the work would probably be picked up elsewhere.

Orie Steele: imo we made the right move by dividing things like this.

Dave Longley: Orie: that’s just a securing mechanism. (that’s what I believe this group thought).

Manu Sporny: It was upsetting that the VCWG knew of this, but did not address it. What I have heard from the community at IETF was different from what was described here.

Orie Steele: https://datatracker.ietf.org/group/spice/about/.

Manu Sporny: This raises a bunch of questions around vc-jose-cose.

Orie Steele: manu: I agree, it raises the question of if its worth doing that work at W3C…. and I have been clear before, I am not sure W3C is the right place to do that work.

3. Issue Discussion.

Brent Zundel: We’ll move on to GitHub issue discussion.

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

Brent Zundel: The question that we will tackle today is what steps need to be taken to obtain a proposal for each issue before mid-December.

3.1. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247)

See github issue vc-data-model#1247.

Manu Sporny: This came from the PING review, and I’ll work with Sebastian on it.

3.2. Address Metadata-Driven Correlation (issue vc-data-model#1244)

See github issue vc-data-model#1244.

Brent Zundel: Who can take this work?

Sebastian Crane: I think these ones from the PING review seem to be very similar and I think they should be addressed in a cohesive manner. In the security world one often has faux attacks to gauge the security of a system. Privacy can be different, especially because of aggregate data concerns. Having some kind of mock attack would be good for showing correlating data issues, but the full extent won’t be known until production.
… Lots of academic papers about correlating data and we could apply the work here.

3.3. Add `relatedResource` to `VerifiablePresentation` (issue vc-data-model#1265)

See github issue vc-data-model#1265.

Brent Zundel: I don’t believe we have consensus on this, so let’s discuss it now.

Ivan Herman: I don’t believe we’ll get to agreement on this issue, so I would suggest marking it ‘prepare to close’.

Dave Longley: There is no way to put a VC that’s secured with JOSE into a Verifiable Presentation.
… I’m concerned that if we don’t have a property for it, implementers will invent new ones.

Orie Steele: When you see nested JSON structures it’s easy to seem them as a whole, but the RDF graph is clear that they are separate entities.
… If the N-quads don’t reflect reality, the solution is to update the JSON-LD context.

Dave Longley: Orie: using a URL in verifiableCredential will just drop it.

Dmitri Zagidulin: I think it’s surprising to many that you can’t include JOSE-secured credentials in a Verifiable Presentation. I agree with dlongley that if we don’t include our own mechanism, either people will invent new methods or use JOSE version of VCs. We know that the ecosystem is divided between JSON-LD support and JOSE support.

Orie Steele: to be clear, you can…. go ahead and test it.

Orie Steele: whether the information is “correct” with respect to RDF data model is a separate question.

Orie Steele: dlongley: not in the security format we use.

Manu Sporny: +1 to “property that lets you do that”, the more specific the better.

Joe Andrieu: The fact that we can’t include JOSE-secured credentials in a VP is an issue. I think we could create a new property for ‘external proof’ so that there’s a semantic link.

Dave Longley: I would prefer there to be a specific property for it too, but that didn’t get consensus. Therefore ‘related resource’ was used as a fallback.

Orie Steele: You can use related resource to serve a context, that doesn’t drop credentials by reference from the graph.

Dave Longley: If we added a new property, we would need much more effort and more properties to support it. I think we need Related Resource anyway, and if we need a property for JOSE support add that too.

Dmitri Zagidulin: what are the objections to adding ‘relatedResource’ to a VP?

Orie Steele: +1 ivan.

Dave Longley: “relatedResource” was proposed by Mike Prorock / Orie to express context hashes in VCs.

Dave Longley: VP can also have custom contexts.

Ivan Herman: The Related Resource is very loosely defined at the moment for external data with integrity, and I think it would be a mistake to use that for the specific purpose of supporting JOSE-secured VCs in VPs.

Orie Steele: its different thing to secure context, or include credentials by reference.

Manu Sporny: +1 to well-defined property for the use case we’re trying to solve… relatedResource doesn’t sound like it?

Dmitri Zagidulin: @manu - we still need relatedResources to hash-secure @contexts on the VP.

Dave Longley: “relatedResource” was good enough for context hash information in VCs, why not in VPs? … if we want yet another property for JOSE-secured/other-envelope/external-secured VCs, that’s good too.

Ivan Herman: I would support a specific new structure for JOSE support. I recall that Joe had strong opposition to Related Resource.

Manu Sporny: dmitriz, who is doing that right now? What implementer is shipping that feature?

Orie Steele: including properties that are specific to a securing format, is a layer violation imo.

Dave Longley: VC-JOSE-COSE could add context hashes to its format.

Dave Longley: Orie^.

Dmitri Zagidulin: First question we have is what to do with JOSE-secured credentials. The second question though is what to do with SRI digests.
… What are the objections to adding the property to the VP.

Dmitri Zagidulin: I did specifically highlight that it IS two separate issues.

Dave Longley: +1 to dmitri.

Orie Steele: dlongley: security best practices seems to imply securing bytes, when they are JSON-LD bytes representing a conforming document, thats all that is needed, imo.

Dave Longley: Orie: non-three-party model best securing practices do that.

Manu Sporny: I believe that the two use-cases can be described as 1: support for JOSE-secured VCs in VPs, and 2: to support secured contexts.

Orie Steele: +1 manu.

Ivan Herman: +1 manu.

Manu Sporny: If we can use the same property for both, that would be great.

Joe Andrieu: I agree with what manu said. I don’t believe we need an arbitrary integrity facility, and that could open up vulnerabilities with unknown binary content.

Brent Zundel: I’ll close the Related Resource issue so two new issues can replace it.

Dmitri Zagidulin: @JoeAndrieu - what vulnerabilities are you referring to? digest hashing /anything/ is safe.

Joe Andrieu: @dmitriz yes, but you are trusting the untrustable. This isn’t about trusting an issuer, it’s trusting the holder.

Manu Sporny: +1 to what JoeAndrieu said above – that’s the problem w/ relatedResource in presentations.

Manu Sporny: (well, one of them) :).

3.4. Cross-check the `domain`/`range` statements in the vocabulary with the VCDM spec (issue vc-data-model#1319)

See github issue vc-data-model#1319.

Manu Sporny: I was able to review Ivan’s changes; thank you Ivan.

Ivan Herman: I responded to the issues manu raised.

Brent Zundel: I expect that the results of the conversation will lead to a pull request with changes.