Hi Mohamad, Thank you for your review and the valuable feedback.
I find your points and remarks very helpful. Regarding your first comment, I would like to take a bit more time to think through the implications before responding fully. I am currently working on a detailed response to all of your points and will get back to the list as soon as it is ready. Thank you again for your time and insights. Best regards, Efe > On 13 Jun 2026, at 09:25, Mohamad Khalil-Yossif > <[email protected]> wrote: > > 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/ >> >> 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]
