Verifiable Credentials Working Group Telco — Minutes

Date: 2024-08-28

Attendees

Present: Hiroyuki Sano, Ted Thibodeau Jr., David Chadwick, Manu Sporny, Brent Zundel, Will Abramson, Gabe Cohen, Dmitri Zagidulin, Michael Jones, Benjamin Young, Phillip Long, Jennie Meier, Steve McCown, Joe Andrieu, David Lehn, Dave Longley

Regrets:

Guests: Rob De Feo

Chair: Brent Zundel

Scribe(s): Dmitri Zagidulin

Rob De Feo: hi my name is Rob De Feo, I’m an implementer, CEO of Vidos.id.

Brent Zundel: any other introductions?
… ok, let’s do agenda review. TPAC first, then wrapping up the VC DM, then bulk of our time on Controller Doc.

Manu Sporny: update on work items, and should discuss - what’s our publication plan for TPAC. As in, are we on track for CR2 for TPAC etc.

Brent Zundel: sounds good, we’ll cover that.

1. TPAC attendance.

Brent Zundel: first topic: TPAC attendance.

Brent Zundel: https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?usp=sharing.

Brent Zundel: a number of folks indicated intention to attend, here’s a link to our attendance spreadsheet.
… some expressed interest in a ‘pay for your own’ group dinner.
… taking restaurant recommendations; or I’ll do some research.

Joe Andrieu: I’ll volunteer, to recommend something.

Brent Zundel: please add dietary restrictions to the spreadsheet.
… so if you haven’t yet, add yourself to that sheet, whether attending in person or remote.
… there’s a 2nd tab on that sheet, please add topics of discussion. we have 3 sessions planned, 2 morning sessions that’s just us, and a combined session with security folks.
… so, not a TON of time, but suggestions welcome.

2. Work Item Status Updates.

Manu Sporny: good news, core VC data model has had at least 2 editorial passess, full, with changes made.
… we are down to like 1 editorial issue, still need to fix the respec vc plugin (the cbor stuff).
… gabe is doing a pass on privacy & security considerations section, thanks gabe. we’re in good shape.
… could potentially cut a CR2 this week or next week.
… we’re in similar shape for VC Data Integrity, eddsa and ecdsa - full editorial passes, with mods and changes incorporated.
… and we can probably cut CR2s for all those specs as well for TPAC.
… brent, there’s one issue remaining on VC DI spec, that’s the Mattr security issue.
… what are we planning on doing with that?
… other than that, the spec is as done as it’s gonna be.
… so that’s 4 specs ready for CR2.
… Bitstring Status List could probably get there by TPAC. although Controller Document developments are affecting that.
… so we’ll need to discuss that.
… but as far as I can see, we’re generally ready for CR2.

Brent Zundel: gabe, I’ll let you talk re VC JOSE/COSE.

Gabe Cohen: we closed a number of issues in VC JOSE/COSE, still have a couple of issues.
… we have the media type issue, couple others. I’m actively working on the test suite, reach out if you want to help out.

Brent Zundel: reminder to folks - the original hoped-for schedule … and reminder that our current charter is over as of January 2025.
… so what we’re able to do will depend on whether or not our proposed extended charter gets approved or not.
… the proposed charter is for a couple of years, it lets us wrap up a couple of last in-progress parts. For the most part, the group is to maintain the various specs we published.
… but that charter hasn’t been approved yet.
… original plan was - we need to publish the Controller Document as a CR draft by the end of August.
… so, really, this meeting.
… it has recently gotten feedback from Google, along with a thorough walkthrough by Mike Jones, so currently a large number of open issues.
… so we’re not ready for CR today.
… we need to continue working on it beyond today, to get it ready.
… this only becomes a huge problem if our next charter is not approved.
… if it IS approved, then we have time to get Controller Doc to CR, push other ones as we need to into CR2 etc.
… since a number of specs rely on Controller Doc. (vc jose/cose, vc di, vc data model).
… if we get that new charter, we have more time. we still need to get it wrapped up as quickly as we can.
… but we’re not sunk.
… if charter is NOT approved, or if it gets a formal objection, scope of the Controller Doc needs to drastically change.
… most likely, we may need to axe the Controller Doc entirely, and return the original sections to jose/cose and vc di.
… basically revert to how they were as they went into first CR. and proceed with the second CR using that.
… saying, Controller Doc standalone was a nice idea, but this time around won’t work.
… happy to take comments on the queue.
… but that’s the scope of the work for Controller Doc.

