Verifiable Credentials Working Group Telco — Minutes
Date: 2024-08-07
See also the Agenda and the IRC Log
Attendees
Present: Ivan Herman, Ted Thibodeau Jr., Brent Zundel, Gabe Cohen, David Chadwick, Benjamin Young, Hiroyuki Sano, Michael Jones, Manu Sporny, Kevin Dean, Will Abramson, Joe Andrieu, Dave Longley, Jennie Meier
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Dave Longley, Manu Sporny
Content:
Brent Zundel: Welcome to the VC telecon. Our agenda today is talking a bit more about wrapping up the VCDM. Then we’ll talk about media types for VC jose-cose and then finish up a meeting talking about the controller document because that’s the next one we have that we need to try to transition, ideally, by the end of the month.
… Any changes or additions to the agenda?
1. VCDM Wrap Up.
1.1. Added the new vocabulary file for undefined terms (pr vc-data-model#1536)
See github pull request vc-data-model#1536.
Brent Zundel: We have a PR we should look at.
… There are a number of requests for changes here, Ivan can you give us a summary of what the PR does?
… I encourage folks who would like changes to also jump in.
Ivan Herman: Just to say what you said here a little differently. There were a number of comments, so they have all been incorporated, so as far as I know, no more open comments.
… What it does is – following up on the PR(s) which changed the place for the @vocab
term and now there is a separate undefined term that has to be done properly and this PR handles that.
… There is one part of the PR that isn’t in there which is for htaccess file changes I have to do externally.
… This will handle redirections, etc. it’s not on github, won’t be subject to PR, but I put a verbatim copy of the .htaccess file.
… There were some small comments incorporated on that as well, as far as I am concerned this can be merged and then I will change the .htaccess file after that.
Brent Zundel: Thanks for that summary, Ivan.
… To add a little bit more context, I believe three weeks ago this group came to consensus on and merged two PRs to make changes to add the undefined terms context and remove the @vocab
from the core context.
… This PR just does administrative work to finish up those things that were done nearly a month ago.
Ivan Herman: That is correct.
Brent Zundel: Ted and Mike Jones, your reviews are still showing requests for changes, Ted your changes have been merged, Mike if you’d like to jump on the queue you can do so.
Michael Jones: Alright, I still think it’s a mistake but I think the ship has sailed and I’ll approve it.
Brent Zundel: Thank you Mike, I appreciate that.
… Ok, if there are no more comments on this PR, then we can look briefly at our set of issues.
Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc.
Brent Zundel: There are two remaining issues on the VCDM.
… I think the first issue will be addressed by the PR we just looked at.
1.2. Respec’s VC plugin still does not work (issue vc-data-model#1538)
See github issue vc-data-model#1538.
Brent Zundel: I think the final issue here is 1538.
… This is about respec plugin not working.
Manu Sporny: It’s just a bug that needs to be fixed. We are going to fix it because the spec is bad without it.
… This has to do with all the autogeneration of the code examples, and echnida is not waiting for the auto-generation to finish, we need to just figure out how to stop it from doing that and wait for the examples to generate.
… Just some code to be written.
Ivan Herman: If this is solved, I will have to fix the overview document too – if you see a commit over there it’s for the same reason to get the respec plugin working over there too. No change on content.
Brent Zundel: Thanks, Ivan.
… Benjamin, do you have an estimate … when can we get an estimate for getting an estimate for fixing it?
Benjamin Young: I think we have already merged in changes to disable the async generation – I can give you another estimation after we check on that.
1.3. editorial pass.
Brent Zundel: I know that Manu, wearing his editor hat is doing a full sweep of the spec, I encourage others to do so as well.
Manu Sporny: I am about 30% of the way through the data model spec – I expect to have to do a little more clean up in the advanced concepts area because we made more changes there.
… A lot of the spec is considerations.
… It would be awesome if someone would step forward if someone would step forward to do the editorial pass on privacy and security considerations. Ted, I don’t know if you any spare cycles, that would speed things along, I understand if people don’t have cycles.
… If someone could take security considerations on in parallel – that would help. It’s going pretty quickly, but once I’m done with this pass, it’s ready to go into CR2.
… Arguably it could be ready to go to PR if those go smoothly.
… We’re still trying to get implementers to implement enveloped presentations and credentials, I don’t think we have any implementers there yet, and that would be a reason not to go into CR2 until we have implementers for those features. Now’s the time for people that really wanted it to step forward and do it.
… Those are not marked as at-risk, because we were fairly certain people would implement, but I think it’s just that people haven’t known to implement yet, that’s the long pole.
Brent Zundel: Thanks, Manu.
Ivan Herman: Minor things related to this editorial thing, do I understand well that the termsOfUse
is a full-blown property now? Not just reserved?
Manu Sporny: Correct, there’s an error in the spec, I have to fix that.
Ivan Herman: It has to be removed from the vocabulary as reserved as well.
Manu Sporny: Can you do that, Ivan?
Ivan Herman: Can I do it now?
Manu Sporny: Yes.
Ivan Herman: I know that this came up some time ago….
… I haven’t followed all the details the discussion on vc-jose-cose, I would like someone to look at the diagrams to make sure the right media types and whatnot are set in the diagrams. I want a check on that again.
… So someone can tell me what has to be changed.
Michael Jones: I don’t understand the question, the media types are in the spec.
Ivan Herman: There are diagrams in the VCDM that provide oversight of vc-jose-cose and there are some JSON web terms things there and I want to make sure they are correct.
Michael Jones: This may pertain the subsequent discussion, but this isn’t about text in vc-jose-cose?
Ivan Herman: No, this is in the diagrams in VCDM.
Gabe Cohen: I’ll review those diagrams. I wanted to respond to enveloped VPs and VCs.
… I’ll be implementing over the next week, so I’ll be an implementer.
Brent Zundel: Chair hat off, as a representative of a company that is also implementing JOSE-signed VCs using the enveloped format, our hold up has been the lack of test suite, but the implementations are there and I know of at least two companies that could supply implementation evidence if they so desire.
… I am not concerned about that feature being at-risk.
2. VC JOSE COSE Media Types.
See github pull request vc-jose-cose#283.
Brent Zundel: Next topic is vc-jose-cose media types.
… In our group there was media type confusion … we had media types that we wanted and we tried to get them registered for quite a long time – or get the group into a state where we could get them registered.
… The IETF registrations dragged on for years, but what it came down to was that we could not register the media types that we wished to, but due to some quirks of our process, consensus fell in different places in different specs in different ways.
… The way consensus worked out was that our core spec uses application/vc
and application/vp
.
… The vc-jose-cose spec were different.
… The mismatch in media types between the two specification might be bad.
… I have learned since then, that it’s actually not that big of a deal.
… I talked to a bunch of folks at IETF and learned a lot more about how they are interpreted – the way the media types are used and how they are seen and interpreted, plus signs don’t mean what we thought they meant which is related to why our multiple plus signs didn’t go through.
… As the person that raised the issue about making the media types align – I’m now saying it doesn’t matter, it might not be awesome, but it doesn’t matter.
… However, another thing I learned at IETF last month, the inconsistency across media types handling things at different levels in different specs, isn’t a big deal, but in the same spec could lead to confusion.
… So the conversation right now with doing application/vc+jwt
but then application/vc-ld+sd-jwt
would be bad.
… Why does this matter? There’s a specification at IETF called SD-JWT-VC and they have been using the media type application/vc+sd-jwt
in production over there. We could talk about the appropriateness of them doing that if we want, but I think them using a media type that wasn’t in conflict with our group’s media types at the time doesn’t really matter.
… There are a lot of cans of worms we could open here – that is where the conflict lies. If we were to go forward and assert that we should have application/vc-sd+jwt
to mean something else, out from underneath that group that was using it for something else, that would be the kind of move I wouldn’t be proud to make.
… I’m going to go to the queue we can talk about this for about 15 minutes.
Manu Sporny: Thanks for that summary, Brent, I agree with most of it, except potentially the last bit.
… My interpretation of the way this unfolded between people that knew we were working on things in this WG is different.
… You said that there are production deployments using vc+sd-jwt
– I’d like to know what those are.
… We need to understand at what level it’s deployed in production because the core issue here is that we are going to put the entire ecosystem into a situation where all of the application/vc
media types except for one is going to use the W3C VC data model.
… Just one of them is going to specifically not use that.
… Anyone looking at this without this deep understanding of the text strings not meaning anything – which is new – which is where we could get to consensus, but even that isn’t quite right, having been the one that has had to tease apart the plus signs and their meaning. But that one plus sign still means something.
… What it means is that there is a base subtype – and I know there’s a difference of opinion at IETF – and the expectation that most developers have is that you’re using something remotely the same.
… Most of those media types that use the W3C VC data model, you will be surprised when just one doesn’t.
… I agree there’s a consistency problem here, where vc-jose-cose isn’t going to be consistent. And, it’s going to create confusion in a way that is at IETF that doesn’t use the W3C data model, there will be confusion there as well.
… People are using this non-W3C VC data model – they will be very surprised that it’s not W3C VC.
… We can pick a different media type – the people in that process at IETF are also involved in this group. We cannot say they didn’t see it coming. We told them it would create a problem, and they did it anyway.
… I also Brent for us to say that if we prevent the registration of that media type … that it’s something we should not be proud of doing. I think there are a number of anti-social things that have happened during this process and that is not on this group.
… I think we can take the higher road maybe with someone threading the needle with different data models sharing the base part of the media type, but it’s highly problematic.
… I think the way that some groups have been operating and it’s created a problem now. We should potentially have that group come in here and talk about what the best path forward is. I don’t think we should confuse developers with media types that look like the same thing but they are different.
Michael Jones: On the editors call I was asked to prepare some remarks.
… I will paste into the minutes to save the scribe.
Michael Jones: Level set.
Michael Jones: The VCDM media types are application/{vc,vp}.
Michael Jones: I am not going to cover the politics, just the engineering.
… The VC-JOSE-COSE media types are application/{vc-ld,vp-ld}+{jwt,sd-jwt,cose}.
… The VCDM and VC-JOSE-COSE media types are used in different places.
… The VCDM types are used in the “cty” (content type) header parameter to describe the type of the payload.
… The VC-JOSE-COSE media types are used in the “typ” (type) header parameter to describe the type of the entire secured object.
… They are not in the same logical or semantic namespace.
… The VC-JOSE-COSE media types do not reference the VCDM media types in their definitions.
… Rather, they reference the data types defined by the VCDM.
… There is no syntactic relationship between the VCDM and VC-JOSE-COSE media types.
… There is no concept of “Base Media Type”.
… There is a concept of Structured Suffix, which is different.
… As David Waite commented, there is no concept of a base media type; application/foo, application/foo+bar and application/foo+baz are entirely different concepts. In particular, you don’t extract application/foo as a commonality between the three on a programmatic level and do something with it.
… Therefore, while it would be nice for the name components across the specs to be similar (which they already are), they needn’t be identical.
… Practicalities:.
… We’re not going to get consensus to merge https://github.com/w3c/vc-jose-cose/pull/283.
… We’re not going to get consensus to change application/{vc,vp} to application/{vc-ld,vp-ld}.
… We’re not going to get consensus to make the VC-JOSE-COSE media types inconsistent with one another.
… We could keep beating our head against this or solve it now.
… Recommendations:.
… 1. Close https://github.com/w3c/vc-jose-cose/pull/283.
… 2. Request registration of the VC-JOSE-COSE media types with IANA.
Gabe Cohen: Thanks, Mike for laying that out. I think I reached the same conclusion through different reasoning. The editors of vc-jose-cose have tried to talk to the sd-jwt-vc group but haven’t been able to find common ground.
… I don’t think it’s worth this group’s time to invite them here because I don’t think things will change.
… I don’t see a better path, I think we should keep the -ld
types, I think that’s the best we can get.
Dave Longley: I can make comments about how I think that other group is going to continue to have problems because they’re using VC terminology and there is already a stake in the group what VCs mean and that other group is going to continue to confuse people related to prohibiting the use of VCs… but we don’t have control over that group or if we can’t convince them to do something different.
… For the concept of enveloped VCs, maybe we can solve them in a way to do enveloped-vc? Maybe because of the way we express media types and information, maybe we don’t need to have additional media types for this case. Those are two other options we can put on the table.
Manu Sporny: https://datatracker.ietf.org/doc/html/rfc6838#section-3.
Manu Sporny: I’m taking issue with some of the assertions that are being said. Subtype names do mean things. This section does says that subtype names can be registered to accommodate the … [missed see link].
… This was revisited during the subtype discussions and many people stepped up to the mic to say that the subtype matters and it should match.
… The discussions in that WG have said that they do matter. Item two – huge strong -1 to vc-ld as the core mechanism.
… The problem here is anti-social behavior in another group that has been requested multiple times – asking them to not do what they are doing. This has been happening for 18 months.
… They have been asked multiple times, that group continues to not do it, there have been technical, process, social arguments and that group continues to not do that. I think there is a problem with us making invalid technical arguments, I think that someone rushed forward and used the media type in production and then tell others it can’t be changed – don’t do that, people who work on standards don’t do that.
… I think we need to make decisions based on technical rational decisions based on what’s in the specs, if we don’t do that, it’s a problem – we can’t go against what’s said in the RFCs and specs. All that said. I think maybe Dave’s enveloping thing might work.
… Or we can just do with application/sd-jwt
and say you don’t need the media type on there. But huge -1 to just going forward with what’s in the spec right now.
… We need to do something better.
Brent Zundel: Dave has made a suggestion – Manu says he could live with it, if we changed the media types to application/enveloped-vc+whatever
– could you live with that?
… From my perspective as chair, that’s the closest thing we have for consensus.
Michael Jones: Responding to Dave Longley’s suggestion that we don’t need VC-JOSE-COSE media types, Explicit Typing of JWTs, etc. is a best practice defined at https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing.
Michael Jones: One is long – responding to Dave Longley’s suggestion that we don’t need vc-jose-cose media types, it’s a best practice to do it.
… Following best practices we don’t have an option to not do that.
… The whole enveloped thing is superclunky – and never in plain human language describe things that way, just in the spec. It’s an explicit goal for JWTs to be compact and that goes against that engineering design principle.
Ted Thibodeau Jr.: “best practice” is not a standard in the sense of SDO. it’s a practice and can be changed.
Brent Zundel: What about env-vc+jwt
?
David Chadwick: +1 brent.
Michael Jones: We don’t talk verbally about “Enveloped Verifiable Credentials”. So we shouldn’t put that in the names.
Dave Longley: I think env-vc+jwt would be ok.
… Saying vc-ld is redundant.
Michael Jones: No, it’s not, there are other formats for VCs.
Dave Longley: No, VC is JSON-LD, that’s what this group created and established.
… I’m ok with env-vc+jwt
, I don’t think a few extra characters matter since the JWT enveloped VCs are already quite large because they base64-encode everything anyway.
Manu Sporny: The attacker generally controls the media type – and there’s a part of that that can be signed over though. But if we’re talking about the media type inside, then that is an application/vc
or an application/enveloped-vc
– it’s not actually a JWT that is inside, isn’t that correct? I’m ok with env-vc
thing.
… I forgot about version 1.1 that does have VC-JWTs, and we use a media type there. That is also something in production in a big way that we may need to pay attention to. I don’t think we need to pay attention to it so much that we establish it as the only way things can be done before the media types were decided and they will have to live with changing it to whatever we say here.
… But that’s another consideration – and we might want to think about that.
Brent Zundel: Can we live with env-vc
env-vp
for JOSE/COSE?
Joe Andrieu: +1 for living with env-vc and env-vp.
Michael Jones: The VC-JOSE-COSE media types are used in the “typ” (type) header parameter to describe the type of the entire secured object. This is in the cryptographically secured JWT Header Parameter. It is not subject to control of the attacker.
Brent Zundel: I believe everyone has nodded to live with it except Mike.
Benjamin Young: +1 to evn-vc and env-vp.
Michael Jones: No, I think it’s not verbally how we talk about it.
… The vc-jose-cose types are used in the header parameter to define the entire cryptographic object, it’s not subject to control of the attacker.
Brent Zundel: I suppose we will try again next week, thanks for scribing, Dave, the meeting is done.