Preventing multiple single-credential status lists per issuer

[kezike]

What prevents the issuer from hosting several status list bitstrings (one for each credential) and embedding a statusListIndex value that represents one of those bitstrings at issuance time? This loophole would allow a 1:1 mapping between credential and status list, eliminating the herd privacy guarantees that are integral to this spec.

[kezike]

This issue could be the intention behind the spec requiring that the id property of the credentialStatus attribute is not the URL for the status list (See id property of RevocationList2021 here). However, it is possible for these two values not to be equal yet the issuer still manages multiple single-credential status lists 🤔

[dlongley]

So this issue has been contemplated before but it may not have made it into the privacy considerations section (yet?). It should get some text in that section.

I do want to say that it's also important to understand the threat model here; this revocation mechanism can't stop an issuer that wants to track you from tracking you. Instead, issuers may choose to use it properly because they don't want to track you and probably also want you to know that. IOW, this technology doesn't stop an issuer from being "evil"; its a tool for issuers that want to respect your privacy -- which is also good for the ecosystem on the whole as it drives other issuers to offer the same guarantees in order to compete.

[iherman]

The issue was discussed in a meeting on 2023-01-31

• no resolutions were taken

View the transcript

2.2. Preventing multiple single-credential status lists per issuer (issue vc-status-list-2021#6)

See github issue vc-status-list-2021#6.

Orie Steele: I think this is trying to get at bad issuers..
… They can track with status list if they do a 1:1 mapping -- what can the spec do to prevent issuers from being bad? The spec could mandate that you have a fixed size of the bitstring and spec can direct you to consume indexes randomly and not have new list... but malicious issuer can do whatever they wish..

Michael Prorock: +1 orie - people are bad on the internet sometimes, not sure we can solve it all.

Orie Steele: If you have to trust them for digital signature, they can do many other bad things, I think that's what he's asking about, don't know how much guidance we can place in here. Perhaps we should add something to Security Considerations wrt. things "not to do with the spec"..

Brent Zundel: We can say an evil issuer is non-conformant..

Manu Sporny: yes, agree with orie and brent..
… we can't prevent bad issuers from being evil, we should write about this in security considerations section.
… we have been trying to figure out if its detectable.
… maybe wallets can detect that the issuer has lots of status lists?.
… but it seems like a wallet can't know if this is happening.
… because of the design, its very hard to know if the issuer is evil.
… issuers will be evil, and they will try to do things like this... and its hard for us to detect it... so we should comment on it in sec considerations.

Michael Prorock: evil issuer is gonna support better 3rd party snooping an coordination?.
… there are much easier ways around this for bad actors....

Manu Sporny: truth, mprorock.

Kristina Yasuda: filed: #48.

Andres Uribe: can enforcing the structure of the URL help?.
… perhaps URL structure could help?.

Michael Prorock: see data brokers, and services... they are not going to make it obvious.
… we should provide guidance for honest parties.
… the bad guys will turn around and sell it, without leaving a trace in the open.

[msporny]

Addressed by PR #57, closing.