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

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

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

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

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

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

Related discussion:
text: user authentication using asymmetric cryptography that can be invoked from a web browser or native client.  Version 2.2 of the FIDO Client to Authenticator Protocol (CTAP) supports a new cross-device <del> authentication protocol, called "hybrid", which enables an external device, such as a phone or tablet, to be used as a roaming </del> <ins> authentication protocol, called "hybrid transports", which enables an external device, such as a phone or tablet, to be used as a roaming </ins> authenticator for signing into the primary device, such as a personal computer.  This is commonly called FIDO Cross-Device Authentication <del> (CDA). </del> <ins> (CDA).  CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms. </ins> When a user wants to authenticate using their mobile device (authenticator) for the first time, they need to link their authenticator to their main device.  This is done using a scan of a QR code.  When the authenticator scans the QR code, the device sends an encrypted BLE advertisement containing keying material and a <del> tunnel ID.  The main device and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </del> <ins> tunnel ID.  The main device (CTAP client) and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </ins> If the user chooses to keep their authenticator linked with the main device, the QR code link step is not necessary for subsequent use.
Code change:
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

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

Related discussion:
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> <ins> FIDO credential is not available on the Consumption Device.  It MAY </ins> 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> <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.
Code change:
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.

Related discussion:
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> <ins> Kiosk, Personal Computer or other electronic devices.). </ins> 3.1.
Code change:
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.

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

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

Related discussion:
text: 6.1.16. <del> The user MAY be asked to verify if they initiated an authentication </del> <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
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: 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