Verifiable Credentials Working Group Telco — Minutes

Date: 2022-07-13

Attendees

Present: Brent Zundel, Shigeya Suzuki, Kristina Yasuda, Dave Longley, David Lehn, Michael Prorock, David Chadwick, Michael Jones, Manu Sporny, Ted Thibodeau Jr., Gabe Cohen, Gregory Natran, Samuel Smith, Joe Andrieu, Drummond Reed

Regrets: Ivan Herman

Guests:

Chair: Kristina Yasuda

Scribe(s): Manu Sporny, Orie Steele, Kristina Yasuda

Kristina Yasuda: Our agenda today Participation renewal, Work Mode, and structure of deliverables..

1. Introductions.

Orie Steele: Hi Orie Steele, from Transmute, DID Spec Editor, DID Spec REgsitries, post-quantum key formats..

Justin Richer: Hi, Justin Richer independent consultant, representing Avast here..

Gabe Cohen: I’m Gabe, I work at Block you may have seen our announcements about web5, interested in financial use cases, and json schemas.

Gregory Natran: I work for protagecybertech, consulting with the canadian public sector, current interest is government consumption / production of verifiable credentials.

2. Participation Renewal.

Kristina Yasuda: deadline is july 28th, make sure to renew.

Brent Zundel: there are folks who are still determining status, make sure you resolve that..

3. DID testimonials.

Manu Sporny: https://lists.w3.org/Archives/Public/public-did-wg/2022Jul/0000.html.

Manu Sporny: reminder that DID Core has been approved for REC, the W3C comms team has asked for testimonials, they are due in 2 days… if you have not gotten your testimonial in yet, the cut off is this Friday.
… Get your testimonials in by this Friday July 15th.
… Just respond to the email above to do so..

4. Work Mode.

Kristina Yasuda: we ended last week on editorship.
… there have been some interested parties, do we want the concept of a “lead editor” or a group..
… it can help give the chairs and group a single directly responsible individual.

Brent Zundel: to expand, there are a couple models we are looking at.
… previous vcwg and didwg we encouraged everyone to do PRs editors help merge and cleanup and maintain a single voice.
… epub wg has the editors as the only folks who submit PRs.
… this gives the editors more ability to maintain tone, clarity… at an extra burden.

Manu Sporny: +1 to having a lead editor on each item, +1 to keeping things as we have, where anyone can raise a PR.
… we have benefitted from active contribution from a large group of people, it empowers people.
… I wouldn’t want to see us pick 1 editor where only they open PRs.
… +1 for there being a single person responsible for moving the spec forward… it is more work for editors at the end.
… if you are signing up for the lead editor position.
… we have taken an algorithmic approach for who shows up as editors / authors at the end.
… typically editors have contributed ~25% of PRs in the spec.
… I like our existing process.

David Chadwick: +1 Manu.

Orie Steele: +1 Manu.

Dave Longley: +1.

Brent Zundel: +1 Manu.

Michael Jones: I agree, anyone should be able to raise issues and PRs.

Michael Prorock: +1 manu and selfissued.

Michael Jones: I am volunteering to be an editor, based on my experience with JWTs and registries.
… I’ve never worked in a group where there are “lead editors”.
… I assume there will be editors calls with chairs.
… I’m not in favor of having a lead editor.

Michael Prorock: +1 editor / chair calls have been helpful in other WGs.

Michael Jones: I would rather have all the editors feel the responsibility of contribution.

Michael Prorock: +1 to set of editors as opposed to lead editor.

Michael Jones: I don’t view the algorithmic approach as applying to editors as much as authors.

Manu Sporny: To clarify, I meant “lead editor PER DOCUMENT” – as in, we’ll have lots of lead editors (for each document).

Manu Sporny: -1 to lead editor across all documents… doesn’t make sense for items that editors don’t have specialization in..

Brent Zundel: one thing we ran into with the did wg, we had a group, but a lack of a single DRI for making things got done, we struggled without someone in that role.
… it made some things harder.

Gregory Natran: +1 to a set of editors rather than algorithmic selection.

Brent Zundel: the proposal is for items, we want a single person responsible per item.

Gabe Cohen: +1 having a DRI (directly responsible individual) = higher guarantee things get progressed.

Brent Zundel: we def want multiple editors working together to act on the consensus of the group.
… do we want someone where “the buck stops here”….

