Verifiable Credentials Working Group Telco — Minutes

Date: 2024-02-28

Attendees

Present: Ivan Herman, Paul Dietrich, Brent Zundel, Dave Longley, David Chadwick, David Lehn, Will Abramson, Ted Thibodeau Jr., Manu Sporny, Joe Andrieu, Benjamin Young, Jennie Meier

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley

Brent Zundel: We will look at work items, get status updates, highlight PRs that the editors want more review on, then jump into processing the VCDM issues.
… Anyone who would like to suggest changes or additions to the agenda?

Manu Sporny: Apologies – a bit out of the blue. In the RCH WG, we just resolved to take that spec to PR. Part of that discussion was around what a maintenance WG would do around security specs. It may be a bit premature here, but we can mention what that group did and then think along those lines.
… So five minutes to explain what happened, that would be useful.

Brent Zundel: Ok.

1. maintenance?

Manu Sporny: Ivan, please correct me if I get this wrong. We said we were going to attempt to transition RDF-CANON to PR, we’ve kept the door open for a while and have plenty of implementations and feedback.
… One of the things mentioned was around what to do about possible future security issues. The proposal was to say that the spec allows “class 4” changes.
… Those changes could be applied during the maintenance period to address security vulnerabilities.
… If we do that here as well, which I think is a good idea, then a maintenance WG can be responsive to fix any found security vulnerabilities.
… The alternative is to not do that and then you can’t update the spec even in the face of security vulnerabilities.
… As we transition these specs into PR… – this group will propose a maintenance group charter and we should say that that group can and will fix any security vulnerabilities that come up.
… Hopefully that was a useful summary.

Brent Zundel: Any comments?
… Thank you for that.

2. Work Item Status Updates/PRs.

Manu Sporny: Updates on VC DI specs. I’m putting some focus on that to give the other editors and I … we’re trying to reduce all the issues down to zero. There are a mix of editorial and normative changes to be made, working towards a second CR. The major change was integrating Jeffrey Yaskin’s interfaces into the DI specs.
… It didn’t change implementations, just how things interrelated.
… We’re behind on the BitstringStatusList stuff, some internationalization things to address there.
… There are some PRs there to look at.
… The W3C TAG has also completed their review of VCDM 2.0, the status list spec, and one other one … and the general feedback was that the VCDM 2.0 was that they wouldn’t take a position on polyglot, no consensus on that concept.
… There was a DI spec they mentioned, they said they were not taking a position on whether unlinkable signatures should be mandatory or not, but they’d like to hear more from PING.
… For BitstringStatusList, they raised some concerns and so did PING and we asked for them to raise issues on our tracker for things they really want addressed. Many issues we knww about and we just explained how we got to where we are.
… Some of the feedback was saying that it would be great to have even more privacy preserving mechanisms – and that would be great, but we need to be rechartered to take that on and on top of that there are some concerns around NIST, EDSI accepting those sorts of things.
… That’s an update on DI and status list – there are PRs to be updated and merged, take a look.
… Many of the things left aren’t very controversial, we just need to put our heads down and get them done.

Brent Zundel: I don’t see Gabe or Mike Jones here – I can report on VC-JOSE-COSE, they are down to seven issues triaged before CR.
… They are on a good track to get those done on a reasonable time frame.
… The group decision to reintroduce JWS has been accomplished and that PR was merged. The remaining issues are pretty straightforward, there are some that are a little trickier but overall things are proceeding well with it.

David Chadwick: A lot of the issues I raised and a PR raised as well … but when the solutions were raised I didn’t get a chance to comment on them.

Brent Zundel: The review window was at least a week and the PRs were discussed in this call, folks were given an opportunity to review, I haven’t seen any procedural violations.

David Chadwick: I would just think as a matter of politeness folks would be asked to review on the PRs.

Brent Zundel: Let the minutes show that the vc-jose-cose editors ping folks when they raise PRs to address their issues to come review those PRs.

