Verifiable Credentials Working Group Telco — Minutes

Date: 2022-11-23

Attendees

Present: Brent Zundel, Dave Longley, Michael Jones, Sten Reijers, Michael Prorock, Manu Sporny, Orie Steele, Kevin Dean, Tobias Looker, Logan Porter, David Chadwick, Antony Nadalin, Shawn Butterfield, Ted Thibodeau Jr.

Regrets: Charles Lehner

Guests:

Chair: Brent Zundel

Scribe(s): Orie Steele, Manu Sporny, Michael Prorock

Brent Zundel: Agenda: We are doing work items status updates and PRs.
… agenda bash?.
… Oliver is there anything holder binding related?.

Oliver Terbu: not for today.

1. Introductions.

Sten Reijers: Joining.
… from verid in the Netherlands, connecting wallet providers to platforms and using verifiable credentials.

2. Work Item Status Updates.

Orie Steele: The main update is we did merge the FPWD on JSON Web Signature 2020, Ivan has added some other updates which I’m approving and merging because they’re editorial..

See github pull request vc-jws-2020#28.

Orie Steele: That’s the link that was merged. We’ve done the things we needed for FPWD for JsonWebSignature2020 which uses detached JWS, this is the first data integrity proof suite to go to FPWD for the group..
… We have not yet done that for VC-JWT, we should do our best to get that document to the point where it’s ready..

Brent Zundel: Any comments/questions about this work item?.
… what are next steps for FPWD for VC-JWT?.

Michael Jones: Editors need a side call to discuss and report back to the WG.

Orie Steele: I agree with that, I’ll ping you..

Brent Zundel: Other work items?.

Manu Sporny: https://github.com/w3c/vc-data-model/pulls.

Manu Sporny: VC Data Model pulls, oliver raised one on credential subject objects.
… we also got JSON Schema for VCs.

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

Manu Sporny: In process, this is Ivan setting the range of credentialSubject to be IRI.

Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.

Manu Sporny: VC Data Integrity has no active PRs, but the EdDSA crypto suite is being worked on outside the group.

Manu Sporny: https://w3c.github.io/rdf-canon/spec/.

Manu Sporny: ^ this spec work continues, it blocks the data integrity specs… the group seems to be focusing on URDNA2015..

Brent Zundel: when do you propose to the group to bring in EdDSA?.

Manu Sporny: we already did an FCGS in july, we could do another?… should we propose to bring it in today?.

Michael Prorock: Don’t see the need to get a second inclusion, its a rubber stamp from the CCG as editorial..
… either way I am good.

Manu Sporny: We could say that this group is going to pull that work in..

Michael Prorock: +1 manu.

Manu Sporny: the IPR would be on the final commitment today..

Orie Steele: Don’t want to be hostile to incubation, however concerned that JWS(2020) covers this suite as well - do we want multiple ways of handling the same algorithms?.
… want to ensure WG understands what this means.

Manu Sporny: its a charter deliverable and we have 5 implementations.

Manu Sporny: 5 implementations: https://w3c-ccg.github.io/di-ed25519-test-suite/#Ed25519Signature2020%20(issuer).

Oliver Terbu: I don’t necessarily see the value of adding this suite… but I respect that there are 5 implementations and its a charter deliverable..
… I don’t think its needed..

Michael Prorock: personal implementer hat only, we are going to now have 2 different ways of securing a credential, with the same cryptography, i’m worried implementers may get confused… and that we are setting a precedent..

Tobias Looker: +1 agree with mike, orie and oliver more options is bad for interop and security.

Michael Prorock: +1 Orie - some changes need to occur to match current data integrity FPWD.

Dave Longley: +1 to Orie on the design trade offs.

Manu Sporny: +1 to Orie about that different design trade offs have been made..

Dave Longley: +1 to Orie in short: i’d say that the differences exist on purpose (design trade offs).

Brent Zundel: would it be accurate to say that the EdDSA suite that is being brought in, that there are use cases that are specific to it?.

