#874: Verifiable Credential Status List 2021

Visit on Github.

Opened Jul 20, 2023

I'm requesting a TAG review of Verifiable Credential Status List 2021.

This specification describes a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials.

  • Explainer¹ (minimally containing user needs and example code): Explainer
  • Specification URL: Verifiable Credential Status List 2021
  • Tests: Test Suite WIP
  • User research: N/A
  • Security and Privacy self-review²: Security and Privacy Self-Review
  • GitHub repo (if you prefer feedback filed there): VC Status List Github
  • Primary contacts (and their relationship to the specification):
    • Brent Zundel (@brentzundel), VCWG Chair, Gen
    • Kristina Yasuda (@Sakurann), VCWG Chair, Microsoft
    • Manu Sporny (@msporny), Editor, Digital Bazaar
    • Dave Longley (@dlongley), Editor, Digital Bazaar
    • Orie Steele (@OR13), Editor, Transmute
    • Mike Prorock (@mprorock), Editor, Mesur.io
    • Mahmoud Alkhraishi (@mkhraisha), Editor, Mavennet
  • Organization(s)/project(s) driving the specification: W3C Verifiable Credentials Working Group
  • Key pieces of existing multi-stakeholder review or discussion of this specification: n/a
  • External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Issue Tracker

Further details:

The VCWG is planning to take this specification to Candidate Recommendation in September 2023 (at W3C TPAC), reviews before that time frame (ideally, by the end of July 2023) would be ideal.

The specification is undergoing work to address definition and reference of multiple status beyond suspension and revocation.

  • This work is being funded by: The members of the W3C VCWG that are actively participating in the development of these specifications including funding from the US Federal Government, the European Commission, and the Canadian Federal Government

You should also know that this work intersects heavily with the Verifiable Credentials v2.0 work, which is also something that the TAG will be actively reviewing around the same time

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

Discussions

2023-09-04

Minutes

<blockquote>

Hi @mkhraisha thanks for your review request.

Is it possible for an issuer to use their own value for the statusPurpose field? It's clear that the strings revocation and suspension must be used correctly as defined in the spec, but given the extensible nature of JSON-LD it looks like it would be possible for additional terms to be introduced here. Is there a risk of this being overloaded and potentially leaking other information about the credential? Should the spec be explicit about constraining the values only to these strings, or has it been deliberately left open to permit other strings to be used without additionals to the spec? If it's the latter, what other (legitimate or malicious) values do you think we might see here?

Do the vavlues of statusMessages carry simiar risks related to overloading/data leakage, as these are defined by the issuer?

I have more general concerns about malicious issuers tracking credential holders, which I've no doubt has been thought about at length in the WG and wider community. It would be great to see pointers to more work on this, and mitigations in particular, given the types of organisations which are likely to issue credeintials, the limited options people may have for credentials that are accepted, and the power dynamics involved here.

Thanks for your suggestion in the Security & Privacy questionnaire about asking about maturity of dependencies. I've raised an issue to add this to the questionnaire. Do you have an answer in mind for this question for the VC Status List spec?

</blockquote>

amy to post

2023-10-09

Minutes

Amy: I feel kind of stupid but I don't really understand Orie's response. Also it only answered half the questions.

Amy: let's punt and I can get some explainers... Tess wrote a blog post about polyglots which could be relevant.. But they've also gone to CR with most of the VC specs

punts one week - Amy will work on getting more context

2023-10-16

Minutes

bumped

2023-10-23

Minutes

Max: had similar opinion to Amy about security and privacy

Amy: did you understand Orie's reply?

Max: they mentioned the privacy conern in their explainer.. but they don't explain how to address this

2023-11-27

Minutes 

Sorry for the delay on following up. Have you had chance to find pointers to any work on [mitigations to the risks of malicious issuers and an answer to the suggested security question about dependencies](https://github.com/w3ctag/design-reviews/issues/874#issuecomment-1709584748)?

Amy: they have loads of open issues a lot of them to do with privacy...

2023-12-18

Minutes

Amy: A couple of points where we should open issues on their specs.

Dan: Can we close this one then?

Amy: Probably - there's the stuff about malicious issuers of VCs that bothers me but not sure we need to block this particular one...

revisit at plenary

2024-02-19

Minutes

Amy: feedback from ping is that this could be a cross-origin unique identifier and they should stop. https://github.com/w3cping/privacy-request/issues/127#issuecomment-1932531261 The spec acknowledges the privacy concerns...

Dan: Ok with satisfied with concerns

Amy: will make it clear that we're satisfied that you're thinking about this - not because we don't think it needs to be resolved - specifically the privacy issue - not that we don't think it needs to be resolved.

<blockquote> Thanks for your comprehensive reply, and for your patience while we loaded this back into our collective heads.

We think it's important that you continue to explore and elaborate on mitigations for the privacy concerns raised in this thread, and in the horizontal review with PING. We're closing this as 'satisfied with concerns' because it's clear that you intend to do so, though we think it's important that these issues are resolved before the spec goes to REC.

</blockquote>