Subject: Re: draft-ekahraman-oauth-attestation-authz-native-app Hi Efe,
Thanks, this all sounds right. The DPoP code-binding direction and the Section 7 / Security Considerations clarifications close the points I raised. One small addition on key binding: it is worth stating that the key carried in the AR and the key proven at the token endpoint MUST be the same key, with the AS rejecting on divergence. Without that equality check a substituted-but-valid AR can be presented alongside a PoP for a different key. On clock skew, your distinction is correct and I accept it. I had conflated skew tolerance with where the authoritative clock sits; they are independent, and an explicit Verifier-asserted expiry makes the validity interval unambiguous without removing the freshness evaluation at the AS. RFC 9334's timestamp-based passport model is the right precedent. One refinement on the leeway itself: the two directions are not symmetric and should not share a single tolerance. An AR whose generation time is slightly in the past is a freshness-window question. An AR whose generation time is in the future is a pure clock-error question and should be bounded much more tightly, since a large future-dated value is more likely error or manipulation than legitimate skew. Two separate bounds, each with a recommended default, would give implementers something interoperable rather than a single MAY. Regards, Mohamad Khalil Yossif > On 24 Jun 2026, at 14:28, Efe Kahraman <[email protected]> > wrote: > > Hi Mohamad, > > Please find my statements inline below. > > Best regards, > > Efe > >> On 13 Jun 2026, at 15:07, Efe Kahraman <[email protected]> wrote: >> >> 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. >>> > > Thank you for raising this point. I agree that key binding is an important > property here, particularly for public clients, and that relying on freshness > alone is not sufficient to address substitution or replay of an exfiltrated > Attestation Result. > > I think the right direction is to make the binding explicit in two places: > first, by carrying the client public key in the Attestation Result, and > second, by requiring the Authorization Server to verify proof of possession > of that same key when the client presents the authorization code. In that > respect, the authorization code binding mechanism defined by DPoP in RFC 9449 > is a good fit here. I plan to revise the draft accordingly. > >>> 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. >>> > > I agree that this distinction should be made more explicit. I think it would > be useful to clarify this point both in Section 7, where the snapshot nature > of the Attestation Result is discussed, and in Security Considerations, so > that the scope of the guarantee is explicit. > >>> 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. >>> > > I agree that skew handling needs more concrete guidance, particularly because > freshness is essential to the authorization logic here rather than merely a > general validity check. I am not sure, however, that an expiry timestamp > should be framed as the remedy for skew itself. My view is that an expiry > timestamp is useful because it makes the validity interval of the Attestation > Result explicit, whereas freshness still needs to be evaluated relative to > the Attestation Result generation time and a policy-defined freshness window > at the Authorization Server. In that respect, I think adding an expiry > timestamp would be a useful improvement, and the Timestamp-Based Passport > Model in RFC 9334 provides a helpful precedent for timestamp-bounded validity. > > For skew handling, I plan to make the validation guidance more concrete by > explicitly defining the leeway applied by the Authorization Server, including > both stale results and results whose generation time appears to be > unreasonably far in the future. >>> 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. >>> > > Thank you for the explanation. I agree that the relationship to > draft-ietf-oauth-attestation-based-client-auth should be described more > explicitly, since the two documents are likely to be read together but > address different layers of the problem. As I mentioned in my earlier reply > to Emelia, I plan to extend the "Related Works" section to make that > distinction clearer. >>> 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]
