jiebi/TextFlow huggingface dataset:
Original text:
the credentials are presented, the original session from the attackers device is authorized with the user's credentials. <del> 3.4.9. </del>  In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding

Reviewer comments:
See issue
There are two new attacks, the consent bombing and fake helpdesk attacks, that may be added as examples of attacks, or as extensions of existing attacks.
After discussing ith Daniel we agreeed: Add an example for the consent bombing attacks Add a sub-attack to example B.4 (split into two attacks).

Revised text:
the credentials are presented, the original session from the attackers device is authorized with the user's credentials.  <ins> 3.4.10. </ins> In all of the attack scenarios listed above, a user is misled or exploited.  For other attacks, where the user is willingly colluding
Original text:
phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow. <del> Starting with an authenticated flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] 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 [8] and Example A7: Transfer a session [9]. </del>  5.1.16.

Reviewer comments:
Alternative name for authenticated flow (see )
Can we find a better name for the "Authenticated Flow" mitigation?
Additional authentication on consumption device Initial authentication on consumption device Authenticate before initiating cross-device flow. Authenticate on consumption device before initiating cross-device flow. Cross-Device Flow with previous authentication Authenticate before initiating cross-device flow.
Thanks, approved with minor editorial changes

Revised text:
phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow.  <ins> Authenticating on the Consumption Device before starting a cross- device flow does not prevent the attacks described in Example B5: Illicit Network Join [6] and Example B7: Illicit Session Transfer [7] 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 [8] and Example A7: Transfer a session [9]. </ins> 5.1.16.
Original text:
The Device Authorization Grant (RFC8628) is an example of a cross- device flow that relies on the user copying information from the <del> Consumption Device to the Authorization Device.  The figure below shows a typical example of this flow: </del>  2.1.2.

Reviewer comments:
See issue
Closing issue
Add reference to VC presenation specs in section 4 and section 2.2.1
Only adding references to section 4. Adding this in section 2.2.1 will be confusing, even though a QR code is being scanned in these protocols, unlike device code flow, the session does not revert back to the consumption device.
Addressed in PR
Looks good to me, one small editorial change.

Revised text:
The Device Authorization Grant (RFC8628) is an example of a cross- device flow that relies on the user copying information from the  <ins> Consumption Device to the Authorization Device by either entering data manually or scanning a QR code.  The figure below shows a typical example of this flow: </ins> 2.1.2.
Original text:
Protocol flows that span multiple end-user devices are in widespread use today.  These flows are often referred to as cross-device flows. A common example is a user that uses their mobile phone to scan a QR <del> code from their SmartTV, giving an app on the TV access to their </del>  video streaming service.  Besides QR codes, other mechanisms are often used such as PIN codes that the user has to enter on one of the devices, or push notifications to a mobile app that the user has to

Reviewer comments:
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >

Revised text:
Protocol flows that span multiple end-user devices are in widespread use today.  These flows are often referred to as cross-device flows. A common example is a user that uses their mobile phone to scan a QR  <ins> code from their smart TV, giving an app on the TV access to their </ins> video streaming service.  Besides QR codes, other mechanisms are often used such as PIN codes that the user has to enter on one of the devices, or push notifications to a mobile app that the user has to
Original text:
3. Cross-device flows allow a user to start a flow on one device (e.g., <del> a SmartTV) and then transfer the session to continue it on a second </del>  device (e.g., a mobile phone).  The second device may be used to access the service that was running on the first device, or to perform an action such as authenticating or granting authorization

Reviewer comments:
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >

