The five-check formulation is correct, and mapping it onto the RFC 9334 Appendix A event definitions is the right way to make it unambiguous. The asymmetry is captured properly: leeway_1 guarding the future-dated direction and leeway_2 the AS-ahead direction, with the expiry check (3) and the internal sanity checks (4, 5) sitting cleanly on top.
One thing worth making explicit in the text, since it is the real reason leeway_1 must stay small. Future-dating is not only a plausibility concern. Because freshness is evaluated as OP_r - RG_v, a future-dated RG_v shrinks that interval and makes the AR appear fresher than it is. Check 1 bounds how far this can be pushed, so the effective freshness window an attacker can obtain is freshness_threshold + leeway_1. That means leeway_1 should be small relative to freshness_threshold, not merely small in absolute terms. Stating that relationship gives implementers the reason behind the constraint rather than just the constraint. On defaults, leaving the tolerances to deployment policy is the right call. Standardizing numeric skew values here would be over-specification, and the qualitative guidance that leeway_1 be kept small is sufficient at this layer. Mohamad > On 24 Jun 2026, at 16:30, Efe Kahraman <[email protected]> > wrote: > > Hi Mohamad > > Thank you again for the detailed review. I agree that the key equality check > should be stated explicitly: if the Attestation Result carries a client key, > the Authorization Server must verify that the same key is demonstrated at the > token endpoint and reject the request on mismatch. > > I also agree with the distinction between the two skew directions. A > future-dated Attestation Result is a different class of check and I think the > draft should reflect that by using separate leeway values. The logic I am > currently considering is as follows. > > Following the event definitions in Appendix A of RFC 9334, let: > > RG_v: the Attestation Result generation time, according to the Verifier's > clock. > RX_v: the Attestation Result expiry time, according to the Verifier's clock. > OP_r: the time at which the Authorization Server evaluates the Authorization > Policy, according to the Authorization Server's clock. > > The Authorization Server then validates the Attestation Result using the > following checks: > > 1. `RG_v < OP_r + leeway_1` > > This checks that the Attestation Result was not generated unreasonably far in > the future from the Authorization Server's perspective. The `leeway_1` value > accounts for cases in which the Authorization Server's clock is behind the > Verifier's clock. > > 2. `OP_r - RG_v < freshness_threshold + leeway_2` > > This verifies that the Attestation Result is recent enough to meet the > Authorization Server's freshness policy. The `leeway_2` value accounts for > cases in which the Authorization Server's clock is ahead of the Verifier's > clock. > > 3. `OP_r < RX_v + leeway_2` > > This checks that the Attestation Result has not expired according to the > Verifier's declared validity interval. The `leeway_2` value accounts for > cases in which the Authorization Server's clock is ahead of the Verifier's > clock. > > 4. `RX_v > RG_v` > > This checks that the Verifier's declared expiry time is after the generation > time. > > In addition, the Authorization Server may apply the following policy check: > > 5. `RX_v - RG_v < max_lifetime` > > This checks that the Verifier's declared validity interval does not exceed > the maximum lifetime accepted by the Authorization Server. > > On the question of default values, my current inclination is not to > standardize specific leeway values in the draft. I would prefer to leave the > precise tolerance to the deployment policy. However, I think the draft can > still state that `leeway_1` should be kept sufficiently small, since > future-dated Attestation Results are more likely to indicate clocking error > or manipulation. > > Best Regards > > Efe > >> On 24 Jun 2026, at 15:05, Khalil-Yossif, Mohamad >> <[email protected]> wrote: >> >> 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]
