Verifiable Credentials Working Group Telco — Minutes

Date: 2024-10-09

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Wesley Smith, Hiroyuki Sano, David Chadwick, Calvin Cheng, Dave Longley, Kevin Dean, Gabe Cohen, Phillip Long, Jennie Meier, Dmitri Zagidulin, Benjamin Young, Michael Jones, Ted Thibodeau Jr., Brian Campbell

Regrets:

Guests: Calvin Cheng, Yvonne, Maya, Ken, Kay, Kyle

Chair: Brent Zundel

Scribe(s): Wesley Smith

Content:

Brent Zundel: gonna get going here, our agenda today is simple, we will recap TPAC briefly, then spend the rest of our time on controller document and what we need to do to move that spec forward. We also have folks on the call who may be here for the first time, if they would like to introduce themselves please do.
… I can call out folks’ names if that would be more amenable.

Calvin Cheng: I am Calvin from the government technology agency of Singapore, this is my first time in this meeting, but I have attended sessions with manu before. I have my colleagues with me from Singapore, we are trying to have a followup on our use case for cross border trade. I will let them introduce themselves.

Kyle: I am also from the gvt technology agency of Singapore, I am one of the software engineers on the open attestation framework.

Maya: Hi everyone, Maya, also colleague of Calvin on government side, this is my first time here.

Kay: Hello, I am Kay, from the Infocomm Media Development Authority. Working on the cross-border trade use case.

SinYong: Hi everyone, I am from Singapore as well, we are applying VCs in international trade use cases.

Yvonne: Yvonne, also from government technology agency of Singapore.

Kay: Kay, also from IMDA Singapore, working on VCs for cross border trade use cases.

Brent Zundel: Just to clarify, membership in W3c is first step towards participation, the next step is to formally join the WG, there may be one more step that needs to be taken before the government of Singapore representatives can substantively contribute.

Calvin Cheng: I had the assumption that we were part of the WG but we will sort this out.

Brent Zundel: https://www.w3.org/groups/wg/vc/.

Brent Zundel: I will drop a link to the WG page in IRC - on that page you will see a “how to join” link that gives you the instructions you need (or it will tell you you are already in the group, in which case I apologize).
… A couple notes before we move into our formal agenda: we are currently operating under our new charter. What this means for our day to day is that nothing is going to change. We have our official timeline goals, to have everything published as a rec by Feb next year. This means we need to continue moving quickly.
… The other note is that you should have seen emails regarding the next candidate rec phase for VCDM 2.0 as well as Data Integrity, ecdsa, and eddsa. Those docs have all been prepared for their next CR phase. That is in reflection of resolutions made at TPAC.

1. TPAC Recap.

Brent Zundel: First topic is TPAC recap.
… The group met for a day and a half and had focus time for each of our specifications that are still under way, for VCDM 2.0 the group resolved during TPAC to advance it to another CR round, which we anticipate will be the last CR round. We will get a round of feedback and then will respond to that feedback, respond to horizontal review, and then will continue advancing that specification based on the implementation results we get from the test suite.

Manu Sporny: https://w3c.github.io/vc-di-ecdsa/transitions/2024/CR2/.
Manu Sporny: https://w3c.github.io/vc-di-eddsa/transitions/2024/CR2/.
Manu Sporny: https://w3c.github.io/vc-data-integrity/transitions/2024/CR2/.
Manu Sporny: https://w3c.github.io/vc-data-model/transitions/2024/CR2/.

Manu Sporny: I was going to drop some links so that people have them. We sent the same links out to the mailing list. As Brent mentioned, we decided to go to CR2 with a number of documents, in IRC is a link for ecdsa cryptosuite, eddsa cryptosuite, Data Integrity, VCDM 2.0.
… Ivan has prepared the transition requests, they still need a little editing, we need to still merge a couple PRs in before going to CR2, those are waiting in the wings. These are just implementing what we agreed to at TPAC, but I wanted to make sure everyone had the opportunity to review those as of this call. When we get to issue/PR processing I will point these out. As Brent also mentioned, in each of these documents in the status of doc section, we have linked to the test suites and said that anything without at least 2 implementations is at risk.
… As far as I recall, DI and the ecdsa/eddsa crypto suites have nothing at risk, the enveloped presentation stuff in the VCDM is at risk but we expect multiple implementations there. There is good stability in the specs and test suites, but as people implement we might have to update or change the test suite. Another thing that came up is that there are a couple implementers that would like another interface into the test suite, and we are discussing that with the test suite team, how to incorporate things like VC-JOSE-COSE. Things are on a well-known, calm path for those documents.

Brent Zundel: chair hat off to comment on the need for enveloped presentation implementation evidence and the current test suite’s inability to accept enveloped presentations, correlation there.

Benjamin Young: we will bring back office hours to try to get engagement on the needed test suite changes to get people integrated.

