Verifiable Credentials Working Group Telco — Minutes

Date: 2024-05-01

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Benjamin Young, Michael Jones, Brent Zundel, David Chadwick, Hiroyuki Sano, Dmitri Zagidulin, Ted Thibodeau Jr., Dave Longley, Mahmoud Alkhraishi, Jennie Meier, Phillip Long, Will Abramson, Phil Feairheller, Paul Dietrich, David Lehn, Joe Andrieu, Gabe Cohen, Anil John, Nicholas Steele

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley, Benjamin Young

Content:

Brent Zundel: Agenda today is we’re going to look at work item status updates and do issue processing, etc.
… Anything additional for the agenda?

Michael Jones: We should talk about the controller document work.

Brent Zundel: Yes, we should, we can cover that during status updates.
… We can make that the first topic of the day.

1. Controller Document.

Brent Zundel: Quick intro. There are references to controller documents that, if I remember correctly, were originally references to DID documents. Folks in the group realized that a more general notion was needed for what we were looking for.
… Those words about controller documents were written up separately in VC-JOSE-COSE and VC-DI, with the intention that at some point we could take out those portions from each spec and put them in a single unified controller document specification.
… Last we spoke about it, consensus was that was a fine idea and Manu and Mike agreed to be editors on that document. The question now is: do we still need to do that as a group? We can have a brief conversation about it today.
… Let us know your thoughts on this.

Ivan Herman: Is this document … was this document meant as a REC track doc or something else?

Brent Zundel: Yes, a REC track document.

Ivan Herman: Ok.

Michael Jones: So I think, to the extent that our securing specs are using the controller document terminology, it would be better if it was in one place, which is why Manu and I volunteered to do this. As part of the background, the DID controller document notion only supports DIDs, whereas the more general controller document syntax used by this WG also supports Web URLs.
… Which is why we have our own notion of controller document that is more general in the first place.
… That said, while Brent’s characterization is accurate, I’ll also note that it’s expected that the different securing specs will profile the general controller document exposition saying which parts we want you to use and which parts we don’t want you to use.

Brent Zundel: Thanks, Mike, that’s helpful.
… Since VC-JOSE-COSE and VC-DI are both in CR right now, and these changes would officially be normative changes to those documents now and we would be shifting language around, it would be very important that the controller document be roughly settled relatively soon before those documents go into a second candidate recommendation phase.
… Timing wise, the sooner it can come together the better.
… I’m not hearing anyone on the call opposed to those proceeding with drafting a controller document.
… As far as I’m concerned, I think we should proceed.

Michael Jones: I agree. Timing wise, we had agreed some months ago, that once the two docs were in CR stage then would be the time to do this. Manu did check something into a repository which was a copy of the controller document section from the DI spec at that time, I believe. So the onus is on me to create PRs against that to do what may be necessary to make it general purpose.
… Unless anyone else tells me not to, I’m going to do that.

Ivan Herman: There is one thing that we should check – I don’t remember the details off the top of my head – there are some non-compressible times in the process in terms of how long something should stay a CR but also a WG, etc. I’m a little bit worried that time wise, this will clash with our plans on the current REC track doc at publication but we can check that soon.

Brent Zundel: Yes, you and I can look at that.

Ivan Herman: Let’s try to do that on Friday, because the dependency is very strong, and we cannot publish VC-JOSE-COSE and the other documents at Recommendations only if this one is a Recommendation, so we can publish together but not any other way.

Brent Zundel: So what Ivan and I will be calculating is the go/no-go, or absolute last date that we can publish the controller document if we’re going to make those equivalent modifications to the securing specs. If the controller document doesn’t get done on that schedule we’ll have to revert and just wish it a good day.

Joe Andrieu: See https://github.com/w3c/vc-controller-document/.

Joe Andrieu: The repo that has Manu’s draft, it looks pretty good. I think we’re in a place where we’re wordsmithing, but to Mike’s point, let’s dive in and do that work.

Brent Zundel: Any other comments?

Michael Jones: Thanks all.

2. Work Item Status Updates/PRs.

Brent Zundel: I’ll pause for a moment if there are any updates from work item editors or PRs they want to look at, please jump on the queue otherwise, there are a couple in the data model to look at.

