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]
