Verifiable Credentials Working Group Telco — Minutes

Date: 2024-04-24

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Paul Dietrich, Michael Jones, Ted Thibodeau Jr., Anil John, Manu Sporny, Jennie Meier, David Chadwick, Dave Longley, David Lehn, Hiroyuki Sano, Phillip Long, Joe Andrieu, Benjamin Young, Dmitri Zagidulin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Phillip Long

Content:

Brent Zundel: agenda listed.

1. Digital Credentials API.

Manyu: current discussion around the digital credentials API.

Ivan Herman: See Proposed FedID WG Charter.

Manu Sporny: https://github.com/w3c/strategy/issues/450#issuecomment-2071044945.

Manu Sporny: suggested the credential API be included in the charter.
… could be very positive if done right.

2. TPAC.

Brent Zundel: https://www.w3.org/events/tpac/2024/tpac-2024-hybrid-meeting/.

Brent Zundel: Topic is TPAC.
… should we meet at TPAC, if so, what topics are most important to discuss.

Manu Sporny: +1 for meeting at TPAC.

Brent Zundel: by the time of TPAC we’ll have had a number of specs in CR with implementer feedback, and thus a good time to discuss feedback, finalize testing and exiting CR, notes in progress and what is next for the VCWG?
… sufficient topics to validate having the meeting.

Manu Sporny: gather feedback before TPAC and discussing it there is a good use of the group’s time.
… there are competing meetings that may be problematic but maybe impossible to avoid.

Ivan Herman: could separate the DID and VC working groups to avoid most of the conflicts.
… overlap with federated ID isn’t sufficient to be a problem for the VC WG.

Manu Sporny: would it be a good time to bring Ping or the Security Working group in for a discussion?

Brent Zundel: could see security folks involved that would be useful.

Ivan Herman: Could with advanced scheduling bring in Simone as well.

Anil John: introduces himself to the group from DHS and involved in many working groups. DHS is extensively using W3C Standards in their work.

Manu Sporny: Welcome Anil! :).

Dave Longley: Welcome!

Phillip Long: great to see you Anil!

3. Bitstring Status List CR.

Brent Zundel: https://w3c.github.io/vc-bitstring-status-list/CR/2024-05-09/.

Proposed resolution: Publish the Bitstring Status List v1.0 specification (https://w3c.github.io/vc-bitstring-status-list/CR/2024-CR1/) as a W3C Candidate Recommendation with a target publication date of May 9th 2024 and a CR period of 1 month. (Brent Zundel)

Ivan Herman: +1.

Brent Zundel: +1.

Dave Longley: +1.

Manu Sporny: +1.

Joe Andrieu: +1.

David Chadwick: +1.

Ted Thibodeau Jr.: +1.

Brent Zundel: any changes to this proposal from the group here? (note URL of bitstring status list is going to the same content).

Benjamin Young: +1.

Hiroyuki Sano: +1.

Jennie Meier: +1.

Phillip Long: +1.

Paul Dietrich: +1.

Resolution #1: Publish the Bitstring Status List v1.0 specification (https://w3c.github.io/vc-bitstring-status-list/CR/2024-CR1/) as a W3C Candidate Recommendation with a target publication date of May 9th 2024 and a CR period of 1 month.

Phillip Long: brentz proposal passes unanimously!

Anil John: +1 for me as well.. (New member trying to catch up on process).

4. Test Suites and CR Exits.

Brent Zundel: intend to have test suites for implementers to demonstrate features for the specifications, each with their own test suite. Topic to help understand status of text suites & what needs doing to exit CR?

bigluehat: ECDSA test suite is ready (98% if not 100%) - the next test suite VCDM2.0 then BBS+ and a EDSA slight updates. Have test suite ofc. hours fortnightly 10:00 am EDT. More participation would help.

Benjamin Young: have not seen JOSE/COSE or JSON Schema; plumbing set up for a Mocha based test suite infrastructure.

Brent Zundel: there are test suites in progress for JOSE/COSE but they haven’t reached out to bigbluehat.

Benjamin Young: not implying their way to doing test suites are the only way, they just haven’t heard from some that may be in development.

Manu Sporny: another question - when do we go to a second CR? As soon as each test suite has multiple implementations and 100% coverage we could say we’re ready for a second CR. Assumption nothing will change.
… can do them one by one. Painful for all concerned. But it works. Or queue up all the second CR for one final push. But dependencies between specs becomes problematic.
… Open question on the strategy to get things done. Preference of the group?

Anil John: agree with the need for JOSE/COSE test suites. Use them for trade based credentials. Anil will ping the implementation teams if they can help support the test suites.

Brent Zundel: as with first CR transition the only rule for moving to CR2 is when the editors thing it time.
… whether to do them at once or staggered is up to the group (there are 9 specs going to CR2).

Manu Sporny: oh! I thought we had to do another transition request for CR2! Ok, that makes things way easier (except for Ivan and the webmaster) :P.

Ivan Herman: One misunderstanding - a second CR is NOT reviewed by W3C management. Only the Webmaster and Ivan have to review it. A second CR is relevant if there are normative changes. If only editorial we can ignore it.
… with Ivan’s experience if before proposed recommendation and have had a long CR period we might be asked to do a CR snapshot because it’s the last chance to review it, maybe horizontal review, etc.
… we might want to plan a CR snapshot after TPAC - but there is no reason to rush into a CR snapshot because no normative changes of import made to the documents. Hence, not warranted to do a CRS.

selfiissued: pronounciation of JOSE (think San Jose).

Anil John: Thank you Mike :-).

