jiebi/TextFlow huggingface dataset:
Original text:
6.1.16. <del> The user MAY be asked to verify if they initiated an authentication </del>  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 Consumption Device to confirm the request.  If the request was

Reviewer comments:
Added reference to the mitigation when describing .
NAME I made one editorial change. If your OK with it, I will merge.
Ok for me, thanks! NAME

Revised text:
6.1.16.  <ins> The user MAY be asked to confirm if they initiated an authentication </ins> 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 Consumption Device to confirm the request.  If the request was
Original text:
process of being standardized that share these characteristics include:  5. The unauthenticated channel between the initiating device and the

Reviewer comments:
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

Revised text:
process of being standardized that share these characteristics include: <ins> Cross-device protocols should not be used for same-device scenarios. If the initiating device and authorization device is the same device protocols like OpenID Connect Core OpenID.Core and OAuth 2.0 Authorization Code Grant as defined in RFC6749 are more appropriate. </ins> 5. The unauthenticated channel between the initiating device and the
Original 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>  5.2.2.

Reviewer comments:
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

Revised 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-  <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.
Original 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>  5.2.3.

Reviewer comments:
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

Revised 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  <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.
Original 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>  5.2.2.2.

Reviewer comments:
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.

Revised text:
5.2.2.1.  <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.
Original text:
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

Reviewer comments:
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

Revised 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
Original text:
5.1.13.  The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When

Reviewer comments:
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

Revised 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
Original text:
of the credentials and after completing the onboarding process, their account is activated.  3. The benefits of cross-device flows is compelling and is seeing

Reviewer comments:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Revised 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
Original text:
3.7.  3.8. In all of the attack scenarios listed above, a user is tricked or

Reviewer comments:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Revised 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
Original 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>  5.1.15.

Reviewer comments:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Revised text:
5.1.14.  <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.
Original text:
[2] #Unique Codes [3] #Content Filtering 

Reviewer comments:
Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.

Revised 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>
Original text:
displays a message to the attacker with instructions on how to access their account.  4. Cross-device flows that are subject to the attacks described earlier,

Reviewer comments:
Accepted proposed text to clarify that this document does not cover cases where the user is colluding with an attacker.

Revised 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,
Original 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>  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>  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>  The Authorization Server may choose to authenticate the user before sending the access code.  The access code may be delivered as a text

Reviewer comments:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Revised text:
2.1.  <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.  <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.  <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
Original text:
[3] #Content Filtering <del> [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 (Hybrid Pattern) </del>  <del> [7] #Example B7: Illicit session transfer (Hybrid Pattern) </del>  <del> [8] #Example A5: Add a device to a network (Hybrid) </del>  <del> [9] #Example A7: Transfer a session (Hybrid) </del> 

Reviewer comments:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Revised text:
[3] #Content Filtering  <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)  <ins> [6] #Example B5: Illicit Network Join (User-Transferred Authorization Data Pattern) </ins>  <ins> [7] #Example B7: Illicit session transfer (User-Transferred Authorization Data Pattern) </ins>  <ins> [8] #Example A5: Add a device to a network (User-Transferred Authorization Data Pattern) </ins>  <ins> [9] #Example A7: Transfer a session (User-Transferred Authorization Data Pattern) </ins>
Original 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>  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.

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:
2.2.  <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.
Original text:
3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del>  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>  resulting in an authorization request presented to the user without context of why or who triggered the request.

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:
3.2.  <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  <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.