Verifiable Credentials Working Group Telco — Minutes

Date: 2024-01-31

See also the Agenda and the IRC Log

Attendees

Present: David Chadwick, Phillip Long, Ted Thibodeau Jr., Brent Zundel, David Lehn, Joe Andrieu, Will Abramson, Manu Sporny, Dave Longley

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley

Content:

Brent Zundel: Agenda today is straightforward, will look at PRs on core data model and highlight PRs for other work items and jump into data model issue processing.
… Any other suggestions?

Manu Sporny: Quick announcement about BBS signatures stuff.

Brent Zundel: Ok.

David Chadwick: Can we see how jose-cose is progressing as well?

Brent Zundel: Yes, we plan on covering that but we don’t have either vc-jose-cose editors here yet, but we can look.

1. Work Item Status Updates/PRs.

Dave Longley: present+.

1.1. BBS advances.

Brent Zundel: Will you talk to us about BBS, Manu?

Manu Sporny: Yes, one work item is to produce an unlinkable signature spec using BBS. Greg Bernstein has been pushing that forward at DIF, IETF, and here.
… Some of the rest of us in the group have been supporting.
… We, Digital Bazaar, just last week launched a breakthrough, the first time we’ve done combined digital signatures with both NIST-crypto and BBS together.

Manu Sporny: Breakthrough: Parallel Signatures - NIST, ECDSA-SD, and BBS: https://lists.w3.org/Archives/Public/public-credentials/2024Jan/0054.html.

Manu Sporny: We took all the specs this group is working on in this WG and applied all of them to a single VC such that the single verifiable credential was secured using data integrity and every cryptosuite: ecdsa, ecdsa-sd, eddsa, bbs.
… There’s an announcement on the CCG talking about this.
… Also talks about how you can try this out in the vc-playground (vc-playground.org) and how Anoncreds is also being aligned so we can do parallel DI proofs with that as well.
… I know a lot of us have been striving towards this and now that there’s a system in the VC playground out there that people can test against will help with interop.
… We do know a couple of vendors that are implementing and expect them to make some announcements in the future about that.

Brent Zundel: Thank you, Manu, cool. Are there any PRs on BBS?

Manu Sporny: Yes, there are several ready to merge, 12 of them.

Brent Zundel: https://github.com/w3c/vc-di-bbs/pulls.

Manu Sporny: Most of them came from implementation experience while Digital Bazaar went through their implementation and while Greg did his independent implementation as well.
… I expect that we’ll merge those PRs within the next couple of days / weekend at the latest.

Brent Zundel: Thank you, Manu.

1.2. Other updates.

Brent Zundel: Still not seeing anyone from vc-jose-cose on the call, I will try giving an update.

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

Brent Zundel: There are 7 open PRs.
… I had a conversation with Gabe – he said they believe they have an agreed upon course of action for each of the open issues of which there are 29, 15 of which are before CR.
… A number of those are being addressed by the open PRs.
… More PRs will continue to be raised.
… vc-jose-cose is slowly making progress but isn’t quite to the point where we can anticipate when it will go into CR.
… With that, any questions on that before we move into the core data model?

Brent Zundel: https://github.com/w3c/vc-data-model/pulls.

Brent Zundel: Here are the PRs open on the core data model. I believe most of these are editorial/post-CR type PRs.
… Manu, a couple to look at on this call?

Manu Sporny: Yes, we need to make a decision on one of them specifically.