Michael Prorock: regarding selfissued comment on contribution.
… should we distinguish between editors and authors, cleaning whitespace not the same as contributing… also managing consensus, doesn’t always lead to direct PRs, but its still a lot of work.
… being listed as an editor does not mean you are there to do anything but reflect the consensus of the group.

Michael Jones: agree with that.

Manu Sporny: I just wanted to clarify, selfissued question to you… hypothetically, are you saying there will be 5 editors responsible for all documents (shakes head no)…..
… instead per spec, there will be a set of editors with experience.
… for example JWT spec, DI spec different editors, but anyone can open a PR on any document.
… but specific editors are responsible for moving the document forward.

Michael Jones: I remain skeptical of the “lead editor” role.

Michael Prorock: +1 mike - let’s leave that to chair discretion over time.

Michael Jones: responding to brent, if one of the editor’s isn’t doing their job, the chairs are responsible for demoting editors.

Manu Sporny: +1 to this should be performance based instead of an honorific.

Orie Steele: +1 selfissued.

Manu Sporny: One of my primary concerns is “honorific editorship”.

Kristina Yasuda: seems we have agreement, anyone can open PRs.

Dave Longley: +1 is performance-based, -1 “honorific editorship”.

Kristina Yasuda: seems we don’t have clarity regarding “lead editorshhip”.

Manu Sporny: +1 to what Kristina just said.

Kristina Yasuda: for algorithmic leadership, we want to re-address closer to document stages.

Michael Jones: Kristina’s formulation works for me.

Brent Zundel: as far as lead editor, sounds like we are going to have a group… with different editors per spec… chairs will monitor, and may ask for leadership as we go.
… as far as attribution, the chairs set editors, grant powers etc… there is a difference with the end, where we may expand that list… I am in favor of the algorithmic approach.
… knowing that attribution will be fair, is a motivating factor for contribution.
… and that’s exactly why we have the algorithmic approach… to make sure we honor the work that people have done, even if they weren’t named as an Editor/Author initially..

Manu Sporny: (but that’s a decision we can make waaay later).

Kristina Yasuda: lets start with chairs appointing editors, and let leadership emerge.

Michael Prorock: +1 manu.

Michael Jones: brent some of what you said seems ambiguous… what is the scope for editors?.
… I think we should have different editors for different deliverables.
… we should specialize editors with experience per spec.
… can we get a confirmation that there are different editors per deliverables.

Brent Zundel: yes, agree.

Manu Sporny: +1 to update the use case documents.

Phil Archer: Kevin Dean (GS1) is offering to update the use case document last updated in 2019, to help update that document (we want to).

Michael Prorock: +1 use cases (and implementation guidance).

Phil Archer: GS1 offers to co-edit the use case document.

5. Structure of Deliverables.

Kristina Yasuda: I think we have consensus on separate documents per deliverable.
… DI Doc, JWT Doc, Data Model Doc.

Manu Sporny: in general +1 to that… I sent out a planned document structure on what the deliverables could be like.
… it would be good to get to details, eventually.
… maybe we should gather more feedback?.

Michael Prorock: +1 manu - but i think we hashed some of that out during re-charter.

Kristina Yasuda: the charter clarifies this, I think we can proceed to clarify.
… concrete deliverables.

Brent Zundel: 1. VCDM (VC Data Model), 2. Securing VCDM -> VC JWT, Data Integrity.

Michael Jones: +1 to Brent’s document set.

Brent Zundel: any opposition?.

Manu Sporny: +1 to at least that separation.

Michael Prorock: +1.

Orie Steele: +1.

Gabe Cohen: are json schemas under (1)?.

Michael Prorock: fine.

Brent Zundel: we have conditional normative deliverables all under “securing VCs umbrella”.
… some of these are blocked.
… VC JWP, JsonWebSignature2020, Koblitz, KoblitzRecovery, etc…

Michael Prorock: +1 jwp, jws2020.

Brent Zundel: is this a set we want to focus on now?.

Manu Sporny: +1 to begin writing now (but not a super strong focus).

Brent Zundel: I am concerned that if we do too much we will spread too thin.

Michael Prorock: regarding starting on stuff now, we want to start to address crypto-agility now… feels like JsonWebSignature2020 might be good to start now… assuming editors are not strongly overlapping.
… also wanted to note the implementation guide.
… want to start imp guide, but some will need to wait for progress.

Brent Zundel: +1, we are first looking at normative.

Orie Steele: Some of this may have been covered, just wanted to make my position clear. I can offer to be editor for core data model spec, offer to be editor of JWT specific variant, and interested in JWS components..
… If I had to only put myself in one item, it would be VC-JWT..

