Original text:
a verifiable credential for authentication.  The attacker creates a phishing website which will in real time capture log-in QR Codes from the original website and present these to the user.  The attacker <del> tries to get the user to use the phishing website using an e-mail campaign etc.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </del>  4.3.10.

Reviewer comments:
Adressing feedback in issue
NAME
Feedback from Dean Saxe on WGLC Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? URL
Fixed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know. Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes

Revised text:
a verifiable credential for authentication.  The attacker creates a phishing website which will in real time capture log-in QR Codes from the original website and present these to the user.  The attacker  <ins> tries to get the user to use the phishing website by sending messages by e-mail or other messaging technologies.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </ins> 4.3.10.