Revised text:
3. Cross-device flows allow a user to start a flow on one device (e.g.,  <ins> a smart TV) and then transfer the session to continue it on a second </ins> device (e.g., a mobile phone).  The second device may be used to access the service that was running on the first device, or to perform an action such as authenticating or granting authorization
Original text:
4.1.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the Consumption Device (e.g., Smart TV) </del>  which is then scanned or entered on the Authorization Device (the 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

Reviewer comments:
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >

Revised text:
4.1.1. A common action in cross-device flows is to present the user with a  <ins> QR code or a user code on the Consumption Device (e.g., smart TV) </ins> which is then scanned or entered on the Authorization Device (the 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
Original text:
Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service <del> (e.g., a personal computer, Smart TV, Kiosk) to request the OpenID </del>  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

Reviewer comments:
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >

Revised text:
Client Initiated Back-Channel Authentication (CIBA) CIBA: A standard developed in the OpenID Foundation that allows a device or service  <ins> (e.g., a personal computer, smart TV, Kiosk) to request the OpenID </ins> 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
Original text:
FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant RFC6749 and PKCE RFC7663, to grant authorization to an Consumption <del> Device (e.g., Smart TV or interactive whiteboard) using a mobile </del>  phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device

Reviewer comments:
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >

Revised text:
FIDO credential is not available on the consumption device.  It MAY be used as an authentication method with the Authorization Code Grant RFC6749 and PKCE RFC7663, to grant authorization to an Consumption  <ins> Device (e.g., smart TV or interactive whiteboard) using a mobile </ins> phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device
Original text:
6.2.3.3. <del> Both the Consumption Device and the authenticator require BLE support.  The Consumption Device must support both FIDO2/WebAuthn, specifically CTAP 2.2 with hybrid transport CTAP22Draft.  The mobile phone must support CTAP 2.2 or greater to be used as a cross-device authenticator. </del>  6.2.3.4.

Reviewer comments:
Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME

Revised text:
6.2.3.3.  <ins> Both the Consumption Device and the authenticator require BLE support and access to the internet.  The Consumption Device must support both FIDO2/WebAuthn, specifically CTAP 2.2 with hybrid transports CTAP22Draft.  The device serving as the FIDO authenticator must support CTAP 2.2 or later to be used as a cross-device authenticator. </ins> 6.2.3.4.
Original text:
FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable <del> FIDO credential is not available on the consumption device.  It MAY </del>  be used as an authentication method with the Authorization Code Grant <del> RFC6749 and PKCE RFC7663, to grant authorization to an Consumption Device (e.g., smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </del>  6.2.4.

Reviewer comments:
Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME

Revised text:
FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable  <ins> FIDO credential is not available on the Consumption Device.  It MAY </ins> be used as an authentication method with the Authorization Code Grant  <ins> RFC6749 and PKCE RFC7663, to grant authorization to a Consumption Device (e.g., smart TV or interactive whiteboard) using a device serving as the FIDO authenticator (e.g. a mobile phone) for authentication.  This combination of FIDO2/WebAuthn and Authorization Code Flow with PKCE enables cross device authorization flows, without the risks posed by the Device Authorization Grant RFC8628. </ins> 6.2.4.
Original text:
These flows typically involve using a mobile phone to scan a QR code or enter a user code displayed on the first device (e.g., Smart TV, <del> Kiosk, Personal Computer etc.). </del>  3.1.

Reviewer comments:
See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.

Revised text:
These flows typically involve using a mobile phone to scan a QR code or enter a user code displayed on the first device (e.g., Smart TV,  <ins> Kiosk, Personal Computer or other electronic devices.). </ins> 3.1.
Original text:
Attackers exploit the unauthenticated channel by changing the context of the user code or QR code and then sending a message to a user <del> (e-mail, text, instant messaging etc).  By deploying content 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 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 authorization to access restricted resources. </del>  Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g., retries).  To prevent the disruption of

Reviewer comments:
See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.

Revised text:
Attackers exploit the unauthenticated channel by changing the context of the user code or QR code and then sending a message to a user  <ins> (e-mail, text messaging, instant messaging or other communication mechanisms).  By deploying content 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 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 authorization to access restricted resources. </ins> Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g., retries).  To prevent the disruption of
Original text:
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 <del> communications systems and channels (e-mail, messaging, text etc), </del>  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.

Reviewer comments:
See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.

Revised text:
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  <ins> communications systems and communication channels (e-mail, text messaging, instant messaging or other communication mechanisms), </ins> 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.