Manu Sporny: hearing we should be opportunistic. will need CR2 for data integrity specs.

Ivan Herman: no snapshot needed if no normative changes.

5. Work Item Status Updates/PRs.

Brent Zundel: if any work items need reviews now is the time.

5.1. Address Jeffrey Yasskin’s review comments that are Editorial (pr vc-data-model#1464)

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

Manu Sporny: the big ones for VCDM 2.0 are the editorial changes from J. Askin’s (sp) proposed changes. Having more eyes on this would be helpful.

Brent Zundel: reviews of VCDM 2.0 has received positive reviews.

Manu Sporny: he will merge the VCDM 2.0 this weekend. Get your comments in!

5.2. Move lifecycle section to Use Cases. (pr vc-data-model#1476)

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

Manu Sporny: it seems some level of disagreement on PR #1476.

See github pull request vc-use-cases#154.

Brent Zundel: two lifecycle sections in the spec was moved, the second life cycles was going to be incorporated into the use cases document. Moving the second section to that place seemed unnecessary.
… David Chadwick noted there wasn’t any ecosystem section in the spec but the current approach is not to include it and move forward.

Manu Sporny: agrees we don’t need the above sections. If something is missing we should have the discussion in the use cases document.

Ivan Herman: wondering whether it’s worth having an overview document for all the specs we’ve done. For an outsider coming in, it appears extremely messy. Some of the things moved to the use cases doc might better be in an overview doc.

Ted Thibodeau Jr.: Agrees an overview doc is called for. Still doesn’t make sense to TallTed to consider lifecycle as as use case.

Ted Thibodeau Jr.: +1 nobody coming when v3 or v4 is “current” is going to look to v1 to learn the lifecycle.

David Chadwick: the arguments for removing it are spurious. But people who come to VCDM v2.0 without reading earlier versions because so many newbies are coming to the v2 fresh.
… Value i leaving it in because there value for it in V1.

Manu Sporny: maybe use cases is a temporary location for the lifecycle until we have an overview document. We have one from RWOT that may be usable.

Brent Zundel: chair hat on -Brentz will do whatever the group wants to do. If we move forward would DavidC object?

David Chadwick: no he would not object.

Ivan Herman: See Example for a standards’ Overview document for the OWL family.

5.3. Update media types to application/vc and application/vp (pr vc-data-model#1478)

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

Manu Sporny: media types PR…. Should use /vp and /vc - dont’ know how long this last. Should go with clear media types and continue multiple suffix’s discussion in parallel.

Brent Zundel: change media types to something that we know will be approved with the intention of doing multiple structured suffixes until we know what IETF is going to do.

Michael Jones: this is a breaking change to many specs. It’s a set of experts. Selfissued would like to request registration to call the question.

Manu Sporny: we tried to do this 3 years ago and it was rejected that led to the multiple suffixes draft. It’s a breaking change but it’s been barely implemented, and we’re in CR so we can make breaking changes now.

Dmitri Zagidulin: @manu - what’s the downside of just asking for registration? Stuff has changed in 3 years.

Manu Sporny: designated experts take advice from the spec which this case is the multiple suffixes spec which Manu is editor to. No timeline on getting this stuff resolved.

Manu Sporny: dmitriz – it will be rejected, I can guarantee it. At the very least, I will object to it as the editor of the multiple suffixes draft.

Manu Sporny: I also expect the other DEs to reject it, having had this discussion with them for years.

Manu Sporny: I also expect the MEDIAMAN WG to suggest it be rejected, because it’s actively used.

Ivan Herman: we have a timing issue as well. We’ll need to republish the CR right after TPAC which must have the final version of the media types. To do this change to start media type registration will take 3 months and he’s in favor of doing this change right now.

Michael Jones: good data that it was tried 3 years ago. Not clear that the decision 3 years ago would be be the same now. Designated experts have a 2 week response time so that’s not a timing issue. Now we’re basing our path forward uncertain data.

6. Resolutions