Code change:
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 <del> 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. </del> <ins> requests.  This malicious behaviour could be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes. </ins> 10.3. <del> Once the Verifier gets the Referenced Token, this enables him to </del> <ins> Once the Relying Party gets the Referenced Token, this enables him to </ins> request the Status List to validate the status of the Token through the provided "uri" property and look up the corresponding "index". <del> 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. </del> <ins> However, the Relying Party 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 Relying Party 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. <del> 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. </del> <ins> Colluding Issuers and Relying Parties have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. </ins> <del> 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. </del> <ins> To avoid privacy risks for colluding Relying Parties, it is recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Relying Parties.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation lateron. </ins> To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to:

Related discussion:
text: Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology