jiebi/TextFlow huggingface dataset:
Original text:
filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or <del> user codes that are being reused in multiple messages to disrupt spray attacks. Content filtering may be better suited to interrupt large scale spray attacks since some scenarios may require re-transmission of user, QR and access codes.  Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </del>  5.1.6.

Reviewer comments:
Instead of referencing spray attacks, describe how they work (see )
Instead of referring to spray attacks, describe how an attacker might use the same QR or user code by sending it to the different recipients.

Revised text:
filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or  <ins> user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authroization to access restricted resources. Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g. retries).  To prevent the disruption of legitimate scenarios, content filters may use a threshold and allow a limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </ins> 5.1.6.
Original text:
attacker gathers a large number of access and refresh tokens on a single device and then sells them for profit more difficult, since the attacker would also have to export the cryptographic keys used to <del> sender constrain the tokens or be able to access them and generate </del>  signatures for future use.  If the attack is being executed on a trusted device to a device with anti-malware, any attempts to exfiltrate tokens or keys may be detected and the device's trust <del> status may be changed.  Using hardware keys for sender constraining </del>  tokens will further reduce the ability of the attacker to move tokens to another device. Sender-constrained tokens, especially sender-constrained tokens that require proof-of-posession, raise the bar for executing the attack <del> and and profiting from exfiltrating tokens.  The quality of key protection has an impact on the effectiveness of the attack. Although a software proof-of-posession key is better than no proof- of-posession key, an attacker may still exfiltrate the software key. Hardware keys will be harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise they key, even if it is in hardware, thus the main protection derived from sender constrianed tokens is preventing them from being moved from the Initiating Device to another device that can be used to profit from the attack. </del>  5.1.13.

Reviewer comments:
Consistently hypheante and clarify section on sender constrained tokens
consistently hyphenate sender-constrained tokens. Clarify limitations.
One typo from earlier.

Revised text:
attacker gathers a large number of access and refresh tokens on a single device and then sells them for profit more difficult, since the attacker would also have to export the cryptographic keys used to  <ins> sender-constrain the tokens or be able to access them and generate </ins> signatures for future use.  If the attack is being executed on a trusted device to a device with anti-malware, any attempts to exfiltrate tokens or keys may be detected and the device's trust  <ins> status may be changed.  Using hardware keys for sender-constraining </ins> tokens will further reduce the ability of the attacker to move tokens to another device. Sender-constrained tokens, especially sender-constrained tokens that require proof-of-posession, raise the bar for executing the attack  <ins> and profiting from exfiltrating tokens.  Although a software proof- of-posession key is better than no proof-of-posession key, an attacker may still exfiltrate the software key.  Hardware keys are harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise the key, even if it is in hardware. Consequently the main protection derived from sender-constrained tokens is preventing tokens from being moved from the Initiating Device to another device, thereby making it harder sell stolen tokens and profit from the attack. </ins> 5.1.13.
Original text:
The unauthenticated channel between the Initiating Device and Authorization Device allows attackers to obtain a QR code or user <del> code in one location and display in another location.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users across the globe.  There are a couple of ways to establish proximity: </del>  Depending on the risk profile and the threat model in which a system is operating, it may be necessary to use more than one mechanism to

Reviewer comments:
See
I have trouble explaining why scanning a QR code is dangerous to initialize authentication flows to gain access because sometimes it is less dangerous. When using a device which is close proximity to the second device and forcing this through a protocol, the danger is reduced. I think introducing a new wording context would help (especially if this was used in the corresponding protocols, for example FIDO2 passkeys) Near device A device which is in close proximity to the second device and uses a protocol which forces a close proximity communication channel for the authentication steps. Cross device A device which communicates to a separate device and uses a protocol which does not force proximity to the second device. Then it would be easy to explain attacks and mitigations: Using a near device communication, the attack X is not possible etc. Not sure this is the right place to add this, but it would help I think.
That's and interesting idea. To me it is more about cross-device protocol properties. Some of them have strong proximity assurance properties, and some don't. Perhaps terminology like "proximity verified cross-device flows" or "proximity enforced cross device flows" vs "proximity-less cross device flows" works better? It is also somewhat protocol neutral.
I like these two: "proximity enforced cross device flows" vs "proximity-less cross device flows"
Let me think about how to work that terminology into the text at the right places.

Revised text:
The unauthenticated channel between the Initiating Device and Authorization Device allows attackers to obtain a QR code or user  <ins> code in one location and display it in another location. Consequently, proximity-enforced cross-device flows are more resistant to Cross-Device Consent Phishing attacks than proximity- less cross-device flows.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users that are geographically distributed.  There are a couple of ways to establish proximity: </ins> Depending on the risk profile and the threat model in which a system is operating, it may be necessary to use more than one mechanism to
Original text:
the user in order to convince them to grant authorization on the Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating <del> Device and the Authorizing Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </del>  3.1.

