Verifiable Credentials Working Group Telco — Minutes

Date: 2024-03-13

See also the Agenda and the IRC Log

Attendees

Present: Michael Jones, Ivan Herman, Will Abramson, David Chadwick, Brent Zundel, Manu Sporny, Ted Thibodeau Jr., Jennie Meier, Dave Longley, Paul Dietrich, David Waite, bibgbluehat, Joe Andrieu, David Lehn, Benjamin Young, Steve McCown, Dmitri Zagidulin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Greg Bernstein

Content:

Ted Thibodeau Jr.: previous meeting: https://www.w3.org/2024/03/06-vcwg-minutes.html.

1. BBS Data Integrity CR proposal.

Manu Sporny: sorry I didn’t write a statement for BBS.

Manu Sporny: CR ready draft is here: https://w3c.github.io/vc-di-bbs/CR/2024-03-28/.

Manu Sporny: have prep’d a CR ready draft, in the same way as other DI specs…
… BBS supports unlinkable signatures, hence its importance.

Ivan Herman: date is set for March 28th.
… test suite?
… I’ve created a approval request draft in the repo. HR references?

Manu Sporny: The BBS test suite is here: https://github.com/w3c-ccg/vc-di-bbs-test-suite.
… procedure, go to CR then test suite or test suite then CR…
… can put test suite and implementation report list…
… I’ll fill out transition request stuff.

Ivan Herman: will submit request to management with pointer to the repo and install the file to /TR right away. Only when the transition is approved.

Manu Sporny: I agree with Ivan’s proposed direction on processing the CR Draft.

