I approve Filip, thanks for consolidating all the inputs.
Deb thanks for the ongoing support and quick turnarounds on decisions. Kaelin, a very big thank you for the detailed review and suggestions to improve the specification. With gratitude. Pieter On Wed, Aug 5, 2026 at 12:18 AM Deb Cooley <[email protected]> wrote: > > The draft itself is much needed (I was skeptical of QR codes, this draft > confirms that). The example was greatly improved! > > Deb > > On Aug 4, 2026, at 6:40 PM, Filip Skokan <[email protected]> wrote: > > > I approve. > > Big thank you! > > S pozdravem, > Filip Skokan > > > On Wed, 5 Aug 2026 at 00:09, Kaelin Foody <[email protected]> wrote: >> >> Hi *Deb and Authors, >> >> *Deb - As AD, please review the changes to Section 4.3.8. and let us know if >> they are approved. >> These changes are viewable in the diff: >> https://www.rfc-editor.org/authors/rfc10027-auth48rfcdiff.html. >> >> >> Authors - Thank you for your reply. We have updated the files accordingly. >> >> Upon careful review, please contact us with any further updates or with your >> approval of the document in its current form. >> We will await approvals from each party listed on the Final Review status >> page for this document prior to moving forward in the publication process. >> >> The Final Review status of your document is available here: >> https://queue.rfc-editor.org/final-review/rfc10027 >> >> — FILES (please refresh): — >> >> The updated files have been posted here: >> https://www.rfc-editor.org/authors/rfc10027.txt >> https://www.rfc-editor.org/authors/rfc10027.pdf >> https://www.rfc-editor.org/authors/rfc10027.html >> https://www.rfc-editor.org/authors/rfc10027.xml >> >> Diff files showing changes made during Final Review: >> https://www.rfc-editor.org/authors/rfc10027-auth48diff.html >> https://www.rfc-editor.org/authors/rfc10027-auth48rfcdiff.html (side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc10027-diff.html >> https://www.rfc-editor.org/authors/rfc10027-rfcdiff.html (side by side) >> >> All the best, >> >> Kaelin Foody >> RFC Production Center >> >> > On Aug 4, 2026, at 8:29 AM, Filip Skokan <[email protected]> wrote: >> > >> > Dear RFC Editor(s), >> > >> > Thank you for the careful review. Our consolidated responses follow. >> > Textual changes use the requested OLD/NEW format. >> > >> > 1) The new BCP assignment is correct. >> > >> > 2) Global (document title) >> > >> > OLD: >> > Cross-Device Flows: Security Best Current Practice >> > >> > NEW: >> > Best Current Practice for Security of Cross-Device Flows >> > >> > >> > 3) Section 1.2 >> > >> > OLD: >> > This flow may be streamlined by rendering the session transfer code as a >> > QR code on the Authorization Device and scanned by the Consumption Device. >> > >> > NEW: >> > This flow may be streamlined by rendering the session transfer code as a >> > QR code on the Authorization Device and scanning it with the Consumption >> > Device. >> > >> > >> > 4) Section 1.2 >> > >> > OLD: >> > These flows are often used to add new devices to a network, onboard >> > customers to a mobile application, or provision new credentials (e.g., >> > [OpenID.SIOPV2]). >> > >> > NEW: >> > These flows are often used to add new devices to a network, onboard >> > customers to a mobile application, or provision new credentials (e.g., as >> > described in [OpenID.SIOPV2]). >> > >> > >> > 5) Section 1.4 >> > >> > OLD: >> > This specification uses the terms "access token", "refresh token", >> > "authorization server", "resource server", "authorization endpoint", >> > "authorization request", and "client" defined in "The OAuth 2.0 >> > Authorization Framework" [RFC6749]. >> > >> > NEW: >> > This specification uses the terms "access token", "refresh token", >> > "authorization server", "resource server", "authorization request", and >> > "client" defined in "The OAuth 2.0 Authorization Framework" [RFC6749]. >> > >> > >> > 6) Section 2 >> > >> > OLD: >> > Section 3 provides details about susceptible protocols, and Section 4 >> > provides attack descriptions. Section 6.1 provides details about the >> > security mechanisms and mitigations, Section 6.2 provides protocol >> > selection guidance, and Section 6.3 provides details from formal analysis >> > of protocols that apply to cross-device flows. >> > >> > NEW: >> > Section 3 provides details about susceptible protocols, and Section 4 >> > provides attack descriptions. Section 5 provides an overview of existing >> > protocols and standards. Section 6.1 provides details about the security >> > mechanisms and mitigations, Section 6.2 provides protocol selection >> > guidance, and Section 6.3 provides details from formal analysis of >> > protocols that apply to cross-device flows. >> > >> > >> > 7) Section 3.3.8 (heading) >> > >> > OLD: >> > Example A8: Access a Productivity Application >> > >> > NEW: >> > Example A8: Access a Productivity Application (User-Transferred >> > Authorization Data Pattern) >> > >> > >> > Section 4.3.8 >> > >> > OLD: >> > Example B8: Account Takeover (User-Transferred Session Data Pattern) >> > >> > This exploit applies to the use case described in Section 3.3.8. >> > >> > An attacker wants to use some website that requires presentation of a >> > verifiable credential for authentication. The attacker creates a phishing >> > website, which will in real time capture login QR codes from the original >> > website and present these to the user. The attacker tries to get the user >> > to use the phishing website by sending messages by email 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 >> > attacker's device is authorized with the user's credentials. >> > >> > NEW: >> > Example B8: Account Takeover (User-Transferred Authorization Data Pattern) >> > >> > This exploit applies to the use case described in Section 3.3.8. >> > >> > An attacker obtains a user's credentials for a Computer-Aided Design (CAD) >> > application but cannot complete the authorization without the 6-digit >> > authorization code sent to the user's mobile phone. The attacker triggers >> > the authorization request, causing the Authorization Server to send a >> > 6-digit authorization code to the user's mobile phone. The attacker then >> > contacts the user, claiming to be from the CAD application's support desk >> > and investigating a problem with the user's account, and asks the user to >> > read back the code they have just received. Because the attacker has >> > established the context for the code, the user provides it. The attacker >> > enters the code in the CAD application and obtains access to the user's >> > designs. >> > >> > >> > 8) This change is superseded by the replacement text for Section 4.3.8 in >> > response 7. >> > >> > >> > 9) Section 5 >> > >> > OLD: >> > An authorization server MAY use techniques such as device fingerprinting, >> > network address, or other techniques to detect if a cross-device protocol >> > is being used on the same device. >> > >> > NEW: >> > An Authorization Server MAY use device fingerprinting, network address, or >> > other techniques to detect if a cross-device protocol is being used on the >> > same device. >> > >> > >> > 10) Section 6.1.1 >> > >> > OLD: >> > The paragraph beginning "Note: There are scenarios that require that >> > authorization takes place..." is a normal paragraph. >> > >> > NEW: >> > Place this paragraph in an <aside> element. >> > >> > >> > 11) Section 6.1.5 >> > >> > OLD: >> > Some scenarios may require legitimate retransmission of user, QR, and >> > authorization data (e.g., retries). >> > >> > NEW: >> > Some scenarios may require legitimate retransmission of user data, QR >> > codes, and authorization data (e.g., retries). >> > >> > >> > 12) Section 6.1.8 >> > >> > OLD: >> > In some deployments, a trusted network may also be inferred using SIM or >> > network operator supplied information. >> > >> > NEW: >> > In some deployments, a trusted network may also be inferred using >> > information supplied by a Subscriber Identity Module (SIM) or the network >> > operator. >> > >> > >> > 13) Section 6.1.8 >> > >> > OLD: >> > Even if it is possible to deploy network-level controls, it SHOULD be used >> > in conjunction with other controls outlined in this document to achieve >> > defense in depth. >> > >> > NEW: >> > Even if it is possible to deploy network-level controls, they SHOULD be >> > used in conjunction with other controls outlined in this document to >> > achieve defense in depth. >> > >> > >> > Section 6.1.11 >> > >> > OLD: >> > Therefore, it should be used along with other techniques to provide a >> > defense-in-depth defense against cross-device attacks. >> > >> > NEW: >> > Therefore, they should be used along with other techniques to provide >> > defense in depth against cross-device attacks. >> > >> > >> > 14) Section 6.2.1.4 >> > >> > OLD: >> > In addition to the security considerations section in the standard, it is >> > RECOMMENDED that one or more of the mitigations outlined in this document >> > be considered, especially mitigations that can help establish proximity or >> > prevent attackers from obtaining QR or user codes. >> > >> > NEW: >> > In addition to the Security Considerations section in [RFC8628], it is >> > RECOMMENDED that one or more of the mitigations outlined in this document >> > be considered, especially mitigations that can help establish proximity or >> > prevent attackers from obtaining QR or user codes. >> > >> > >> > Section 6.2.2.4 >> > >> > OLD: >> > In addition to the security considerations section in the standard, it is >> > RECOMMENDED that one or more of the mitigations outlined in this document >> > be considered, especially mitigations that can help establish proximity or >> > prevent attackers from initiating authorization requests. >> > >> > NEW: >> > In addition to the Security Considerations section in [CIBA], it is >> > RECOMMENDED that one or more of the mitigations outlined in this document >> > be considered, especially mitigations that can help establish proximity or >> > prevent attackers from initiating authorization requests. >> > >> > >> > 15) Section 6.2.2.2 >> > >> > OLD: >> > Less susceptible to unauthenticated channel attacks, but still vulnerable >> > to attackers who know or can guess the user identifier and initiate an >> > attack as described in Section 4.3.4.1. >> > >> > NEW: >> > CIBA is less susceptible to unauthenticated channel attacks, but it is >> > still vulnerable to attackers who know or can guess the user identifier >> > and initiate an attack as described in Section 4.3.4.1. >> > >> > >> > 16) Section 6.2.3.2 >> > >> > OLD: >> > The CDA flow proves proximity by leveraging BLE advertisements for service >> > establishment, significantly reducing the susceptibility to any of the >> > exploits described in examples 1-6. >> > >> > NEW: >> > The CDA flow proves proximity by leveraging BLE advertisements for service >> > establishment, significantly reducing the susceptibility to any of the >> > exploits described in examples B1-B6 in Section 4.3. >> > >> > >> > 17) References >> > >> > a) Please alphabetize the references. >> > >> > b) The updates to [W3CWebAuthn], [OpenID.VP], [OpenID.Core], and >> > [W3C.DCAPI] look correct. >> > >> > c) The update to [NEWDCPHISH] looks correct. >> > >> > d) The update to [DCATTACK] looks correct. >> > >> > >> > 18) Global terminology >> > >> > OLD: >> > Mixed use of "Authorization Server" and "authorization server". >> > >> > NEW: >> > Use "Authorization Server" consistently. >> > >> > >> > OLD: >> > Mixed use of "sender-constrained tokens" and "sender-constraining tokens". >> > >> > NEW: >> > Use "sender-constrained tokens" consistently. >> > >> > >> > OLD: >> > Mixed forms of "defense in depth". >> > >> > NEW: >> > Use "defense in depth" as a noun phrase and "defense-in-depth" when used >> > attributively. No definition in Section 1.4 is needed. >> > >> > >> > OLD: >> > Pattern names use inconsistent capitalization. >> > >> > NEW: >> > Capitalize pattern names consistently, including: >> > User-Transferred Session Data Pattern >> > Backchannel-Transferred Session Pattern >> > User-Transferred Authorization Data Pattern >> > Cross-Device Session Transfer Pattern >> > >> > >> > OLD: >> > Device Authorization Grant >> > Authorization Code Grant >> > Authorization Code Flow >> > >> > NEW: >> > device authorization grant >> > authorization code grant >> > authorization code flow >> > >> > No changes are required to the different forms of "user code" and "QR >> > code" listed in question 18(d). >> > >> > >> > 19) Abbreviations >> > >> > a) "Proof Key for Code Exchange (PKCE)" is correct. >> > >> > b) Section 6.1.7 >> > >> > OLD: >> > Trusted devices MAY have their identities rooted in hardware (e.g., a TPM >> > or equivalent technology). >> > >> > NEW: >> > Trusted devices MAY have their identities rooted in hardware (e.g., a >> > Trusted Platform Module (TPM) or equivalent technology). >> > >> > >> > SIM is expanded in the response to question 12. >> > >> > FAPI has no current official expansion. Please refer to it as "OpenID >> > FAPI". If a link is useful, the working group page is >> > https://openid.net/wg/fapi/. >> > >> > SATMC is the name of the tool and should remain unexpanded. >> > >> > c) Global >> > >> > OLD: >> > Client-Initiated Backchannel Authentication is expanded repeatedly. >> > >> > NEW: >> > Expand the first occurrence as "Client-Initiated Backchannel >> > Authentication (CIBA)" and use "CIBA" thereafter. >> > >> > >> > 20) Global >> > >> > The terms "native client" and "native apps" should remain unchanged. >> > >> > OLD: >> > traditional phishing attacks >> > >> > NEW: >> > conventional phishing attacks >> > >> > >> > Thank you, >> > Pieter, Daniel, and Filip >> > >> > On Fri, 31 Jul 2026 at 06:42, <[email protected]> wrote: >> > Authors, >> > >> > While reviewing this document during Final Review, please resolve (as >> > necessary) the following questions, which are also in the source file. >> > >> > 1) <!--[rfced] This document has been assigned a new BCP number. Please >> > let us >> > know if this is not correct (i.e., it should be part of an existing BCP). >> > >> > See the complete list of BCPs here: >> > https://www.rfc-editor.org/bcps >> > --> >> > >> > >> > 2) <!-- [rfced] May we update the document title as follows to align with >> > other RFC >> > titles that include "Best Current Practice"? >> > >> > Original: >> > Cross-Device Flows: Security Best Current Practice >> > >> > Perhaps: >> > Best Current Practice for Security of Cross-Device Flows >> > --> >> > >> > >> > 3) <!-- [rfced] In the text below, how may we clarify "and scanned by"? >> > >> > Original: >> > This flow may be streamlined by rendering the >> > session transfer code as a QR code on the Authorization Device and >> > scanned by the Consumption Device. >> > >> > Perhaps A: >> > This flow may be streamlined by rendering the >> > session transfer code as a QR code on the Authorization Device and >> > scanning it with the Consumption Device. >> > >> > Perhaps B: >> > This flow may be streamlined by rendering the >> > session transfer code as a QR code on the Authorization Device that is >> > scanned by the Consumption Device. >> > --> >> > >> > >> > 4) <!-- [rfced] How may we clarify "(e.g., [OpenID.SIOPV2])" here? Is the >> > intent >> > "(e.g., as described in [OpenID.SIOPV2])"? >> > >> > Original: >> > These flows are >> > often used to add new devices to a network, onboard customers to a >> > mobile application, or provision new credentials (e.g., >> > [OpenID.SIOPV2]). >> > >> > Perhaps: >> > These flows are >> > often used to add new devices to a network, onboard customers to a >> > mobile application, or provision new credentials (e.g., as described in >> > [OpenID.SIOPV2]). >> > --> >> > >> > >> > 5) <!-- [rfced] The term "authorization endpoint" is listed in Section 1.4 >> > but is >> > not used elsewhere in the document. Should it be removed from Section 1.4? >> > --> >> > >> > >> > 6) <!-- [rfced] Should Section 5 be mentioned in this paragraph? If so, >> > please >> > provide the text. >> > >> > Current: >> > Section 3 provides details about susceptible protocols, and Section 4 >> > provides attack descriptions. Section 6.1 provides details about the >> > security mechanisms and mitigations, Section 6.2 provides protocol >> > selection guidance, and Section 6.3 provides details from formal >> > analysis of protocols that apply to cross-device flows. >> > --> >> > >> > >> > 7) <!-- [rfced] We note empty parentheses in the section title below. We >> > have >> > removed them, but please review and let us know if you would like to add >> > any >> > text to them. We see that other subsections of Section 3.3 have >> > parentheses that >> > indicate the applicable pattern. >> > >> > Original: >> > >> > 3.3.8. Example A8: Access a Productivity Application () >> > --> >> > >> > >> > 8) <!-- [rfced] May we move "in real time" as shown below to improve the >> > flow of >> > this sentence? >> > >> > Original: >> > 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. >> > >> > Perhaps: >> > The attacker creates a >> > phishing website, which will capture login QR codes from >> > the original website and present them to the user in real time. >> > --> >> > >> > >> > 9) <!-- [rfced] May we update this sentence to avoid using "techniques" >> > twice? >> > >> > Original: >> > An authorization server MAY use techniques such as device >> > fingerprinting, network address or other techniques to detect if a >> > cross-device protocol is being used on the same device. >> > >> > Perhaps: >> > An authorization server MAY use device >> > fingerprinting, network address, or other techniques to detect if a >> > cross-device protocol is being used on the same device. >> > --> >> > >> > >> > 10) <!-- [rfced] Please review whether the note in Section 6.1.1 (i.e., >> > the text >> > prefaced with "Note:") should be in the <aside> element. It is defined as >> > "a >> > container for content that is semantically less important or tangential to >> > the >> > content that surrounds it" >> > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> > --> >> > >> > >> > 11) <!-- [rfced] Should "of user, QR and authorization data" be updated as >> > follows? >> > >> > Original: >> > Some scenarios may require legitimate re-transmission >> > of user, QR and authorization data (e.g., retries). >> > >> > Perhaps: >> > Some scenarios may require legitimate retransmission >> > of user codes, QR codes, and authorization data (e.g., retries). >> > --> >> > >> > >> > 12) <!-- [rfced] Is the information supplied by the network operator >> > (Perhaps >> > A) or by SIM or the network operator (Perhaps B)? >> > >> > Original: >> > In some deployments a trusted network may also >> > be inferred using SIM or network operator supplied information. >> > >> > Perhaps A: >> > In some deployments, a trusted network may also >> > be inferred using SIM or information supplied by the network operator. >> > >> > Perhaps B: >> > In some deployments, a trusted network may also >> > be inferred using information supplied by SIM or the network operator. >> > --> >> > >> > >> > 13) <!-- [rfced] We have a question about "it SHOULD", which appears in >> > the second >> > sentence of each block of text below (first sentence is included for >> > context). >> > Should "it SHOULD" be updated to "they SHOULD", "this mitigation SHOULD", >> > or >> > something similar? We believe that the pronoun "it" refers to >> > "network-level >> > controls" in the first text block and to "rate limits" in the second text >> > block. >> > >> > Original: >> > *Limitations:* Network level controls may not always be feasible, >> > especially when dealing with consumer scenarios where the network may >> > not be under control of the service provider. Even if it is possible >> > to deploy network level controls, it SHOULD be used in conjunction >> > with other controls outlined in this document to achieve defence in- >> > depth. >> > ... >> > *Limitations:* Rate limits are effective at slowing an attacker down >> > and help to degrade scaled attacks, but they do not prevent more >> > targeted attacks that are executed with lower volumes and velocity. >> > Therefore, it should be used along with other techniques to provide a >> > defense-in-depth defense against cross-device attacks. >> > >> > Perhaps: >> > *Limitations:* Network-level controls may not always be feasible, >> > especially when dealing with consumer scenarios where the network may >> > not be under control of the service provider. Even if it is possible >> > to deploy network-level controls, they SHOULD be used in conjunction >> > with other controls outlined in this document to achieve defense in >> > depth. >> > ... >> > *Limitations:* Rate limits are effective at slowing an attacker down >> > and help to degrade scaled attacks, but they do not prevent more >> > targeted attacks that are executed with lower volumes and velocity. >> > Therefore, they should be used along with other techniques to provide a >> > defense-in-depth defense against cross-device attacks. >> > --> >> > >> > >> > 14) <!-- [rfced] In the sentences below, would it be helpful to clarify >> > "the >> > standard"? >> > >> > Original: >> > >> > In addition to the security considerations section in the standard, >> > it is RECOMMENDED that one or more of the mitigations outlined in >> > this document be considered, especially mitigations that can help >> > establish proximity or prevent attackers from obtaining QR or user >> > codes. >> > ... >> > In addition to the security considerations section in the standard, >> > it is RECOMMENDED that one or more of the mitigations outlined in >> > this document be considered, especially mitigations that can help >> > establish proximity or prevent attackers from initiating >> > authorization requests. >> > >> > Perhaps: >> > >> > In addition to the Security Considerations section in [RFC8628], >> > it is RECOMMENDED that one or more of the mitigations outlined in >> > this document be considered, especially mitigations that can help >> > establish proximity or prevent attackers from obtaining QR or user >> > codes. >> > ... >> > In addition to the Security Considerations section in [CIBA], >> > it is RECOMMENDED that one or more of the mitigations outlined in >> > this document be considered, especially mitigations that can help >> > establish proximity or prevent attackers from initiating >> > authorization requests. >> > --> >> > >> > >> > 15) <!-- [rfced] What is the subject of the sentence below? Specifically, >> > what does >> > "less susceptible" refer to? >> > >> > Original: >> > >> > Less susceptible to unauthenticated channel attacks, but still >> > vulnerable to attackers who know or can guess the user identifier and >> > initiate an attack as described in Section 4.3.4.1. >> > >> > Perhaps: >> > >> > CIBA is less susceptible to unauthenticated channel attacks, but it is >> > still >> > vulnerable to attackers who know or can guess the user identifier and >> > initiate an attack as described in Section 4.3.4.1. >> > >> > --> >> > >> > >> > 16) <!-- [rfced] Would adding a section number to indicate where readers >> > can find >> > examples 1-6 be helpful here? Also, should "examples 1-6" be updated to >> > "examples B1-B6"? >> > >> > Original: >> > The Cross-Device Authentication flow proves proximity by leveraging >> > BLE advertisements for service establishment, significantly reducing >> > the susceptibility to any of the exploits described in Examples 1-6. >> > >> > Perhaps: >> > The Cross-Device Authentication flow proves proximity by leveraging >> > BLE advertisements for service establishment, significantly reducing >> > the susceptibility to any of the exploits described in examples 1-6 >> > in Section 4.3. >> > --> >> > >> > >> > 17) <!-- [rfced] Please review the following questions regarding the >> > References >> > section of this document: >> > >> > a) Would you like the references to be alphabetized or left in their >> > current order? >> > >> > b) FYI - The reference entries below contained outdated information based >> > on the URLs provided, so we have updated them to match the information >> > found at the URLs. Please review the changes made to the following >> > reference entries: >> > >> > [W3CWebAuthn] >> > [OpenID.VP] >> > [OpenID.Core] >> > [W3C.DCAPI] >> > >> > c) FYI - The original URL for the reference [NEWDCPHISH] is no longer valid >> > (https://o365blog.com/post/phishing/#new-phishing-technique-device-code-authentication). >> > It appears the author moved their blog to a new domain >> > (https://x.com/DrAzureAD/status/1579875043563438080). We have updated this >> > reference to use the newer URL. >> > >> > Original: >> > [NEWDCPHISH] >> > Syynimaa, N., "Introducing a new phishing technique for >> > compromising Office 365 accounts", October 2020, >> > <https://o365blog.com/post/phishing/#new-phishing- >> > technique-device-code-authentication>. >> > >> > Updated: >> > [NEWDCPHISH] >> > Syynimaa, N., "Introducing a new phishing technique for >> > compromising Office 365 accounts", October 2020, >> > <https://aadinternals.com/post/phishing/>. >> > >> > >> > d) FYI - The original URL for the reference [DCATTACK] redirects to an >> > updated >> > page >> > (https://www.secureworks.com/blog/oauths-device-code-flow-abused-in-phishing-attacks). >> > It appears Secureworks was acquired by Sophos in February 2025 >> > (https://www.sophos.com/en-us/secureworks-sophos-acquistion). We have >> > updated >> > this reference to match the information at the new URL. Please let us know >> > if >> > you have any objections. >> > >> > Original: >> > [DCATTACK] Secureworks Counter Threat Unit (CTU), "OAuth's Device >> > Code Flow Abused in Phishing Attacks", August 2021, >> > <https://www.secureworks.com/blog/oauths-device-code-flow- >> > abused-in-phishing-attacks>. >> > >> > Updated: >> > [DCATTACK] Secureworks Counter Threat Unit Research Team, "OAuth's >> > Device Code Flow Abused in Phishing Attacks", June 2021, >> > <https://www.sophos.com/en-us/blog/oauths-device-code- >> > flow-abused-in-phishing-attacks>. >> > --> >> > >> > >> > 18) <!-- [rfced] Terminology >> > >> > a) We note inconsistencies in the terms below throughout the text. Should >> > these >> > be uniform? If so, please let us know which form is preferred. >> > >> > Authorization Server >> > authorization server >> > >> > sender-constrained tokens >> > sender-constraining tokens >> > >> > defense in depth >> > defence in-depth >> > defence-in-depth defence >> > Note: We updated to use "defense" (with "s"). We see that the NIST >> > Glossary, which is an informative reference for this document, uses >> > "defense-in-depth" with hyphens (see >> > https://csrc.nist.gov/glossary/term/defense_in_depth). This term has not >> > been used often in the RFC Series. We see a few instances of "defense in >> > depth" (open) and "defense-in-depth" (hyphenated) in published RFCs. The >> > hyphenated forms are mostly used in the attributive position (i.e., before >> > a noun) such as "defense-in-depth approach". Also will readers know what >> > this term means? Should it be added to Section 1.4 ("Conventions and >> > Terminology")? >> > >> > >> > b) In general text, should the names of patterns be capitalized or >> > lowercased? We >> > see both forms in the document. >> > >> > Lowercase: >> > Examples of the user-transferred authorization data pattern include >> > flows in which the Consumption Device requests the Authorization >> > Server ... >> > >> > In the backchannel-transferred session pattern, the client requests >> > the authorization server to authenticate the user and obtain >> > authorization for an action. >> > >> > In cross-device flows that follow the user-transferred authorization >> > data pattern, the client ... >> > >> > Attackers exploit the user-transferred authorization data pattern by >> > combining the social engineering techniques ... >> > >> > Capitalized: >> > ... using the Backchannel-Transferred Session pattern only after >> > the user is already authenticated and attempts a high-value >> > transaction. >> > >> > In the User-Transferred Session Data Pattern, users MAY enter out-of- >> > band information on the Consumption Device to start the authorization >> > process. >> > >> > ... on the primary device (Backchannel-Transferred Session >> > Pattern, Section 3.1.2). >> > >> > ... to approve the authentication >> > attempt on the primary device (User-Transferred Session Data >> > Pattern, Section 3.1.1). >> > >> > >> > c) Would you like to make the following capitalization changes per usage >> > in RFCs >> > 8628 and 6749? Or do you prefer the current capitalization? >> > >> > "Device Authorization Grant" to "device authorization grant" (per RFC 8628) >> > "Authorization Code Grant" to "authorization code grant" (per RFC 6749) >> > "Authorization Code Flow" to "authorization code flow" (per RFC 6749) >> > >> > >> > d) We see the following forms in the document; we did not make any changes >> > as >> > the meaning is clear, but let us know if you would like for the usage to be >> > consistent. Note that plurals of these forms also appear in the document. >> > >> > user code or QR code >> > user or QR code >> > QR code or user code >> > QR or user code >> > --> >> > >> > >> > 19) <!-- [rfced] Abbreviations >> > >> > a) FYI - We have expanded the following abbreviation per Section 3.6 of >> > RFC 7322 >> > ("RFC Style Guide"). Please review to ensure correctness. >> > >> > Proof Key for Code Exchange (PKCE) >> > >> > b) How may we expand the abbreviations below? >> > >> > TPM >> > SIM >> > FAPI >> > SATMC >> > >> > c) The abbreviation CIBA is expanded multiple times in the document; in >> > fact, >> > it is expanded every time it is used except for two instances. Would you >> > like >> > to expand the first instance in the text and then use the abbreviation >> > after? >> > --> >> > >> > >> > 20) <!-- [rfced] Please review the "Inclusive Language" portion of the >> > online >> > Style Guide >> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> > and let us know if any changes are needed. Updates of this nature >> > typically >> > result in more precise language, which is helpful for readers. >> > >> > For example, please consider whether "native" and "traditional" should be >> > updated throughout. >> > >> > While the NIST website >> > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >> > indicates that "traditional" is potentially biased, it is also ambiguous. >> > "Traditional" is a subjective term, as it is not the same for everyone. >> > >> > --> >> > >> > >> > Thank you. >> > >> > Kaelin Foody and Rebecca VanRheenen >> > RFC Production Center >> > >> > >> > On Jul 30, 2026, at 9:38 PM, [email protected] wrote: >> > >> > *****IMPORTANT***** >> > >> > RFC Author(s): >> > -------------- >> > >> > Final Review for RFC-to-be 10027 <draft-ietf-oauth-cross-device-security> >> > >> > Your document is now available for Final Review (previously AUTH48). Once >> > it has been >> > reviewed and approved by you and all coauthors, it will be published as an >> > RFC. >> > If an author is no longer available, there are several remedies; >> > see the Unavailable Authors section >> > (https://authors.ietf.org/rfc-publication-process#unavailable-authors). >> > >> > You and you coauthors are responsible for engaging other parties >> > (e.g., Contributors or Working Group) as necessary before providing >> > your approval. >> > >> > Planning your review >> > --------------------- >> > >> > Please review the following aspects of your document: >> > >> > * RFC Editor questions >> > >> > Please review and resolve any questions raised by the RFC Editor >> > that have been included in the XML file as comments marked as >> > follows: >> > >> > <!-- [rfced] ... --> >> > >> > These questions will also be sent in a subsequent email. >> > >> > * Changes submitted by coauthors >> > >> > Please ensure that you review any changes submitted by your >> > coauthors. We assume that if you do not speak up that you >> > agree to changes submitted by your coauthors. >> > >> > * Content >> > >> > Please review the full content of the document, as this cannot >> > change once the RFC is published. Please pay particular attention to: >> > - IANA considerations updates (if applicable) >> > - contact information >> > - references >> > >> > * Copyright notices and legends >> > >> > Please review the copyright notice and legends as defined in >> > RFC 5378 and the Trust Legal Provisions >> > (TLP – https://trustee.ietf.org/license-info). >> > >> > * Semantic markup >> > >> > Please review the markup in the XML file to ensure that elements of >> > content are correctly tagged. For example, ensure that <sourcecode> >> > and <artwork> are set correctly. See details at >> > <https://authors.ietf.org/rfcxml-vocabulary>. >> > >> > * Formatted output >> > >> > Please review the PDF, HTML, and TXT files to ensure that the >> > formatted output, as generated from the markup in the XML file, is >> > reasonable. Please note that the TXT will have formatting >> > limitations compared to the PDF and HTML. >> > >> > >> > Submitting changes >> > ------------------ >> > >> > To submit changes, please reply to this email using 'REPLY ALL' as all >> > the parties CCed on this message need to see your changes. The parties >> > include: >> > >> > * your coauthors >> > >> > * [email protected] (the RPC team) >> > >> > * other document participants, depending on the stream (e.g., >> > IETF Stream participants are your working group chairs, the >> > responsible ADs, and the document shepherd). >> > >> > * [email protected], which is an archival mailing list >> > to preserve discussion about the document while in the RPC editorial >> > queue; it is not an active discussion list: >> > >> > * More info: >> > >> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> > >> > * The archive itself: >> > https://mailarchive.ietf.org/arch/browse/auth48archive/ >> > >> > * Note: If only absolutely necessary, you may temporarily opt out >> > of the archiving of messages (e.g., to discuss a sensitive matter). >> > If needed, please add a note at the top of the message that you >> > have dropped the address. When the discussion is concluded, >> > [email protected] will be re-added to the CC list and >> > its addition will be noted at the top of the message. >> > >> > You may submit your changes in one of two ways: >> > >> > An update to the provided XML file >> > — OR — >> > An explicit list of changes in this format >> > >> > Section # (or indicate Global) >> > >> > OLD: >> > old text >> > >> > NEW: >> > new text >> > >> > You do not need to reply with both an updated XML file and an explicit >> > list of changes, as either form is sufficient. >> > >> > We will ask a stream manager to review and approve any changes that seem >> > beyond editorial in nature, e.g., addition of new text, deletion of text, >> > and technical changes. Information about stream managers can be found in >> > the FAQ. Editorial changes do not require approval from a stream manager. >> > >> > >> > Approving for publication >> > -------------------------- >> > >> > To approve your RFC for publication, please reply to this email stating >> > that you approve this RFC for publication. Please use 'REPLY ALL', >> > as all the parties CCed on this message need to see your approval. >> > >> > >> > Files >> > ----- >> > >> > The files are available here: >> > https://www.rfc-editor.org/authors/rfc10027.xml >> > https://www.rfc-editor.org/authors/rfc10027.html >> > https://www.rfc-editor.org/authors/rfc10027.pdf >> > https://www.rfc-editor.org/authors/rfc10027.txt >> > >> > Diff file of the text: >> > https://www.rfc-editor.org/authors/rfc10027-diff.html >> > https://www.rfc-editor.org/authors/rfc10027-rfcdiff.html (side by side) >> > >> > Alt-diff of the text (allows you to more easily view changes >> > where text has been deleted or moved): >> > https://www.rfc-editor.org/authors/rfc10027-alt-diff.html >> > >> > Diff of the XML: >> > https://www.rfc-editor.org/authors/rfc10027-xmldiff1.html >> > >> > >> > Tracking progress >> > ----------------- >> > >> > Details on the status of your Final Review are here: >> > https://queue.rfc-editor.org/final-review/rfc10027/ >> > >> > Please let us know if you have any questions. >> > >> > Thank you for your cooperation, >> > >> > RFC Editor >> > >> > -------------------------------------- >> > RFC 10027 (draft-ietf-oauth-cross-device-security) >> > >> > Title : Cross-Device Flows: Security Best Current Practice >> > Author(s) : P. Kasselman, >> > D. Fett, >> > F. Skokan >> > WG Chair(s) : Hannes Tschofenig, Rifaat Shekh-Yusef >> > Area Director(s) : Deb Cooley, Christopher Inacio >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
