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

[Pieter Kasselman <[e-mail]>]

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]> 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]
> To unsubscribe send an email to [e-mail]
>