jiebi/TextFlow huggingface dataset:
Original text:
possession sender constrained token is presented without valid proof of possession of the cryptographic key, it MUST be rejected. <del> 9.4.1. </del>  DPoP is an application-level mechanism for sender-constraining OAuth RFC6749 access and refresh tokens I-D.ietf-oauth-dpop.  If DPoP is

Reviewer comments:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Revised text:
possession sender constrained token is presented without valid proof of possession of the cryptographic key, it MUST be rejected.  <ins> 9.5.1. </ins> DPoP is an application-level mechanism for sender-constraining OAuth RFC6749 access and refresh tokens I-D.ietf-oauth-dpop.  If DPoP is
Original text:
Server MUST reject the request (do we need to define a specific error code for that?). <del> 9.4.2. </del>  It may be possible to use other proof of possession mechanisms to sender constrain access and refresh tokens.  Defining these mechanisms are out of scope for this specification. <del> 9.4.3. </del>  PoP binding of device session parameter <del> 9.5. </del>  When there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below. <del> 9.5.1. </del>  Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking <del> experiences.  When multiple native applications are support, the </del>  implementation MUST ensure the native experience is identical across all the 1st party native applications.

Reviewer comments:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Revised text:
Server MUST reject the request (do we need to define a specific error code for that?).  <ins> 9.5.2. </ins> It may be possible to use other proof of possession mechanisms to sender constrain access and refresh tokens.  Defining these mechanisms are out of scope for this specification.  <ins> 9.5.3. </ins> PoP binding of device session parameter  <ins> 9.6. </ins> When there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below.  <ins> 9.6.1. </ins> Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking  <ins> experiences.  When multiple native applications are supported, the </ins> implementation MUST ensure the native experience is identical across all the 1st party native applications.
Original text:
will not complete the authentication experience for the 1st party native application. <del> 9.5.2. </del>  In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses. <del> 9.5.3. </del>  To address these risk, when multiple 1st party native applications must be supported, and other methods such as OpenID.Native-SSO are

Reviewer comments:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Revised text:
will not complete the authentication experience for the 1st party native application.  <ins> 9.6.2. </ins> In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses.  <ins> 9.6.3. </ins> To address these risk, when multiple 1st party native applications must be supported, and other methods such as OpenID.Native-SSO are
Original text:
5.2.2.  If the request contains invalid parameters or incorrect data, the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following

Reviewer comments:
Added option for redirecting to the web. Notes: Re-using the PAR response - feels strange to have the "request_uri" parameter as the redirect URI - is that OK? Added and example of redirecting to the web. Not entirely sure how control gets passed back to the "native" app/client or how much detail we should provide.
I see the problem with the current text. In PAR, the response is a which represents the PAR request itself: The client is expected to then start an authorization request and put the value in the query string parameter: So the text in this section should instead be:

Revised text:
5.2.2. <ins> In the case where the authorization server wishes to interact with the user directly, it can return the "redirect" response.  The authorization server may choose to interact directly with the user based on a risk assesment, the introduction of a new authentication method not supported in the application, or to handle an exception flow like account recovery.  In this case the client is expected to initiate a traditional OAuth Authorization Code flow with PKCE according to RFC6749 and RFC7636. 5.2.3. </ins> If the request contains invalid parameters or incorrect data, the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following
Original text:
whether that is to do an MFA flow, or perform an OAuth redirect-based flow.  5.1. The client makes a request to the authorization challenge endpoint by

Reviewer comments:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Revised text:
whether that is to do an MFA flow, or perform an OAuth redirect-based flow. <ins> In order to preserve the security of this specification, the Authorization Server MUST verify the "first-partyness" of the client before continuing with the authentication flow.  Please see first- party-applications for additional considerations. </ins> 5.1. The client makes a request to the authorization challenge endpoint by
Original text:
5.2. The authorization server determines whether the information provided <del> up to this point is sufficient to issue an authorization code, and responds with an authorization code or an error message. </del>  5.2.1.

Reviewer comments:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Revised text:
5.2. The authorization server determines whether the information provided  <ins> up to this point is sufficient to issue an authorization code, and if so responds with an authorization code.  If the information is not sufficient for issuing an authorization code, then the authorization server MUST respond with an error response. </ins> 5.2.1.
Original text:
code (unless specified otherwise) and includes the following parameters with the response:  The parameters are included in the content of the HTTP response using the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each

Reviewer comments:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Revised text:
code (unless specified otherwise) and includes the following parameters with the response: <ins> This specification requires the authorization server to define new error codes that relate to the actions the client must take in order to properly authenticate the user.  These new error codes are specific to the authorization server's implementation of this specification and are intentionally left out of scope. </ins> The parameters are included in the content of the HTTP response using the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each
Original text:
vary. The authorization server MAY define additional parameters in the <del> response depending on the implmentation. </del>  5.3.

Reviewer comments:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Revised text:
vary. The authorization server MAY define additional parameters in the  <ins> response depending on the implmentation.  The authorization server MAY also define more specific content types for the error responses as long as the response is JSON and conforms to "application/<as- defined>+json". </ins> 5.3.
Original text:
applications and to ensure the user experience is identical for all first-party apps.  10. IANA has (TBD) registered the following values in the IANA "OAuth

Reviewer comments:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Revised text:
applications and to ensure the user experience is identical for all first-party apps. <ins> 9.7. Single Page Applications (SPA) run inside the context of a browser instance.  Due to the inability to securely attest to the first- partyness of a browser based application, it is NOT RECOMMENDED to use this specification in a browser-based application. </ins> 10. IANA has (TBD) registered the following values in the IANA "OAuth
Original text:
server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del>  If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client

Reviewer comments:
Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in

Revised text:
server. The "auth_session" value is completely opaque to the client, and as  <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client
Original text:
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response.  See auth-session-security for additional security considerations. 6.

Reviewer comments:
Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in

Revised text:
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.