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]
