Comments on section 12.5.1 Unlinkability

[Denisthemalice]

The text states:

12.5.1. Colluding Relying Parties

Two or more colluding Relying Parties may link two transactions involving the same Referenced Token by comparing the status claims of received Referenced Tokens, and therefore determine that they have interacted with the same Holder.

To avoid privacy risks for colluding Relying Parties, it is RECOMMENDED that Issuers use batch issuance to issue multiple Referenced Tokens, see Section 13.1.

"Batch issuance" of Referenced Tokens, does not implies "one-time-use "Referenced Tokens.
Therefore the wording "one-time-use Referenced Tokens" is preferred and used.

Change into:

12.5.1. Colluding Relying Parties

Two or more colluding Relying Parties may link two transactions involving the same Referenced Token by comparing the status claims of received Referenced Tokens, and therefore determine that they have interacted with the same Holder.

To avoid privacy risks for colluding Relying Parties, it is RECOMMENDED that Issuers issue one-time-use Referenced Tokens, see Section 13.1. The status of every one-time-use Referenced Token SHOULD be placed in a Token Status List chosen at random.

After Verification, Relying Parties SHOULD NOT store the Referenced Token. It may be sufficient to store the result of the verification and any user data that is needed for the application.

The text continues with:

To avoid further correlatable information by the values of uri and index, Status Issuers are RECOMMENDED to:

• choose non-sequential, pseudo-random or random indices
• use decoy entries to obfuscate the real number of Referenced Tokens within a Status List
• choose to deploy and utilize multiple Status Lists simultaneously

Because this text is about implementation considerations, it should be removed from section 12.5.1 and placed into section 13 (Implementation Considerations) and more precisely section 13.1 (13.1. Token Lifecycle).

However, while this text has been considered, it has not been reused verbatim. See the text proposals done when considering section 13.1.

[paulbastian]

Editors Call:

• add "one-time usage to batch-issued
• in general, we don't want to talk much about Referenced Token
• if Referenced Token is not needed by the RP, e.g. for audit trail, then RP may remove it, or its status list part, or be aware of the linkable nature of the Referneced Token