David Chadwick: Yes, I think that’s good. I know Manu was always asking me to review even if I didn’t ask for changes / make issues.

Ivan Herman: I was asked last week to reach out to the activity streams people on mediaType to try and reuse what they have.
… I don’t want to get into the details, it’s not that exciting, the bottomline is that they don’t have a process to change anything normative and the changes we wanted were normative. So we can’t take that avenue.
… In some sense, was that the original issue wasn’t really of interest anymore and the person who raised it, Benjamin Goehring, said we can close that issue because it isn’t relevant anymore.
… I recommend we close the issue.

Manu Sporny: I want to agree with Ivan. I think we should probably do that. I have some trepidation where we haven’t addressed the root cause or given them a way to use VCs and AS together. I’m concerned about leaving that there.
… I think they will be incompatible with each other, you can’t put a VC in an AS thing.
… They said that you could if you used the “as:” prefix to differentiate. I don’t know if that would actually survive expansion and recompaction.
… We should maybe provide some guidance somewhere on that.
… The other decision we need to make internally here – is that you’re saying we should switch to encodingFormat?

Ivan Herman: That was ruled out by the WG.

Manu Sporny: That was because we were trying to work with AS.

Ivan Herman: See AS Issue.

Ivan Herman: See Our relevant issue.

Manu Sporny: Evan, in AS, was annoyed that we would create something to conflict with AS – the good reason is that it’s important when you digitally sign things you know what you’re signing – and the software is doing the right thing to point out mediaType is being used in two different ways.
… We need to provide some kind of guidance here – the idea that we’re purposefully creating conflicts isn’t right/will be repeated.

Ivan Herman: In any case, we do have a general problem, which isn’t necessarily AS-related, but that requires a longer/more difficult discussion in the future. The fact that the context file for VC uses @protected feature, it has very good reasons, I don’t deny that, but that’s the source of the problem. That’s why they can’t directly put an AS into a VC without any change.
… Whether the usage of @protected or not or whether other features could be used instead, I’m not really an expert in using these.
… That might be a discussion for a future version, I don’t want to get into this right now.

Dave Longley: bottom line from me is that we (and they) want to use the same JSON keys with different meanings and that creates issues.

3. VCDM Issue Processing.

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

