Re: [w3ctag/design-reviews] Verifiable Credential Status List 2021 (Issue #874)

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](https://github.com/w3ctag/security-questionnaire/issues/155). Do you have an answer in mind for this question for the VC Status List spec?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/874#issuecomment-1709584748
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/874/1709584748@github.com>

Received on Thursday, 7 September 2023 07:00:42 UTC