Reviewer comments:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Revised text:
the user in order to convince them to grant authorization on the Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating  <ins> Device and the Authorization Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.
Original text:
It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device <del> (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </del>  Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by

Reviewer comments:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Revised text:
It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device  <ins> (e.g., smart TV) and the Authorization Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by
Original text:
5.2.2.3. There is no requirement on the Initiating Device to support specific <del> hardware.  The authorizing device must be registered/associated with the user and it must be possible for the Authorization Server to </del>  trigger an authorization on this device. 5.2.2.4.

Reviewer comments:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Revised text:
5.2.2.3. There is no requirement on the Initiating Device to support specific  <ins> hardware.  The Authorization Device must be registered/associated with the user and it must be possible for the Authorization Server to </ins> trigger an authorization on this device. 5.2.2.4.
Original text:
The popularity of cross-device flows attracted the attention of attackers that exploit the unauthenticated channel between the <del> Initiating Device and Authorizing Device using techniques commonly </del>  used in phishing attacks.  These Cross-Device Consent Phishing (CDCP) attacks allow attackers to obtain access and refresh tokens, rather than authentication credentials, resulting in access to resources

Reviewer comments:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Revised text:
The popularity of cross-device flows attracted the attention of attackers that exploit the unauthenticated channel between the  <ins> Initiating Device and Authorization Device using techniques commonly </ins> used in phishing attacks.  These Cross-Device Consent Phishing (CDCP) attacks allow attackers to obtain access and refresh tokens, rather than authentication credentials, resulting in access to resources
Original text:
5.1.13.  The user experience SHOULD preserve the context within which the protocols were initiated and communicate this clearly to the user when they are asked to authorize, authenticate or present a

Reviewer comments:
Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.

Revised text:
5.1.13. <ins> Research shows that user education is effective in reducing the risk of phishing attacks Baki2023.  The service provider MAY educate users on the risks of cross-device consent phishing and provide out-of-band reinforcement to the user on the context and conditions under which an authorization grant may be requested.  For example, if the service provider does not send e-mails with QR codes requesting users to grant authorization, this may be reinforced in marketing messages and anti-fraud awareness campaigns.  The service provider MAY also choose to reinforce these user education messages through in-app experiences. Although user education helps to raise awareness and reduce the overall risk to users, it is insufficient on its own to mitigate cross-device consent phishing attacks.  In particular, carefully designed phishing attacks can be practically indistinguishable from benign authorization flows even for well-trained users.  User education SHOULD therefore be used in conjunction with other controls described in this document. 5.1.14. </ins> The user experience SHOULD preserve the context within which the protocols were initiated and communicate this clearly to the user when they are asked to authorize, authenticate or present a
Original text:
default option or given similar prominence in the user experience as the "grant" option.  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> The service may provide out-of-band reinforcement to the user on the context and conditions under which an authorization grant may be requested.  For example if the service provider does not send e-mails with QR codes requesting users to grant authorization, this may be reinforced in marketing messages, in-app experiences and through anti-fraud awareness campaigns. </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. <del> 5.1.14. </del>  By requiring a user to authenticate on the Initiating Device with a phishing resistant authentication method before initiating a cross-

Reviewer comments:
Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.

Revised text:
default option or given similar prominence in the user experience as the "grant" option. <ins> 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. </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").  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.  <ins> 5.1.15. </ins> By requiring a user to authenticate on the Initiating Device with a phishing resistant authentication method before initiating a cross-
Original text:
flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9]. <del> 5.1.15. </del>  The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or

Reviewer comments:
Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.

Revised text:
flows are used in scenarios such as Example A5: Add a device to a network [8] and Example A7: Transfer a session [9].  <ins> 5.1.16. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or
Original text:
message that unless the user initiated the authorization request, or was expecting it, they should decline the request.  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

Reviewer comments:
Incorporating feedback based on
Follows . (CC NAME User Experience (extension) During potentially dangerous operations (e.g., reading the QR code on the Authorizing Device), advise users to verify the trustworthiness of the source, for instance by checking that the connection is protected through TLS or by verifying that the URL really belongs to the Authorization Server. In particular, when activating the camera to read the QR code on the Authorizing Device, the activity could also display a warning message advising users to only scan QR codes displayed on a specific website. Limitations: those already reported in the mitigation
After discussing with Daniel, this is very close to the recommendations on user education. We will review that addition and incorporate the recommendation to add warning messages when scanning a QR code, if it is not sufficiently clear already.

Revised text:
message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <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 which circumstances they should never scan a QR code (e.g. display a message that the QR code will only be displayed on kiosks within trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). </ins> 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
Original text:
5.1.16.  The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When

Reviewer comments:
Added "Request Initiation Verification" as an additional mitigation based on issue
Follows . (CC NAME OTP Verification In the User-Transferred Session Data Pattern and Backchannel-Transferred Session Pattern, before authorizing the attempt, the Authorizing Device could display an OTP to be inserted back in the Initiating Device. In case the QR code or the push notification was generated without the users' consent, they would not have performed any action on the Initiating Device, and therefore they would not know where to insert the OTP they received. Limitations: Attackers could deceive users into revealing the OTP through other means (e.g., via email) and use it to finalize the authorization process; the additional step could reduce the usability level of the protocol. Effect on attacks (Table 1): .
Discussed with Daniel and proposal is to include as an additional mitigation and position this as part of the user authentication (i.e. not a protocol extension). It makes it harder to scale attacks, as the attacker has to find a way to recover the PIN as well.
Fix typo on "Authorization Device"

Revised text:
5.1.16. <ins> The user MAY be asked to verify if they initiated an authentication or authorization request by sending a one-time password (OTP) or PIN to the user's Authorization Device and asking them to enter it on the Initiating Device to confirm the request.  If the request was initiated without the users' consent, they would receive an OTP or PIN out of context which may raise suspicion for the user.  In addition, they would not have information on where to enter the OTP or PIN.  The user experience on the Authorization Device MAY reinforce the risk of receiving an out-of-context OTP or PIN and provide information to the user on how to report an unauthorized authentication or authorization request. The additional verification step may reduce the overall usability of the system as it is one more thing users need to do right.  Attackers may combine traditional phishing attacks and target users who respond to those messages with an interactive attack that sets the expectation with the user that they will have to provide the OTP or PIN, in addition to granting authorization for the request. 5.1.17. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When