Hi Pieter, Thank you for the follow-up.
Appreciate the clarifications. Overall, I’m fine with your resolutions/PRs. Thanks. Cheers, Med De : Pieter Kasselman <[email protected]> Envoyé : mercredi 14 janvier 2026 19:48 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: [OAUTH-WG] Mohamed Boucadair's No Objection on draft-ietf-oauth-cross-device-security-14: (with COMMENT) Thanks for the review Mohamed. I appreciate the deep read and comments. Much appreciated. I will keep an eye out for the PR. Responses are inline: On Wed, Jan 14, 2026 at 12:36 PM Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-oauth-cross-device-security-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Pieter, Daniel, and Filip, Thank you for the effort put into this document. Thanks to Bing Liu for the OPSDIR review and to the authors for engaging and the PR. This is a well-written and easy-to-read document, although there are some repetitions here and there. Please find below some comments (ordered following the doc flow). I will send you a PR for some nits I tagged when reading. # Target Abstract: It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. I understand this is not an exhaustive list, but given that the guidance also recommendations for service providers and users, I thought that these are better listed here as well. # Beyond OAUTH WG CURRENT: This section describes the set of security mechanisms and measures to secure cross-device protocols against Cross-Device Consent Phishing and Cross-Device Session Phishing attacks that the OAuth working group considers best practices at the time of writing this specification. Once approved, this will reflect the IETF consensus, not only this specific WG I suggest to reword accordingly. Opened an issue for this (https://github.com/oauth-wg/oauth-cross-device-security/issues/238). # Implementers What is meant by “implementers” in Section 2? Is this the “service providers” mentioned in the discussion sections? Else? Implementers refer to anyone implementing these protocols. I will add text to provide a bit more clarity (eee issue: https://github.com/oauth-wg/oauth-cross-device-security/issues/239) # Implement with risk CURRENT: 2. Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated. Should there by a companion recommendation to encourage flagging/disclosing the unmitigated risk for user awareness? Section 6.1.14 provides specific guidance on the user experience and what information is most likely to help users make better decisions. Knowledge of the protocol and the nuances of the protocol's risks are not helpful to users who have "expertise elsewhere" (that is experts at something other than the underlying system protocols), have limited time and are focused on task completion. # Same-device scenarios CURRENT: Cross-device protocols SHOULD NOT be used for same-device scenarios. If the Consumption Device and Authorization Device are the same device, protocols like OpenID Connect Core [OpenID.Core] and OAuth 2.0 Authorization Code Grant as defined in [RFC6749] are more appropriate. The background sections didn’t mention the same-device case. The introduction and use of “Cross” hint that target devices are distinct. You may elaborate this part early in the document. This is an anti-pattern. We have seen instances of its use and wanted to give this guidance. I think it makes sense to add additional information on why using the other protocols is better (reduced risk surface and avoidance of any consent phishing flows). See issue: https://github.com/oauth-wg/oauth-cross-device-security/issues/240 # Same-device/Channel CURRENT: the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. I’m not sure to understand this case. Which channel are we referring to here if these are the same device? We added this to warn against an anti-pattern (it is always surprising to see how protocols get. used in the real world). When you use a cross-device flow in a same-device scenario, you inject the user back into the middle of the flow, for example, to transfer a user code. The moment this happens, an attacker can change the context and inject themselves into the flow. So, if you're using cross device flows on same-device deployments, you should treat the two different parts of the flow (e.g. display of the user code) and the authorization (entry of user code and authentication/authorization) as if they are two different devices. You cannot assume any of the benefits you would get from not putting the user in the middle of the flow. So the intent of this text is to (1) warn against this pattern and (2) if implementers insist on using it (because they may have already done so), the mitigations defined in this document should still be deployed. # Privacy considerations CURRENT: Note that the authorization server typically cannot directly determine whether the Consumption Device and Authorization Device are physically close to each other. Instead, it must rely on the surrounding systems, protocols in use, device capabilities, or information it obtains from other systems to establish or verify proximity. Some of the mitigations have implications on privacy (tracking locations, user fingerprinting, etc.). The trade-off between privacy vs intended benefit should be called out. We can add language to remind implementors of this trade-off - see issue (https://github.com/oauth-wg/oauth-cross-device-security/issues/240). # Efficiency CURRENT: The authorization server can validate information it receives, but it cannot independently measure or enforce proximity on its own. An attacker can also present (fake) location information that can be misleading for authorization server. Unless there is a mean to attest the authenticity of presented data, trusting this data for driving the authorization server behavior may lead to suboptimal behavior. BTW, almost all the listed alternatives for proximity matters do not guarantee the outcome, while others depend on the user setup (e.g., NFC/BLE activation). Yes, none of these are perfect - they are better than doing nothing, but should not be trusted in the absolute sense. They make the attacks harder, but not impossible. These limitations are called out already at the end of section 6.1.1 # Risk profile CURRENT: Depending on the risk profile and the threat model in which a system is operating, it MAY be necessary to use more than one mechanism to establish proximity to raise the bar for any potential attackers. ## What is “risk profile”? Who is supposed to do that risk assessment? This is organization- and deployment-specific and varies across industry segments and applications. All systems carry risk, and developing them typically involves conducting a risk assessment. Defining that aspect of deployments is out of scope of this specification. ## How is this reco different from this one provided earlier? It is RECOMMENDED that one or more of the mitigations be applied when implementing a cross-device flow. The same recommendation is given in the sumamry and then repeated in specific protocol sections. This anticipates that an engineer may choose to skip to the sections that pertain to the protocol they are interested in, and may not read the entire document. We really want the recommendation to come through. # What risk? CURRENT: There is no guarantee that the primary and secondary holders are in the same location at the time of the authorization. In such cases, proximity (or lack of proximity) may be an indicator of risk and the system may deploy additional controls (e.g., transaction value limits, transaction velocity limits) or use the proximity information as input to a risk management system. How is this a risk? Proximity checks can even be a hindrance to the service in such a case. The intent here was to flag that when you have primary/secondary card holder, proximity is still a risk signal (e.g. if primary and secondary users are usually in the same location, and they suddenly are not, or the inverse, it may be appropriate to apply additional controls. I opened an issue to re-word this (see https://github.com/oauth-wg/oauth-cross-device-security/issues/241) # Why isn’t this a reco? CURRENT: If an authorization server determines that a user code or QR code is being used in an attack it may choose to invalidate all tokens issued in response to these codes and make that information available through a token introspection endpoint (see [RFC7662]). The document uses MAY as a reco for similar discussions in other sections. Why is this not a reco (i.e., use MAY as in other sections)? I believe it SHOULD be a reco :) Thanks for catching this (spec blindness kicked in). Issue here: https://github.com/oauth-wg/oauth-cross-device-security/issues/242 # Trusted Networks Note sure if this is useful to be mentioned in that section, but there are cases where SIM-based checks are used as trusted network. Cellular operators may provide APIs for such checks. I think it is fine to add a sentence referring to this as an example - see issue (https://github.com/oauth-wg/oauth-cross-device-security/issues/243). # Prevent CURRENT: The practical mitigations described in this section can prevent the attacks from being initiated, … It seems to me that none of the mitigations completely nullify the risks. At best, they can contribute to soften them. Maybe “prevent” is not accurate here, or at least, I would explain what is meant. We can add some clarification that the mitigations provide prevention, disruption or recovery from attacks, within the limits described for those mitigations. Issue here: https://github.com/oauth-wg/oauth-cross-device-security/issues/244 # Security Considerations CURRENT: Security considerations are described in Section 2 and Section 6. I’m afraid this needs some elaboration to reflect implications of some proposed mitigations. For example, Click here to grant access to your files. If you are not trying to access your files, you should decline this request and notify the security department"). opens the door for a variety of attacks. There are security issues with clickable links per se that are worth to be highlighted. The approach taken for security considerations is consistent with that of RFC9700 Best Current Practice for OAuth 2.0 Security (see https://www.rfc-editor.org/rfc/rfc9700.html#name-security-considerations). Section 6.1.3 mentions that research shows user education effectively reduces the risk of phishing attacks (which typically include advising against clicking on links). This document does not address general phishing or anti-phishing, but we can reference some of the NIST guidelines as examples of topics covered in anti-phshing programs ( which includes educating users about not to click on links). Issue here: https://github.com/oauth-wg/oauth-cross-device-security/issues/245 Cheers, Med _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