2.1. Update media types to application/vc and application/vp (pr vc-data-model#1478)

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

Brent Zundel: The group had a conversation about media types and the difficulty in trying to register the media types we were hoping to register which were application/vc+ld+json – the attempt to register multiple suffixes in the DID WG the registration was denied, since then a lot more work has gone into defining what multiple suffixes mean and conversation with mediaman, the group working on those things at IETF and at IANA.
… We still don’t have a clear direction from IETF on what we should do.
… The last time we discussed, we said, let’s just proceed with application/vc and application/vp and then we can add the multiple suffixes stuff later once it gets sorted out.
… Mike suggested that perhaps we don’t abandon our hopes and put forth both options to IANA instead and see what they say.

Michael Jones: The essence of what I had written in the comments is that I’d rather us not proceed based on informed speculation, but to try to call the question, with IANA.
… To try and register what’s in our documents now.
… I volunteered to do so with the motivation that – or explanation to the designated experts and that while discussions are ongoing, we have timelines to publish REC track docs.
… And we’ll encourage that they proceed with the registrations, and we’ll get a “yes” or “no” and they only have two weeks to decide so it doesn’t impinge on our timelines.

David Chadwick: very sensible proposal.

Brent Zundel: Any objections to that approach – any feedback on that?

Phil Feairheller: +1 that sounds like a viable approach. I don’t see a downside.

Mahmoud Alkhraishi: +1 to proposal.

Gabe Cohen: +1.

Michael Jones: The group decided to proceed with whats in our spec, and I’m looking to proceed to make what’s in our spec a reality.

Dave Longley: my comment would be that agree that doing this would be what the group decided earlier–pre-Brisbane–but I’m concerned we’re headed into opposition knowingly.
… but I’d prefer we attempt both variations, to see which they prefer.

Benjamin Young: Yeah, I think what I was proposing is probably very similar to what Dave said – I think we want to attempt multiple variations at once.
… The idea of putting these singular things up vs. multiple suffixes at the same time, it would give them a way to pick a lane.
… And I think that not doing both approaches at wouldn’t give us enough information nor wrestle them in public – we don’t want to do things one at a time, we won’t get new information, getting compare/contrast would be more helpful.

Michael Jones: Yeah, I was in Brisbane, my characterization of what happened in Brisbane, there was a lot of talk about a lot of parties on what we could do. Decision making hats weren’t on, but more like talking about multiple possibilities. It even digressed into maybe single suffixes was a bad idea.
… That ship sailed most of a decade ago. This is one of the dysfunctions that can happen in a WG, discuss mode and not decision mode. That was in broad evidence in Brisbane.
… I think suggesting multiple things at once is bad tactics. If we give them the easy option and the one we decided on, they will pick the easy one, we will never find out what they think.
… It’s not a discussion just a request to register.

Ivan Herman: +1 to selfissued.

Michael Jones: They either will or will not. If we frame it as endless discussion, then we won’t get the data we need, so I won’t do that.

Brent Zundel: This was attempted and failed three years ago for the DID WG. A lot has changed since then, so we’ll see what happens.

Ted Thibodeau Jr.: Approximately what Mike said. If we ask for the thing that looks the most like the thing that looks most like what has been registered most recently, we won’t get what we really want. If we ask for what we really want, we might get it or we might not.
… I really dislike the idea of repeating the exercise of three years ago with little difference. I don’t think any of the decision maker decisions have changed. No different decision makers. I don’t have high hopes of approval.
… I think given everything in the picture, I think asking for what we really want, is the way to go, then we can use the fallback.

Brent Zundel: The course of action we will take is to register application/vc+ld+json and application/vp+ld+json as written in the spec today and we’ll see what happens.

Ivan Herman: Just a question – Mike, what about the media types that are in the VC-JOSE-COSE documents?

Michael Jones: Yes, we’ll do those too.
… It is a liaison request from W3C to IETF for what we’ve defined.

Brent Zundel: So it will be all of the media types that we have in all of our specs that we would attempt to register.

Benjamin Young: I wasn’t at the IETF meeting, but I watched it. There was a lot of microphone time spent talking about letting multiple suffix stuff in so it can be weeded out as a bad idea. I’m concerned that would be an outcome – and then our spec would be pointed at as a bad example.

Michael Jones: Maybe I’m a little too hard-nosed. But I’m not worried about the optics, it’s apparently to me that different people in the mediaman group have different views and people who think it’s a good idea won’t change and neither will those who think it’s a bad idea.

Anil John: +1 to what Mike just said.

Michael Jones: I think the outcome is inevitable either way.

Brent Zundel: If we have multiple suffixes and we succeed – then multiple suffixes only ever means what we want it to mean.

Joe Andrieu: +1 to applying to see if our concerns are real, rather than not applying out of concern.

Brent Zundel: I haven’t heard anybody say: Don’t do this.

Anil John: Wanted to close the loop that I checked internally with the implementation teams that are working with us on using JOSE for securing our trade focused VCDM credentials, and they noted that they will be contributing to the relevant portions of the test suite for “W3C Securing Verifiable Credentials using JOSE and COSE”.

2.2. Address Jeffrey Yasskin’s review comments that are Editorial (pr vc-data-model#1464)

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

Brent Zundel: This is Manu’s healthy response to a very thorough review from Google’s AC rep, Jeffrey Yasskin.
… The impetus for the review is that we wanted Google to say all the things they wanted fixed to avoid any formal objections from them. That was the gist of the request – and he provided an acceptable thorough review, the normative changes have already been made, and this is the editorial requests.
… This is someone who is very versed in Web specs in general and the Web in particular, but not so versed in VCs and he requested clarifications where he thought clarifications would result in a better spec.
… Some other changes are in a PR from David Chadwick.
… This PR is quite long and has some requests for changes and some approvals.
… Timeboxing this one to 7 minutes.
… Please jump on the queue to talk about 1464.

Ted Thibodeau Jr.: I believe all of my stuff is editorial.

Brent Zundel: Mike you were perhaps saying “don’t do this at all”?

Michael Jones: I am ok with the vast majority of this. I’m requesting that the text elevates multihash into normative usage be struck because that’s not appropriate in an editorial PR.
… Manu’s tried to say it’s already in the context so it doesn’t matter. The specification defines what people normatively do, not the context.

Brent Zundel: The one issue I’m running into – with the additional commits and changes … trying to find the comments. Down in line 3155, if folks want to read along. That’s a conversation we want to have.

Gabe Cohen: I believe it would be more neutral to say that you can use a digest property defined by the securing mechanisms. digestSRI isn’t defined by either of our securing mechanisms.
… Manu’s suggestion was to move it into VC-JOSE-COSE, but I think on further reflection we shouldn’t move it, I think it’s in another spec already and neutral. I think a possible way forward is to say you can use either digestSRI or a method from another securing spec without saying which spec.

Dave Longley: my memory of consensus was that implementers could use either, and we’d see how that goes.
… in terms of how digestSRI being in a different spec, that’s not quite right…there’s lots of work in our spec to shape it as a property and value for VCs.
… this PR seems to aim at the previous consensus.

Brent Zundel: the digestMultibase in the Data Model does not point to an unspecified thing, but to something we have published.
… Before going back to the queue – the digestMultibase as referenced, does not point to an unpublished spec somewhere at IETF, it points to the DI spec that our group has published as CR that defines the particular things it is concerned with. In my understanding, there is no normative pointing to something that isn’t a spec, except that we’re pointing at the DI spec which is underway in becoming a spec.
… so there is no normative pointing to something that cannot be normatively pointed to.

Dave Longley: +1 to brent.

Ted Thibodeau Jr.: Mike, you are objecting to a thing called multihash which isn’t in this document.

Michael Jones: digestMultibase sorry.

Ted Thibodeau Jr.: That appears to not be as significant a change as you’re making it be.
… My eyes are different than yours.

Michael Jones: Gabe, thank you, you are correct, I have no objection to digestSRI because that’s in a W3C REC that defines or largely defines what we would need. Largely for the record, my objections to the whole multihash family is that they fail to make a choice.
… That’s my primary objection to using that at all.

Dmitri Zagidulin: I think ‘multihash family’ may be somewhat confusing. I think Mike’s main objection is to multiBASE.

Michael Jones: With respect to using that at all, with respect to DI standardizing digestMultibase, that’s fine, but we went through an exercise six months ago or so of making sure that the data model didn’t have any normative dependencies on either security spec – it has informative references.
… Part of the reasons for doing the controller document work – an alternative was expressed that maybe we can just reference the controller document section from the data model and call it good. Orie and I and others felt like that was turning things on their heads and the data model should stand on its own.
… I don’t want to change it to have dependencies on either securing spec.

Dave Longley: just a clarification, there are pieces of the SRI spec did have to be added to our vocabulary earlier.
… I did not mean to imply that it was yet to be done, but to point out that we could not simply point to someone else’s specification.

Gabe Cohen: +1 Brent.

Brent Zundel: Since the changes to section 5.3 of related resources is the piece under contention, and I will reach out to Manu here too, the suggestion is that the changes to this section be removed from this PR and made a separate PR that can be further discussed so it doesn’t hold up all of the other myriad changes that do not have opposition.
… Mike, would that alleviate your concerns with the PR?

Michael Jones: Absolutely, once that text is gone, I’ll approve.

Brent Zundel: I’ll let Manu know we can put those changes in a separate PR.
… Any other comments on this PR before we move on?
… I think we covered the main big things we wanted to talk about and maybe we can move to issue processing now.

3. Issue Processing.

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

Brent Zundel: A number of these are those we know have to happen, others we will look at now.

3.1. Should we use Ed25519Signature2020 in the Examples? (issue vc-data-model#1457)

See github issue vc-data-model#1457.

Brent Zundel: David Lehn, can you talk to us about this issue?
… There are some cryptosuites that are being referred to specifically – which should be updated.

David Lehn: This is related to the respec vc plugin, I haven’t had time to work on it – and I know Benjamin was making some changes to it and we had movement on it.
… There were some general ideas where we wanted to improve the generation of the output and improve auto-generation.
… I just need to re-prioritize things and get it done quickly, it’s not a lot of work, I just need to spend some time on it.

Brent Zundel: Would it be possible by next week for you to let us know when you can get it done?

David Lehn: Yes, excellent.
… I’ll probably just be doing it by then.

Brent Zundel: Ok, thank you for that feedback.

3.2. credential repository vs repository, and definitions in 1.2 Ecosystem Overview vs 2. Terminology (issue vc-data-model#1475)

See github issue vc-data-model#1475.

Brent Zundel: Ted, could you jump on the queue and walk us through this – and to the group, who would be willing to be assigned to make it happen?

Ted Thibodeau Jr.: One item here is a quick search and replace PR, another is rephrasing a sentence, the third is rationalizing some competing definition of things. Ecosystem and terminology do the same thing partly – but with different definitions.
… That one I hadn’t resolved at all. That’s not in the comment from Manu either.

Brent Zundel: Is this something you could begin to address in a PR?

Ted Thibodeau Jr.: I don’t think it needs discussion, just heads down.

Brent Zundel: Can I assign you?

Ted Thibodeau Jr.: Sure.

3.3. Consider explicitly allowing/recommending language maps for use in internationalisation. (issue vc-data-model#1479)

See github issue vc-data-model#1479.

Brent Zundel: This was raised a couple of weeks ago – consider explicitly allowing / recommending language maps.
… This was read by someone outside the group who wanted more clarity on the i18n text – they are making a concrete request for more text.
… We did ask for specific language that they’d perhaps find acceptable – would like to hear from folks on this in the group.

Anil John: The ability to do language translations automatically for the credentials and attestations that we have would be good. I saw the feedback from Manu on the issue. Just a clarification question – it sounds like basically having JSON-LD compact form, you have the ability to do that. Does anything in the current spec prevent the use of language maps in anyway shape or form?
… For people who want to use that for translation?

Ivan Herman: I think the problem is that there a section – I don’t know from the top of my head – that shows how a pure JSON processor can handle JSON-LD credentials and that is not describing anything about language maps the way they are done in JSON-LD.

Anil John: Understand Ivan’s point – I’m glad the flexibility exists that allows someone who wants to use a JSON-LD API to get functionality that is unique to JSON-LD and obviously in a context-specific processing love the flexibility to avoid doing that using static contexts and JSON schemas.
… The question I would ask is – if you wanted to use the features that are unique to JSON-LD, you would need to use a JSON processing capability. Great. If you choose to go down that path, does anything prevent you from doing that – with the full understanding that you’re going to be treating the credentials that way, you won’t have access to that functionality?

Brent Zundel: Nothing in the spec prevents you from using JSON-LD to use its full capabilities to my knowledge.

Dmitri Zagidulin: would just more examples (of multi-language VCs) help?

Benjamin Young: This isn’t about JSON-LD processing being required. The spec simply says “shape the JSON like JSON-LD does.”.

Phil Feairheller: Isn’t the issue here simply that there isn’t a comparable set of paragraphs that describe using JSON-LD specific language processing? Implication is that it would be good to have both explanations.

Anil John: Thank you. that is very helpful dlongley.

Gabe Cohen: It seems there is a JSON-LD language map solution – is there another one if they don’t want to use it?

Brent Zundel: Thanks Gabe.

Dmitri Zagidulin: Reading this issue from Anthony, he does a lot of advising to the EU commission on the learning data model, etc. lots of skin in the game. The way he phrases the issue is that he would like it to clarify whether only the subset of i18n is supported or if multiple methods are supported.
… JSON-LD has several methods, we support and recommend a subset, so I am reading the issue as “our subset vs. all options”.

Brent Zundel: Perhaps this issue could be resolved with a sentence that says “Additional JSON-LD capabilities could be utilized – but if the recipient doesn’t do JSON-LD processing they may not be received”.

Dave Longley: It’s not a JSON-LD processing issue but a type-specific VC one.

Brent Zundel: We’ll get back on timing issues for the controller docs, thanks all!
… Thanks for scribing, Dave.