Verifiable Credentials Working Group Telco — Minutes

Date: 2023-05-24

Attendees

Present: Brent Zundel, Phillip Long, Kristina Yasuda, Michael Prorock, Dave Longley, Kevin Griffin, Oliver Terbu, Will Abramson, Orie Steele, Gabe Cohen, Greg Berstein, David Lehn, Manu Sporny, Dmitri Zagidulin, Joe Andrieu, Markus Sabadello

Regrets: Shigeya Suzuki

Guests:

Chair: Kristina Yasuda

Scribe(s): Dave Longley, Manu Sporny

Kristina Yasuda: We have PRs and issues for today.
… Anything people want to make sure we cover today?
… Mike Prorock has some PRs to discuss.
… Let’s start with those.

1. PRs.

1.1. Support for multiple status codes (pr vc-status-list-2021#65)

See github pull request vc-status-list-2021#65.

Michael Prorock: The first one to put out there for attention is VC status list PR #65. This adds a backwards compatible approach to providing the ability to encode multiple statuses in a single list.
… We have multiple use cases for this, such as US customs that have 3-4 or more statuses at once.
… This is to add this in a backwards compatible way.
… Having written an implementation of this and tested it in two different languages, it doesn’t seem like a huge list.
… If you assume a size of 1 for the existing stuff, if the size is expressed you use that as a multiplier instead.
… It’s not a huge lift.

Dave Longley: This would mean that there were two different ways to express multiple statuses, we should consider if we can get down to one way and which one is better and what the tradeoffs are.

Orie Steele: This approach would cut down on http overhead, and associated privacy implications when multiple independent lists are used.

Dave Longley: I haven’t been able to think about privacy considerations approach, bit list, and herd privacy. In terms of complexity, it’s not just about having number to multiply by… need to think about this. We had said previously that we could have multiple lists… this is a different approach to that, don’t know what the consequences are here.

Michael Prorock: One thing I would note – Orie noted this in the chat – this significantly cuts down on network trips if you have multiple things to check, you use one network call instead of N.
… This cuts down on business rules like having to specify business rules and things like that – you can avoid that.
… In regards to having multiple ways to represent statuses, I’m not sure if that’s a bad thing. There are cases that require just suspension or revocation checks and this just provides more flexibility in the ways the use cases can be addressed.

Manu Sporny: Real quick. I’ve been trying to work on the privacy characteristics. People have said that the problem with the bit string starting at zero – what if we want to hide the number of members in a herd. I think what’s being proposed might make some of those approaches not work anymore. I haven’t been able to look at the PR can’t say positive or negative yet.
… Mike, I don’t know if you looked into herd privacy, I know in supply chain it’s not a super important thing but in the digital ID use cases it’s important, these might be in conflict, we’ll have to think about it more.

Michael Prorock: Absolutely, well aware and appreciate your reasoning. I think we need to think it through. Sometimes linkability is desirable and sometimes not. We could have a follow-on PR for these considerations.

Orie Steele: consider the case where you have many statuses on the minimum length… https://w3c.github.io/vc-status-list-2021/#revocation-bitstring-length.
also consider decoyes.

Michael Prorock: I personally think things like fuzzing size and so on could be done and worth considering.

Kristina Yasuda: Thank you Mike.
… Any other PRs to talk about?

1.2. remove 1.1 (pr vc-jwt#85)

See github pull request vc-jwt#85.

Orie Steele: This PR should be merged: https://github.com/w3c/vc-status-list-2021/pull/46.

Michael Prorock: It has all approvals in – just want to make sure there are no additional commentaries in there before it goes in.

Kristina Yasuda: I see 6 approvals and 1 week time. Why is it not merged yet?

Michael Prorock: Just hit a week now.

Kristina Yasuda: Any objections on this call now?

1.3. update title of securing json-ld section (pr vc-jwt#86)

See github pull request vc-jwt#86.

Kristina Yasuda: No one is blocking.

Michael Prorock: Great. PR #86 is also ready for merging, last chance to get adjustments in.

Kristina Yasuda: Any objections to merging this one as well?

Phillip Long: +1 to #86.

Kristina Yasuda: No blockers here either.

1.4. remove securing json (pr vc-jwt#88)

See github pull request vc-jwt#88.

Michael Prorock: We have a valid change request in – for PR #88 – but it will need discussion.
… This one does something potentially controversial. It removes the securing JSON section. It makes VC-JWT focus only on securing the core data model with no transformations or mappings, nothing else.
… Kristina has mentioned market interest in vanilla JSON claims in VC-JWT.
… So I’ve raised that to get comments from the community.

Kristina Yasuda: Any comments on that?

Orie Steele: Regarding removing VC-JWT media type and securing plain JSON – I’m in favor of this PR. I’m in favor of this based on the day 3 F2F resolution and the work load for this group.
… We have several technical recommendations to work on and it’s very unlikely to get consensus on the day 3 resolution in the core data model and without that consensus we will not be able to elevate this item to the point where it will go into CR.
… Without adding normative statements that will be contentious and it won’t be able to get merged and I foresee this not going anywhere as long as this section stays in the document. I’m making that assessment based on the rate of engagement and so on.

Dave Longley: +1 to remove the section.

Phillip Long: +1 to remove this section.

Kristina Yasuda: Any other PRs?

1.5. Ensure that statusListCredential can be dereferenced. (pr vc-status-list-2021#46)

See github pull request vc-status-list-2021#46.

Orie Steele: I’d like to circle back to PR #46 on status list. The changes requested are assuming a particular transport protocol and it’s possible that additional PRs could come in to improve the quality of the spec and I don’t think we should hold up this PR.
… There’s nothing in there, this is an improvement and others need to be made and I’d like to merge this so we can make incremental improvements.

Manu Sporny: In addition to what Orie said – I raised issue #64 and that issue’s title is “Add a section on expected server HTTP status codes”, that’s now being tracked. I believe that’s what both Kristina and Mike Jones were asking for that.
… So I think there’s a way to do it – but doing it in this PR would just make the PR really big and potentially further delay it getting merged in.
… The only change request that was blocking this – I requested a re-review from you, Kristina and Mike Jones.

Michael Prorock: Yeah, if we merge we can build on top of it.
… Can I add a note that references that issue?

Manu Sporny: Yes, totally fine.

Kristina Yasuda: Ok, I will re-review and hopefully MikeJ will read the notes.
… Thank you, Orie.
… Anything else?

1.6. Add JSON Web Token Examples (pr vc-status-list-2021#60)

See github pull request vc-status-list-2021#60.

Orie Steele: We seem to have a difference of opinion regarding adding examples to the specification. And I would like to merge the examples as-is. I don’t agree with the perspective that every example in our spec needs multiple context values.
… I don’t agree with that and in light of bundling the Data Integrity context.
… This adds informative examples, can we merge this, please, thank you.

Greg Berstein: Please!

Manu Sporny: -1 to merge until the WG discusses it. With all the examples it keeps coming up and we need to have a consistent way that we’re doing examples and figure out what it is so the editors can apply that uniformly across all the specs.

Phillip Long: is this a special topics call?

Kristina Yasuda: I’m up for spending 5-10 minutes on this call on this.

Orie Steele: lets remove the DataIntegrityProof RDF class from the core context… and make the examples include multiple contexts.

Manu Sporny: I don’t know if we’ll get through it in 5 minutes. The proposal is to just use the example in the core spec.
… Use it as an example across all the specs that need to use an example. That way we’re just using an example that we’ve agreed to use across all the specs and we don’t need to do variations of that in every other specification.

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

Kristina Yasuda: Are you fundamentally not ok with the example, Manu?

Manu Sporny: Yes.

Kristina Yasuda: Anyone else who has strong opinions about what examples we use?

Orie Steele: All the examples conformant to the core data model.

Michael Prorock: My question is along the same line… what precisely is wrong with the examples?
… At least by my read and going and running the example code it all checks out fine.

Manu Sporny: One of the things is that we have a suspension false entry in here, I don’t know where that property came from, I think Orie said that’s an artifact in the PR and it’s not in the data model.
… There’s a concern over the use of the undefined / issuer-independent context / vocab.
… Now we’re using the issuer-dependent terms in the example.
… There are a number of people that said in the other PR that’s not a good practice.
… We’ve had people say that they would rather the examples use the examples context instead of the issuer-defined one.
… I don’t know why we’re doing in status list when core does something else.

Dave Longley: A lot of developers will come along and look at examples to get things started, and there are such things as good examples and bad examples.

Orie Steele: IMO a good example is one that uses the minimal required fields.
it is bad form to include optional stuff in example, and bad form to include DataIntegrityProof in the core v2 context.

Dave Longley: You can create examples that are bad examples, which would be conformant, but wouldn’t look good. It’s not enough to say “We created an example and it validates so it’s fine.” If we get people started off on he wrong foot, or encouraging market failures, we’re making mistakes. We should not be flippant about the examples we put in the spec. They’re important, developers will look at these examples and maybe not the text.
… Saying “this verifies” is not enough, these are entry points into the spec and possibly exit points.

Kristina Yasuda: Sounds like we’re leaving this issue open for now.
… Anything on the BBS cryptosuite stuff?

1.7. General discussions on PRs.

Michael Prorock: Before we go – I’m seeing a comment here objecting to claim name and value.

Orie Steele: They are not defined… we added @vocab to the spec…

Orie Steele: the assertion that @vocab is not a best practice, is false.

Dave Longley: My general objection is creating examples with undefined properties that relies on issuer-dependent properties without there being issuer-dependent properties. That is a bad practice that has plagued the ecosystem for the past 10 years. This is not a best practice, this is something you can fall back on.

Michael Prorock: So you’re going to objecting to anything with @vocab?

Dave Longley: That’s not what I said.

Orie Steele: Put another way, want to encourage developers to resolve multiple contexts for any terms not in the core data model, except for DataIntegrityProofs.

Dave Longley: I said that for anything we’re doing, we shouldn’t have issuer-dependent vocabularies as a first cut… if you don’t have time for it or doing an experiment, you should know full well that doing issuer-dependent isn’t the best thing for the ecosystem. Maybe there is a use case that doesn’t matter… but it should not be used inf fundamental examples to developers on how to use basic features.

Michael Prorock: Ok, got it.

Kristina Yasuda: Ok, good, thank you.
… We’re down to three PRs, very nice.

Orie Steele: Part of the reason we’re down to 3 is that I just closed some PRs. I closed one to come up with language regarding issuer-dependent terms where we weren’t getting consensus.
… I encourage Dave and Ivan to make PRs on that to improve the document.
… I opened and closed PRs for predicates that we don’t define and I assume we’ll get a chance to object to those when we get to CR.

Dave Longley: I would recommend, rather than unilaterally closing PRs, people make suggestions to these PRs… we can close those PRs, that causes others to create PRs and that’s a way forward. We might want to be more efficient by continuing the work inside the PR itself.

Orie Steele: Is there a process requirement to do as dave suggested?

Michael Prorock: I suspect that an author of a PR in a WG might want to close a PR, simply because this WG is extremely difficult to achieve consensus at all, and the author feels attacked to the point of utter frustration.
… I don’t see any process requirements that say otherwise, I’m happy for the chairs to say otherwise.

Kristina Yasuda: The author of a PR may close the PR.
… If a WG member thinks there was useful information in a PR please feel free to open a new one.

Manu Sporny: On Mike’s comment. Going back, presuming good faith among the WG members, we’re all trying to work toward a common goal here. I know it can be incredibly frustrating to raise a PR and have it languish or be constantly whittled at – I know a number of my PRs have gone through that and at the end we closed them.
… I know that can be really frustrating but we should all keep in mind that it’s not a personal attack.

Orie Steele: If it really mattered to me, I would not have closed it.
I sincerely hope other people will try to raise PRs to improve the spec.

Manu Sporny: And please try really hard not to take these things personally as frustrating as it may be. I wanted renderMethod in there, for example, and tried really hard to get it in, but it didn’t get in, everyone has their own motivations and sometimes we just don’t get to consensus.
… I would be careful with saying that people are attacking you.
… I don’t think we’re dealing with those sorts of people in this WG.

Kristina Yasuda: I think Orie addressed that in chat.

Michael Prorock: +1 kristina.

Kevin Griffin: I assume since we had the special topic call regarding 1100/1101 that we wouldn’t be discussing those here, the chairs noticed paths forward, just wanted to make sure that’s the case.

Kristina Yasuda: Yes, thanks for bringing it up, we discussed those on the special topic call. It was a good call.
… I think Brent and I will sync and propose something.
… In the meantime do what you can in the PR.
… Let’s move to the issues.

2. Issues.

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

Kristina Yasuda: Let’s stick to the usual policy. If there’s no one who can lead an issue we’ll put pending close.

2.1. Single Extension Point (issue vc-data-model#1102)

See github issue vc-data-model#1102.

Kristina Yasuda: David Chadwick is looking to remove extension points and replace them with another approach.
… I think there are very strong voices against it.
… Anyone willing to lead this issue?

Michael Prorock: Frankly, I’d object to a change of this nature. Unless someone in the WG is willing to write a PR for this we should close it.

Dave Longley: +1 to close.

2.2. Better visualization of data model (issue vc-data-model#1095)

See github issue vc-data-model#1095.

Kristina Yasuda: Images in the data model.
… Is there anyone who could take the lead on this?

Manu Sporny: This is a great idea, we should have it in the spec, there are some possibilities… but starved for time. :(.

Michael Prorock: I pun intended … think this is a beautiful idea but have no bandwidth to deal with it. If no one else is willing to stand up I’m willing to mark as pending closed.

Orie Steele: suggest closing.

Brent Zundel: Another option is to mark this as post CR. This is proposing completely editorial changes. Theoretically we’d have time and bandwidth once we’re in CR and going through that process. Now we could say “our diagrams are prettier!” and that’s not a substantive change.

Michael Prorock: +1 brent - this is editorial in nature.

Kristina Yasuda: Any objections to post CR label?
… Ok, we’ll do that.

Orie Steele: https://github.com/digitalbazaar/respec-vc/pull/8.

Orie Steele: I do think … Manu raised a concern regarding the existing SVG assets that we have. Something to the effect that we need semantic annotation so we can align with a11y requirements of W3C.
… I wanted to confirm that W3C requires SVG with web a11y with annotation to provide images in specs.
… I’ve also updated a plugin for examples and updated that to support the latest VC-JWT spec.
… It contains some visual examples using mermaid.

Kristina Yasuda: I’m keeping post CR for now.
… If later on – we can close or address.

2.3. Handle predicate for confidenceMethod in JSON-LD context (issue vc-data-model#1116)

See github issue vc-data-model#1116.

Orie Steele: I don’t think we should include confidenceMethod or any predicates in the core contexts for which there are no defined RDF types.
… Exceptions to that – are where we have a formal spec that defines an RDF type for that extension point.

Michael Prorock: +1 orie.

Orie Steele: If there’s a CG spec then we can include it, like renderMethod … for any predicates with “a blank check” because they have no RDF types … should not be in the core context.

Kristina Yasuda: I’ll assign this to Oliver for now to have him handle that.

Oliver Terbu: The confidenceMethod PR is currently stuck.
… And I don’t know how to proceed.
… I don’t have anything to add today. I encourage everybody, especially those people who raised concerns in the PR to follow up on the latest.
… Just to make it clear that there’s a chance to get this PR merged or not.
… If there’s a chance to get it merged, what needs to be changed?

Orie Steele: ideally, define an RDF type for confidenceMethod completely, such and interoperability at both the predicate and the type can be achieved.

Orie Steele: look at the renderMethod PR.

Michael Prorock: I would suggest that there’s a path forward but might not be desirable. It is to follow exactly the model that was taken with renderMethod, where you take confidenceMethod define it in a CCG spec.
… I don’t see people objecting.
… Point to it – and at that point the road is clear, make sure it’s in there and referencable, etc. It gives a clean path to incubate and polish.
… In the render case, there’s a lot of implementers – it may not be suitable as part of the core data model.
… I was having this conversation in person – it isn’t that a lot of things aren’t good ideas, it’s just a question of whether it would be better to standardize things in their own documents instead of in the core data model spec.

Oliver Terbu: I’m totally fine with that approach by the way. I can’t really speak for the other people – especially people who created holder binding over the last couple of years.
… I think before closing this PR and moving forward with the way MikeP suggested, we need to reach out to those people and see if they object to moving forward the way he said.

Orie Steele: I just wanted to say – a lot of this is related to VPs.
… I find this incredibly poorly defined in the current data model. It’s possible that efforts going into this confidenceMethod could massively improve the requirements around VPs.
… I don’t know, it’s hard for me to tell. The requirements for a VP is that it’s a JSON-LD object with a context and a type and that’s enough rope to build anything.
… It seems weird to me, some of this is related to subject-is-holder flows.

Michael Prorock: +1 orie - there is good value here - however once again this may be better handled as a separate specification.

Orie Steele: That’s one reason this is held up – it’s covering a lot of ground.
… VPs remain a weak spot in the spec and they need improvement.

3. Cancelling next week’s calls.

Kristina Yasuda: Next week we are canceling both calls because both Brent and I are unavailable.
… So we will see you in two weeks.