Michael Jones: I thought you were going to say that the third spec that relies on controller doc is the new DID spec (DID 1.1 WG).

Brent Zundel: that’d be fantastic, and would be a disappointment to the group if Controller Doc has to be axed.

Michael Jones: I’m optimistic we can wrap it up and get it done pretty quickly.

Manu Sporny: agree with your analysis, Brent,.
… I think regardless of where the Controller Doc is, it’d be good to go into a second CR with the other 4 specs.
… primarily because we’re as done with them as we can foresee.
… and if we go into CR2 and we’re not, or the charter gets messed up, the whole timeline changes anyway.
… it’d be a good signal to send that out to the group and broader community.
… that it’s a new snapshot, we finished a bunch of work, everybody should upgrade.
… so that’s another proposal, basically we publish a CR2 for Data Model, Data Integrity, ecdsa and eddsa.
… signaling that we’ll keep working on Controller Doc.

Dave Longley: +1 to Manu.

Manu Sporny: so, signal we’re going down that path, and only if charter falls through, we’ll do a CR3 (reverting controller doc stuff).
… we’re almost past the point of no return on that; it’d be highly disruptive to drop controller doc at this time.

Brent Zundel: agree with that, my only concern about going to CR2 of those docs with Controller Doc in limbo is,.
… we should clearly indicate that “these sections might change”.
… lets jump into VC DM issues.

3. VCDM Wrap Up.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc.

3.1. Respec’s VC plugin still does not work (issue vc-data-model#1538)

See github issue vc-data-model#1538.

Brent Zundel: this is Respec VC Plugin not working.

Manu Sporny: we did a new release, fixed a bug where it wasn’t generating all the examples on TR, except for the COSE stuff, that’s still broken for some reason.
… and regardless we’ll need to figure out what happens with COSE, both from media type perspective and in terms of detached vs not signatures.
… it could happen literally the day before we go to CR.
… once Benjamin gets back, we’ll fix the generation of the examples, and once there’s closure on jose/cose and detached sigs vs not, we’ll put that into the plugin.

Brent Zundel: sounds like this is tracking not only VC Respec plugin, but it’s tracking the completeability of the examples themselves.

Manu Sporny: that’s correct.

Brent Zundel: I’m fine with that, as long as everyone remembers that it’s tracking both of those.
… any other comments?

3.2. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)

See github issue vc-data-model#1551.

Brent Zundel: this is ‘rename spec registry to ‘VC Extensions’’.
… this is in parallel to the DID WG renaming their spec registry to DID Extensions.
… for us, renaming it to VC Extensions avoids the whole ‘registry vs directory’ issue.

Manu Sporny: we made a WG resolution last time, I’ve made that change.
… it’s at the new URL at github.
… however, I’ll keep this issue open until Ivan makes proper redirects on the w3c TR website.

Brent Zundel: would anyone be opposed to making this change?
… sounds like a straightforward move.

Phillip Long: +1 to this change.

