Code change:
Examples of the user-transferred authorization data pattern include flows in which the Consumption Device requests the Authorization Server to send authorization data (e.g., a 6 digit authorization code <del> in a text message or e-mail) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization Server for validation before gaining access to the user's resources.  The figure below shows an example of this flow. </del> <ins> in a text message, e-mail or mobile application) to the Authorization Device.  Once the Authorization Device receives the authorization data, the user enters it on the Consumption Device.  The Consumption Device sends the authorization data back to the Authorization 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 <del> sending the authorization data.  The authorization data may be delivered as a text message or through a mobile application. </del> <ins> sending the authorization data. </ins> 3.2.

Related discussion:
text: Addresses issue NAME
WCLC Feedback from Dean Saxe 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. URL
addressed in
lgtm 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.