Verifiable Credentials Working Group Telco — Minutes

Date: 2023-10-25

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Shigeya Suzuki, Manu Sporny, Dmitri Zagidulin, Benjamin Young, Joe Andrieu, Michael Jones, Andres Uribe, Dave Longley, Ted Thibodeau Jr., Orie Steele, David Lehn, Kristina Yasuda, Paul Dietrich

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dmitri Zagidulin, Manu Sporny

Content:

Brent Zundel: welcome everyone.
… our agenda is straightforward - we’ll have a brief section on work item status updates.
… review pertinent PRs, then move into discussion of issues.
… primary issue being 1307.
… after that, will move to other ‘Before CR’ issues we need to address.
… anyone who would like changes to the agenda?

1. Work Item status updates/PRs.

Brent Zundel: Looking for brief status updates for each work item.
… Manu, you’re first up.

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

Manu Sporny: I’ll run through these really quickkly.
… this is VC Data Model. there are 6 PRs that are newly opened over the last week.
… one of them is on adding a definition for well-formedness. One is on suggesting the use of oblivious HTTP, one about adding a section on key management.
… other is Trust Boundaries & Considerations, another on JWTs [something], and the last is about explanation of use of graphs in VC DM.
… I’ll also note that previous PRs marked ‘Pending Close’ have expired, so, we should close them (Brent).

Brent Zundel: 2 of the Pending Closes are PRs waiting on companion PRs. and 2 have expired, will close.

Manu Sporny: got it.

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

Manu Sporny: moving on to Data Integrity.
… here are the DI PRs, one is a ‘During CR’, other is the ‘At Risk’ marker for Controller Doc.
… which we discussed yesterday. it’s in PR Ready draft, will be merged in 2 days.
… there are no active open PRs for ECDSA suite, also none for EDDSA.
… all the issues are Post-CR.

Manu Sporny: Bitstring Status PRs: https://github.com/w3c/vc-bitstring-status-list/pulls.

Manu Sporny: moving on to Status List. No open PRs for this, I’ve done the rename for the spec.
… and I think we picked the wrong name :).
… don’t want to bikeshed today, but a bunch of different status methods use bitstrings.
… we should pick something else like ‘Herd Privacy Status List’ or similar (not for discuss today).
… we might want to call out what this Status List is going to do.
… there’s a number (30) of Before CR issues that need to be processed.
… and 8 of those are ready for PR, so expect updates & changes there over the coming weeks.
… that’s it for me.

Michael Jones: I can talk to the VC JOSE/COSE.
… there is one editorial PR by TallTed,.
… two editors believe it’s ready to merge (strictly typo corrections).
… there are only 2 Before CR issues remaining.
… one requires some language cleanup about using registered JWT claims in JOSE header.
… the other is about Controller Documents, which we’ll have discussion about.
… so those are the two main things for CR.

Brent Zundel: we’re ready to move forward to next topic.

2. Issue Discussion.

