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

Related discussion:
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> <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.
Code change:
Consistently hypheante and clarify section on sender constrained tokens
consistently hyphenate sender-constrained tokens. Clarify limitations.
One typo from earlier.

Related discussion:
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> <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 <del> status may be changed.  Using hardware keys for sender constraining </del> <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 <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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Related discussion:
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> <ins> Device and the Authorization Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.
Code change:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Related discussion:
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> <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
Code change:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

Related discussion:
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> <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.
Code change:
The "Authorization Device" was sometimes referred to as "Authorizing Device".
NAME Looks good to me, please merge if you approve as well.
Agreed.

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

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

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

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

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

Related discussion:
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
Code change:
I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.

Related discussion:
text: Abstract This document extends the OAuth 2.0 Authorization Framework RFC6749 <del> with new grant types to support first-party native applications that want to control the user experience of the process of obtaining authorization from the user. </del> <ins> with a new endpoint "authorization_challenge_endpoint" to support first-party native applications that want to control the process of obtaining authorization from the user using a native experience. </ins> In many cases, this can provide an entirely browserless experience suited for native applications, only delegating to the browser in
Code change:
I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.

Related discussion:
text: 1.2. <del> TODO If the service provides multiple applications, then it creates an additional burden to build and maintain native login flows within each application.  Instead, the redirect-based authorization code flow removes the burden of implementing login flows from each application by centralizing all aspects of logging in at the authorization server. See phishing section below. </del> <ins> It's important to remember that the scope of this specification is limited to 1st party native applications.  Please review the entirety of security-considerations and when more than one 1st party native application is supported, multiple-applications. </ins> 2.