Brent Zundel: continuing the recap, we also had a conversation around the VC-JOSE-COSE media types, it was a good presentation of all of the options as we have been made aware of them, the only option that came close to gaining full consensus was to attempt to register application/vc+ the various media types, jwt, sd-jwt, and cose. While this group came close to consensus there are folks at IETF that were hoping to register application/vc+sd-jwt, we did have meetings with those folks and proposals from them were part of the proposals presented to this group. Those conversations were not able to find mutual agreement.
… We are moving forward because that was the last normative decision we needed to make and we need to move forward. The group should expect formal objections from W3C members when we go to move VC-JOSE-COSE forward. We expect those formal objections will be heard and arbited per W3C process.

Manu Sporny: IETF mailing list discussion on VCWG media types: https://mailarchive.ietf.org/arch/msg/media-types/ZTOqW6NHfb6h82Ev28NptMWOFZQ/.

Manu Sporny: +1 to what you said, Brent, there is an active thread of discussion on the IETF mailing list, the discussion has been broadened a bit, there has been a question raised around whether our group registered our media type too soon, that has to do with media types used in other specs as well including VCDM 2.0.
… I went back and looked, we have been using application/vc media type in the spec for 18+ months at the time that it was registered, the conversation around the +ld +json parts of the media type is why we did not do a provisional registration beforehand. The fact that we have published our spec in 2019, started the work in 2017, is a demonstration of how this has existed for a while. Take a look at that thread, if folks want to provide input in a personal or corporate capacity, we all agree that Gabe would be reflecting the intention of the WG in engaging. Please be clear if you make a comment on that list in what capacity you are making it. Gabe is the only one supposed to represent the WG.
… The other thing I want to point out is that the proposal we passed allows us to share the media type with the folks at IETF that want to share the media type, we can switch off content type, it is distasteful to a number of people but possible to determine the contents of the envelope based on content-type. This isn’t an either or, we try to balance things and allow sharing of a media type in a way that is technically deterministic.

Brent Zundel: just to add a bit to that, the official W3C guidance for registering media types is that a couple of months prior to our first CR phase we should begin that conversation with IETF. We definitely did that, the media type conversation with IETF has been going on for a long time, we even had a previous registration rejected. I believe that we were already in CR when we requested application/vc and application/vp, so we were a little late per W3C guidelines.

Gabe Cohen: I’m noticing a bunch of comments from the IETF folks on our PR giving historical arguments, I believe this should be a technical argument, and our path forward is technically sound. I have the request drafted and am willing to submit it with the group’s approval.

Brent Zundel: I have a response drafted, I expect to respond and merge the PR today, after which feel free to make the request.
… that covers TPAC unless folks have additional.

Brian Campbell: the comments on the changes after candidate rec were mine, I stand by them and they were not made in ignorance. The given change does not represent any form of compromise. My commentary was factual and I would appreciate if “ignorance” were not used.

2. PRs and Issues.

Brent Zundel: manu you had mentioned wanting to point to a couple PRs that were not in controller document.

