jiebi/TextFlow huggingface dataset:
Original text:
or <del> parameter as defined in OIDC. </del>  Those extensions will make it possible to implement interoperable step up authentication with minimal work from resource servers,

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
or  <ins> authorization request parameters as defined in OIDC. </ins> Those extensions will make it possible to implement interoperable step up authentication with minimal work from resource servers,
Original text:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  2. The following is an end-to-end sequence of a typical step-up

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "client", "protected resource", and "resource server" defined by The OAuth 2.0 Authorization Framework RFC6749. </ins> 2. The following is an end-to-end sequence of a typical step-up
Original text:
This specification introduces a new error code value for the <del> parameter of RFC6750 or authentication schemes, such as I-D.ietf- oauth-dpop, which use the </del>  parameter:

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
This specification introduces a new error code value for the  <ins> parameter of the challenge of the authentication scheme from RFC6750 and other OAuth authentication schemes, such as I-D.ietf-oauth-dpop, which use the same </ins> parameter:
Original text:
deploying and publishing such requirements) is out of scope for this document. <del> Furthermore, this specification defines additional </del>  <del> auth-param values to convey the authentication requirements back to the client. </del>  acr-challenge below is an example of a  header using the error code value to inform the client that the access token presented

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
deploying and publishing such requirements) is out of scope for this document.  <ins> Furthermore, this specification defines the following </ins>  <ins> auth-param values for those OAuth authentication schemes to convey the authentication requirements back to the client. </ins> acr-challenge below is an example of a <ins> authentication scheme challenge with the </ins> header using the error code value to inform the client that the access token presented
Original text:
4. <del> A client receiving an authorization error from the resource server carrying the error code </del>  SHOULD parse the

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
4.  <ins> A client receiving a challenge from the resource server carrying the error code </ins> SHOULD parse the
Original text:
and and use them, if present, in constructing an authorization request, <del> which is then conveyed to the authorization server via the user agent in order to obtain a new access token complying with the corresponding requirements.  Both </del>  and

Reviewer comments:
changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
and and use them, if present, in constructing an authorization request,  <ins> which is then conveyed to the authorization server's authorization endpoint via the user agent in order to obtain a new access token complying with the corresponding requirements.  Both </ins> and
Original text:
to frequent prompts, hence a suboptimal user experience, if reused for routine operations.  In those scenarios, the client would be better served by keeping both the old tokens, associated with a lower <del> authentication level, and the new one- selecting the appropriate </del>  token for each API call.  This is not a new requirement for clients, as incremental consent and least privilege principles will require similar heuristics for managing access tokens associated to different

Reviewer comments:
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL

Revised text:
to frequent prompts, hence a suboptimal user experience, if reused for routine operations.  In those scenarios, the client would be better served by keeping both the old tokens, associated with a lower  <ins> authentication level, and the new one - selecting the appropriate </ins> token for each API call.  This is not a new requirement for clients, as incremental consent and least privilege principles will require similar heuristics for managing access tokens associated to different
Original text:
. <del> Subsequent to the challenge in age-challenge, a client might direct the user agent to the following example authorization request URI where the </del>  parameter indicates to the authorization server that the user authentication event needs to have occurred no more than five seconds

Reviewer comments:
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL

Revised text:
.  <ins> After the challenge in age-challenge, a client might direct the user agent to the following example authorization request URI where the </ins> parameter indicates to the authorization server that the user authentication event needs to have occurred no more than five seconds
Original text:
6. To evaluate whether an access token meets the protected resource's <del> requirements, the resource servers needs a way of accessing </del>  information about the authentication event by which that access token was obtained.  This specification provides guidance on how to convey that information in conjunction with two common access token

Reviewer comments:
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL

Revised text:
6. To evaluate whether an access token meets the protected resource's  <ins> requirements, the resource server needs a way of accessing </ins> information about the authentication event by which that access token was obtained.  This specification provides guidance on how to convey that information in conjunction with two common access token
Original text:
impose requirements that are impossible for users to comply with, or leading to an undesirable user experience outcome.  The authentication prompts presented by the authorization server as a <del> result of the requirements propagation method described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </del>  9.

Reviewer comments:
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL

Revised text:
impose requirements that are impossible for users to comply with, or leading to an undesirable user experience outcome.  The authentication prompts presented by the authorization server as a  <ins> result of the method of propagating authentication requirements described here might require the user to perform some specific actions such as using multiple devices, having access to devices complying with specific security requirements, and so on.  Those extra requirements, concerning more about how to comply with a particular requirement rather than indicating the identifier of the requirement itself, are out of scope for this specification. </ins> 9.
Original text:
attacks.  Implementers should use care in determining what to disclose in the challenge and in what circumstances.  The logic examining the incoming access token to determine whether a challenge <del> should be returned can execute either before or after the traditional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token. However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </del>  As this specification provides a mechanism for the resource server to trigger user interaction, it's important for the authorization server

Reviewer comments:
updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL

Revised text:
attacks.  Implementers should use care in determining what to disclose in the challenge and in what circumstances.  The logic examining the incoming access token to determine whether a challenge  <ins> should be returned can execute either before or after the conventional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token.  However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </ins> As this specification provides a mechanism for the resource server to trigger user interaction, it's important for the authorization server