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

> 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)?

Hi @rhiaro, apologies for the delayed response. The VCWG has been heads down getting Data Integrity and VC JSON Schema into CR (this was done as of last week). We are now heads-down trying to get the VCDM v2.0 into CR (target date is last week of December). After we get through that hurdle, we'll shift our focus to "Verifiable Credential Status List 2021", which has been renamed to "Bitstring Status List".

As such, we will probably not have a WG response on a timeline before the upcoming holiday break.

I'll respond as an Editor of the specification, but this probably warrants TAG raising an issue on the spec and us marking it as "resolve before Candidate Recommendation". Note that my responses represent what the specification does *today*, not what we might change it to do in the future (based on TAG, implementation, and other Horizontal Review feedback):

> Is it possible for an issuer to use their own value for the statusPurpose field? 

At present, yes, it is possible to do that.

> 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. 

The `statusPurpose` property value  is a free form string, not a JSON-LD typed value... which means, "Any string can be used here". When implementations use strings that are not defined by the specification, the behavior is undefined.

> Is there a risk of this being overloaded and potentially leaking other information about the credential? 

Yes. The more information you encode in the status list information, the more possibility there is for correlation (based on the extra bits of information you're getting). For example, we will most likely need to put Privacy Considerations entries in the specification noting the use of the (concerningly named) "status" value for the "statusPurpose" field.

> 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?

It's the latter, we wanted multiple statuses to be able to be expressed... not all of them contemplated by the VCWG.

As for legitimate values, one could conceive of: "sanctioned", "suspended-pending-review", "probation", "inactive", "under-review", "revoked-with-cause", "revoked-without-cause" ... though we don't know of anyone actively pursuing those `statusPurpose` values. In short, we don't know what we don't know and we didn't want to close off this particular extensibility mechanism at this point in time.

As for, "Why a string instead of a JSON-LD type"? We've noted that there is a point of diminishing returns to use certain types. For example, with Data Integrity, we found that there was an explosion of JSON-LD Contexts for proof types and that we could reduce that explosion by just providing a single `DataIntegrityProof` type and provide a string-based `cryptosuite` property that could be used by individuals and organizations that wanted to extend the `DataIntegrityProof` base type. This meant that you could use the same base VCDM v2.0 JSON-LD context to support a very large set of proof extension types w/o having to create yet another JSON-LD Context to specify the type values in the "cryptosuite" property. This reduces the implementation burden for cryptosuite authors as well as implementers. We are applying the same design approach here to see if we can get the same benefits.

When it comes to malicious values, that implies a malicious issuer, and if you have a malicious issuer all bets are off. A malicious issuer can issue VCs that say horrible and untrue things about you, they can construct status lists that are designed to track you, and do a number of other harmful things. The key there to prevent abuse is to understand whether the behavior can be detected such that the issuer can be punished for that behavior (regulatory action, public shaming, boycott, loss of market share to more privacy-preserving issuer, etc.). We do speak to this in the current spec:

https://w3c.github.io/vc-bitstring-status-list/#malicious-issuers-and-verifiers

and the VCDM spec:

https://w3c.github.io/vc-data-model/#issuer-cooperation-impacts-on-privacy

... but that might not be enough. Can you think of something more we should say in those sections (or others)?

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

Yes, they do.

I imagine that we will probably want to say more about this, and a fresh set of eyes (the TAG's) will help focus our attention on what's missing and what more we should write.

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

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