Verifiable Credentials Working Group Telco — Minutes

Date: 2023-03-08

Attendees

Present: Ivan Herman, Brent Zundel, Paul Dietrich, Shigeya Suzuki, Gregory Natran, Kevin Griffin, Mircea Nistor, Will Abramson, Phillip Long, Dave Longley, Manu Sporny, Sebastian Elfors, Dmitri Zagidulin, David Lehn, Orie Steele, Joe Andrieu, Juan Caballero, Kerri Lemoie, Ted Thibodeau Jr., ToddSnyderGS1, Todd Snyder, David Waite, Steve McCown, David Chadwick, Andres Uribe, Oliver Terbu, Chris Abernethy, Andrew Whitehead, Shawn Butterfield, Kristina Yasuda

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Paul Dietrich, Dmitri Zagidulin, Manu Sporny

Brent Zundel: agenda is work item proposal, status updates and PRs. Finish with Issue discussion as time permits.
… introductions.

1. Work Item Proposals.

Brent Zundel: work item proposals. This is to round out the body of work we attempt to complete and then feature freeze..

1.1. VC Spec Dir.

Manu Sporny: See repository.

Manu Sporny: Announcement over email. VC specifications directory pulled in. Open to take for a test run, This is experimental. Question to group. Was this problematic or should we start adding PRs..
… Request to the other chairs to redirect other registries to this directory. Looking for guidance..

1.2. VC-ACDC.

Kevin Griffin: send a proposal to the group for VC-ACDC. PROPOSAL is to move the draft for VC-ACDC to editors draft..

Brent Zundel: Work item adoptions. Must be on the mailing list for a week, Must be in scope of the charter Must have 3 parties endorsing..
… believes that the three steps for the work items have been addressed.

Orie Steele: understand the process around rough consensus for the work item. Wants to understand how much regular group work time will be spent on this. What is the expectation for work time in the group?.

Brent Zundel: chairs recognize there are a lot of work items. They will focus on work items that are progressing and don’t expect to spend a lot of time on this item..

Manu Sporny: question to spec editors. Has normative references to other specifications not in this group. One thing required to move along the track is stable references to specifications..

Brent Zundel: W3C guidelines for normative references: https://www.w3.org/2013/09/normative-references.

Manu Sporny: How much will this specification need to pull in this other work..
… We will need to address this in candidate specification.

Ivan Herman: Kevin, be prepared for the horizontal reviews for this specification as well. It will need internationalization and other experts. This will take working group time. The other thing is the CR phase as we will have a testing environment. This will include tests and implementations..
… these are all to be factored in..

Kevin Griffin: regarding the work, this is a transformation effort..

Kevin Griffin: regarding related specifications, its proceeding with Sam Smith in IETF. They fully expect to continue to move them forward.

Manu Sporny: +1, thank you for the response kgriffin, that addresses my concerns (they will be standards-track at IETF in time and normatively referenced).

Brent Zundel: See the guidelines for writing normative references in the chat.

Manu Sporny: Offer advice. Its a good answer to reference these normative specs from IETF. The danger is that the work is in the group and published as a draft. If this group goes into maintenance mode before IETF completes, this may get stuck in limbo..
… other option is that this work doesn’t have to be done in this group. But it would be good to have input from this group for the transformation rules..
… can the work in IETF be done in time to make sure it doesn’t end up in limbo..

Ivan Herman: its possible to work towards a working group note which would reduce the severity of the normative references requirement. but this needs to be decided between now and the first working group draft..

Kevin Griffin: thank you for the feedback Manu and Ivan..

Proposed resolution: The VCWG will adopt Securing Verifiable Credentials using Authentic Chained Data Containers. as a work item using the short name vc-acdc, and move https://weboftrust.github.io/vc-acdc/ to the VCWG as an editor’s draft.. (Brent Zundel)

Kevin Griffin: +1.

Orie Steele: -1.

Andres Uribe: 0.

Joe Andrieu: 0.

David Chadwick: 0.

Kerri Lemoie: 0.

Shigeya Suzuki: 0.

Will Abramson: 0.

Manu Sporny: +0 (supportive of the work happening, will not be able to contribute to the work nor plan to use it).

Steve McCown: 0.

David Waite: 0.

Chris Abernethy: -1.

Dave Longley: +0.

Brent Zundel: +1.

Ivan Herman: 0.

Phillip Long: 0.

Oliver Terbu: 0.

