msporny
commented
8 months ago We went with a SHOULD because there are some populations where randomization might not matter. For example, corporations in a particular locality -- it's public information, you know exactly how big the set size should be, and whether or not a certain license for a corporation is revoked is often a matter of public knowledge.
The argument was made that we should just ratchet up the privacy characteristics with a MUST, but the implementers (at the time) felt like that was too overbearing. Implementers are either going to do a good job with ensuring their allocations happen in a privacy preserving manner, or they're not, and a MUST would require us to write a conformance test, which would require us to issue a VC for every item in the list and then determine if the allocation was "random enough". As you can imagine, testing this would take a long time across the 15+ issuance implementations we have today (and the implementers complained about eating that much compute/network time just to prove conformance with a W3C test suite).
In short, it's not a MUST today, because if we make it a MUST, we have to test it, and the only way to really test this is to exhaust a statistically significant portion of a status list, which would create a burden on implementers during testing that they were not willing to bear.
I think the most we can do here is document, in the privacy considerations section, that it is vital for implementers to ensure the randomization of the status list entries in such a way as to reduce or eliminate what a recipient could infer from the index.
The spec requires that the status list index SHOULD be randomized. I can see that there may be alternatives, but there could be a MUST requirement for the unpredictability/intelligence-free nature of the index: it must not be something that a recipient could infer, or where the index reveals something about the credential (like its recency, etc.).