Oliver Terbu: its less about the signatures, and more about the encoding of the public key..
… the suites tend to use different publicKey types, publicKeyMultibase vs publicKeyJwk.
… it might be easier to use a single encoding for verification keys.

Manu Sporny: its not only that, there are a set of design tradeoffs… there 2 things are different, and they are not going to reconcile.
… Ed25519Signatute2020 is already built into point of sale systems, and encoded in QR Codes… this helps us make the QR code small enough..
… this helped make the credential compact.
… it has different goals, that JWS 2020.

Michael Jones: multibase last I checked is not a standard, and not in a process for standards track.

Michael Prorock: are we allowed to point to multicodec / multibase?.

Manu Sporny: multibase was sent to IETF secdispatch.
… we only use multibase for key encoding, and we only us z (base58btc)… we don’t need to refer to an IETF RFC..
… the only multibase letter we use is z (base58btc)….
… if multibase moves along faster at IETF, we could refer to it.
… we could define how to use multibase here in W3C VCWG, and then we can refer to it at IETF, if it lands there..

Brent Zundel: a normative track spec, needs to point to a spec at the same level… an ED or FPWD can point to IETF, we will only encounter challenges to CR or PR if its not done at IETF.

Michael Prorock: https://mailarchive.ietf.org/arch/browse/dispatch/?gbt=1&index=Q9aUoF01Upbvl7STjJvjoU8hlHM.

Orie Steele: I know the question went to secdispatch, have we gotten a response on this issue? Clarifying question - Manu had offered an alternative, define base58btc in spec and no need to refer to IETF. Could make it clear to proceed through CR/PR if we go through that path?.

Brent Zundel: Yes, that’s the case, we can point to multibase I-D, starting off the process, just as this is starting off the process, can point to that normatively, both specs can advance to normative status at that same pace. Failing that, there is another way to do it regardless..
… the text as is points to an I-D at IETF, so its still appropriate to point to IETF until it needs to point to something better, and then yes..

Michael Jones: Can we get a link to the secdispatch minutes.

Brent Zundel: Lets run the proposal.

Proposed resolution: Pull in the EdDSA cryposuite https://w3c-ccg.github.io/di-eddsa-2020/ into the group after it has had a final FCGS publication in CCG and publish it as an Editor’s Draft.. (Brent Zundel)

Manu Sporny: +1.

Dave Longley: +1.

Orie Steele: +0.

Oliver Terbu: +0.

Shawn Butterfield: -1.

Michael Prorock: -0.

Michael Jones: -1 due to the unnecessary duplication.

Sten Reijers: +0.

David Chadwick: 0.

Charles Lehner: +1.

Tobias Looker: ~0 worried about duplication of approaches here too, would like to see less optionality.

Brent Zundel: is there a way to reword the proposal?.

Shawn Butterfield: Maybe I need to think about it more, but knee jerk reaction is I see potential problems, and feedback from security experts on practices that involve transformation prior to hash and then sign…. I also have a bad feeling about duplicity, and it feels like a mix of data model and sec, and its a bad practice.

Michael Jones: There is no record of multibase being considered by secdispatch, but there has been no presentation or resolution from the chairs.
… I don’t see IETF proposing a standards path.

Manu Sporny: we don’t need a WG or standards track document to pull it in.
… we also said we can define the encoding in the spec.
… sounds like you are objecting to the data integrity work in general, which means you might also object to the JWS2020.

Michael Prorock: https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-06.

Michael Prorock: is this the latest draft on data tracker ?.
… not aware of of anything moving beyond the list, as far as I know, its not been assigned a home yet.
… and i don’t think it should block the work.

Shawn Butterfield: fair question manu, canonicalized forms that are in practice applied to JWS2020 detached proof… in my implementation, it does not conform to the data integrity proof spec.

Brent Zundel: we don’t have consensus to pull the work item in.

Dave Longley: there are different design considerations for the different crypto suites.
… are these other design considerations used not possible to achieve with JWS2020.
… are we arguing to limit optionality?.

