Subject: Re: draft-ekahraman-oauth-attestation-authz-native-app-00
Hi Efe,
Thank you for publishing this. I read the -00 with interest. The mapping of
RATS roles onto the OAuth authorization flow is clean, and the passport model
is a pragmatic choice for native app deployments where a direct AS-to-Verifier
channel is unrealistic. A few comments.
* Holder-of-key binding between the Attestation Result and the token request.
Section 4 binds the Challenge to the client's public key (or a JWK thumbprint)
at the Verifier. But the draft does not require the Attestation Result itself
to carry that key binding, and Section 7 does not require the Authorization
Server to verify that the party presenting the AR controls the attested key. As
specified, the AR is bearer evidence within its freshness window. An AR
exfiltrated from one client instance can be presented by a different instance
of the same application on a compromised device, which is exactly the
substitution case this mechanism exists to prevent. Section 9.1 positions DPoP
as complementary, but I think possession binding needs to be normative: the
Verifier should embed the client key (or thumbprint) in the AR, and the AS MUST
verify that the token request demonstrates possession of that key. Without
this, freshness is the only replay control, and the timestamp check in Section
12.1 carries more weight than it can bear.
* The snapshot logic in Section 7.1.
Section 7.1 requires a fresh AR on refresh grants because Attestation Results
are snapshots of runtime state at a single point in time. That reasoning is
correct, and it applies equally within the access token lifetime. A device can
be compromised one minute after issuance, and every subsequent resource access
under that token inherits the stale trust decision. I am not suggesting the
draft solve this; it is arguably out of scope for a grant-time mechanism. But
the Security Considerations should state explicitly what the freshness window
protects and what it does not: it bounds the staleness of the trust decision at
issuance, not the trustworthiness of the environment during token use.
Implementers will otherwise over-read the guarantee.
* Clock skew.
Freshness validation is a MUST (Section 7, step 2) but skew handling is a MAY
(Section 12.1). For an interoperable check the draft should give concrete
guidance: either a bounded acceptance window with a recommended default, or
have the Verifier assert an expiry so the AS validates against the Verifier's
clock instead of computing freshness across two clocks.
* Interop surface, and relationship to attestation-based-client-auth.
Emelia's pointer to draft-ietf-oauth-attestation-based-client-auth on the list
is worth addressing directly in the draft, since the two will be read together.
They solve different problems: client-auth establishes client-instance identity
at authentication time, whereas this draft consumes an Attestation Result to
make per-scope authorization decisions. The overlap is the evidence carrier,
not the function. Stating that distinction explicitly would head off the "isn't
this the same thing?" reading. Separately, since AR format, policy expression,
and attestation_profile semantics are all AS-local, the interoperable surface
of this draft is effectively the two parameter registrations plus the
processing rules — worth noting that two deployments will not interoperate at
the policy layer.
A point of agreement to close: keeping the AR format open (EAR recommended, not
mandated) is the right call. Mandating a single vendor's evidence or result
format at this layer would be harmful to the ecosystem.
Best regards,
Mohamad Khalil Yossif
On 12/06/2026 17:30:08, Efe Kahraman <[email protected]> wrote:
Dear OAuth Working Group,
I would appreciate your review and feedback on the following Internet-Draft:
https://datatracker.ietf.org/doc/draft-ekahraman-oauth-attestation-authz-native-app/
[https://datatracker.ietf.org/doc/draft-ekahraman-oauth-attestation-authz-native-app/]
This draft proposes an OAuth 2.0 extension that enables Authorization Servers
to consider attestation results associated with native applications when making
authorization decisions. The goal is to support authorization policies that
take into account the security characteristics and trustworthiness of the
application and its execution environment.
I would be grateful for any comments on the document, security considerations,
and whether this work addresses a problem that the OAuth WG believes is worth
pursuing.
Thank you for your time and consideration.
Best regards,
Efe Kahraman
_______________________________________________ OAuth mailing list --
[email protected] To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