Proposed resolution: We will publish BBS Data Integrity Cryptosuites v1.0 (https://w3c.github.io/vc-di-bbs/CR/2024-03-28/) as a Candidate Recommendation Snapshot with a goal to publish on March 28, 2024, and will use echidna to automatically publish Candidate Recommendation Drafts. (Brent Zundel)

Manu Sporny: +1.

Ivan Herman: +1.

Dave Longley: +1.

Dmitri Zagidulin: +1.

Ted Thibodeau Jr.: +1.

Benjamin Young: +1.

David Lehn: +1.

Joe Andrieu: +1.

Greg Bernstein: +1.

Jennie Meier: +1.

Will Abramson: +1.

Paul Dietrich: +1.

Brent Zundel: +1.

Resolution #1: We will publish BBS Data Integrity Cryptosuites v1.0 (https://w3c.github.io/vc-di-bbs/CR/2024-03-28/) as a Candidate Recommendation Snapshot with a goal to publish on March 28, 2024, and will use echidna to automatically publish Candidate Recommendation Drafts.

2. Bitstring Status List PING issues.

Brent Zundel: https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Aprivacy-needs-resolution.

Brent Zundel: all the issues raised, only a couple need group input.

Manu Sporny: suggest all but one is editorial.

2.1. caching status lists as a mitigation for identifying when the holder visited a verifier (issue vc-bitstring-status-list#144)

See github issue vc-bitstring-status-list#144.

Manu Sporny: PING wants normative guidance on caching behavior on status list.

Dmitri Zagidulin: (yeyyy normative guidance!).

Manu Sporny: if we put MUST we need to test it; Not sure how we would test it in this group.
… best we can say is SHOULD cache rather than MUST.

Dave Longley: +1 to SHOULD.

Dmitri Zagidulin: +1 to SHOULD.

Manu Sporny: would prefer SHOULD.

Brent Zundel: why don’t we simply ask implementers whether they do cache. It is lame test, but may work.

Ivan Herman: agree with you. The goal of testing is to see if the recommendation is implementable…

Brent Zundel: other comments on this issue?

Manu Sporny: Fine, but concerned with precedent.
… Maybe the way we implement this is to add a field to each implementations implementation config file… “iCacheStatusListsISwear”: true.

Brent Zundel: I hear the concerned. This group has had a commitment to developing solid test suites. I think we are okay.

Manu Sporny: I agree with Brent’s analysis.

Paul Dietrich: arguing MUST may be too restrictive.

Manu Sporny: I also agree with Paul’s concern.

Dave Longley: “yes, my implementation caches when validUntil is present”.

Brent Zundel: editors of bitstring stat list, do you have what you need?

Manu Sporny: yes.

Dave Longley: +1 to pauld_gs1’s concerns, i think we don’t want to lock in caching rules either.

Dave Longley: (i.e., it would be good to allow better caching rules over time with experience).

Manu Sporny: I’ll take a shot at caching rules, with a MUST and otherwise will backoff to a SHOULD.

Brent Zundel: could have a MUST with recommended caching rules.

Dave Longley: +1 to something like what Brent said around caching rules.

2.2. information revealed by status updates (issue vc-bitstring-status-list#146)

See github issue vc-bitstring-status-list#146.

Manu Sporny: multi-status entries PING – this could be more dangerous to privacy than “simple status list”.
… “message” put arbitrary message allows issuer to add new types of status dynamically.
… explanation of the privacy concern and data leakage opportunity.

Dave Longley: e.g., issuer publishes, after the fact, that the credentialSubject likes Nickelback, without their consent.

Manu Sporny: other info can be exposed after the fact. PING wants this written up.
… feature is largely for traceability, but can be problematic in other cases.
… can even be sensitive in supply chain. This “messages” feature will have quite a write up in privacy section.

Joe Andrieu: surprised this is here. A bit too open ended.

Manu Sporny: half agreeing with you Joe…

Greg Bernstein: manu/JoeAndrieu: discussion…

Joe Andrieu: arbitrary messages stuff in the spec?

Dave Longley: +1 to Joe’s concerns.

Manu Sporny: +1 to Joe’s concerns (but not to the level that DB would object to it going in).

3. Work Item Status Updates/PRs.

Manu Sporny: quick update VC DM: down to 11 issues, can knock that down to 5 or 6 in a couple weeks.
… status list try to get to 2nd CR.
… status list trying to resolve all issues that PING raised.

Michael Jones: JOSE/COSE working on examples. After that we’re ready for CR.

4. VCDM Issue Processing.

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

Brent Zundel: no meeting next week, IETF meeting.
… would like for issues without activity, mark as pending close. Then next meeting decide to close. Inputs?

Manu Sporny: +1 to Brent’s proposed plan.

Manu Sporny: agree, makes me a bit nervous.

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

See github issue vc-data-model#1254.

Manu Sporny: I’ll continue to work on this.

4.2. first example contains an http url identifying a credential (issue vc-data-model#1432)

See github issue vc-data-model#1432.

Brent Zundel: Gabe agreed to do a PR, he’s not here… I’m marking pending close. Will reach out to Gabe.

4.3. Define verification material find replace public keys (issue vc-data-model#1197)

See github issue vc-data-model#1197.

Brent Zundel: assigned to X, manu said he will take it. manu: still planing to work on this.

4.4. Non-normative changes from Jeffrey Yasskin’s review (issue vc-data-model#1348)

See github issue vc-data-model#1348.

Brent Zundel: will not be marked pending close. Jeff Y. review. manu: trying to address as many as possible.
… folks if you want to raise a small PR, please do, greatly appreciated!

David Chadwick: section on trust model Jeff Y. wants quite a lot. I’m willing to work on but need more discussion. Break out into.
… separate issues.

Manu Sporny: can skip section 5.2, will provide commit for each checkmark. agree trust model changes require discussion.

4.5. What does the hash values in §B.2 mean? (issue vc-data-model#1442)

See github issue vc-data-model#1442.

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

Brent Zundel: there is a PR, positive review, changes from TallTed. Please review. Should be merged soon.

4.6. Do we need sha3-512 in the vocabulary tables? (issue vc-data-model#1455)

See github issue vc-data-model#1455.

Manu Sporny: add crypto hashes to files referred to. Disagreement on whether SHA-256 is enough, then folks wanted SHA-384 then why not 512.
… then why not a CLI that everyone has, then OpenSSL, but different on different platforms.
… NIST guidelines, PQ in year 2035, SHA-256 good until 2035.

Steve McCown: FYI, Apple us launching PQ for iMessages in the near term: https://security.apple.com/blog/imessage-pq3/.

Manu Sporny: so we have confirmation from NIST, so we should backoff multiple hashes.
… should change all hashes across the board for SHA2-256.

Ivan Herman: OpenSSL on Mac doesn’t have SHA-3. It is possible to install alternative that has sha3, but a bit tricky… Not everyone will do that…

Dave Longley: i.e., no wide, default support for sha3.

Ivan Herman: happy to write a PR if group agrees. Only when PR 1454 is merged. Don’t want merge conflicts.
… will write PR for DI spec to have everything aligned.

Joe Andrieu: disagree, we shouldn’t get rid of extensibility.

Manu Sporny: to be clear a maintenance group can publish at any time. If SHA-256 is broken, many things would need to be rev’d.
… many things more important that hashes of vocabulary files. This is different from the cryptography used in ECDSA, EDDSA, etc…
… This is for vocabulary files.

Michael Jones: If SHA-256 is broken, then every piece of software that uses crypto will be broken.

Manu Sporny: Completely agree with Mike Jones… “It’ll be a frikkin’ big deal” <– YES! :).

Dave Longley: +1 to Mike.

Brent Zundel: closing meeting for today, not meeting next week. Thanks.

5. Resolutions