Verifiable Credentials Working Group Telco — Minutes

Date: 2023-08-23

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Paul Dietrich, Sebastian Crane, Greg Bernstein, Benjamin Young, Manu Sporny, Hiroyuki Sano, Shigeya Suzuki, Gabe Cohen, David Chadwick, Phillip Long, Dave Longley, Andres Uribe, Orie Steele, Joe Andrieu, Ted Thibodeau Jr., Chris Abernethy, Przemek Praszczalek, Kevin Griffin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Sebastian Crane, Dave Longley

Content:

Phillip Long: pl-asu has joined #vcwg.

Brent Zundel: please indicate your presence or not at TPAC using the online form.

1. Work Item status updates/PRs.

Gabe Cohen: I am working on the VC-JSON test suite and work is going well.

Gabe Cohen: https://github.com/vc-json-schema-test-suite.

1.1. Update controller document reference (pr vc-data-integrity#99)

See github pull request vc-data-integrity#99.

Manu Sporny: Orie raised the PR; it has had a number of reviews which are approximately 50-50 for and against. It doesn’t seem like there will be consensus.

Orie Steele: I think we should copy the content into VC JOSE/COSE, and we should live the vc-data-integrity PR open until that or another strategy is completed. I agree that the vc-data-integrity PR is unlikely to gain consensus.

Manu Sporny: I wonder if we should convert it to an issue in the VC JOSE/COSE specification. I also think that copying-and-pasting is a risky strategy for spec text.

Orie Steele: We could promote the use of Multibase, and not mention JWK at all.
… I don’t feel that the content of VC data integrity is acceptable.
… I think there is an opportunity to reduce market confusion by ‘picking a side’ between Multibase and JWK.

Manu Sporny: I don’t want to ‘pick a side’; that’s not what I think the specification is trying to do. We shouldn’t force things on markets, because it would split communities of implementers.

Orie Steele: I don’t agree, and I believe we are perpetuating a major reason that we don’t see market adoption of these specifications.

Dmitri Zagidulin: @Orie - and you think it’ll help adoption to say, in the spec, “Oh, people who implemented Multibase, go ahead and re-do everything in JWK”?

Sebastian Crane: I think there is a philosophical issue and Manu alluded to that. There’s the issue of whether or not VCs should essentially force a specific technology to facilitate the whole working of the ecosystem or if it’s better to let the implementers decide.
… There’s also the technical merits of the different key formats.
… I think those debates are tangential, I think we can talk about those merits separately and I recommend creating an issue to document the differences in a collaborative way that can guide those decisions later on.

2. Fate of BBS.

Orie Steele: I don’t believe there has been any further progress on the BBS work.

Dave Longley: +1 to let what Orie said happen – let the work progress and if it makes it further along it does, otherwise it doesn’t.

Orie Steele: See https://github.com/w3c/vc-di-bbs.

Manu Sporny: I agree that there is not adequate work on BBS. Have you heard, Orie, whether Matter is continuing to work on it?
… Digital Bazaar would be happy to contribute to the specification if Mattr will be working on it.
… We could extend the VCWG’s charter in order to get BBS published, and Digital Bazaar has an interest in unlinkable signatures. Digital Bazaar doesn’t think that is too big of an issue.

Orie Steele: I don’t want to speculate about Mattr, but Transmute isn’t planning to support eddsa-sd.
… I don’t think we should extend the charter.

Greg Bernstein: I’ve been working on BBS in the IETF.
… RDF Blank Nodes can be handled correctly. Although it’s not my specialty, ecdsa-sd seems to do exactly what we want.
… I have a BBS implementation that I intend to experiment with. I am optimistic that the basics are adequate to support BBS in VCs.

Brent Zundel: As a chair, I’m comfortable with postponing a decision about BBS until the other securing methods are through CR.

Orie Steele: I suggest we start looking for an editor to replace me, we don’t plan to implement it, and I don’t think I have the cycles to manage it.

3. Issue Triage.

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

3.1. Section title and contents mismatch on “Complex Language Markup” (issue vc-data-model#1254)

See github issue vc-data-model#1254.

Sebastian Crane: Is this considered important enough to be its own bullet point in security considerations or is it best practice to just know it?

Manu Sporny: I would suggest ‘Post-CR’ for this issue. I don’t think we should add normative text to the specification about this issue.

Sebastian Crane: I would like to agree with Manu and have the extra justification for post-PR is that this can be said about anything in RDF; we can put any content anywhere and it’s up to implementers to be careful in what they pass in what security context they want to.

3.2. N3 rendering of Verifiable Claims Examples problems (issue vc-data-model#1248)

See github issue vc-data-model#1248.

Manu Sporny: This has to do with the ‘verifiable credential graph’ language that some would like, and also relates to the diagrams. I think Henry got it right, and suggested some post-CR modifications we could make.

Brent Zundel: I’m not hearing any objections to this being post-CR.

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

See github issue vc-data-model#1247.

Brent Zundel: I believe all the horizontal reviews are before CR.

Manu Sporny: I think we can pick-and-choose, as not all of them are requesting normative changes.

Dave Longley: +1 to not ask for review until issues addressed.

Brent Zundel: Once we go to CR, we’ll be asking PING for another review, so not having addressed those would be awkward.

Manu Sporny: We can avoid asking for another review until we’re ready.

Brent Zundel: Yes, that will work.

Manu Sporny: I think this is post-CR.

Sebastian Crane: Thank you. So, my gut feeling is that this is Pre-CR, there are a lot of situations where privacy and security is left up to implementers. The general record is that implementers don’t address those adequately. Since VCs have at heart security and privacy, I think we should have a go at including statements like “you should not keep PII in this manner for this amount of time” as that might take a while to resolve.

Manu Sporny: I am very concerned about having that discussion in this group. This is because it’s not testable, and that there are use-cases where retention may be required by law.
… The timeline is too tight in my opinion.

Greg Bernstein: +1 to post CR.

Sebastian Crane: I’m not suggesting in response to Manu. I’m not suggesting we add normative statements, but I’m suggesting we prioritize discussion about that issue to see if there are any normative statements that are effectively statements. Like what you said, Manu, about requiring something in one context and not others. We should prioritize figuring these things out that we’ve been notified of.
… Given what I’ve just said, I think I should be assigned and I’ll see what I can do.

3.4. Strengthening Trust Boundaries for Holder Software in Verifiable Credential Processing (issue vc-data-model#1246)

See github issue vc-data-model#1246.

Brent Zundel: I am not sure what we could say about the topic considering our own charter.

Dmitri Zagidulin: +1 to post-cr on 1246.

Manu Sporny: +1 to handling this during CR.

Brent Zundel: I don’t believe we are qualified as a WG to make this Pre-CR.

3.5. Mitigating Location Correlation via Common Issuers (issue vc-data-model#1245)

See github issue vc-data-model#1245.

Manu Sporny: +1 to this being a security consideration, post CR.

Brent Zundel: This is a security consideration. This is less of a data model aspect; maybe this is Post-CR.

Greg Bernstein: +1 1245 post CR.

Sebastian Crane: Essentially my comments regarding the previous issue apply to all of the ones from PING. We don’t have to have normative statements, but Post-CR could just be undesirable given how critical these things are.

Manu Sporny: To address Sebastian’s concerned, maybe we should add a topic specifically for discussing the PING review in general.

Greg Bernstein: Post CR I may have more time to help with PING items…

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

See github issue vc-data-model#1244.

Manu Sporny: I don’t know what normative language we could add to address the issue.
… I think it’s good advice, but I don’t think a normative statement is appropriate.

Ted Thibodeau Jr.: Privacy considerations aren’t necessarily about normative language. They’re considerations.

griffin-again-again: griffin-again-again has joined #vcwg.

4. Issue Discussion.

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

4.1. Add guidance on ignoring optional fields (issue vc-data-model#1027)

See github issue vc-data-model#1027.

Brent Zundel: Kristina was assigned, but is not present. Orie has left the meeting.

4.2. Indicating Encrypted VCs in VPs (issue vc-data-model#938)

See github issue vc-data-model#938.

Sebastian Crane: Generally, when people say “optional fields” are they referring to fields that are absent from the RDF or simply have a null value?

Brent Zundel: The issue should tell you that.

Sebastian Crane: I’ll take a look.

David Chadwick: What happens if an optional field is present – can you ignore it?
… an important issue is whether optional fields cans be ignored by processors even if they are present.
… We wanted this feature in a project I was working on last year. I don’t work on that any longer, so we can drop the issue now.

Manu Sporny: There is some interest in it.