jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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> <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.
Code change:
Corrected typo (related to )
In the first sentence of section 3.3 you say "authorizations" instead of "authorization"

Related discussion:
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> <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
Code change:
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!

Related discussion:
text: 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 <del> initiating device (e.g., Smart TV, Kiosk, Personal Computer etc). </del> <ins> Initiating Device (e.g., Smart TV, Kiosk, Personal Computer etc). </ins> The channel between the Initiating Device and the Authorization Device is unauthenticated and relies on the user's judgment to decide whether to trust a QR code, user code, or the authorization request pushed to their authorization device. <del> Several publications have emerged in the public domain (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6), describing how the unauthenticated channel can be exploited using social engineering techniques borrowed from phishing.  Unlike traditional phishing attacks, these attacks don't harvest credentials.  Instead, they skip the step of collecting credentials by persuading users to grant authorization using their Authorization Devices. </del> <ins> Cross-Device Consent Phishing (CDCP) attacks exploit the unauthenticated channel between the Initiating Device and Authorization Device using social engineering techniques to to gain unauthorized access to the victims data.  Several publications have emerged in the public domain (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6), describing how the unauthenticated channel can be exploited using social engineering techniques borrowed from phishing.  Unlike traditional phishing attacks, these attacks don't harvest credentials.  Instead, they skip the step of collecting credentials by persuading users to grant authorization using their Authorization Devices. </ins> Once the user grants authorization, the attacker has access to the user's resources and in some cases is able to collect access and
Code change:
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!

Related discussion:
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> <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 <del> are also known as illicit consent grant attacks. </del> <ins> are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.
Code change:
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!

Related discussion:
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> <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.
Code change:
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!

Related discussion:
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> <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 <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> <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 <del> attack, disrupts attacks when in process or reduces the impact of a </del> <ins> attack, disrupts attacks in progress or reduces the impact of a </ins> successful attack. 5.1.1.
Code change:
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!

Related discussion:
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> <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.
Code change:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Related discussion:
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> <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
Code change:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Related discussion:
text: 5.1.8. <del> An attacker can be prevented from initiating a cross device flow </del> <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
Code change:
See issue
Closing issue
Hyphenate all uses of cross device (e.g. cross-device).

Related discussion:
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> <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 <del> protection against attacks on the unauthenticated channel for cross </del> <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
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
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> <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
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
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> <ins> to a streaming service) on the Initiating Device. </ins> Cross-device flows have several benefits, including:
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
text: 2.1. <del> The Device Authorization Grant (RFC8628)is an example of a cross- </del> <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:
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
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.
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
text: In cross-device flows that follow the user-transferred authorization data pattern, the client on the Initiating Device initiates the authorization request, but the user still has to transfer the <del> authorization code to the Initiating Device.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </del> <ins> authorization data to the Initiating Device.  The authorization data may take different forms, including a numerical value such as a 6 digit authorization code.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </ins> Attackers exploit the user-transferred authorization data pattern by combining the social engineering techniques used to set context for <del> users and tricking users into providing them with access codes sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </del> <ins> users and tricking users into providing them with authorization data sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </ins> authorization request to be sent to the user directly by the Authorization Server. The unauthenticated channel may also be exploited in variations of <del> the above scenario where the user (as opposed tot he attacker) initiates the flow and is then tricked into sending the authorization data (e.g. access code) to the attacker.  In these flows, the user is already authenticated and they request authroization data to transfer </del> <ins> the above scenario where the user (as opposed to the attacker) initiates the flow and is then convinced using social engineering techniques into sending the authorization data (e.g. a 6 digit authorization code) to the attacker.  In these flows, the user is already authenticated and they request authorization data to transfer </ins> a session or obtain some other privilege such as joining a device to <del> a network.  The authorization data may be represented as a QR code o text message.  The attacker then proceeds to exploit the </del> <ins> a network.  The authorization data may be represented as a QR code or authorization code.  The attacker then proceeds to exploit the </ins> unauthenticated channel by using social engineering techniques to <del> trick the user into initiating a flow and send the QR code or user code to the attacker, which the attacker use to obtain the privileges </del> <ins> convince the user to send the QR code or user code to the attacker. The attacker then use the authroization data to obtain the privileges </ins> that would have been assigned to the user. 3.4.
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
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> <ins> defence against cross-device attacks. </ins> 5.1.12.
Code change:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Related discussion:
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> <ins> protection against attacks on the unauthenticated channel for cross </ins> 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> <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