Code change:
11.1. <ins> Unlinkability is a property whereby adversaries are prevented from correlating credential presentations of the same user beyond the user's consent.  Without unlinkability, an adversary might be able to learn more about the user than the user intended to disclose, for example: The following types of unlinkability are considered here: In all cases, unlinkability is limited to cases where the disclosed claims do not contain information that directly or indirectly identifies the user.  For example, when a taxpayer identification number is contained in the disclosed claims, the Issuer and Verifier can easily link the user's transactions.  However, when the user only discloses a birthdate to one Verifier and a postal code to another Verifier, the two Verifiers should not be able to determine that they were interacting with the same user. Issuer/Verifier unlinkability with a colluding or compromised Verifier cannot be achieved in salted-hash based selective disclosure approaches, such as SD-JWT, as the issued credential with the Issuer's signature is directly presented to the Verifier, who can forward it to the Issuer. In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamic between Issuers and Verifiers.  This dynamic can compel an otherwise honest Verifier into collusion.  For example, a governmental Issuer might have the authority to mandate that a Verifier report back information about the credentials presented to it.  Legal requirements could further enforce this, explicitly undermining Issuer/Verifier unlinkability. Similarly, a large service provider issuing credentials might implicitly pressure Verifiers into collusion by incentivizing participation in their larger ecosystem.  Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as possible, and/or make the risks transparent to the End-User. Contrary to that, Issuer/Verifier unlinkability with an honest Verifier can generally be achieved.  However, a callback from the Verifier to the Issuer, such as a revocation check, could potentially disclose information about the credential's usage to the Issuer. Where such callbacks are necessary, they MUST be executed in a manner that preserves privacy and does not disclose details about the credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel. Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding keys and salts MUST be used for each credential in the batch to ensure that the Verifiers cannot link the credentials using these values.  Likewise, claims carrying time information, like , , and , MUST either be randomized within a time period considered appropriate (e.g., randomize within the last 24 hours and calculate accordingly) or rounded (e.g., rounded down to the beginning of the day). 11.2. </ins> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition