[OAUTH-WG] Re: Mohamed Boucadair's No Objection on draft-ietf-oauth-cross-device-security-14: (with COMMENT)

[[e-mail]]

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 <[e-mail]>
Envoyé : mercredi 14 janvier 2026 19:48
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
____________________________________________________________________________________________________________
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.