jiebi/TextFlow huggingface dataset:
Original text:
techniques to prime the user for an authorization request and thereby trick them into granting authorization.  The social engineering techniques range in sophistication from messages misrepresenting the <del> reason for receiving an authorization request to triggering a large </del>  volume of requests at an inconvenient time for the user, in the hope that the user will grant authorization to make the requests stop. The figure below shows an example of such an attack.

Reviewer comments:
Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a

Revised text:
techniques to prime the user for an authorization request and thereby trick them into granting authorization.  The social engineering techniques range in sophistication from messages misrepresenting the  <ins> reason for receiving an authorization request, to triggering a large </ins> volume of requests at an inconvenient time for the user, in the hope that the user will grant authorization to make the requests stop. The figure below shows an example of such an attack.
Original text:
[4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern) <del> [5] #Example B4: Illicit Transaction Authorization (Client Transferred Pattern) </del>  [6] #Example B5: Illicit Network Join (User Transferred Authorization Data Pattern)

Reviewer comments:
Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a

Revised text:
[4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern)  <ins> [5] #Example B4: Illicit Transaction Authorization (Backchannel Transferred Session Pattern) </ins> [6] #Example B5: Illicit Network Join (User Transferred Authorization Data Pattern)
Original text:
that this is the third time that they have been notified and their last opportunity to prevent deletion of their work files.  One or more employees respond by following the URL, entering the code and <del> performing multi-factor authentication.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens. These tokens may be exfiltrated and sold to third parties. </del>  3.4.3.

Reviewer comments:
Included feedback based on
Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script. While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.

Revised text:
that this is the third time that they have been notified and their last opportunity to prevent deletion of their work files.  One or more employees respond by following the URL, entering the code and  <ins> performing multi-factor authentication.  Throughout the authentication experience, the user is interacting with a trusted user experience, re-enforcing the legitimacy of the request.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens.  These tokens may be exfiltrated and sold to third parties. </ins> 3.4.3.
Original text:
protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated Backchannel Authentication (CIBA) provides an alternative, provided <del> that there is a channel through which the authorizations server can </del>  contact the end user.  Examples of such a channel include device push notifications, e-mail or text messages which the user can access from their device.  If CIBA is used, additional mitigations to enforce

Reviewer comments:
Corrected typo (related to )
In the first sentence of section 3.3 you say "authorizations" instead of "authorization"

Revised text:
protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated Backchannel Authentication (CIBA) provides an alternative, provided  <ins> that there is a channel through which the authorization server can </ins> contact the end user.  Examples of such a channel include device push notifications, e-mail or text messages which the user can access from their device.  If CIBA is used, additional mitigations to enforce
Original text:
Attackers exploit cross-device flows by initiating an authorization flow on the Initiating Device and then use social engineering techniques to change the context in which the request is presented to <del> the user in order to trick them into granting authorization on the </del>  Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating Device and the Authorizing Device is unauthenticated.  These attacks <del> are also known as illicit consent grant attacks. </del>  3.1.

Reviewer comments:
Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!

Revised text:
Attackers exploit cross-device flows by initiating an authorization flow on the Initiating Device and then use social engineering techniques to change the context in which the request is presented to  <ins> the user in order to convince them to grant authorization on the </ins> Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating Device and the Authorizing Device is unauthenticated.  These attacks  <ins> are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.
Original text:
In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding <del> with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. </del>  This document only considers scenarios where a user does not collude with an attacker.

Reviewer comments:
Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!

Revised text:
In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding  <ins> with the attacker, the threat model, security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to circumvent proximity checks. </ins> This document only considers scenarios where a user does not collude with an attacker.
Original text:
equipped to authenticate the channel between the two devices. Mitigations should focus on: <del> To achieve the above outcomes, mitigating the exploits of cross- device flows require a three-pronged approach: </del>  5.1. A number of protocols that enable cross-device flows that are <del> susceptible to illicit consent grant attacks are already deployed. The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </del>  It is recommended that one or more of the mitigations are applied whenever implementing a cross-device flow.  Every mitigation provides an additional layer of security that makes it harder to initiate the <del> attack, disrupts attacks when in process or reduces the impact of a </del>  successful attack. 5.1.1.

Reviewer comments:
Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!

Revised text:
equipped to authenticate the channel between the two devices. Mitigations should focus on:  <ins> To achieve the above outcomes, mitigating against Cross-Device Consent Phishing attacks require a three-pronged approach: </ins> 5.1. A number of protocols that enable cross-device flows that are  <ins> susceptible to Cross-Device Consent Phishing attacks are already deployed.  The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </ins> It is recommended that one or more of the mitigations are applied whenever implementing a cross-device flow.  Every mitigation provides an additional layer of security that makes it harder to initiate the  <ins> attack, disrupts attacks in progress or reduces the impact of a </ins> successful attack. 5.1.1.
Original text:
5.2.1.2. There are several reports in the public domain outlining how the <del> unauthenticated channel may be exploited to execute an illicit consent grant attack. </del>  5.2.1.3.