Paul Dietrich: 0.

Gregory Natran: 0.

ToddSnyderGS1: 0.

Ted Thibodeau Jr.: -0.5 I’m concerned that we may not have enough resources for already existing work items.

Orie Steele: Reason for my -1 is that I cannot contribute to the work, and I am concerned it will reduce contribution to other work items, which I am required to contribute to..

Orie Steele: I would also like to see more +1’s which would indicate that there will be more support / contribution / editing for the work item..

Brent Zundel: at this point we don’t have consensus. Recommendation to engage with the folks that voted -1 or 0..
… recognizes concerns about the amount of work but would rather that concern not be used as a reason to vote no on any particular proposal..

Dave Longley: +1 to brent’s comments on not voting -1 on any particular work item due to number of work items.

Kevin Griffin: process question. If I was to amend the proposal, re ACDC, could that later be amended to change the language?.
… for example, if we wanted to take Ivan’s advice and introduce it as a note, which would alleviate some of the workload concerns. Could we then say “the work’s progressed far enough, let’s make it normative”.

Brent Zundel: there is a distinction between a Note and a Recommendation that is not clear if you’re not deeply entrenched in a W3C process.
… a Note is any statement made by a WG, doesn’t necessarily reflect consensus. In the past, it wasn’t uncommon to see a Note published, and then have the Note become a REC track document.
… recent W3C clarification recommended that not be the way to do things.
… it would be appropriate to publish a Note that says, here is ACDC, here’s the transformation to have it match the VC Data Model.
… that would work, would not prohibit a later REC track document.

Ivan Herman: +1 to Brent.

Kevin Griffin: Thank you, Brent..

Brent Zundel: I hope that clarifies the options a bit more.
… so, you wouldn’t produce a Note that says “this will be REC track, it’s a Note for now”.
… so, your proposal is not off the table, chairs are happy to give you more time to drum up more support, to try and address concerns.

Kevin Griffin: thanks.

Joe Andrieu: speak in favor of ACDC eventually being a VC standard both with the feature freeze and the normative references..

Orie Steele: I also agree with Daniel Hardman’s comment on the list, that the work can progress regardless of adoption by this working group..

Manu Sporny: +1 to Joe. Need good examples for how transformations can be done, but feeling pressure of time constraints..

1.3. “Multilingual”.

Shigeya Suzuki: want to propose multilingual support. Not sure it needs to be proposed as a work item if its already in the charter. Doesn’t have a complete proposal at this moment but is willing to do the work..

Brent Zundel: believes there are issues open on this..

Manu Sporny: +1 to multilingual support. What shigeya has previously proposed was a great example. Effectively using a translation file that allows a credential to be linked to a translation file..

Ivan Herman: in favor of shigeyas work. From a formal point of view there is no need for a resolution on a work item. Its something we must deliver per our charter..

Brent Zundel: any other proposals for new work items?.

1.4. Circulating on the ECDSA Cryptosuite.

Manu Sporny: not a proposal, just circulating.

Manu Sporny: Work item suggestion: ECDSA Cryptosuite – https://lists.w3.org/Archives/Public/public-vc-wg/2023Mar/0014.html.

Manu Sporny: I wanted to highlight the work item suggestion that went out to the mailing list on the ECDSA Cryptosuite. Reasoning for it is - since we have withdrawn the work for JWS2020, which had support for ECDSA, now we don’t have one.
… ECDSA is important for many hardware support for crypto operations (FIPS compliant).

Orie Steele: VC-JWT has supported ECDSA and many other registered algorithms in the IANA registry..

Manu Sporny: which only leaves ECDSA for elliptic curves. This will change in the next couple of years, but for the moment, it’s our only option.
… in terms of how much work this will be - not that much more work. we already have the EddSA crypto suite. so ECDSA is just switching out a couple of algorithms..
… the spec so far has been written to align with the Data Integrity specs.
… if you’re an org that believes you’ll need hardware encryption support, consider signing the letter of support.

Manu Sporny: Letter of support for ECDSA: https://docs.google.com/document/d/1wcEg1P3AXOF0tUwzgNo_2IDLC_vBJNEGJRg_5JfprRM/edit.

Manu Sporny: chairs, we’ll plan to bring this in front of the group once we feel there’s adequate signatures.

Brent Zundel: thank you for heads up.

