jiebi/TextFlow huggingface dataset:
Original text:
However, an XSS attack would still result in the attacker being able to initiate a new OAuth flow, and/or unregister the Service Worker. <del> 6.3.3. </del>  To limit the risk of token exfiltration:

Reviewer comments:
I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.

Revised text:
However, an XSS attack would still result in the attacker being able to initiate a new OAuth flow, and/or unregister the Service Worker.  <ins> 6.4.3. </ins> To limit the risk of token exfiltration:
Original text:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above.  10. This document does not require any IANA actions.

Reviewer comments:
As discussed on the OSW, this PR adds a small section with security considerations on the use of (a.k.a. "web messaging") to this draft. It makes reference to , which already discusses the security implications of in-browser communication flows in detail. Since (silent) iframe flows and popup flows are especially used in browser-based apps, we think that it makes sense to include security considerations of their in-browser communication into this draft. Please let us know what you think about this. We appreciate any feedback.
Sounds good to me, thanks!

Revised text:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <ins> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </ins> 10. This document does not require any IANA actions.
Original text:
6.3.2.4.2.  Browser-based applications MUST prevent CSRF attacks against their redirect URI.  This can be accomplished by any of the below:

Reviewer comments:
The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.

Revised text:
6.3.2.4.2. <ins> In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. 6.3.2.4.3. </ins> Browser-based applications MUST prevent CSRF attacks against their redirect URI.  This can be accomplished by any of the below:
Original text:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <del> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run hidden iframe-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </del> 10. This document does not require any IANA actions.

Reviewer comments:
The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.

Revised text:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above.  10. This document does not require any IANA actions.
Original text:
The token-mediating backend pattern is more lightweight than the BFF pattern (See pattern-bff), since it does not require the proxying of <del> all requests to a resource server, which improves latency and significantly simplifies deployment.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </del>  If an attacker is able to execute malicious code within the JavaScript application, the application architecture is able to

Reviewer comments:
This PR offers an alternative to . Compared to PR it makes two changes: I removed the newly added text to avoid creating confusion between the responsibilities of a BFF. While it is technically possible to deploy a BFF as part of an API gateway, I believe this suggestion may create confusion for someone trying to grasp the pattern. An API Gateway is closely linked to an API, while a BFF is (in theory) closely linked to a frontend. Reworded the benefits of the Token Mediating Backend to more accurately represent the advantages/disadvantages of the pattern, as correctly suggested by this PR If this PR is merged, can be closed.

Revised text:
The token-mediating backend pattern is more lightweight than the BFF pattern (See pattern-bff), since it does not require the proxying of  <ins> all requests and responses between the JavaScript application and the resource server.  From a security perspective, the token-mediating backend is less secure than a BFF, but still offers significant advantages over an OAuth client application running directly in the browser. </ins> If an attacker is able to execute malicious code within the JavaScript application, the application architecture is able to
Original text:
The code in the browser initiates the authorization code flow with the PKCE extension (described in authorization_code_flow) (B) above, and obtains an access token via a POST request (C).  The JavaScript <del> app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs. </del>  When the JavaScript application in the browser wants to make a <del> request to the Resource Server, it can include the access token in the request (D) and make the request directly. </del>  In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to

Reviewer comments:
Arrow C is referenced in the text "[The code in the browser] obtains an access token via a POST request (C).". The arrow should have an arrowhead on both ends as it symbolizes both the token request and token response. "The JavaScript app is then responsible for storing the access token (and optional refresh token) securely using appropriate browser APIs." I think this sentence was misleading, because as of today there is no way for the app to store tokens securely in the browser. Arrow E was not referenced in the text.

Revised text:
The code in the browser initiates the authorization code flow with the PKCE extension (described in authorization_code_flow) (B) above, and obtains an access token via a POST request (C).  The JavaScript  <ins> application is then responsible for storing the access token (and optional refresh token) as securely as possible using appropriate browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </ins> When the JavaScript application in the browser wants to make a  <ins> request to the Resource Server, it can interact with the Resource Server directly.  It includes the access token in the request (D) and receives the Resource Server's response (E). </ins> In this scenario, the Authorization Server and Resource Server MUST support the necessary CORS headers to enable the JavaScript code to
Original text:
described in this document.  By restricting the protocol to only be executed on devices trusted by the authorization server, it prevents attackers from using arbitrary devices, or by mimicking devices to <del> initiate the protocol.  Trusted devices include devices that are pre- registered with the authorization server or are subject to device management policies.  Device management policies may enforce </del>  patching, version updates, on-device anti-malware deployment, revocation status and device location amongst others.  Trusted <del> devices may have their identities rooted in hardware (e.g., a TPM or equivalent technology).  By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </del>  An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to

Reviewer comments:
Refined the trusted device section to make it clear that restricting to a specific device type is another option to limit the impact of deploying cross-device flows (issue )
Limit it to specific devices.