Reviewer comments:
Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!

Revised text:
5.2.1.2. There are several reports in the public domain outlining how the  <ins> unauthenticated channel may be exploited to execute a Cross-Device Consent Phishing attack (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6). </ins> 5.2.1.3.
Original text:
(e.g., a smartphone) to authorize access to a resource (e.g., access to a streaming service). <del> Cross device flows have several benefits, including: </del>  There are three cross-device flow patterns for transferring the authorization request between the Initiating Device to the

Reviewer comments:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Revised text:
(e.g., a smartphone) to authorize access to a resource (e.g., access to a streaming service).  <ins> Cross-device flows have several benefits, including: </ins> There are three cross-device flow patterns for transferring the authorization request between the Initiating Device to the
Original text:
5.1.8. <del> An attacker can be prevented from initiating a cross device flow </del>  protocol by only allowing the protocol to be initiated on a trusted network or within a security perimeter (e.g., a corporate network). A trusted network may be defined as a set of IP addresses and joining

Reviewer comments:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Revised text:
5.1.8.  <ins> An attacker can be prevented from initiating a cross-device flow </ins> protocol by only allowing the protocol to be initiated on a trusted network or within a security perimeter (e.g., a corporate network). A trusted network may be defined as a set of IP addresses and joining
Original text:
RFC6749 and PKCE RFC7663, to grant authorization to an Initiating Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ <del> WebAuthn and Authorization Code Flow with PKCE enables cross device </del>  authorization flows, without the risks posed by the Device Authorization Grant RFC8628. 5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross </del>  device flows.  It can be combined with OAuth 2.0 and OpenID Connect protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated

Reviewer comments:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Revised text:
RFC6749 and PKCE RFC7663, to grant authorization to an Initiating Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/  <ins> WebAuthn and Authorization Code Flow with PKCE enables cross-device </ins> authorization flows, without the risks posed by the Device Authorization Grant RFC8628. 5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best  <ins> protection against attacks on the unauthenticated channel for cross- </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated
Original text:
Cross-device flows enable a user to initiate an authorization flow on one device (the Initiating Device) and then use a second, personally <del> trusted, device (Authorization Device) to authorize access to a resource (e.g., access to a service). </del>  These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
Cross-device flows enable a user to initiate an authorization flow on one device (the Initiating Device) and then use a second, personally  <ins> trusted, device (Authorization Device) to authorize the Initiating Device to access a resource (e.g., access to a service).  The Device Authorization Grant (RFC8628) and Client Initiated Backchannel Authentication CIBA are two examples of popular cross-device flows. </ins> These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an
Original text:
In a cross-device flow, a user starts a scenario on the Initiating Device (e.g., a smart TV) and then uses an Authorization Device (e.g., a smartphone) to authorize access to a resource (e.g., access <del> to a streaming service). </del>  Cross-device flows have several benefits, including:

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
In a cross-device flow, a user starts a scenario on the Initiating Device (e.g., a smart TV) and then uses an Authorization Device (e.g., a smartphone) to authorize access to a resource (e.g., access  <ins> to a streaming service) on the Initiating Device. </ins> Cross-device flows have several benefits, including:
Original text:
2.1. <del> The Device Authorization Grant (RFC8628)is an example of a cross- </del>  device flow that relies on the user copying information from the Initiating Device to the Authorization Device.  The figure below shows a typical example of this flow:

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
2.1.  <ins> The Device Authorization Grant (RFC8628) is an example of a cross- </ins> device flow that relies on the user copying information from the Initiating Device to the Authorization Device.  The figure below shows a typical example of this flow:
Original text:
user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action. <del> The Client Initiated Backchannel Authentication CIBA follows this pattern. </del> 2.3.

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
user authorization, including a push notification to a dedicated app on a mobile phone, or sending a text message with a link to an endpoint where the user can authenticate and authorize an action.  2.3.
Original text:
degrade spray attacks, but do not prevent more targeted attacks that are executed with lower volumes and velocity.  Therefore, it should be used along with other techniques to provide a defence-in-depth <del> against cross-device attacks. </del>  5.1.12.

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
degrade spray attacks, but do not prevent more targeted attacks that are executed with lower volumes and velocity.  Therefore, it should be used along with other techniques to provide a defence-in-depth  <ins> defence against cross-device attacks. </ins> 5.1.12.
Original text:
5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross- </del>  device flows.  It can be combined with OAuth 2.0 and OpenID Connect <del> protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated </del>  Backchannel Authentication (CIBA) provides an alternative, provided that there is a channel through which the authorization server can contact the end user.  Examples of such a channel include device push

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best  <ins> protection against attacks on the unauthenticated channel for cross </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect  <ins> protocols for standards-based authorization and authentication flows. If FIDO2/WebAuthn support is not available, Client Initiated </ins> Backchannel Authentication (CIBA) provides an alternative, provided that there is a channel through which the authorization server can contact the end user.  Examples of such a channel include device push