Orie Steele: I agree with what Dave said, I’m pretty sure the intention at the time was to pull in cryposuites, not just one w/ a compact representation, but also ones for NIST curves and Ed25519 is prohibited, I agree with Dave. The way it was originally communicated was we’d pull multiple ones in. One comment I have is compaction in JSON, what I believe is that compaction was based on CBOR-LD codecs and it would be possible to compact detached JWS base64 URl instead of base-58 btc and base64 might be more compatible, codec in base64 URL would result in more compact ones across the board instead of one particular key … need to focus on compact representations. Being able to compact verification method or signature material is a valuable feature, shouldn’t be limited only..

Manu Sporny: I thought we would pull in multiple crypto suites, its the reason we were ok with JWS2020.
… I thought we would allow people to choose cryptosuite, and I imagine that the vote would be different… and we are maybe creating a need for 1 single winning cryptosuite.
… seems like we are creating conflict in the group.
… we already have multiple implementations of this, going into production.
… regardless of if the group pulls it in, the group would not be documenting the reality in the commercial market.
… now limiting the number of cryptosuites being pulled in, we’re going to spend a lot of time arguing over crypto suites.

Brent Zundel: we have heard concerns from folks regarding bringing the work item in, I’m resolving this proposal, and we’re going to take it and move forward.

Michael Jones: how will this be resolved?.

Dave Longley: 3-2 = 1.

Dave Longley: the actual votes (unless i’m misreading it).

Shawn Butterfield: I’m okay with that dlongley, and FWIW I’m okay changing -1 –> 0 for the reasons Orie is outlining..

Michael Jones: a charter provides boundaries on what we “may do” it does not decide what the wg “will do”… the charter allows for us to decide.

Michael Prorock: I want to agree with selfissued and Orie, what are our actual goals as a WG? how does this work, help us achieve our goals?.
… there are things like bbs and hpke and we may have to wait on….
… the WG should beware of the items, I am not saying not to take the work, I am just concerned on duplication.
… there are use cases that are building on this path.

Manu Sporny: shawnb changed his vote to a 0.

Tobias Looker: +1 mike the only reason BBS cannot fit under the JWS umbrella is that it wont ever be registered as a JWA compatible with JWS because of future proposals like JWP covering it instead.

Manu Sporny: can we ask who will object?… I am hearing there is concern, but maybe not blocking the work?.

Michael Prorock: +1 tplooker - it is a nuanced thing that we need to account for.

Antony Nadalin: I would object.

Michael Prorock: i will object due to lack of consensus at this point.

Michael Jones: I object to it being pulled in this way, there is a cost to pulling in work and committing to do work…. I object on the principle that it does not reflect consensus.

Dave Longley: I think the health of the wg is determined by how we achieve consensus, and there are design tradeoffs.
… JWS2020 was allowed in because of the promise of the other crypto suites coming it.
… I think the approach that is being taken here is a change after the fact to what we agreed to, and we should re-vote on the other items.
… and we may not be able to resolve the design choices.

Antony Nadalin: I don’t understand why this work is being brought here, and not somewhere else… if there is so much work for it, it can be done elsewhere.

Michael Jones: I disagree with dlongley’s characterization.
… we agreed to a charter, and now we are using it to decide what we want to work on.
… just because its in a charter does not ensure that it will be done.
… I can see there is not consensus….

Antony Nadalin: +1 to Mike.

Dave Longley: +1 to Orie, this is not healthy for the WG and items we’ve pulled in so far.

Dave Longley: not acknowledging that those received support in the WG because other items were expected to receive support does not acknowledge what members in the WG are saying..

Ted Thibodeau Jr.: backseat chairing is not helpful… “if i were chairing…” etc… if you have an issue with the chairs, raise it to them… and follow the process.
… does the charter control what the work can do? yes, it can declare out of scope and deliverables.
… the group is supposed to complete deliverables.
… there are aspects of the work we are doing here, and if there are some that better than others, perhaps the work can be improved here.
… the people who want to do the work, should be allowed to work together.

Orie Steele: +1 TallTed.

Shawn Butterfield: Take care all.

Michael Prorock: thanks all!.