Michael Prorock: +1 orie as an editor.

Orie Steele: I think I can be useful and helpful on that. Wanted to make my preferences clear..

Manu Sporny: +1 to the refinement that brent put forward.
… i like the tracks.
… I think we should start in parallel, assuming we have enough editors to do things in parallel..
… we don’t want to overload a single editor.
… I am happy to do editorial on the VCDM, happy to be lead editor of Data Integrity spec, and 1-2 cryptosuites.
… thats probably what I can commit to.
… my concern about delaying is that we always run out of time, we should start in parallel.
… given that our charter is really about getting the “securing part” right… I would like to see us focus on those 2 primary deliverables first.

Kristina Yasuda: thanks for clarify and offerign to help.

Michael Jones: There will be a JSON Web Proofs BoF at IETF in Philadelphia on Monday, July 25 at 1:30pm. The BoF description is https://datatracker.ietf.org/doc/bofreq-miller-json-web-proofs/, which includes links to a draft charter and a draft agenda. Please participate!.

Michael Jones: I wanted to advertise the JWP BoF at IETF 114.

Michael Prorock: +1 BOF on JWP - could be very cool and timely.

Michael Jones: it was helpful to the IETF AD to help schedule the BoF based on our current charter.
… the WG to be reformed will be the JOSE WG at IETF <??>.

Kristina Yasuda: there is also SD-JWT work in IETF oauth WG https://datatracker.ietf.org/doc/html/draft-fett-oauth-selective-disclosure-jwt-02.

Michael Jones: We are asking that the WG to be formed to be a reconstituted JOSE WG.

Samuel Smith: I am new to this WG… is this the only things this WG is going to do? can we propose new work items for ACDC, KERI, Caesar.

Michael Prorock: https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html.
Michael Prorock: “Other cryptographic suites for NIST RSA, EASC DSA, SM9 IBSA, NIST post-quantum cryptography, or other externally standardized cryptographic primitives may be produced under the same conditions as the table above.”.

Samuel Smith: what is the process for proposing new work items.
… the charter is not exhaustive, the WG can come to consensus on adding new conditional things.

Samuel Smith: longer answer, in order to be released as a normative spec from W3C, all the dependencies must be from an “equivalent standards body” such as IETF, ISO, etc….

Kristina Yasuda: seems we agree to start on 3 main items, VCDM, VC JWT, VC DI.
… we don’t seem to have agreed on which items to start with?.
… parallelism, and editors?.

Manu Sporny: yeah… folks will need to step forward and do the work.
… clearly we should start VCDM2.0.
… I also think we do need to focus on the VC JWT and VC DI stuff.
… these documents should start immediately.
… cryptosuites seems dependent on that.
… seems they are a secondary priority.
… at least 1 suite per “securing the data model” spec..

Michael Prorock: +1 we really need some cryptosuites along side, especially items that can inform both JWT and LD Proofs.

Michael Jones: I agree with Manu’s characterization of the deliverables we want at minimum.

David Chadwick: I announced to the OIDC last week, Spruce Inc and ourselves won a competition to do interop work on OIDC4VC with JWTs.
… we’ve been talking to OIDC about their existing test infra.
… interested in testing new features from OIDC4VC.
… in that vein, I was an author of the VCDM1.1 and willing to be author / editor of that document.

Michael Jones: I agree with manu.
… we did have a volunteer for use case, where we have volunteers, i think we should start that work.

Brent Zundel: +1 Mike.

Michael Prorock: +1 selfissued.

Michael Jones: I would be willing to help with JsonWebSignature2020.

Manu Sporny: I wanted to share the diagram I shared a week ago.
… maybe this visual will help.
… see red, green and purple.

potential organization of group deliverables

potential organization of group deliverables (purely for informational purposes). See original

Michael Jones: Good diagram.

Manu Sporny: since we have volunteers for use case, we should kick that off.

Michael Jones: agree.

Manu Sporny: lets see how far we get with these items.

Joe Andrieu: I am willing to help with use cases.
… I want talk about more non normative docs and the vc-api.

Kristina Yasuda: thanks joe, this has been a great conversation.
… if you are interested in editor ship, reach out to chairs.

6. AOB.

Ted Thibodeau Jr.: W3 is aiming to change all calls to 55 minutes.
… please end on time.

Brent Zundel: fwiw, we always aim for 55 minutes..

Brent Zundel: and we always go over.

Kristina Yasuda: see TPAC.
… register, etc…