2.1. Require digest verification for related resources. (pr vc-data-model#1567)

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

Manu Sporny: I took an action to raise a PR in VCDM 2.0 for requiring digest verification if it’s provided, there has been some discussion on it, I wanted the group to see that this is out there, there are some suggested changes, I will process this and merge it by the end of the week, please get in there and provide commentary, hopefully the PR reflects consensus in the group. I plan to close the DI issue based on the merge of requiring digest verification if it’s provideds provided.

3. Controller Document.

See github issue vc-use-cases#157.

Calvin Cheng: I apologize if this is not the right time, because with my colleagues here, we are just trying to move forward on the use case, I want to highlight and mention this, but we will probably work with you all offline on a followup.

Joe Andrieu: I just want to confirm cc that we want to work with you and probably should set up a call. Now that I understand you have this novel cryptography that enables this use case, happy to work with you and move this forward.

Calvin Cheng: we will set up a call.

Manu Sporny: this is going back to controller document, but +1 to the use case that cc mentioned.

3.1. What is the role of the subject when the controller property is present? (issue controller-document#33)

See github issue controller-document#33.

Manu Sporny: switching to controller document, the first issue, JoeAndrieu, is waiting on you for PR text, this is issue 33 and also issue 75.

See github issue controller-document#75.

Joe Andrieu: I have 90% of a PR for one of them, which is the language around that a controller document lets you verify proofs. That was a straightforward change, the other is on my queue and I will have something by next week, that has language defining the controller property, which is a CR issue.

Manu Sporny: moving through the other issues, there were a number of these that we briefly discussed during W3C TPAC, we marked them as discussed or editorial, we have not had any pushback on the editorial nature of most of them, so we are going to address those during the CR phase.

3.2. PING review for v1.0 (issue controller-document#93)

See github issue controller-document#93.

Manu Sporny: there are other issues, that were raised, that we need to address before we go into CR. Two of those are the horizontal review, including the privacy review and the technical architecture group review.

Manu Sporny: https://github.com/w3c/controller-document/issues/93#issuecomment-2395585400.

Manu Sporny: I will put in the PING review first, issue 93, if you go to the bottom of that issue I have specifically said what we are going to do, and we believe that those would address PING’s concerns. There is a checklist of 4 PRs that the editors can raise on the spec that the editors believe will address their issues. Once those are merged, unless PING says otherwise, we can close this issue.
… For PINGs review, we will add content to the specification that will outline use cases for controller documents, we will highlight those use cases and point to the DID use cases document, they also asked for us to describe how this spec relates to the web origin model, we will add a section there, they asked us to clarify what we mean by personal information, we will clarify what we mean by personal information, which is things that can be easily correlated to your in person identity.
… Finally, we said we would address the issue that Joe just spoke to, and we will do that. Those are the things we will do as a result of the PING review, would anyone object to any of those things?

Joe Andrieu: just a note on the personal information, we might include characteristics, I don’t know if my gender or my race is considered biometric or biographic, just a note to try to include something like that maybe.

Manu Sporny: +1, I will do my best, we can adjust my PR as needed.

3.3. TAG review for v1.0 (issue controller-document#94)

See github issue controller-document#94.

Manu Sporny: the next item, subtopic issue 94, is the TAG’s horizontal review of controller document.

Manu Sporny: https://github.com/w3c/controller-document/issues/94#issuecomment-2395604054.

Manu Sporny: we were joined by jyasskin at TPAC, there is an overlap with the PING’s review around use cases, the second item is to clarify that the semantics between a “JSON interpretation” and a “JSON-LD interpretation” must be the same, and any differences are either a spec bug or an implementation bug.
… they said that would address that concern. We will also raise a PR that while multihash/base/key give flexibility, the spec should choose specific formats to increase interoperability. That is a common misconception around multiformats, that because you can add a header it is the Wild West and people can do anything. We will raise a PR to do that. We will add a section to security considerations around not hash pinning controller of a document. It’s a double edged sword - the controller field allows you to support use cases like guardianship on a controller document, but it also means that if your guardian is compromised in some way, it impacts your document as well. There is a way to protect against that with hash pinning, but you can lock your guardian out if you do that.

3.4. Find a better name for the specification (issue controller-document#100)

See github issue controller-document#100.

Manu Sporny: lastly, we need to be more specific about throwing an error if people try to claim keys that are not theirs. We will raise PRs over the next week or two to get that done. That’s it for the TAG review. During W3C we raised an issue to rename the specification, so that is issue 100, this is very much a bikeshedding discussion, everyone has an opinion. One thing that kind of at least came to me and I suggested it in the issue is, we have been using controller document historically because the controller field can point to the document. It’s about control over public keys and control over services, but one other name we could consider is that this is also about “interacting” with an identifier or an entity identified by an identifier. There is still disagreement about which we are doing, but it’s about understanding how to interact with those things, whether in a decentralized way through crypto or through services like engaging with an email address.
… One suggestion is to use the word “interaction document”, it is definitely not perfect, but the question is whether it is better than “controller document”.

Brent Zundel: My intended procedure for this issue is, unless a proposal is made for a new name that everyone really likes, then we are not going to change it. If we cannot find something that is a clear winner among participants, we are going to stick with what we have.

Dave Longley: +1 to brent, not worth changing without a “big winner”.

Brent Zundel: It’s unlikely that we will spend much group time on what a new name ought to be, if you have preferences and would like to make them known please engage on the issue. We can take a few minutes now if folks really want to voice their opinions, but without a clear winner we will make no change.

Manu Sporny: can we take a quiet poll on what people would prefer between “controller document” and “interaction document”?

Michael Jones: Controller Document.

Manu Sporny: Interaction Document.

Kevin Dean: interaction document.

Joe Andrieu: verification document.

Gabe Cohen: identifier document.

Phillip Long: identifier document.

Dave Longley: controller document (despite its imperfections… because the others don’t sway me enough to change it).

Brent Zundel: not seeing clear consensus on this issue, the conversation is welcome to continue in the issue, however when everything else has been addressed to move to CR we will proceed forward with “controller document” if consensus not reached.

3.5. Add security and privacy considerations for services. (pr controller-document#101)

See github pull request controller-document#101.

Manu Sporny: probably not valuable to look at open PRs, there is an open PR for adding new sections related to services to controller document that needs review. Effectively a copy paste from did core.

Brent Zundel: with that we are done for the day. Thank you folks for coming. Thank you Wes-smith for scribing. I will not be able to join the next call but decentralgabe will guest chair for us, we will discuss controller document PRs.
… thanks to the folks from Singapore for coming, we hope the use case discussions will prove fruitful.