Original text:
10.1. <del> TODO elaborate on herd privacy, size of the status list </del>  10.2. <del> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list </del>  10.3. <del> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO elaborate on issuers avoiding sequential usage of indices and status lists TODO elaborate that a status list only gives information about the maximum number of possible statuses that a list conveys, issuers are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms </del>  10.4. <del> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy </del>  10.5.

Reviewer comments:
URL
As described in the title the size of the list (number of token statuses represented by the list) will have a significant impact on privacy related applications.
I see this is related to
Should we define a minimum size or give this as a recommendation in privacy recommendation?
use SHOULD for minimum size 16K

Revised text:
10.1.  <ins> The main privacy consideration for a Status List, especially in the context of the Issuer-Holder-Verifier model, is to prevent the Issuer from tracking the usage of the Referenced Token when the status is being checked.  If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the issued token by correlating the date and identity of Verifiers, that are requesting the status. The Status List approaches these privacy implications by integrating the status information of many Referenced Tokens into the same list. Therefore, the Issuer does not learn for which Referenced Token the Verifier is requesting the Status List.  The privacy of the Holder is protected by the anonymity within the set of Referenced Tokens in the Status List, also called herd privacy.  This limits the possibilities of tracking by the Issuer. The herd privacy is depending on the number of entities within the Status List called its size.  A larger size results in better privacy but also impacts the performance as more data has to be transferred to read the Status List. </ins> 10.2.  <ins> A malicious Issuer could bypass the privacy benefits of the herd privacy by generating a unique Status List for every Referenced Token.  By these means, he could maintain a mapping between Referenced Tokens and Status Lists and thus track the usage of Referenced Tokens by utilizing this mapping for the incoming requests.  This malicious behaviour could be detected by Verifiers that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes. </ins> 10.3.  <ins> Once the Verifier gets the Referenced Token, this enables him to request the Status List to validate the status of the Token through the provided "uri" property and look up the corresponding "index". However, the Verifier may persistently store the "uri" and "index" of the Referenced Token to request the Status List again at a later time.  By doing so regularly, the Verifier may create a profile of the Referenced Token's validity status.  This behaviour may be inteded as a feature, e.g. for a KYC process that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential.  This behaviour could be constrained by adding authorization rules to the Status List, see security-authorization. </ins> 10.4.  <ins> Colluding Issuers and Verifiers have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. To avoid privacy risks for colluding Verifiers, it is recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Verifiers.  In this case, every Referenced Token MUST have a dedicated Status List entry. Revoking batch issued Referenced Tokens might reveal this correlation lateron. To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to: choose non-sequential, pseudo-random or random indices use decoy or dead entries to obfuscate the real number of Referenced Tokens within a Status List choose to deploy and utilize multiple Status Lists simulantaniously </ins> 10.5.