Original text:
11.1.  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

Reviewer comments:
Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw. 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

Revised text:
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