Revised text:
described in this document.  By restricting the protocol to only be executed on devices trusted by the authorization server, it prevents attackers from using arbitrary devices, or by mimicking devices to  <ins> initiate the protocol. Authorization Servers MAY use different mechanisms to establish which devices it trusts.  This includes limiting cross-device flows to specific device types such as intractive whiteboards or smart TVs, pre-registering devices with the authorization server or only allow cross-device flows on devices managed through device management systems.  Device management systems may enforce policies that govern </ins> patching, version updates, on-device anti-malware deployment, revocation status and device location amongst others.  Trusted  <ins> devices MAY have their identities rooted in hardware (e.g., a TPM or equivalent technology). By only allowing trusted devices to initiate cross-device flows, it requires the attacker to have access to such a device and maintain access in a way that does not result in the device's trust status from being revoked. </ins> An attacker may still be able to obtain access to a trusted device and use it to initiate authorization requests, making it necessary to
Original text:
credential.  In preserving the context, it should be clear to the user who invoked the flow, why it was invoked and what the consequence of completing the authorization, authentication or <del> credential presentation is.  The user experience should reinforce the </del>  message that unless the user initiated the authorization request, or was expecting it, they should decline the request.  If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under

Reviewer comments:
Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.

Revised text:
credential.  In preserving the context, it should be clear to the user who invoked the flow, why it was invoked and what the consequence of completing the authorization, authentication or  <ins> credential presentation is.  The user experience SHOULD reinforce the </ins> message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> This information MAY be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under
Original text:
trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). <del> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as the "grant" option. </del> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. <del> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.

Reviewer comments:
Moved paragraphs to improve the flow of the section. Removed references to User Education (which is now a mitigation itself, so all the details are already in the ad hoc section). Fix case for keywords should and may.

Revised text:
trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations).  The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested.  Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document.
Original text:
it in the CAD application, after which the CAD application displays the user's most recent designs.  3. Attackers exploit cross-device flows by initiating an authorization

Reviewer comments:
Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.

Revised text:
it in the CAD application, after which the CAD application displays the user's most recent designs. <ins> 2.4.9. A network administrator wants to access an adminstration portal used to configure network assets and deploy new applications.  When attempting to access the service, the network administrator receives a notification in an app on their mobile device, requesting them to confirm access to the portal.  The network administrator approves the request on their mobile phone and is granted access to the portal. </ins> 3. Attackers exploit cross-device flows by initiating an authorization
Original text:
3.4.10.  In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications and

Reviewer comments:
Added an example described at OSW 2023 (see issue )
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).
Approved with editorial changes.

Revised text:
3.4.10. <ins> An attacker attempts to access an adminstration portal repeatedly, generating a stream of authorization requests to the network administrator.  The attempts are timed to occur while the administrator is asleep.  The administrator is woken by the incoming requests on their phone, and, in an attempt to stop the notifications, they accidentally approve access and the attacker gains access to the portal. 3.4.11. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding with the attacker, the threat model, security implications and
Original text:
3.4.5.  An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code

Reviewer comments:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Revised text:
3.4.5. <ins> An attacker obtains the contact information for a user and contacts them, pretending to be a representative of the user's financial institution.  The attacker informs the user that there were a number of fraudulent transactions against their account and asks them to review these transactions by approving or rejecting them.  The attacker then triggers a sequence of transactions.  The user receives an authorization request for each transaction and declines them as they do not recognize them.  The attacker then informs the user that they need to close the users account and transfer all the funds to a new account to prevent further fraudulent transactions.  The user receives another authorization request which they approve, or provide additional authorization information to the attacker which enables the attacker to complete their attack and defraud the user. 3.4.6. </ins> An attacker creates a message to all employees of a company, claiming to be from a trusted technology provider investigating a suspected security breach.  They ask employees to send them the QR code
Original text:
access as an entry point and perform lateral moves to obtain additional privileges and access to restricted resources. <del> 3.4.6. </del>  An attacker initiates an employee onboarding flow and obtains a QR code from the onboarding portal to invoke a digital wallet and

Reviewer comments:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Revised text:
access as an entry point and perform lateral moves to obtain additional privileges and access to restricted resources.  <ins> 3.4.7. </ins> An attacker initiates an employee onboarding flow and obtains a QR code from the onboarding portal to invoke a digital wallet and
Original text:
to obtain the QR code displays a message to the attacker with instructions on how to access their account. <del> 3.4.7. </del>  An attacker creates a message to all employees of a company, claiming to be from the company's IT service provider.  They claim that they

Reviewer comments:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Revised text:
to obtain the QR code displays a message to the attacker with instructions on how to access their account.  <ins> 3.4.8. </ins> An attacker creates a message to all employees of a company, claiming to be from the company's IT service provider.  They claim that they
Original text:
send the QR code to the attacker.  The attacker scans the QR code with their mobile phone and access the users data and resources. <del> 3.4.8. </del>  An attacker wants to use some website which requires presentation of a verifiable credential for authentication.  The attacker creates a

Reviewer comments:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Revised text:
send the QR code to the attacker.  The attacker scans the QR code with their mobile phone and access the users data and resources.  <ins> 3.4.9. </ins> An attacker wants to use some website which requires presentation of a verifiable credential for authentication.  The attacker creates a