3.3. Can we change `Usage Patterns` to `Patterns of Use` throughout? (issue vc-data-model#1555)

See github issue vc-data-model#1555.

Brent Zundel: question - can we change ‘Usage Patterns’ to ‘Patterns of Use’ throughout the spec?

Ted Thibodeau Jr.: See usage pattern ngram.

Ted Thibodeau Jr.: pretty simple and straightforward, ‘use’ is preferred over ‘usage’, it’s one of those words that seems more sophisticated, but is not, leads to more confusion.

Ted Thibodeau Jr.: See another usage pattern ngram.

Brent Zundel: folks, if you think this is a good idea or not, let us know.

Manu Sporny: +1 to making the change, it’ll be easy.

Brent Zundel: we also need someone to volunteer to do the work.

Manu Sporny: I’ll do it, should be an easy change.

Brent Zundel: we also have 1 PR.

3.4. Proof reading for Section 8 - Privacy (pr vc-data-model#1554)

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

Brent Zundel: this is gabe’s review of the privacy section.

Gabe Cohen: this is just privacy section, I’ll do security next.

Brent Zundel: lots of comments, feedback incorporated. I encourage folks to look at the PR.
… anything else, related to VC DM?

4. Controller Document.

Brent Zundel: https://github.com/w3c/controller-document/pulls.

Manu Sporny: when we get to the issues – couple things on controller doc, it would be good to understand which changes are editorial vs substantive.
… we’ve been telling people, hey we just copied & pasted the text out of DID Core, it’s already been approved. but now we’re potentially heavily modifying it, so we’ll have to be careful there how we communicate it.

Dave Longley: +1 to trying to keep everything as editorial as possible.

Manu Sporny: if you raise a PR, please make sure to mark it either as Editorial or Substantive/Normative.

4.1. (pr controller-document#41)

See github pull request controller-document#41.

Michael Jones: we should consider merging pr 41, the ‘remove proof purpose’.
… I think comments have been addressed?

4.2. Context section consistency issue 10 (pr controller-document#43)

See github pull request controller-document#43.

Michael Jones: it’d be good to get closure on 43.

Brent Zundel: Ivan is not on the call. it’s been open for about a week..

Manu Sporny: what this PR does is, it removes ‘digest’ to all the JSON-LD contexts that can be used in the controller doc.
… this PR removes that, without contemplating the side effects. it also removes the section on context injection.
… so, big -1 on this PR, I don’t think Ivan was thinking through the side effects.
… needs work & discussion.

Michael Jones: if you read Ivan’s comment from yesterday, I think he does understand.
… he makes the point that those who choose JSON-LD, they must choose the exact environment of how they use it.
… this spec is designed to be usable by a number of different audiences/environments. one of them is Data Integrity, one of them is vc jose/cose, and one is the new DID Core spec.
… and you’d use different contexts in different use cases.
… one of my issues was - by including the DI context as required, that’s not considering the other different use cases.
… it’s inappropriate to list DI-specific stuff in this spec. so, I think Ivan has it exactly right.

Manu Sporny: strong -1 for it being merged for all the reasons that have been raised in the existing PR.

Dave Longley: the context hashes that are specified in the controller doc are for the context that define the terms used, like key material.
… if other people want to use other contexts or use cases, nothing preventing them from doing that.

Manu Sporny: removing the context – when you go to implement this stuff, and you don’t have the information that’s being removed, it creates implementation problems.
… this completely hobbles jSON-LD implementations.
… so, objection to the PR in its current state.

Michael Jones: maybe we should bring it back up when we have Ivan, but responding to Dave,.
… saying ‘if you use JSON-LD, you must use the DI context’ – that’s the non even-handed part.

Brent Zundel: i agree that we’re likely to make more progress on this PR with Ivan present.

4.3. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Manu Sporny: we did have a discussion related to this in the DID WG.
… I forget what was said, but I think Joe, you said that you saw a way through this.
… that you felt it would be a normative change in the DID WG.
… I don’t quite think we still have alignment, other than that the text in the spec is wrong as it stands.
… so, there’s multiple interpretations of it.

Joe Andrieu: I think we can get there, we do need a broader conversation. maybe the right thing is for me to identify the places with spec text changes.
… I do think there’s some deep inconsistencies in mental models in the spec, we need to clean that up.

Brent Zundel: why does the Controller Doc spec need to talk about subjects at all?

Manu Sporny: we do it today because we have to talk about the thing that’s identified with the ‘id’.
… and we’ve been talking about that as the subject (of a DID or controller doc).
… sometimes (and this is debatable), this is the controller (of the controller doc).
… but if we call that ‘controller’, it becomes confusing when there’s a controller field.
… so like we’d have to say “the .id of the document is the controller, unless there is a .controller field, then that overrides”.
… the Controller Doc was supposed to be just a resource on the web. it’s been specialized over the years to talk about key material, but it didn’t start out as that.
… we call a controller doc’s .id field ‘the subject’ because that’s what it is, in the graph sense.

Brent Zundel: so to recap to make sure I understood,.
… we’re using the term ‘subject’ because there’s an .id property (of controller docs).

Dave Longley: the id identifies the thing (“the subject”) that the other information (e.g., like verification methods) is related to.

Manu Sporny: yes sort of?

Joe Andrieu: I agree, Brent, we should not be mentioning subjects at all.
… it’s a big source of confusion, we should clean it up.
… the mapping between an identifier and some real world state, that’s what VCs do.
… what I think the Controller Doc is doing, and I proposed some language in another issue,.
… is it’s using the ‘subject’ in the RDF sense only, to make statements about the identifier.
… the binding to real world entities, we should nuance out.
… that’s the domain of the Confidence Method in the VC world, it’s not something Controller Doc can address.

Dave Longley: IMO, this isn’t about real world, it’s about saying that the other JSON keys are used to relate stuff to the thing identified by that identifier – regardless of what other things it may refer to.

Manu Sporny: this is the HTTPRange14 discussion.
… we don’t want to go down that rabbit hole.
… I get what you’re saying, and it is a long running debate.
… on semantics of identifiers.
… but we’ve been using this thing consistently with graph terminology, nodes and edges etc,.
… if we make the Controller Doc special in some way, we’d have to specify it in a bespoke way.

Dave Longley: {id: "some_url", "thisIsAPropertyOfWhateverTheIdPropertyRefersTo": "foo"} <– i think that’s all “subject” is about here … it’s not about a “real world”, just binding the identifier to the properties, etc.

4.4. Cryptographic suite definition currently focuses on specifications rather than functionality (issue controller-document#49)

See github issue controller-document#49.

Brent Zundel: the goal of the issue conversation is to determine - is it triaged correctly, is someone assigned, do they need anything.
… I’m gonna jump ahead and say - for most of these that are assigned, folks know what needs to be done.
… we’ll begin with number 49.
… this is labeled as ‘Editorial, ready for PR’.
… which indicates that fix should be straightforward. does anyone disagree with the labeling?
… also, need volunteer.

Michael Jones: I’ll do it.

4.5. (issue controller-document#51)

See github issue controller-document#51.

Brent Zundel: another editorial, ready for pr labeled issue.
… straightforward change suggested. need volunteer.

Manu Sporny: this was raised by Orie, he just wanted an example.

4.6. Add Definition Reference column to Controller Documents property table (issue controller-document#53)

See github issue controller-document#53.

Brent Zundel: same, editorial, ready for pr.

Manu Sporny: I’ll note we already have this in the spec, we link to the sections.
… just to clarify - are you asking to just put those links in another column on the table?

Michael Jones: yes.

4.7. Authorization vs authentication note confusing (issue controller-document#55)

See github issue controller-document#55.

Brent Zundel: same as before, editorial, ready for pr.
… Mike makes a suggestion for some minor changes.
… need volunteers.

Manu Sporny: I can work on rewording.

4.8. Verification method type definition missing (issue controller-document#56)

See github issue controller-document#56.

Michael Jones: this is one of a few of such issues, has to do with - is there an actionable way for a naive reader to find the thing.

Manu Sporny: yeah, I can raise a PR to do that.

Michael Jones: thank you.

Brent Zundel: ok, one more.

4.9. Verification method controller(s) and controller(s) note confusing (issue controller-document#57)

See github issue controller-document#57.

Michael Jones: a meta point, if manu believes it’s ready for PR, and I believe it’s ready for PR, I’d like authorization from the WG for the two editors to collaborate & create PRs.

Brent Zundel: absolutely, that’d be fantastic.

Ted Thibodeau Jr.: to be clear, those are PRs that are then open for comments, yes?

Brent Zundel: yes, of course.