1.3. Adding SHACL as a credential schema language (pr vc-data-model#1416)

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

Manu Sporny: There’s a PR opened that suggests adding SHACL as a credential schema language in addition to the JSON schema stuff. This PR is to add it to the core specification.
… Ivan has noted that there are a number of issues with using SHACL as a credential schema language, notably SHACL doesn’t support datasets (only supports 1 graph, not multiple and we use multiple in the core data model).
… It is not necessary for us to put this as a core part of the VCDM as you can always do this as an extension.
… This is coming in pretty late, we don’t know how many people would implement, feature freeze was a while ago, and I believe Ivan got agreement from Christoph to close it.

Brent Zundel: SHACL doesn’t support what our data model requires?

Manu Sporny: Yes, you could be very careful how you use it and ensure certain parts of the data model but not all of it.

Brent Zundel: Ok, so nice to see a PR from people reading our spec to do cool things with it … but unlikely that this PR will be merged. Any comments before moving on?

Joe Andrieu: I’m just wondering if we could queue up something in the implementation guide to support explaining some of this. How you could extend/use SHACL in this way/be careful about these things … that might address the request. But I agree with feature freeze, I don’t want to change the VCDM in some way.

Ted Thibodeau Jr.: We might want to encourage the person to open issues instead of going straight to PR.

Brent Zundel: In fairness to them they did open a discussion but we don’t use that so nobody really engaged because we don’t use that feature. So I created an issue based on that discussion.
… We will be marking it as future.

Manu Sporny: I’d argue against using SHACL at this point in time, so I think it’s dangerous to just do partial, you could argue that JSON schema falls into that same category but it’s also possible to use it by matching against context to check semantics, etc.
… I think a future version thing is what it is, we shouldn’t merge the PR because of limitations in the current version of SHACL. We should see if this works by having an extension incubate this and try it out and only then later potentially put into a future VCDM.
… They should use the extension point to attempt this and they need to have an answer to the SHACL doesn’t support datasets concern.

1.4. JOSE-COSE discussions.

Brent Zundel: Thank you, Manu. Another PR to look at?

Manu Sporny: No other PRs to look at, editorial.

Brent Zundel: All of them except for the one we just discussed have nothing but approvals, so I anticipate that following our normal timeline they will be merged.

David Chadwick: You pointed me to the latest JOSE COSE stuff and it looks like they’ve taken out the SD-JWT examples and replaced them with pure JOSE examples but the text still says they are using SD-JWT and the media type is still sd-jwt.
… So previously we had a document that said it was pure JOSE but it was SD-JWT … and now the examples are JOSE and the text says SD-JWT … so a bit of a mishmash at the moment.

Brent Zundel: The call we had was to keep the SD-JWT aspects of the spec but add JOSE back in.

Manu Sporny: yes, +1 to what brent just said… that’s my understanding as well.

David Chadwick: Yes, my understanding is the same as yours but they’ve removed SD-JWT examples completely and JOSE is back in the examples.
… What they wanted to do was close my PR which added the description of the SD-JWT one. I think Ted can come in here and he’s been semi-following this as well.

Ted Thibodeau Jr.: I agree, I’ve been following that but not the immediate discussion just now. What’s the question?

David Chadwick: Ted, you did some editorial suggestions to my PR and then Gabe was closing it … and I think it’s not done and you, Ted, were agreeing with me.
… So this hasn’t been completed yet, because the example for VP SD-JWT and no text describing that … and that example is gone now… both SD-JWT examples are removed at the moment. I’m not sure what’s happening with the spec.

Ted Thibodeau Jr.: If the examples have been removed then the issue is resolved by removing them, but if they come back, then the issue will be revived.

David Chadwick: They’ve got text and media type for SD-JWT but examples for pure JOSE.

Brent Zundel: While I appreciate the concerns and feel that a discussion would be valuable – having half that discussion while the vc-jose-cose editors aren’t here … not the best use of our time perhaps.

David Chadwick: Yes, but having it in the minutes makes clear it needs to be addressed.

Brent Zundel: Thank you, David.

2. Issue Processing.

Brent Zundel: Moving onto issue processing.
… Right now, every issue is official post-CR, but some aren’t labeled as such yet and we should make sure that they are issues that we feel need to be addressed.

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

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

See github issue vc-data-model#1410.

Brent Zundel: Does this spec need a normative credentials specification section… we talked about this a couple of weeks ago.
… If we do this, it’s likely it will require some normative text. We created a CR-2 label for it and so it’s triaged and Manu has accepted an assignment for it… can you speak to this Manu?

Manu Sporny: Jeffrey’s concerns are here: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296.

Manu Sporny: Jeffrey Yaskin raised a number of concerns – saying he would like to see specifications that define new credential types like … types for driver’s licenses, or employment authorization documents, or digital coupons, or whatever … that we have guidance to those specs in the core data model.
… So we established things securing specs must do and he’s saying we should establish things that credential type specs must do.
… He suggested some items in the comment I linked to. One way to do that is to have a section that is like the securing specs … and specify requirements there. I’m still a bit fuzzy on what we’d write in that section. We don’t have to write that section, it’s not clear that if we wrote something Jeffrey would be happy with it, I could try to make an attempt… I need direction from the group.
… Is this worth doing this at this point? Do we do one PR and try to make it work and if we don’t just close it?

Brent Zundel: So this issue is asking for, suggesting that the core data model needs a section of normative requirements aimed toward potential credential type spec authors that would guide those authors and tell them what their specs are required to include to be best compliant with the core data model. Is that right?

Manu Sporny: Yes, I think that’s close.

Phillip Long: I like the idea of giving one PR a shot for normative requirements for type specification authors per https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296.

Brent Zundel: So kind of what the DID spec did with DID methods.

Manu Sporny: Yes.

Joe Andrieu: I think this is a form of centralization that is probably not going to be good for us. It would mean that if your new type of credential doesn’t fit and we’re trying to stand in that way.
… The difference with DID methods is we’re running a registry, which I also oppose, and we don’t have a similar registry and I don’t think we should add one, so we shouldn’t try to do this.

Manu Sporny: I think Jeffrey is talking about security requirements, so things that a spec would need to say to be processed as regular JSON – so you can process as JSON-LD or as JSON (“credential type-specific processing”).
… I don’t think this creates a centralization concern.

Brent Zundel: So, in addition to your credential spec needing a security considerations section, what other normative guidance might be necessary for it to work with the core data model?

Manu Sporny: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296.

Brent Zundel: So what, specifically, might we provide in terms of guidance?

Manu Sporny: He’s got like three things in an issue. Like “you must use enveloping proofs”, I don’t agree with that one. He also has “never create a claim that says: ‘this other claim means some other claim means nothing if this one exists’.

Manu Sporny: Here are some normative requirements that we could write into this section: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296.

Brent Zundel: Where is this?

Manu Sporny: Again – I think it would be very challenging writing the language, willing to give it a shot, but not expecting success.

Joe Andrieu: They seem pretty arbitrary, the first one Manu didn’t even agree with – trying to establish these things, I think we don’t have a good enough understanding to get to consensus and limiting what people are allowed to say with VCs I would oppose.

David Chadwick: I find number 3 is problematical given our data model where we have claims that invalidate others.

2.2. Type-Specific Credential Processing is better phrasing than Credential Type-Specific Processing (issue vc-data-model#1415)

See github issue vc-data-model#1415.

Brent Zundel: We’re looking primarily for triage.
… This one is about credential-type specific processing vs. type-specific credential processing.
… That sounds better to me.

Manu Sporny: I agree.

Ted Thibodeau Jr.: I can also take this one.

Brent Zundel: I will assign Manu and Ted, and whoever gets there first wins.
… Labeling that one CR-2.

2.3. Support of SHACL Schema in Version 2.0 (issue vc-data-model#1419)

See github issue vc-data-model#1419.

Brent Zundel: We already had a conversation about this one through the PR that was raised, this is the SHACL one. At this point, it seems likely we’ll just label this future but we should allow the conversation to come to completion on the PR before making that designation here.
… Happy to take comments if folks have them, otherwise moving on.

2.4. Some minor issues.

Brent Zundel: Next three are PR-exists and editorial, taking the liberty as marking them as CR-2. We don’t have to talk about them unless folks are inclined.
… 1418,1424… [and one other].
… Jumping into processing the rest of the issues.

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

Brent Zundel: We will be talking through this, but there was one issue in particular that folks wanted to talk about today which was an older issue but still valid.
… It is the only issue currently marked pending close, issue 942 we can talk briefly about it.

2.5. Create the new role of issuee (issue vc-data-model#942)

See github issue vc-data-model#942.

Brent Zundel: As I recall things, please correct me … as I recall things, we did not come to consensus as a group about creating the new role of Issuee. It was proposed to the group, we had long conversations about it, but ultimately the group could not come to agreement on doing this.
… As Kristina mentioned with her comment – there was no consensus in the group for that. The issue was then adjusted to be about adjusting the holder property to talk a little bit about it. This conversation has gone on for a long time and my recollection is we don’t have consensus to add Issuee as a new role…

Manu Sporny: agree w/ brent’s summary.

Brent Zundel: … and unless everyone on this call disagrees then I’m happy to close it out.

Joe Andrieu: Thanks, the main issue — I wanted to bring it up and let David have this moment to try and speak against it.

Manu Sporny: To underscore … I agree with your recollection, Brent, I think that’s where the group is and wouldn’t personally want a new role in the ecosystem.

Dave Longley: I didn’t think it made sense as a role, but perhaps a property.

Brent Zundel: The extension model allows issuee to be added as a property.

David Chadwick: Can we please record that this role has always existed.

Brent Zundel: I appreciate your view on this but it’s not mentioned by name as a role in the spec, so it’s a new role.

David Chadwick: Just because it wasn’t listed doesn’t mean it hasn’t existed. The issuer has always issued the credential to the issuee, it’s just English grammar if you like, it’s just not documented as such.

Ted Thibodeau Jr.: issuee is a shadow-role, filled by the first holder who gets a VC from an issuer.

Brent Zundel: I appreciate that perspective and I disagree with it, my chair hat off, as a contributor, I don’t think that’s the case.

Ted Thibodeau Jr.: As I said in a few places, included in that issue, I don’t have anything against defining this term, whether it’s fully defined and in the spec or just reserved and I would suggest reserving that label issuee for future use. It does always exist and has existed as David says, we haven’t highlighted it.

David Chadwick: Thankyou Ted.

Ted Thibodeau Jr.: It’s just the first holder of the VC.
… Having it, would resolve some issues to address some issues that are elsewhere in these documents and we’ve gone in circles because we didn’t have this term to use.

Manu Sporny: I’m still a -1 to add this, I get what both David and Ted are saying, yes the concept has always existed since the dawn of time since the first VC was issued by an issuer and handed to the first holder, the issuee.
… I don’t think we have consensus, a strong -1 to add this at this time, I don’t think it’s helpful.

Joe Andrieu: I’m a -1 as well, the vernacular fact that you might refer to the first holder as an issuee doesn’t create a new role, they are still a holder. Adding it as a role to the list of roles would make it a new role. When the holder presents a VC we could call them a presenter, but that doesn’t mean we add it as a role, as it confuses the simple 3-party model that highlights the difference with VCs and previous phone-home architectures.

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

See github issue vc-data-model#1274.

Brent Zundel: A little bit more about verification method type schema. Either this is just an answer we need to give or some editorial content to resolve it.
… Do we need more information about the verificationMethod property, does it need to be done, is there anyone willing to do it?

Manu Sporny: I’m trying to parse what they are saying. I guess I said this was ready for PR a year ago…
… I think the spec was in a different place then.
… The easiest fix for this is to just point to the verificationMethod property in the DI spec, but others in the group might object to us doing that because it’s also defined in vc-jose-cose, we don’t have a unified controller document spec yet.
… The other thing we could do here is just delete the note.
… I don’t know if this note is really helping anymore.
… If folks are ok, we could just delete the note, it came from a time long long ago, where we needed to highlight that the digital signature might include things like the public key associated with it and so on – and now we have whole specs talking about all of that. I suggest we just delete the note.

Brent Zundel: Big +1 to cleaning up the spec you suggested.
… I think getting rid of some things that aren’t necessary now that we’re on version 2.
… The suggestion is to resolve this issue by removing the linked note and move forward in that way.

Dave Longley: +1 to that path forward.

Phillip Long: +1 to that path.

Brent Zundel: Any opposition to that?
… Let’s do that, awesome.

2.7. Clarify evidence section to point to OBv3 evidence property usage (issue vc-data-model#1293)

See github issue vc-data-model#1293.

Brent Zundel: Clarify the evidence section to point to OBv3 evidence property issue, raised by Manu and assigned to no one, Manu, walk us through this?

Manu Sporny: The current evidence property doesn’t use real examples and this is just about updating it to use real examples to use an OpenBadge v3 example of evidence.

Brent Zundel: So this is about updating examples to make use of OpenBadges v3 examples – and changing the text or not?

Manu Sporny: Just to update the examples.

Phillip Long: +1 to that ;-) I’ll make a stab at that/.

Brent Zundel: Can anyone be assigned to update those examples?
… I see Phil Long will work on it.

David Chadwick: It was just to say that the other real example is the one from New York customer work – the OpenID foundation work. Similar examples in the CCG.
… If you want to refer to that as well, as another solid example you could.

Brent Zundel: If you have links to either of those that would be really helpful.

David Chadwick: How should I get those across?

Brent Zundel: Add them directly to the issue, excellent, thank you very much, David.

Phillip Long: Thanks David.

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

See github issue vc-data-model#1291.

Brent Zundel: Multiple credential status lists – is it possible to have multiple credential statuses, i.e., have credentialStatus be a set?
… The short answer is “yes”. Do we want to have an example?

Manu Sporny: We have an example in the bitstring status list spec on having multiple statuses.

Manu Sporny: Multiple Status Lists in One Verifiable Credential: https://w3c.github.io/vc-bitstring-status-list/#multiple-status-lists-in-one-verifiable-credential.

Manu Sporny: But that’s just for the bitstring status list type… let me get a link in here.
… Maybe they are wanting something slightly different which is wanting different types of credential statuses.
… We could just reuse the example from bitstring status list. Or we could point to those examples?

Brent Zundel: We could create an example or modify example 17 in the spec so that credential status an array of objects, but hesitation to propose that as a path forward is that then we have to say how those statuses interact. Maybe we just have to say – if you have multiple statuses and they are conflicting, good luck figuring that out.

Manu Sporny: Yes, +1 to the same concerns.
… He does provide an example – about revocation and suspension. We could just use the example and add the warning that you just mentioned, Brent. It feels like it would address this issue.

Brent Zundel: Ok. There’s a proposal on the table, we take the suggestion from the issue, work it into the example we already have in the spec and then add a sentence to the spec that says, should multiple statuses be included and they be in conflict, the verifier’s business logic needs to take that into account.

Joe Andrieu: I like that general approach, +1, I don’t think it’s as much about them being in conflict as they represent different things semantically, we just need the validation phase to be able to pull in all the factors and be able to understand the semantics to make a decision.

David Lehn: Is the processing of things like this similar to how you’d process proofs, where you have ANDs and ORs – and it’s a bit more work, but should we do that sort of thing?

Manu Sporny: I’m concerned about saying that much in the spec this late in the process.
… Most of the usage of credential status that I know of right now is whether it’s revoked/suspended/or does it have 1-30 different values (multi-status stuff). I don’t think we have enough implementation experience to make broad statements about composition.
… And we should stay silent now until there’s more implementation experience.

Joe Andrieu: General +1 to Manu.
… We do want to say that this is possible, and however many there are, they are inputs to validation and how composition happens and so on is the verifier’s business.
… They need to figure it out. There’s also a use case contribution by Kevin from GS1 – as GTINs get brought in during acquisitions there’s a need to track status things.

Brent Zundel: If anyone here says “that’s a good idea, let’s clean this up” – assign yourself! If no one volunteers it won’t get done.
… Thank you all for being here, still a lot of work to do, hoping we can continue the momentum, thank you Dave for scribing, thank you all for being here, see you next week!