Orie Steele: If you plan on using URDNA2015 with ECDSA, you will need this “data integrity proof suite”…. if you plan to use VC-JWT, you can continue to use ES256, ES384 etc….

Brent Zundel: if there are no more work item proposals, we can move to PRs.

1.5. VC JSON Schemas.

Andres Uribe: wanted to highlight VC JSON Schemas proposals that went out to the list.
… which is, to adopt the work item to improving the VC JSON Schema spec, which has been worked on by the CCG.
… just want to make sure we ran the proposal for adopting the VC JSON Schema.

Brent Zundel: wasn’t clear to me that you wanted to run it today.

Andres Uribe: ah, ok, we can wait, but I want to make sure it’s not forgotten.

1.6. On withdrawing jws2020.

Ivan Herman: before we forget - JWS2020 has been withdrawn, so we have to make steps by re-issuing the draft and making its status clear (that it’s been withdrawn).

Orie Steele: +1 Ivan, we need to do administrative changes..

1.7. ‘evidence’ property.

David Chadwick: this is about the document that Mark (?) and myself has produced, an example of the ‘evidence’ property.
… briefly presented here, and in the CCG. neither group has adopted it yet. is there interest in this group?.
… or whether we should get it adopted as a CCG work item.

Brent Zundel: good question, jump on queue if you have opinion. mine is: if we have an extension point for the spec, I hope we have something normative to point to.
… not seeing anyone on the queue. So, these are additional possible work items..

Kristina Yasuda: i think davidC item belongs in the new directory.

David Chadwick: I don’t think it’s a Work Item as such; it’s under existing charter. It can just be a PR that’s the body of the current document, could go as an annex to the VC data model, or in the Evidence section as an example.

Brent Zundel: I leave it to you to determine how best to move forward.

David Chadwick: thanks.

1.8. ‘render’ property.

Kristina Yasuda: does the directory has to point to a URL or can have a specific text?.

Manu Sporny: question to the group - what do people think about the ‘render’ property for the core spec.
… there’s a PR, we know of at least 3 other mechanisms to provide render hints (and this proposal unifies those).

Kristina Yasuda: +1 for rendering in the directory, -1 in the core spec.

Manu Sporny: this is not a new work item, it’s an extension point.

Orie Steele: +1 for rendering in the directory, -1 in the core spec.

Manu Sporny: if you want this credential rendered, use this extension point.

Kristina Yasuda: me sorry, can’t speak.

Manu Sporny: to be clear, what we’d need to do in the group is just agree to an extension point called ‘render’. and then the VC directory would list the various specs.

Orie Steele: We don’t need to agree to an extension point in this group, we have @context for that :).

Manu Sporny: so, just looking for feedback.

Kerri Lemoie: +1 to render endpoint.

Paul Dietrich: +1 to rendering extension.

Oliver Terbu: +1 to rendering extension.

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

Dmitri Zagidulin: Wanted to say +1 to proposal for render extension point, Orie is right, PR to VC context, but also means adding a paragraphs/section to VC spec to say “render” is an extension point, for options go see the directory..

ToddSnyderGS1: +1 to rendering extension.

Kristina Yasuda: +1 to rendering extension in the directory or in the core spec.

Dave Longley: +1 to render extension point.

Dave Longley: (or rendering if people prefer that name).

Dmitri Zagidulin: The render proposal was a paper in RWoT, with the proposal takes a look at existing prior art, Open Badges, DIF render, this mechanism adds support for expressing all those options. There was a session at IIW , packed room, on render, lots of interest from many parties. Question to the community, is there support for adding an extension point, then specifics in the directory..

Brent Zundel: from what I see in the chat, folks seem generally favorable, so I encourage to go to the PR.

Oliver Terbu: +1 to render instead of rendering.

Orie Steele: the DID Core @context has very few terms defined in core.
… it relies using the JSON-LD @context for extensions, defined as RDF classes or properties.
… there are cases where we probably made the wrong call on that, in DID Core.
… for example, not defining any public key formats in DID Core.
… there may be cases like that in the VC v1 or v2 context.
… where we’re defining things in the @context that we shouldn’t be defining there, that would be better in an extension or in a second context.
… or we’re missing something that SHOULD be defined in the core context..
… this ‘render’ property feels like a perfect candidate for the VC Directory.
… I don’t feel it’s ready for the core spec though.
… the challenge with including the ‘render’ property in the core VC spec, is the interaction with that render property, protected contexts, the terms defined in the specs.
… I propose we wait and see how it’s deployed in the wild.
… so, I recommend we just rely on the JSON-LD mechanism, and not add it to core spec.