2.1. Controller Documents (issue vc-data-model#1307)

See github issue vc-data-model#1307.

See github issue vc-data-integrity#216.

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

Brent Zundel: We’ll begin with the continuation of the topic of our special topic call, which was Controller Doc.
… there were a number of proposals that were brought before the group.
… 3 of them were resolved.
… check email / notes.
… there are 4 more proposals that have been brought up, 3 of them concerning the same thing, and one I’m very confident won’t pass even after long discussion.
… the focus will be around Key Discovery.
… specifically, discovery using ‘.well-known/’.
… one of the proposals says ‘Shared doc will NOT use key discovery’.
… the other one says, maybe we should do key discovery using .well-known.
… would it be amenable to the group for the primary doc to do .well-known as primary mechanism.
… if there’s consensus, we’ll run a proposal.

Michael Jones: it makes sense to include that, it’s a standards based key representation used in practice.
… so it makes sense to make it available to both securing specs.

Dave Longley: so, thinking about our call yesterday and the resolutions,.
… and was thinking forward to how some securing specs might want to profile down.
… as we agreed in the last resolution, and other specs might want to keep those options open.
… given that, it only makes sense for the shared doc to provide multiple options.
… I think that’s were some of us were thinking when we were talking about things in common.
… we might get more consensus on things like ‘.well-known’, if we agree that shared doc has things in it that may or may not be referenced by secured implementations.
… if we’re ONLY going to put things into the shared doc that current specs reference, that’ll show preference for options where it’s not needed.
… I’m concerned we’ll end up making different decisions on that basis, stripping down the shared document.
… as a result, we might need to have multiple shared documents.
… might be better for us that the shared doc has things that securing specs MAY reference.
… that way, we can more likely get to a consensus on something like .well-known (given concerns of preference).

Orie Steele: Seems like showing preference for things that both specs use, would be good for implementers.

Manu Sporny: ^ not when that preference doesn’t exist, Orie.

Manu Sporny: To say that the Data Integrity specs “prefer JWK” is not correct, it’s provided as an option.

Brent Zundel: just to repeat, we have one suggestion from Mike that .well-known be included.
… Dave is suggesting additionally that the core Controller Doc spec be inclusive of not just .well-known but other securing mechanisms / discovery mechanisms.
… so that specs like VC J/C and DI can choose among the options there as a profile.

Dave Longley: yes, that’s great.
… if we do that generally, across all of our options, we’ll have a much easier time to come to consensus.

Dmitri Zagidulin: As a data point, about the .well-known mechanism, based on some recent VC implementations, there are a number of institutions like universities that are not allowed to create folders with dots in them. There are education institutions that can’t put their keys in .well-known due to their web control panels and whatnot. It’s useful, but not everyone can use it.

Michael Jones: two responses.
… first to Dmitri - I certainly believe you, but if they can’t use .well-known, they can’t produce OAuth metadata, just a bunch of things they can’t do.
… I feel for the people in those environments, but that may be not our problem to solve.
… I appreciate Dave’s thoughtful remarks.
… my intent is to only have things in the shared controller doc that will be used for /both/ securing specs.
… if it lets us move forward, I’d hold my nose and accept some things that were not used by both, as long as the securing specs could profile it to say “don’t use this part”.

Orie Steele: Good thing did:web allows you to but controller documents at arbitrary locations…

Dave Longley: +1 to Mike, document everything in the shared spec and then profile down, that can get us to consensus.

Joe Andrieu: I’m not a fan of .well-known because it’s anchored in a centralized resource/url.
… and I don’t think that it applies to all our situations. I don’t see VCs as a subset of the modern web, I see them as larger.

Brent Zundel: just to clarify, are you opposed to .well-known included at all, or to it being the /only/ mechanism.

Joe Andrieu: at all.

Dave Longley: i can hold my nose if everything (key formats, etc.) is in the shared doc and securing specs can profile down.

Manu Sporny: I wanted to agree with what Dave was saying, and what Mike Jones just said. it would be fine to include a number of things in the controller doc, put them in a single document.

Dave Longley: +1 to Manu.

Manu Sporny: and when you go to profile, you can say “Do not use X or Y, we don’t want you doing that” – that’s perfectly fine.
… we’d provide all the options in the controller doc spec, and then securing specs will profile them.
… that feels like a good compromise, people who don’t want to use features can call them out.

Kristina Yasuda: This is what SD-JWT VC spec does. It mentions multiple mechanisms: .well-known, DID, x.509, etc. see spec on datatracker.

Dave Longley: +1 to a resolution that says we provide all the “controller-document-related options” in the shared controller doc spec and then each securing spec profiles that down to what they accept.

Orie Steele: +1 Manu, although i still hope we can limit the controller document options to “good ones”, if we can’t agree on what good is, its ok to just split the difference.

Kristina Yasuda: And I think we should do the same here.

Manu Sporny: so, +1 to that. What that would mean is that we’d include ‘publicKeyJWK’, ‘publicKeyMultibase’, we’d include .well-known discovery mechanism.
… we’d include multiple algos in there.
… which means that the entirety of the contents of the DI spec could be lifted & placed into the new spec (minus DI-specific language).
… and we can add everything related in the JOSE/COSE spec. and add the language “Do not use X feature” etc.

Dave Longley: +1 to Manu, very supportive of that approach – and its sounds like others in IRC would support as well.

Manu Sporny: so, +1 to that if it helps us move forward.
… I also don’t like .well-known, but I’d hold my nose to it being added to the shared spec.

Brent Zundel: I believe we have roughly a path forward.
… we had one person comment that an aspect would not be acceptable; everyone else seems to be willing to move forward with this (the profiling approach).
… so I think we’re to the point of trying to craft proposal language.
… I’m happy to do that unless someone else wants to craft resolutions.

Shigeya Suzuki: For a data point, for some usecases we will use .well-known.

Brent Zundel: here is draft proposal, anyone opposed? (and if yes, how should we change it).

Joe Andrieu: I have some concerns re temporality. the controller document ‘will include’, which seems in the future?
… or is it possible for securing specs to adjust what goes into it?
… so, causality needs clarifying.

Brent Zundel: my understanding is - both DI and Jose/Cose would be written in the controller doc, as they’re written today.
… and then they could be modified as profiles etc.

Dave Longley: +1 to brent’s interpretation.

Proposed resolution: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable. (Ted Thibodeau Jr.)

Brent Zundel: does that help with causality, Joe?

Joe Andrieu: yes.

Kristina Yasuda: it seems that this resolution does not apply to just key discovery, but other aspects as well. is the intent to just mix all the features from the securing specs?

Manu Sporny: yes, my understanding as well. just to be crystal clear,.
… I’m looking at the VC DI controller doc section right now. it defines effectively what’s found in DID Core, says you can use ‘publicKeyJwk’ and ‘publicKeyMultibase’, and the secretKey properties too.
… defines multibase bytes normatively.
… I don’t know what’s in VC JOSE/COSE, maybe Orie and Mike could speak to it.
… I’m hearing the .well-known stuff would move in there.
… also believe that we have a ‘Retrieve Verification Method’ algorithm that’d move into the shared doc.
… that also has a set of processing errors (table).
… things like, throwing an error about invalid controller doc, id, etc.

Dave Longley: +1 to Manu.

Manu Sporny: the errors would move too.

Orie Steele: the vc data integrity controller document defines capability system and encryption related terminology, which is not used in vc data model today.

Dave Longley: and VC-JOSE-COSE talks about .well-known (or would) and that would be put into the shared doc too.

Orie Steele: accurate. just in terms of current VC JOSE/COSE spec - it has already a profiled-down version, just needs to be able to refer to correct term definitions.
… current version in latest draft just expresses preference for common JOSE/COSE key representations. Does not contain elaboration on capabilityDelegation, capabilityInvocation or keyAgreement, as they’re not used in VCs currently, to my knowledge.
… so when we constructed it, we took the DI definition, removed ‘proof’, multibase, the delegation and key agreement keys.

Kristina Yasuda: Clear, thank you.

Dave Longley: +1 for VC-JOSE-COSE to continue to profile down in the way Orie says.

Brent Zundel: with that, we are ready to run the proposal.

Proposed resolution: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable. (Brent Zundel)

Manu Sporny: +1.

Dave Longley: +1.

Brent Zundel: +1.

Ted Thibodeau Jr.: +1.

Dmitri Zagidulin: +1.

Michael Jones: +1.

Shigeya Suzuki: +1.

Andres Uribe: +1.

Joe Andrieu: +1.

Paul Dietrich: +1.

Orie Steele: +1.

Benjamin Young: +1.

Resolution #1: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable.

Brent Zundel: if I’m understanding correctly, this single proposal captures all of the stuff from the remaining resolutions & proposals from yesterday.
… I think we can move to other issues.

Dave Longley: +1 to Brent, this captures the rest in one way or another.

Manu Sporny: agreed.

Michael Jones: question to chairs (I’m open to many different answers) – is it time to request volunteers to work on this new shared doc?

Brent Zundel: If there are folks on the call who want to volunteer, I’d love to hear it.

Michael Jones: I’ll volunteer.

Manu Sporny: I’ll volunteer.

Brent Zundel: solid editorial team. others are also welcome to volunteer now, or reach out to chairs.

2.2. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Brent Zundel: noting this is labeled as ‘Before CR’, but we don’t have anyone assigned.
… ‘Remove at-risk marker for Evidence’.
… where do we go with this?

Orie Steele: the linked issue is about termsOfUse, which is one of the expiring pending close ones?

Manu Sporny: it’ll be merged on its current path.

Orie Steele: to recap, there is an open PR, looks like it’ll get merged. so once we see something about Evidence, we’ll remove at-risk marker.

Manu Sporny: we should ask the EBSI folks to see if they volunteer?

Brent Zundel: sounds like Dmitri is also volunteering, so, with permission, I’ll assign it to you.
… next issue, 1292.

2.3. Prefer Arrays and Objects. (issue vc-data-model#1292)

See github issue vc-data-model#1292.

Brent Zundel: Prefer Arrays and Objects.
… labeled as Before CR, no assignment. there’s a bit of a conversation between folks. Orie - can you give us status?

Orie Steele: as you all know, our conforming docs are compact JSON-LD docs. So, in lots of cases, the JSON is polymorphic – either a string or an array object, etc.
… any of the predicates (schema, proof, subject, etc) can either be string, object, or array.
… reason for that is how RDF data model treats graph representation.
… unfortunately, this causes problems for strongly typed languages.
… these are very common bugs.
… I’ve run into them hundreds of time. Can we reduce this sort of thing?

Brent Zundel: other thoughts?

Dave Longley: brief comment - we had a number of issues where we said, to increase interop, we should do a few of these things,.
… without normatively requiring.
… so maybe non-normative advice would suffice, for interop?

Orie Steele: dlongley maybe you can propose some normative SHOULD language?

Brent Zundel: suggestion before the group - can we address non-norm / post-CR, for future us to deal with?

Dave Longley: Orie: normative “SHOULD” hasn’t worked in other places…

Manu Sporny: I’m a bit on the fence about this. might be good to go all the way to SHOULD, I’d be -1 for MUST.
… we could put SHOULD normative language for objects, for arrays for single values, etc.
… the problem is (and we’ve tripped over this in the past), you don’t want it so that systems that aren’t written to be robust when you DON’T do it, fail.
… so, should we urge everyone to support polymorphism (like with accessor functions)?
… it’s dicey.
… one alternate approach is to go the other way, and enforce all those variations in our test suites.
… I’m fine with either route - SHOULD, or non-normative advice.

Dmitri Zagidulin: How do people about “always require arrays”?

Orie Steele: I would be +1 to always requiring arrays, based on our implementation experience.

Dave Longley: -1 some software already doesn’t do that…

Dmitri Zagidulin: I’d +1.

Orie Steele: … we do that in other specs.

Manu Sporny: I’d be -1 to that … ‘cause there will be people that don’t want to do that and we can’t make them.

Dmitri Zagidulin: @dlongley - what do you mean?

Shigeya Suzuki: +0.5.

Benjamin Young: -1 to new shape requirements…

Dmitri Zagidulin: +1.

Andres Uribe: I’m not sure what the implications are.

Michael Jones: this seems odd. what would this possibly accomplish?
… if stuff is naturally a singleton, it should be represented as such.

Manu Sporny: Agree with selfissued.

Dave Longley: +1 to Mike.

Dmitri Zagidulin: @manu - amend the proposal to ‘require arrays when it’s NOT a functional item’ (single-only).

Orie Steele: it wouldn’t be issuer (since you’re not allowed multiple), but it would mean multiple subjects.
… so, if you’re only allowed to have an object or a string, you’d still see singleton.
… remember, this compact JSON-LD doc is an instance of the RDF data model, so we get the array polymorphism from that.

Dave Longley: not sure if there’s a “net improvement” here… we might improve in one direction and cause harm in another.

Orie Steele: in the real world there are multiple issuers.

Dmitri Zagidulin: To respond to all 3… Mike - reason we’re discussing is this is a cause for a bunch of bugs, singleton vs. array… Orie - disagree that we’re inheriting polymorphism from RDF data models, we’re inheriting it from the real world – sometimes it’s a singleton, sometimes it’s an array. Manu - you have a point, but it’s amenable - require arrays only when arrays are possible (single items only require singletons).

Orie Steele: we are inheriting from using JSON-LD for conforming documents.

Orie Steele: one place this is very likely to cause bugs is credentialSchema and credentialStatus.

Manu Sporny: people are suggesting ‘require arrays whenever arrays are possible’. we don’t have expressions of arity except in spec.
… the vast majority of the vocabularies don’t specify arity; people don’t go through the trouble of doing that.
… we can say “in OUR specification, we do specify the arity” for the fields defined in VC DM.
… but that falls apart the moment you extend the core DM.
… so, this might be brittle.
… I don’t think we can require enforceable arity.

Dave Longley: push this to credentialSchema <–.

Dave Longley: if you want it, use credentialSchema… that’s one thing it’s for, right?

Manu Sporny: unless we require JSON Schemas for all VCs, this is non-enforceable.
… we can provide non-norm guidance for people not to do it.

Brent Zundel: counter-proposal, if I understand, is ‘Do nothing’.
… turning mike over to Kristina.

Orie Steele: I am fine closing the issue.

3. Personal issue.

Kristina Yasuda: I am stepping down as a co-chair of this WG. after this call, I’ll make a PR removing myself from readme.
… and close couple of PRs, will remove my rights, etc.
… if anyone has questions, feel free to reach out to me.
… thank you all, for the opportunity!

Manu Sporny: Sorry to hear that you’re stepping down, Kristina – thank you for your service to the group!

Orie Steele: Thanks for all your help Kristina! enjoy the time back : ).

Brent Zundel: thank you Kristina, it has absolutely been a pleasure.
… thanks everyone, see you next week.

4. Resolutions