Verifiable Credentials Working Group Telco — Minutes

Date: 2024-01-24

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Greg Bernstein, Manu Sporny, Dave Longley, Ted Thibodeau Jr., Nicholas Steele, Paul Dietrich, Kevin Dean, Dmitri Zagidulin, Will Abramson, Kevin Dean GS1, Chris Abernethy, Gabe Cohen, Michael Jones, Wesley Smith, Joe Andrieu, Steve McCown, Benjamin Young

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley

Content:


Brent Zundel: Agenda today is pretty straight forward, will go over vc-jose-cose PRs and then doing issue processing on the core data model.
… We’re in the #vcwg channel as usual, invite people to join us there and that’s where we handle queue management.

Ivan Herman: Can I have a few minutes on current submissions for publication?

Brent Zundel: Yes, thank you.

Ivan Herman: So I had a call yesterday (regular call with PLH), two docs awaiting his approval.
… He did have a question on a github issue last week about the directory becoming a registry or not. Manu responded and he missed Manu’s response and he missed it and apologizes for that.
… He put a minor comment into the issue you may want to look Manu … he said if it’s not a registry that’s fine we just need to make that clear in the status section and once approved can be published next Tuesday I presume.
… For VCDM … there is a TAG F2F meeting with VCDM on the agenda. Hopefully no blocking comments and then the approval will come on Friday.
… I am hopeful we will get everything done for publication on next week Tuesday, the 30th of January.
… One more request for Manu, I am out tomorrow/Friday, please keep an eye on the issue for an approval so you can generate the two documents with the right dates and I’ll take care of it on the weekend for publication on Tuesday.

Manu Sporny: Thanks for all that, Ivan. I will add the language that PLH wants to the vc-specs-dir status section and just preemptively cut two releases so they are ready as I will not be around this weekend.

Ivan Herman: The only possible problem is requiring an editorial change if we’re unlucky. The other possibility is we bite the bullet and head for Feb 1.

Manu Sporny: I’m fine either way. We’ll have to regen anyway.

Ivan Herman: Ok, let’s decide for Feb 1 then and save the effort.

Manu Sporny: Ok, I will do that.

Brent Zundel: Moving forward with the agenda.

1. VC-JOSE-COSE PRs.

Brent Zundel: https://github.com/w3c/vc-jose-cose/pulls.

Gabe Cohen: I don’t know how much time there is for going through these, the first 3 can be closed I think.
… They are about renaming the spec to just focus on SD-JWT and the editors have decided to not go in that direction and include standard JWTs.

Michael Jones: They are already marked pending close so I think we can just close.

Brent Zundel: For the record, this is 212-215 and they have been marked pending close for a while now and the spec is not going in that direction. Any objections?

Michael Jones: For the minutes the WG decided to reinclude JOSE and the editors concur.

Brent Zundel: I’m hearing no objections so we should close those PRs after the meeting.