Manu Sporny: to provide a counter-argument. the reason we define extension points in the spec, is to convey how people SHOULD extend.
… we already have feedback from multiple implementers that they want to render credentials somehow, signaling to the market that rendering has value.
… especially since there are many issuers today who DO care what the VCs look like.

Kristina Yasuda: +1 to relying on json-ld mechanisms for now, instead of adding a new property in the core spec for rendering..

Manu Sporny: the danger if we do not specify the property in the spec, is that market will fragment with many terms, renderFoo and renderBlah etc.
… the ask is very minimal. can we specify it /as/ an extension point.
… so, very tightly scoped.
… with a pointer to the VC Specs directory, where people can do the extension stuff that Orie is mentioning.

Orie Steele: Manu, sounds like you are arguing that JSON-LD’s extension mechanism leads to fragmentation, perhaps this is the core problem this is highlighting..

Dave Longley: Orie: it’s not binary like that..

Manu Sporny: yeah, Orie, please don’t misrepresent the argument. :).

Joe Andrieu: the spec directory (not a registry) is good for open innovation, but isn’t standardization. having a standard for rendering is going to be useful..

Brent Zundel: if you’re an editor for one of our work items and want to provide an update, please jump on the queue, then we’ll move to PRs.

2. Work Item status updates/PRs.

2.1. A mapping proposal (pr vc-jwt#60)

See github pull request vc-jwt#60.

Orie Steele: so, for VCJWT, we have 2 open PRs. PR 60 open by our wonderful chair Brent.
… PR 60 - initially changes requested, seems currently no changes requested..
… the PR uses everyone’s favorite programming language, English, to describe a mapping, and address some of the concerns.
… from compact native representations to the VC data model. Please review..
… it’s been open for 5 days with no objections. we’ll merge it after a week.

2.2. Shorten media types (pr vc-jwt#61)

See github pull request vc-jwt#61.

Orie Steele: the next PR on JWT is ‘shorten media types’.
… it shortens the ‘verifiable-credential’ media type to VC.
… there’s still no consensus on whether we should shorten the media type. But again, there are approvals on the PR and no objections..
… so, if folks are objecting, please use the Github review feature to make the objections clear.
… help me as an editor, so that I don’t accidentally merge over an objection.
… TallTed added comments.

2.3. Editorial fixes to media types section. (pr vc-data-model#1062)

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

Manu Sporny: I’m not going to go over old PRs, please take a look at them.
… latest one - 1062, just does editorial fixes to media types section.
… take a look at it, should be just editorial.
… moving quickly - VC Data Integrity - we’re adding an algorithm for retrieving the verificationMethod.
… we’ll need more people approving, but it seems to be - seems that people want to see this defined.

2.4. Add algorithm for retrieving a Verification Method. (pr vc-data-integrity#86)

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

Manu Sporny: so, please take a look at it, comment, approve, etc..

Orie Steele: just to comment on JCS canon scheme - we discussed it at the f2f, and one of the reason we withdrew the JWS work item, is we knew that JCS was going to be proposed.
… I’m pretty strongly opposed to calling that suite ‘JSON’ when it requires the JCS dependency.
… lots of devs use JSON but don’t know about JCS..
… I’m vocal on the PR regarding the namechange.

Brent Zundel: we’ll discuss.
… but I’m very supporting of /using/ JCS.

2.5. Add json-eddsa-2022 cryptosuite. (pr vc-di-eddsa#26)

See github pull request vc-di-eddsa#26.

Manu Sporny: for EDDSA, there are 2 PRs, one just updates test vectors, the other one is naming things.
… so if you want to get involved in bikeshedding, on what to call the crypto suite that uses JCS for canon + signs with Eddsa, comment on issue 26.

2.6. (pr vc-specs-dir#1)

See github pull request vc-specs-dir#1.

Manu Sporny: we have 2 PRs for the VC spec dir. one is for VC Status List, which I imagine will go in.
… that’s PR 1. then we have a new one, for the 1EdTech specs.
… so take a look at those PRs if you have an opinion.

2.7. (pr vc-specs-dir#2)

See github pull request vc-specs-dir#2.

Manu Sporny: the way the registry works is - if there are no objections and it’s formatted correctly, it just goes in.
… question to the chairs is - do the PRs even need reviews.