jiebi/TextFlow huggingface dataset:
Original text:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB.  7. Being JSON, an object in an SD-JWT payload MAY contain name/value

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:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value
Original text:
claim is treated as an object in the Disclosure. <del> The Issuer would create the following Disclosure: </del>  7.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:
claim is treated as an object in the Disclosure.  <ins> The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT: </ins> 7.2.
Original text:
signatures on them can no longer be trusted to originate from the Issuer. <del> 11.2. </del>  If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the

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:
signatures on them can no longer be trusted to originate from the Issuer.  <ins> 11.3. </ins> If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the
Original text:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. <del> 11.3. </del>  The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

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:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE.  <ins> 11.4. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing
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:
resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name

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.
Original text:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB.  7. Being JSON, an object in an SD-JWT payload MAY contain name/value

Reviewer comments:
resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name

Revised text:
have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB. <ins> After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> 7. Being JSON, an object in an SD-JWT payload MAY contain name/value
Original text:
claim is treated as an object in the Disclosure. <del> The Issuer would create the following Disclosure: </del>  7.2.

Reviewer comments:
resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name

Revised text:
claim is treated as an object in the Disclosure.  <ins> The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT: </ins> 7.2.
Original text:
signatures on them can no longer be trusted to originate from the Issuer. <del> 11.2. </del>  If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the

Reviewer comments:
Despite or maybe in light of some recentish discussion on the mailing list, the topic seems like it deserves more prominent placement.

Revised text:
signatures on them can no longer be trusted to originate from the Issuer.  <ins> 11.3. </ins> If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the
Original text:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. <del> 11.3. </del>  The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Reviewer comments:
Despite or maybe in light of some recentish discussion on the mailing list, the topic seems like it deserves more prominent placement.

Revised text:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE.  <ins> 11.4. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing
Original text:
It may be sufficient to store the result of the verification and any End-User data that is needed for the application. <del> If reliable and secure key rotation and revocation is ensured according to issuer_signature_key_distribution, Issuers may opt to publish expired or revoked private signing keys (after a grace period that ensures that the keys are not cached any longer at any Verifier).  This reduces the value of any leaked credentials as the signatures on them can no longer be trusted to originate from the Issuer. </del> 11.3. If the SD-JWT is transmitted over an insecure channel during issuance

Reviewer comments:
to
As far as I know, the idea of burning private keys to facilitate repudiation or reduced data value didn't resonate with any of the audiences for whom it was intended. I think the document would be better off without the paragraph copied below from URL And we might avoid some potentially difficult/confusing/painful/etc conversations in various latter stage IETF process steps.
I'm told that my statement that it "didn't resonate with any of the audiences for whom it was intended" might be premature.
I agree with deleting the text about publishing private keys. Yes, it's a technique that could be used with SD-JWTs but it's in no way specific to SD-JWTs. It could be used with normal JWTs, CWTs, SAML tokens, X.509 certs, etc. It doesn't add to the specification to describe this here.
leaving this open with no action for the time being because, as Dr. NAME says, "it's complicated".
agreed to remove.

Revised text:
It may be sufficient to store the result of the verification and any End-User data that is needed for the application.  11.3. If the SD-JWT is transmitted over an insecure channel during issuance
Original text:
The following payload is used for the SD-JWT: <del> The respective Disclosures are created by the Issuer: </del>  The payload is then signed by the Issuer to create the following Issuer-signed JWT:

Reviewer comments:
URL and I don't know why my response isn't on the mail archive yet but here's a copy: !
oh hey that's fun:
sadness addressed in 9b7ad2d010e0f49e3dd8b5833c59fe4642e2892b (on the surface anyway)
isn't part of this duplicate of ?
Yeah, I did it here first just to fix things. Then decided fixing the build process should be decoupled from addressing one more of Mike's previous review comments.
Now overcome by events. I'm going to resurrect exactly one of my previous review comments that was not addressed. The original comment was: Issuance: There are many places from here on where the label "SHA-256 Hash" is used, for instance "SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4". Change all of these to "Base64url-Encoded SHA-256 Hash" for correctness. Brian responded "The current wording might not be as descriptive as you'd like but it is correct." I'll water down my request if you're not willing to change all the occurrences to "Base64url-Encoded SHA-256 Hash" to then please at least add a textual caveat before the first such occurrence along the lines of: In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". As I said in my initial review, I look forward to this specification being published as an RFC. Best wishes, -- Mike From: Rifaat Shekh-Yusef Sent: Tuesday, September 3, 2024 3:39 AM To: oauth Subject: [OAUTH-WG] WGLC for SD-JWT All, As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by Sep 17th. Regards, Rifaat & Hannes

Revised text:
The following payload is used for the SD-JWT:  <ins> The respective Disclosures, created by the Issuer, are listed below. In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:". </ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT:
Original text:
For example, the base64url-encoded SHA-256 digest of the Disclosure <del> would be </del>  <del> . The base64url-encoded SHA-256 digest of the Disclosure would be </del>  .

Reviewer comments:
URL
Danke! Thanks Neil, That is indeed an error. Thanks for catching that. We'll get it fixed. I see how that other part is a bit confusing too and will look at improving how those pieces flow together. And also maybe fix some other stuff in that area while we're at it, like inadequate salt length in at least one of the disclosures in 5.2.3. On Wed, Sep 4, 2024 at 9:17 AM Neil Madden wrote: CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Revised text:
For example, the base64url-encoded SHA-256 digest of the Disclosure  <ins> for the </ins>  <ins> claim from disclosures_for_object_properties above is </ins> .
Original text:
method does not matter as long as it does not depend on the original order of elements. <del> For example, using the digest of the object property Disclosure created above, the Issuer could create the following SD-JWT payload to make </del>  selectively disclosable:

Reviewer comments:
URL
Danke! Thanks Neil, That is indeed an error. Thanks for catching that. We'll get it fixed. I see how that other part is a bit confusing too and will look at improving how those pieces flow together. And also maybe fix some other stuff in that area while we're at it, like inadequate salt length in at least one of the disclosures in 5.2.3. On Wed, Sep 4, 2024 at 9:17 AM Neil Madden wrote: CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Revised text:
method does not matter as long as it does not depend on the original order of elements.  <ins> For example, using the digest of the Disclosure from hashing_disclosures, the Issuer could create the following SD-JWT payload to make </ins> selectively disclosable:
Original text:
The same digest value MUST NOT appear more than once in the SD-JWT. <del> Applications of SD-JWT SHOULD be explicitly typed using the header parameter.  See explicit_typing for more details. </del>  It is the Issuer who decides which claims are selectively disclosable and which are not.  End-User claims MAY be included as plaintext as

Reviewer comments:
From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Revised text:
The same digest value MUST NOT appear more than once in the SD-JWT.  <ins> Application and profiles of SD-JWT SHOULD be explicitly typed.  See explicit_typing for more details. </ins> It is the Issuer who decides which claims are selectively disclosable and which are not.  End-User claims MAY be included as plaintext as