Original text:
6.1. <del> The Issuer is using the following input JWT Claims Set: </del>  <del> The Issuer in this case made the following decisions: </del>  The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del>  <del> The payload is then signed by the Issuer to create the following JWT: </del>  <del> The following is the issued SD-JWT: </del>  6.2.

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:
6.1.  <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins>  <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT:  <ins> The respective Disclosures are created by the Issuer: </ins>  <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins>  <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.