3.1. Explain that natural language examples are illustrative (issue vc-data-model#1192)

See github issue vc-data-model#1192.

Manu Sporny: I will do this – anything that’s assigned to me, I have 9 issues assigned to me, as a ready for PR issue, I will do all of those.
… Feel free to check in on each one, but my answer will be “I will raise a PR for this”.

Brent Zundel: So the main question will be – do you need any group discussion or decision from the group?

Manu Sporny: Nothing needed here.

3.2. Define what a credential validity does mean (issue vc-data-model#1176)

See github issue vc-data-model#1176.

Joe Andrieu: If anyone has feedback I’m happy to hear it but I’ll get to this I have what I think I need.

3.3. `expires` header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: Expires header for HTTP is in the past…

Ivan Herman: I looked at that. And I made a relatively longer comment on Jan 25.

Brent Zundel: See ivan’s comment.

Ivan Herman: Essentially what happens is that, if we solve it now to change the .htaccess the way it should be, it would put the same expires settings to our context files as well. Simply because, the way I found it, you can’t put these access things on an individual file, just different types.
… I can’t put it on a single file.
… This change can be done, but my proposal is to not do it now during development but we should flag to do it when we go to PR or REC when freezing the content isn’t a problem anymore.

Brent Zundel: So we can label this as before PR.

Ivan Herman: Or before REC even.
… There will be a point, actually, and we’ll have to come back to this, where some of the files, which are currently on github should be moved to W3C space to be secure by all the backup features, etc.
… That has to be done at some point in the future, that’s also related, so for the time being we should not touch all this in my view.

Brent Zundel: Proposal is not to do anything, sounds like Ivan has a good view for the path forward.
… Any comments?

3.4. Specify what kind of processing is safe on a returned document (issue vc-data-model#1388)

See github issue vc-data-model#1388.

Brent Zundel: Specify what kind of processing is safe on a returned document.
… Do you need feedback?

Manu Sporny: I do.
… On Jan 3rd, Jeffrey gave us some options to make him happy.

Manu Sporny: Jeffrey noted these things as options to mitigate his concerns: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1876019676.

Manu Sporny: I think if we do the first thing – that he listed. His three options as alternatives, the first option is to basically say: “If a verifier doesn’t understand a claim, they can ignore it”.
… The second one is, “Create a new section in the spec that provides instructions for people creating vocabularies and credential types where they say what processing is safe/not safe.”.
… I think that’s a significant amount of work to figure out what to say there.
… The third one is, really a question about an authorization and a claim … we speak to that in the implementation guide already, I think.
… I think we should do the first thing and say that a verifier can ignore … I don’t think we can make a normative statement because it’s business rules, but “it’s expected that a verifier will ignore claims that it does not understand”.
… It’s also expected that a credential type would say what’s mandatory and what’s optional.
… I’m looking for anyone objecting to those kinds of statements at this point.

Joe Andrieu: My first question … of those two statements – are they in IRC or in the issue?

Manu Sporny: They are just in my head unfortunately.

Joe Andrieu: I had a hard time following – I don’t understand the framing of “safety” and it concerns me. Because processing JSON isn’t unsafe.
… I think it’s a weird semantic.

Manu Sporny: +1 to avoid that word. Jeffrey’s concern was that it may be possible to construct something in JSON-LD that is then read by a credential-type-specific process that makes it misconstrue some of the statements.
… It presumes there is zero JSON schema checking and so on – that all the production scale deployments I know of are checking their inputs for a certain structure.
… He’s saying that if you don’t tell people about that, then it’s not safe. But that falls into the category of “If you don’t check your program inputs, that’s bad”, just like SQL injection attacks, etc.
… +1 to not talk about safe/unsafe but talk about expectations when inputs are provided.

Joe Andrieu: That all sounds great I’ll look for your language.
… My frustration is that I don’t think I’ve ever seen this type of thing from any other Web standard. I don’t recall being told what I can do with an HTTP response. Any data I get could be an attack, I think this is just weird framing.

3.5. Multiple Credential Status Lists (issue vc-data-model#1291)

See github issue vc-data-model#1291.

Brent Zundel: Do you need feedback on this one, Manu?

Manu Sporny: I think this example should be in the status list spec, so let’s transfer that over there.
… So I think we already have a multi-purpose list over there so we might be able to close this.
… The only problem is that it’s not clear what implementers prefer to do over there.
… Short answer is to transfer for status list.

Brent Zundel: So the suggestion for 1291 is to move the issue to bitstring status list and address it there.
… The question that comes to my mind is – is that sufficient?
… Theoretically, bitstring status list will be one of many that might go into the credentialStatus property all at the same time.
… Is there sufficient language around the core data model for this – or does the core DM need some language?

Manu Sporny: That’s an excellent point, I take back my proposal. Maybe what we should do here instead is provide an example of multiple status lists and just use BSL as the two entries.
… Proposal is to add an example under credentialStatus with one that has revocation and another that has suspension.

Brent Zundel: And a line that says check the status list specs to see how to handle things. It’s possible for multiple statuses to exist and be contradictory and what you do with them is up to you.

Manu Sporny: Sounds good.

3.6. Tell a bit more about `verificationMethod` type schema (issue vc-data-model#1274)

See github issue vc-data-model#1274.

Brent Zundel: Tell a little bit more about verification method type schema. Do you need feedback, Manu?

Manu Sporny: The path forward here is to delete the note and I’ll do that.

Brent Zundel: Yes, agree.

3.7. Does the specification need a normative “Credential Type Specifications” section? (issue vc-data-model#1410)

See github issue vc-data-model#1410.

Brent Zundel: Do you need feedback on this one, Manu?

Manu Sporny: The proposal here is “no”, we should not add a normative credential types spec, it would be extra work, it’s not clear what we would put in it; unless people feel strongly about this, my proposal is to mark pending close and say we won’t be adding it.
… Saying we won’t add that section this time around.

Brent Zundel: Anyone disagree and think we should get normative in the credential types specification?
… No objections.
… Especially since we’ll have another PR that adds some clarity here.

3.8. address normative statements in non-normative sections (issue vc-data-model#1299)

See github issue vc-data-model#1299.

Brent Zundel: Address normative statements in non-normative sections.
… We talked about this three weeks ago. I should have marked it pending close last time, sorry folks.
… A PR addressed this, that happened, this has been addressed.

Manu Sporny: +1 to close because it’s been addressed.

Brent Zundel: I will close this after the meeting today.

3.9. Remove the at risk issue marker for `Evidence` (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Brent Zundel: Remove the at-risk marker for evidence.
… This is on our list of before-PR actions to take, Manu do you need anything?

Manu Sporny: I added another issue to track this. Can we close this one?
… We’re tracking it elsewhere.

Brent Zundel: I believe the other one covers this.
… Proposal is to close this one because an umbrella issue is tracking this one.

Manu Sporny: +1 to close because it’s being tracked in 1437.

Brent Zundel: Anyone opposed?

David Chadwick: I’m not opposed to closing at all. We ought to make a note somewhere that if any of these have had the at-risk marker removed then they fail the conformance testing, then they need a W3C-CCG spec written for them?

Manu Sporny: No, they need a spec somewhere for them. Where we see two different implementations being able to handle the markup for it.
… I think the resolution a couple of weeks ago – and we did minute it…
… Was that spec has to exist, multiple implementations must exist, but the only thing this WG needs is an example that uses the markup from that other spec.
… And request that the issuers issue a VC with that stuff – and if they can do that, (multiple issuers), e.g., multiple issuers with evidence do it, then we’re good, the feature stays in the spec.

David Chadwick: If they don’t pass that threshold, my understanding is that a CCG spec should exist.

Manu Sporny: It’s any spec.

David Chadwick: We may need to change the wording, the description, I’ll go look again.

Ivan Herman: I may ask the same question as David just differently.
… These properties in the vocabulary, they may refer to a CCG document for their normative description; as long as they are an extension point and not really part of the vocab and that’s ok. If we remove that marker and they become bona fide properties…
… Then we have to have normative text in the VC spec to refer to.
… Just making sure this will happen.

Manu Sporny: My understanding is that the extension specification, the only thing that is required for the extension point, is that we have a test in the VCDM 2.0 test suite. So looking at “evidence”, we have a test in the VCDM 2.0 test suite, it has an evidence field that is populated using an external spec.
… It has another context for that evidence extension.
… And there will be a type that’s used in the evidence field that uses that extension property.
… We don’t have to do anything else. I think that’s the agreement that the group came to.
… We have to demonstrate a spec is out there, multiple people using it, we test that with a test here in the VC 2.0 test suite.

Ivan Herman: I am looking at the vocab spec. The evidence refers back to the data model, so we’re fine there. The same with refreshService, but renderMethod refers to a CCG document.
… That’s what I’m worried about.
… All the others refer back to the VCDM spec as the source for the property specification, I’m worried just about renderMethod.

Manu Sporny: I don’t think renderMethod and confidenceMethod will make it into the main spec, but they will be reserved.

Ivan Herman: Ok, just wanted to make sure.

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

See github issue vc-data-model#1348.

Brent Zundel: Manu, do you need anything on this one?

Manu Sporny: This one scares me … it’s not one issue, it’s like 30 things that Jeffrey would like to have changed but they are all in theory editorial. This one will take the longer amount of time.
… I’m afraid a single normative thing will come up. We have time, but I need to prioritize.

Brent Zundel: It’s good that we’ve wrapped around on the issue discussion. Hopefully we’ll positively increase the pressure to get these done.
… Thank you Dave for scribing.

Dave Longley: welcome!