1.1. Fix example 24 with enveloped credential (pr vc-jose-cose#219)

See github pull request vc-jose-cose#219.

Brent Zundel: Ivan has suggested changes on this one that I believe have been addressed. There’s a suggestion from Kristina about enhancing the description. It looks like a straightforward editorial change.

Gabe Cohen: I do agree with Kristina’s comments that we need an additional example that shows a secured envelope’s presentation and it’s lacking some text. I will do that in this issue and I’ll note that I’ll add this information.

Brent Zundel: Anything else on 219?

1.2. adjust language in example 13 (pr vc-jose-cose#220)

See github pull request vc-jose-cose#220.

Brent Zundel: Adjust language in example 13 – again an editorial change.
… Ted has reviewed and his change requests have been made. I encourage other folks to check out this PR.

Manu Sporny: Just a question – I approved the PR fine as is. There’s this fully specified algorithm stuff that is making it’s way through IETF. How does that spec involve the language here?
… I think this one doesn’t make mention of fully specified algorithms or not … it probably doesn’t need to but do we need any updates around this?

Michael Jones: For the language in example 13?

Manu Sporny: Yeah. The PR also adds some normative text around the alg property. It says the alg property is optional and is recommended to be included.
… It says that crv and kid need to be specified.

Michael Jones: I need to review that then because alg is never optional.

Manu Sporny: This PR says it is. I’ll put your comment into it.

Brent Zundel: Sorry, my understanding is that the normative bits have just been moved around, so it may be more normative than I expected.

Gabe Cohen: Yeah, I was going to say what you said – I think I made a mistake with that first sentence so I will adjust that after Mike gives it a review.

Manu Sporny: I don’t think you made a mistake, it’s confusing or wrong original text that you didn’t add Gabe.

Ted Thibodeau Jr.: I added the all-caps OPTIONAL based on the following text – it needs to be consistent whatever it is.

Michael Jones: JOSE requires alg.

Brent Zundel: Good feedback on that PR, it’s actionable, encourage folks to keep an eye on it as it is reviewed and updated.

1.3. remove some language around proof (pr vc-jose-cose#221)

See github pull request vc-jose-cose#221.

Brent Zundel: Removes some language around proof. This PR does what it says. There is one approval.

Manu Sporny: I think this PR is great, thank you, Gabe.
… This PR would address the issue I raised, thank you, Gabe.

Brent Zundel: This PR looks to be in a good spot.

1.4. update COSE media types (pr vc-jose-cose#223)

See github pull request vc-jose-cose#223.

Brent Zundel: Update COSE media types. It does what it says – in addition to some whitespace changes that make it a little harder to read, it just adjusts the media type.
… Folks should review.
… Please chime in to the PR with feedback.
… Happy to take comments, this one does what it says.

Manu Sporny: This is fine. I think is where we are today. I just wanted to repeat the warning that I believe that in the mediaman WG in IETF, people objected to not registering every structured suffix last time which is why the multiple suffixes draft failed to go to last call last time. I think the way this is written would require us to register…
… +json +cose +[other thing].
… I don’t know how we would justify those registrations, we might be able to point to the vc-jose-cose spec and say we’re registering all these suffixes – and questions will be asked and we need a good response.
… Probably, the vc-jose-cose spec creates all these structured suffixes and that’s why we’re registering them because people wanted all of them registered.

Brent Zundel: Thank you folks for your attention during that topic.

2. VCDM Issue Processing.

Brent Zundel: And for the review, we anticipate some additional PRs on vc-jose-cose as that spec approaches CR. Moving onto the final topic.

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

2.1. Consider removing Use Cases summary from core DM (issue vc-data-model#1169)

See github issue vc-data-model#1169.

Brent Zundel: Consider removing use cases summary from core data model. I raised this issue to suggest that … now that the data model is on a version 2.0 we may not need all the use cases stuff in the core data model spec in addition to the use cases document which also is being refurbished this round.
… The question to the group is: Do folks agree?

Manu Sporny: +1 I think this is ready for PR and we should remove it. One of the strongest arguments for removing it – is we published 1.0 and 1.1 and it was in there.
… We can point back to those. It might be worth putting a link in there to those and another link to the use cases document in the PR you raise, Brent.
… So people can follow their nose to the content.

Brent Zundel: Originally, the question was – do we just get rid of it, do we move it wholesale to the use cases/requirements doc, no takers there – so the plan for the PR is to remove the section and add links and clean up the language.
… If anyone feels the plan should be different, please speak now.
… And I will have to remember I have something on my plate.
… Ok, not hearing any objections.

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

See github issue vc-data-model#1192.

Brent Zundel: This is editorial, it is post CR and also i18n. This is assigned to you, can you give us an update on this issue?
… This looks editorial.

Manu Sporny: I can take this, this came up during their pre-CR review. They want us to say “our examples are in English to make the spec easier to read”.
… They would rather we have i18n everything in the specification, but understand that it’s harder to read examples if we have every single human-readable text string have 15 different translations.

Brent Zundel: Ok, that makes sense. This one is straightforward so if anyone wants to step forward and grab it.

2.3. Document issuer defined vocabulary and use of @vocab (issue vc-data-model#1210)

See github issue vc-data-model#1210.

Brent Zundel: Document issuer-defined vocabulary and use of @vocab.
… This was raised by Manu in response to a comment by Gabe. I believe since this time we have made @vocab normative, what’s the proposal?

Manu Sporny: We made vocab normative and we have this concept of issuer-defined vocabularies and we don’t talk about it in the spec. The resolution would be to raise a PR to make it easier to get started and we might put it in the Getting Started section.
… We could say “by default” if you magic a term out of thin air in a VC it will automatically go into the issuer-defined vocabulary, which means the person that’s creating it needs to do something about that eventually such as creating documentation, talking to your community, or eventually creating a context for it.
… The PR needs to say there’s an issuer-defined vocab concept, it will help you get started, if you create new terms you should write docs so people can find information on your term or ideally, just create a context and a vocabulary file that defines your term formally.
… That’s what the PR should probably say.

Brent Zundel: Thank you, Manu, that sounds straightforward.
… Shout out to the group if anyone else wants to take this on. Generally all these PRs are non-normative and would have a less stressful PR creation experience and I encourage people on the call to jump in.

2.4. Add link to Linked Data Best Practices (issue vc-data-model#1217)

See github issue vc-data-model#1217.

Brent Zundel: This one was opened by Manu in response to a link from Oliver Terbu and says we should link back to best practices.
… For Linked Data best practices.

Ivan Herman: Isn’t it very close to the previous issue?

Brent Zundel: It could possibly be addressed in the same bit of text.

Ivan Herman: I think it’s very much the same thing – what Manu proposed to say is what Linked Data best practices mean.

Manu Sporny: I think they are slightly different, Ivan. It is true that what we’re going to write in this specification is a Linked Data best practice, but I think people were looking for language that was very specific to this spec.
… I don’t know if there’s anywhere we can point to … to say that a default vocab is a best practice, it isn’t one, I’ve said it’s a bad idea but we’ve done it.
… I would hope that we would never in a Linked Data best practice document say use a default vocabulary. I wouldn’t expect us to say that. I know it’s a controversial thing to say we shouldn’t have a default vocab.

Ivan Herman: I turn it a little bit around. If we start by finding a place somewhere what it means if you really add, properly, some vocabulary to a VC of your usage, which means you have to define the terms and put up a JSON-LD context, etc. what you said before, this is the best practices are.
… This is what implementations should do.
… At that point, we can add “as an additional measure @vocab is there, but please do what is described above”.

Brent Zundel: I think exactly the same thing.
… I would be interested to hear if anyone is opposed to us saying “here’s what our spec allows you to do to get started, but best practices, over there is what would be best”.

Manu Sporny: +1 to the approach that ivan and brent are advocating for.

Brent Zundel: I think that would hopefully allow the spec to articulate the concerns that Manu has raised.
… I’m seeing +1’s to Ivan’s recommended course of action.
… Now all we need is someone to put it into place – or does Manu want to handle it in the PR for the last issue.

Manu Sporny: I don’t know for now.

Brent Zundel: Manu is intending to raise a PR that says what we allow you to do with @vocab and this PR would say … well, to do this work would require knowing a link to LD best practices and adding a link to the spec with language that includes that link.
… Whomever gets their PR in first would have to work around the other.
… No one is assigned to this one yet.
… I will see if anyone wants to pick this one up.
… Just a note that issues that do not end up with anyone assigned – will go onto the list of “do we really want to do this, if not why is it open?”.

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

See github issue vc-data-model#1176.

Brent Zundel: Define what a credential validity does mean.
… I’m not sure … this is about validity periods.
… The last conversation happened in July of last year.
… What, if anything, is the action here?

Joe Andrieu: I think this is still tied up in the ambiguity around what should be in verification vs. validation. I don’t know what to do with this issue … that lingering delineation, I don’t remember where the conversation is in github around this but there was some movement and I think I was convinced that other things that should be in verification weren’t.

Manu Sporny: I think Dave Longley had a good proposal somewhere on the Internet. Things can happen during verification that an extract information that can be used in a validation phase.
… There are things that are clearly in verification like checking the proofs.
… Then there are other things that can happen like checking the signature on a status list – but the information in that list – is up to the validation phase to use.
… We can still talk about these things … getting the authentic information during verification and then handing it off for validation seems like it would help.

Brent Zundel: I will note that we have a validation appendix on the data model currently and perhaps an action here would be to update that appendix to reflect what Dave said.
… I haven’t heard anyone say that they disagree with that expression of things.
… Possible action here – but now Joe is assigned.

Joe Andrieu: I will try and do this – and reach out to you, Dave, for the language you proposed.

2.6. [Terminology] claim (issue vc-data-model#995)

See github issue vc-data-model#995.

Brent Zundel: Current definition of claim.
… There was a decently long conversation last year. It was ultimately assigned to Mike Jones.
… I don’t believe … I’m not sure what to do here. I’m not sure if there is appetite with mucking about with our current definition of claim.
… This was on our list of “if we have time and still care then then we can think about doing something”.

Manu Sporny: I don’t know if we care at this point. We had a very long discussion and debate in the PR.

Ted Thibodeau Jr.: JoeAndrieu – as I recall, the key bit relevant to 1176 is that Verification is crypto/technological which we can specify, while Validation is business logic which we cannot specify.

Manu Sporny: I believe Joe raised another PR that modified other things that did get in. This also had to do with adding more roles to the ecosystem like author and party – and the PR just kept growing and changing core roles we didn’t feel comfortable with. Personally, I think the spec is fine as-is.
… I don’t think we need to modify it at this point.

Brent Zundel: Currently our terminology says: “claim: an assertion made about a subject”.

Michael Jones: It being assigned to me and having written the definition of in the JWT spec – I will look into a change to match the understanding in the community or I will close it.

Ivan Herman: More formally, the issue was closed on June 27 – and then it was reopened by you referring to a PR … and then there was a discussion on the 15th of August which says “Fine to just to close it, waiting a week is probably polite.”.
… That was Mike’s last comment, I have the impression that this has already been discussed and decided to be closed and fell between the cracks.

Brent Zundel: We were waiting on closing PR 1172 so the conversation could continue in this issue.
… If folks just want to close this … I think right now Mike is going to look at this now vs. JOSE’s and maybe recommend closing the issue.

Dave Longley: A claim is importantly a triple in the VCDM, not just a property+value – which might not be exactly like other specs.

Ted Thibodeau Jr.: We resolved to close 1172 because we didn’t find consensus there.
… Which also says to just close the issue because we didn’t find consensus.

Michael Jones: I should look at it because the claim definition is different than JWT. If I don’t get to it, if I don’t get to it in a couple of weeks I won’t stand in the way.

Brent Zundel: If this one rolls around in the queue again we will close it.

2.7. Recommend that DIDs are used with VCs (issue vc-data-model#1243)

See github issue vc-data-model#1243.

Brent Zundel: This was raised by and assigned to Gabe.
… About recommending using DIDs. There was some pushback on both sides here.

Ivan Herman: The comment from Orie on August 16, in view of the formal objections to DID we should not do that – but those formal objections are behind us, so that is moot now.

Gabe Cohen: I think this can and should be closed with the controller document spec up and coming. I’m happy to open a similar issue there to have some language around the usage of DIDs in the controller document.

Manu Sporny: Not necessarily opposed – I think that might also fail because the controller document is supposed to be agnostic to DIDs as well. It might be useful saying that the vast majority of deployments use DIDs.
… We designed VCs to be compatible with DIDs.
… I don’t know of many deployments that aren’t using DIDs at all in their roll outs.

Brent Zundel: Would you be opposed to marking it pending close?

Manu Sporny: No.

Brent Zundel: I will mark it pending close.

2.8. 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 HTTPS credentials v1 is in the past.
… Something about caching … I don’t know what this means exactly.

Manu Sporny: I think this person is saying that the HTTP headers for the credentials/v1 context are wrong. Because of the way it’s set, it always expires which forces implementations to always go to the Web.
… They can’t cache – and they shouldn’t be going out to the Web at all for that context or the v2 one – but we should make it do the right thing.

Brent Zundel: Assigned to Ivan.

Ivan Herman: I was assigned because all this is happening via http access files which only I can change. But I have no idea what to change it to, so I need input.

Brent Zundel: If folks have clear and concise inputs?

Manu Sporny: Cache time should be set to three months.

Ivan Herman: How do I do that in htaccess?

Manu Sporny: Ping me and we’ll figure it out together.

Ivan Herman: Ok.

Brent Zundel: And we are done with the call today.
… The editors and chair and team contact have explored the possibility of a F2F meeting this spring and we’re not feeling it necessary, but if you feel differently, please contact us.
… There will be other VC-related conversations at other conferences as well. Thanks for scribing, Dave!

Dave Longley: welcome!