Verifiable Credentials Working Group Telco — Minutes

Date: 2024-04-10

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Paul Dietrich, Brent Zundel, Manu Sporny, Ted Thibodeau Jr., David Chadwick, Dave Longley, Benjamin Young, Dmitri Zagidulin, Steve McCown, Joe Andrieu

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dmitri Zagidulin

Content:

Brent Zundel: agenda today - work items, issue processing.
… any changes to the agenda or preferences?

Ivan Herman: last week we said we’d vote for CR transition of jose-cose - was it today?
… at the moment, the day we had in mind was the 18th, which is next Thurs.
… to do that, necessary to vote for it today. tho there are still minor issues to be settled before I can send it to management, and I dont’ see Gabe.

Brent Zundel: both Gabe and Mike are unable to join.

Ivan Herman: we’ll have to postpone the CR then.

Brent Zundel: confirmed.
… we’ll deal with it next week.

Manu Sporny: next week is IIW, and I expect a decent chunk to be gone for that as well.
… I’m wondering if we could vote today anyway, and put it out to the mailing list to see if anyone objects.
… I realize it’s weird to do a vote without editors here, but I think everyone on the call last week heard that we’d do it this week, and people still have 7 days to object.
… I’m afraid if we don’t do it this week, next week we won’t have enough people again, and it’ll keep being delayed.

Ivan Herman: that’s one aspect, the other is - Gabe put out a CR text in a separate branch / PR. and I had some comments on the text that need to be addressed before merging.
… so, the vote is one thing, final CR is another thing. and I don’t feel like going there and doing changes myself (not even sure I could).
… if we vote today, it will not make things faster.

Brent Zundel: I don’t mind putting a proposal in front of the group today as long as we can craft it properly.
… Gabe mentioned to me that he was going to try and mend the PR with the draft; I don’t see any current changes on it though.
… if someone would like to craft a proposal to put in front of the group, I’m happy to run it.
… I’m still planning to be on the meeting next week, even though it’s IIW.
… and if there’s not enough people, it’ll be a brief meeting.
… anyone opposed to a proposal today?

David Chadwick: I was just looking at the list of issues; there are a lot of issues, all flagged Post-CR. do we know for certain that when those issues are resolved, they won’t require a second CR? or is not a problem?

Ivan Herman: not a problem.

Brent Zundel: I trust editors to triage appropriately.

Ivan Herman: to be clear, PR 265 must be addressed before we go on, but that’s understood.

Proposed resolution: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication. (Brent Zundel)

Ivan Herman: +1.

Manu Sporny: +1.

Dave Longley: +1.

Brent Zundel: +1.

Dmitri Zagidulin: +1.

Paul Dietrich: +1.

Ted Thibodeau Jr.: +1.

Manu Sporny: .

Benjamin Young: +1.

Steve McCown: +1.

Resolution #1: Publish the vc-jose-cose specification based on https://pr-preview.s3.amazonaws.com/w3c/vc-jose-cose/pull/265.html as a W3C Candidate Recommendation with a 28 day CR period and a target date of April 18th for publication.

Brent Zundel: thanks all!

1. Work Item Status Updates/PRs.

Brent Zundel: let’s jump into next topic.
… I’m happy to announce that the status of vc-jose-cose has been approved to go to CR, hopefully a smooth transition.
… number of post-cr issues on it, I trust will be resolved in due time. I do know the test suite for vc-jose-cose is in need of work; we have commitment from some people to do that though.

