jiebi/CodeConvo huggingface dataset:
Code change:
Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph

Related discussion:
text: due to device or system constraints.  Avoid using if the protected resources are sensitive, high value or business critical.  Always deploy additional mitigations like proximity or only allow with pre- <del> registered devices. </del> <ins> registered devices.  Do not use for same-device scenarios (e.g. if the initiating device and authorization device is the same device). </ins> 5.2.2.
Code change:
Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph

Related discussion:
text: the initiating device to obtain a user identifier on the initiating device (e.g., through an input or selection mechanism) and if the Authorization Server can trigger an authorization on the <del> authorization device. </del> <ins> authorization device.  Do not use for same-device scenarios (e.g. if the initiating device and authorization device is the same device). </ins> 5.2.3.
Code change:
Added clarification that CIBA is not a standard under development, but was completed in September 2021 and added references to the completed standard.
Refer back to issue
Thanks for that bit of historic context Brian. I will remove those references.
Thanks NAME and NAME - I also added you to the acknowledgment section.

Related discussion:
text: 5.2.2.1. <del> A standard under development as part of the Financial-grade API (FAPI) family of standards that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device. </del> <ins> Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID Provider to initiate an authentication flow if it knows a valid identifier for the user.  The user completes the authentication flow using a second device (e.g., a mobile phone).  In this flow the user does not scan a QR code or obtain a user code from the initiating device, but is instead contacted by the OpenID Provider to complete the authentication using a push notification, e-mail, text message or any other suitable mechanism. </ins> 5.2.2.2.
Code change:
fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien

Related discussion:
text: 3.7. <ins> 3.8. </ins> In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding with the attacker, the security implications and potential
Code change:
fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien

Related discussion:
text: 5.1.13. <ins> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. 5.1.14. </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:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Related discussion:
text: of the credentials and after completing the onboarding process, their account is activated. <ins> 2.7. An employee is signed into an application on their personal computer and wants to bootstrap the mobile application on their mobile phone. The employee initiates the cross-device flow and is shown a QR code in their application.  The employee launches the mobile application on their phone and scans the QR code which results in the user being signed into the application on the mobile phone. </ins> 3. The benefits of cross-device flows is compelling and is seeing
Code change:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Related discussion:
text: 3.7. <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 typically used to transfer a session.  The employee, eager to assist, initiates the process to transfer a session.  They authenticate and obtain a QR code and then 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.8. In all of the attack scenarios listed above, a user is tricked or
Code change:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Related discussion:
text: 5.1.14. <del> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. </del> <ins> By requiring a user to authenticate on the initiating device with a phishing resistant authentication method before initiating a cross- device flow, the server can prevent an attacker from initiating a cross-device flow and obtaining QR codes or user codes.  This prevents the attacker from obtaining a QR code or user code that they can use to mislead an unsuspecting user.  This requires that the initiating device has sufficient input capabilities to support a phishing resistant authentication mechanism.  Note that this does not prevent the attacks described in Example B5: Illicit Network Join [4] and Example B7: Illicit Session Transfer [5] and it is recommended that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as Example A5: Add a device to a network [6] and Example A7: Transfer a session [7]. </ins> 5.1.15.
Code change:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Related discussion:
text: [2] #Unique Codes [3] #Content Filtering <ins> [4] #Example B5: Illicit Network Join [5] #Example B7: Illicit Session Transfer [6] ##Example A5: Add a device to a network [7] #Example A7: Transfer a session </ins>
Code change:
Accepted proposed text to clarify that this document does not cover cases where the user is colluding with an attacker.

Related discussion:
text: displays a message to the attacker with instructions on how to access their account. <ins> 3.7. In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on his device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. This document therefore only considers scenarios where a user does not collude with an attacker. </ins> 4. Cross-device flows that are subject to the attacks described earlier,
Code change:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Related discussion:
text: 2.1. <del> An example of a cross-device flow that relies on the user copying information from the Initiating Device to the Authorization Device is shown below: The Device Authorization Grant (RFC8628) follows this pattern. </del> <ins> The Device Authorization Grant (RFC8628)is an example of a cross- 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: </ins> 2.2. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization on the user's authorization device via the backchannel. </del> <ins> The Client Initiated Backchannel Authentication CIBA transfers the session on the backchannel with the Authroization Server to request authorization on the Authroization Device.  The figure below shows an example of this flow. </ins> The Authorization Server may use a variety of mechanisms to request 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. The Client Initiated Backchannel Authentication CIBA follows this pattern. 2.3. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization request via the backchannel. </del> <ins> Examples of the user-transferred authorization data pattern includes flows in which the Initiating Device requests the Authorization Server to send a one time access code (e.g. as a text message or e-mail) to the Authorization Device.  Once the Authroization Device receives the code, the user enters it on the Initiating Device.  The Initiatng Device presents it back to the Authroization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </ins> The Authorization Server may choose to authenticate the user before sending the access code.  The access code may be delivered as a text
Code change:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Related discussion:
text: 3.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the initiating device (e.g., Smart TV) which is then scanned or entered on the authorization device (the </del> <ins> QR code or a user code on the Initiating Device (e.g., Smart TV) which is then scanned or entered on the Authorization Device (the </ins> mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider. <del> It is up to the user's judgment to decide on whether they can 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 (smart TV) and the device on which the authentication/ authorization will take place (the mobile phone). </del> <ins> 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 (e.g., smart TV) and the Authorizing 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 initiating the authorization flows).  They then use social engineering techniques to change the context in which authorization is requested to trick end-users to scan the QR code or enter it on <del> their mobile devices.  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </del> <ins> their Authorization Device (e.g., mobile phone).  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </ins> 3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.
Code change:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Related discussion:
text: [3] #Content Filtering <del> [4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern) </del> <ins> [4] #Example B1: Illicit access to a video streaming service (User- Transferred Session Data Pattern) </ins> [5] #Example B4: Illicit Transaction Authorization (Client Transferred Pattern) <del> [6] #Example B5: Illicit Network Join (Hybrid Pattern) </del> <ins> [6] #Example B5: Illicit Network Join (User-Transferred Authorization Data Pattern) </ins> <del> [7] #Example B7: Illicit session transfer (Hybrid Pattern) </del> <ins> [7] #Example B7: Illicit session transfer (User-Transferred Authorization Data Pattern) </ins> <del> [8] #Example A5: Add a device to a network (Hybrid) </del> <ins> [8] #Example A5: Add a device to a network (User-Transferred Authorization Data Pattern) </ins> <del> [9] #Example A7: Transfer a session (Hybrid) </del> <ins> [9] #Example A7: Transfer a session (User-Transferred Authorization Data Pattern) </ins>
Code change:
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

Related discussion:
text: 2.2. <del> The figure below shows an example of the client requesting the authorization server to initiate an authorization on the user's authorization device via the backchannel. </del> <ins> The Client Initiated Backchannel Authentication CIBA transfers the session on the backchannel with the Authroization Server to request authorization on the Authroization Device.  The figure below shows an example of this flow. </ins> The Authorization Server may use a variety of mechanisms to request 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. The Client Initiated Backchannel Authentication CIBA follows this pattern.
Code change:
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

Related discussion:
text: 3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del> <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del> <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.
Code change:
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

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

Related discussion:
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> <ins> [5] #Example B4: Illicit Transaction Authorization (Backchannel Transferred Session Pattern) </ins> [6] #Example B5: Illicit Network Join (User Transferred Authorization Data Pattern)