Manu Sporny: thanks brent, just to go over the other specs,.
… we’ll get to issue processing later. We have a healthy (small) list of issues on the core data model. that one media type discussion we need to have, the only real big question remaining.
… a number of PRs on vc dm that need to be processed; largely editorial.
… for Bitstring Status List, I believe we have all the issues under control, would allow us to suggest a Candidate Rec post april 21st.
… noting that we have actually had significant reviews from PING and the security group is aware of it, and is planning to do a review before or during CR.
… the rest of the technical issues feel like theyr’e under control (internationalization - we do have an answer, if slightly shaky, around the messages in status list – they’re meant for devs not end users, so it’s ok not to have i18n tags on them.
… if we change our mind in the future, we can just use standard JSON-LD tags.
… the potential F.O. about status list VCs being able to be changed after issuing, there’s a PR for that (164).

Manu Sporny: Ensure that status messages are committed to at issuance time: https://github.com/w3c/vc-bitstring-status-list/pull/164.

Manu Sporny: which should address PING’s and Joe’s concerns around that.
… although there have been questions raised around – if messages have meaning only to developers, does that mean anything. I don’t think those will lead to any kind of objections.
… bitstring status list is on a good path towards the end of April, so heads up to chair & editors.
… should I prep the doc for CR, and of so, what’s the target date?

Ivan Herman: there is an issue, 157, that requires manipulation on the repo level, you should take a look at.

Manu Sporny: +1 that needs to be fixed, I’ll take a look.
… that’s a ‘during CR’ though.

Ivan Herman: should be done before.

Manu Sporny: ok, let me change the label.
… i’ll handle it during my next edit cycle.
… moving on to DI issues. VC DI is drawing a number of editorial changes, 3 are normative.
… which will trigger a 2nd CR. same is true for ecdsa- and eddsa-, and probably BBS- as well, so look for PRs on those specs in the next few weeks,.
… based on implementer feedback.
… sometimes in normative statements, which is good, that’s what CRs are for.
… nothing major has come up though during CR though, no catastrophic security vulns, no formal objections brewing, etc.
… I think that’s true of all of our CR docs at this point.

Brent Zundel: thank you manu. in general, regarding Bitstring Status List.
… as soon as the docs are ready to move forward, we can move them forward.

2. VCDM Issues.

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

Brent Zundel: let’s go to our VC DM issues.
… first one we don’t need to talk about, 1437, we know that needs to happen.
… next one is 1239, we know that needs to happen.

2.1. Revisit Verifiable Credential media types (issue vc-data-model#1462)

See github issue vc-data-model#1462.

Brent Zundel: next topic to discuss is - 1462, revisit VC media type.

Brent Zundel: See https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/.

Brent Zundel: here’s a link to the discussion that’s continuing among the media type mgmt WG at IETF.
… it’s a long discussion, a number of us have taken part in it, have shared opinions.
… manu, if you would be willing to give the group a summary of where the thread has gone?

Manu Sporny: Summary of what has happened to date: https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2016609877.

Manu Sporny: I won’t go into the summary in too much depth, there’s a link to it here.
… we need to register a media type for VCs, we suggested using one that uses multiple suffixes, that has led to a long discussion at IETF over the past 5+ years.
… we thought we were done as of last IETF, that was not the case, we don’t know when we’re gonna be done.
… we’re probably at the point that this group can’t wait any longer for “the right thing to happen”.
… a number of options has been brought up – from use suffixes, to deprecate suffixes, and every variation in between.
… based on the last 2 weeks, seems like eventually IETF is going to allow people to do whatever, in certain patterns and categories.
… people are definitely using suffixes in some kind of ways, there seem to be different philosophies on it.
… the outcome if we don’t try and force the discussion to terminate any time soon is – everything registered in the past in fine, here’s some guidance for the future (for media types w suffixes).
… so what it seems like will happen, they’ll punt the explanation of what suffixes mean back to the spec that is registering the suffix.
… like “this is the media type we’re registering, this is what suffixes mean, etc”.
… we thought this was gonna end 6 months ago, and it hasn’t yet, so that’s where we are today.
… we can take a couple of paths forward. there was the ‘exception path’ where we can register whatever.
… option b was - not use any suffixes at all, and just use application/vc and /vp.
… and then for SD-JWT, you can add +jwt to the end of that.
… option c was - wait until discussion ends at IETF.
… as the editor of that spec, I don’t know when that will actually happen. might be within 6 months. 3 months unlikely.
… I wouldn’t be surprised if it went on for another year. Option C is - we’re not gonna register a media type until the WG figures it out.
… there has been some discussion in the issue; my gut tells me that Option B would result in us being able to register it immediately with no major pushback.
… at the same time, it’s not necessarily ideal, as some people are pointing out.
… there are likely more technically correct ways to address the issue.
… another option not there in the beginning, coming from Mozilla / Martin Thompson, was - our spec can say, here’s the base media type,.
… however you can ALSO use these other media types – you can serve it as application/ld+json, or something else, and here are the rules for doing it that way.
… that would require a decent bit of discussion.

Brent Zundel: I’m wondering – my perspective, chair hat off, it seems like one of the reasons we’d want to move forward with a media type registered now, is because a data format that has a media type registered, there’s a perception that it’s “a real thing”,.
… like, we’ve graduated, we’re real, we have a media type, I think that’s the perception.
… so from that perspective, it’d make sense to move forward and claim one.
… the pros of option A, and moving forward w that, is that multiple suffixes make sense to us. drawbacks – registration of multiple suffixes media types will be used for all time as a bad example.
… and I don’t want to be painted with that brush.
… I recognize the drawbacks of choosing something simple like application/vc.
… or you can just use ld+json in our description of the media type.

Dave Longley: +1 to registering application/vc, application/vp, and saying that application/ld+json is also permitted – and keeping open the option to add multiple suffixes in the future.

Ivan Herman: I am pretty worried about all of these things; we’ve been fighting w this for I don’t know how many years now.
… if we’re getting to a registration of something that won’t be really accepted by IETF, it leads to a lot of discussion, and at the end of the day, it will create problems for the final Rec.
… in the meantime, it’s a lot of discussion; I don’t remember how many media types we’re talking about, and to add jose/cose to it, we’re talking about 6 or 7 media types we have to fight for.
… and I don’t feel like doing that. I repeat what I said last week, I still believe an option is, we either don’t do anything right now, or just try and register /vc and /vp.
… additionally, we have this pending charter proposal that we have to talk about at some point.
… and we should add to the charter proposal – if IETF takes a final stand, and if it allows us to register ld+json or whatever, we can do it in the next incarnation of the WG, and we don’t do it now. I think that’s the best option.

Ted Thibodeau Jr.: my sense of the IETF position at this moment is - there are a couple of very loud voices who have been around for a while, and type a lot, who are very much against what is being called “multiple suffixes”, which I think of as sub-subtypes.
… it is not my sense that this is an IETF position as a whole, or even just of the decision makers.
… I don’t think we should be scared off from doing the right thing, because we think it won’t get through.
… most of us have a sense of how media types have worked historically, and that is not what is currently being trumpeted by the loud voices.
… the loud voices are saying, everything we’ve been doing historically is wrong, and we won’t do it anymore. that should be objected to, by as many voices as possible.
… there are some errors in what has been registered in the past, and there are some errors in what’s being requested in the jose/cose thread.
… there’s other options, and I believe those won’t get objections from IETF.
… the timing sucks, no way around that.
… but I don’t want to do anything that precludes us doing the right thing as time moves on.
… IETF is giant in scope.
… but it’s also a giant cruise ship, difficult to turn quickly. more voices help in that.
… partly because more voices can put it in different words, and can be heard differently. if you haven’t participated in the thread, and understand what we’re trying to do, weigh in.

Manu Sporny: I agree with a lot of what Ted said, I do think there is a minority opinion driving the discussion at IETF.
… I am still hopeful we can come to something that won’t undo 20-30 years of media registrations. But that’s not our fight. in this group, we just need a media type.
… I’m a strong +1 to what Brent said, that when you have a media type, something is real.
… for better or for worse. so let’s pick a media type that does not limit our future options.
… for example, one thing we can do (I’m willing to write a PR), is to say, we’re registering application/vc and /vp, today.
… and for the jose/cose specs, we can add a +jwt to it.
… in theory, that matches everything done previously, won’t get pushback.
… and in our specs, we can say, alternatively, you may serve things as application/ld+json,.
… we’ll make a very strong case for application/vc.
… but if you want general semantics, you can just do ld+json.
… in the future, if the multiple suffix stuff gets to consensus, in a future spec, we can say, you may serve it as application/vc+ld+json.
… the only downside to that approach is - all of a sudden, we have potentially 3 media types. but it’s not that difficult for software to deal with 3.
… we do have one issue regarding file extensions.
… which you can associate with just one media type, if I remember correctly. but that’s a smaller problem to deal with.

Ivan Herman: i have the impression that we are widely agreeing. the only thing I’d ask for this PR, which I agree with, can you also make a PR which adds something into the charter proposal for the future WG.
… or, rather, the maintenance WG.

Manu Sporny: happy to do that.

Brent Zundel: sounds like we have a path forward.
… we’ll see how the discussion pans out with the PR. seems like we’re in a place where that PR can be written.

2.2. Non-normative changes from Jeffrey Yasskin’s review (issue vc-data-model#1348)

See github issue vc-data-model#1348.

Brent Zundel: 1348, non-normative changes from J Yaskin.

Manu Sporny: i would love help on this, not sure how to distribute the task, other than people picking sections from the big long list.
… if people want to take sections from the bottom of that list, that’d be awesome.
… there’s roughly 35 changes that need to be made. not too bad, most of those should be editorial.
… so, volunteers welcome.

David Chadwick: the bit I’ve done is nearly agreed on now. the one thing I don’t know how to do is to add a reference to an external document.

Manu Sporny: at the top of the document, there’s a section called Biblio or something like, that has a bunch of square brackets, that’s where you add it.
… if you’re referencing an existing RFC, those should be there already, you just need double brackets around RFC.

Dave Longley: See https://github.com/w3c/vc-data-model/blob/main/common.js#L7.

Dave Longley: DavidC ^.

Dave Longley: note that this: https://github.com/w3c/vc-data-model/blob/main/index.html#L48 links to that common.js file.

David Chadwick: I couldn’t find that section.

Manu Sporny: ok, yeah, what dlongley said.

Brent Zundel: See DavicC’s ongoing PR on this.

Brent Zundel: just to note for the minutes, PR 1469 is DavidC’s PR that he’s addressing.

Brent Zundel: See Manu’s ongoing PR on this.

Brent Zundel: and manu’s PR for the rest is 1464.
… and as has been mentioned, please feel free to claim a section and work on it.

2.3. Truth (or falsity) is not part of VCDM ecosystem (issue vc-data-model#1472)

See github issue vc-data-model#1472.

Brent Zundel: Ted, it’s your issue, do you want to walk us through.

Ted Thibodeau Jr.: possibly just deleting that paragraph.
… the problem with “trust” at all is, it’s outside the bounds of what we can really do.
… we’re cryptographically assuring that contents are the statements of the issuer, that’s it.
… there’s nothing about the truth of them, or anything else.
… just “this issuer said these things at this time”.

Ivan Herman: +1 to TallTed.

Ted Thibodeau Jr.: so talking about truth in the context of revocation doesn’t make sense.

Dave Longley: +1 to TallTed.

Manu Sporny: +1 to that, Ted.

Dave Longley: +1 to just remove the paragraph.

Manu Sporny: I think we do have, in some other part of the spec, exactly what you said.

Dmitri Zagidulin: +1 to remove paragraph.

Manu Sporny: I think it is generally presumed that you’re going to listen to the issuer, but of course there are cases where you might not trust em.
… or just a subset of what they’re saying. I reacted strongly to “lets just delete it”, but now that I’m reading it, if we have that language elsewhere,.
… do you want to take this issue?

Ted Thibodeau Jr.: yeah, I’ll take it,.

Joe Andrieu: this is a really good catch, Ted. I agree we don’t have to depend on the trust. might be useful to say something about trusting that the issuer is using the mechanism correctly.

Brent Zundel: sounds like we have a path forward, look forward to the PR.

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

See github issue vc-data-model#1457.

Brent Zundel: we discussed this one a few weeks ago.

Manu Sporny: David Lehn is working on it, just has a long backlog, he’ll get to it.
… suggestion was - we update ReSpec VC, not only show data integrity securing mechanisms, but some of the VC-JOSE/COSE mechanisms.

2.5. consider merging 3.4 and 5.1 as both sections are about the credential lifecycle. (issue vc-data-model#1465)

See github issue vc-data-model#1465.

Manu Sporny: in the respec vc library, would allow you to choose on an example-by-example basis which securing mechanisms you’d want to show.

Brent Zundel: thanks.
… I raised this. I was reading through spec, and noted that two different sections both talk about the credential lifecycle.
… so the split is not great.
… let’s merge them into one section. take 3.4, put it inside of 5.1.
… also remove the concrete example, say - “we have use cases, they’re over there”, like we’ve done in the path.
… would love to hear feedback.

Manu Sporny: strong +1 to that. I’m wondering if we should go a step further, and merge that section into the Use Cases document.

Brent Zundel: proposal on the table is, in as minimal fashion as possible, merge those two sections, and reference the Use Cases doc, like Joe said.

Manu Sporny: +1.

Joe Andrieu: sounds right.

Brent Zundel: ok, I’ll do that.
… Joe, does the Use Cases doc have this lifecycle stuff?

Joe Andrieu: I think it’s there, but we’ll check.

2.6. Add issuee definition (issue vc-data-model#1467)

See github issue vc-data-model#1467.

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

Brent Zundel: ok, we’re at time, thanks everyone.
… before we close, I do want to note issue 1467, I made a chair statement on that, I’m not seeing any new info that justifies the conversation taking further time.
… that said, if in the comments of the issue and the resulting PR, if people can come to consensus on the way forward, I won’t step in the way.
… I’m just not seeing consensus form.

3. Resolutions