Hi Emelia, Thank you for pointing this out. I agree that the relationship between these two drafts should be described more clearly. While both drafts make use of attestation, they address different problem statements and, consequently, pursue different objectives.
Draft-ietf-oauth-attestation-based-client-auth-09 focuses primarily on client authentication and audience blinding. It defines how a client instance presents a key-bound attestation alongside proof of possession to the Authorization Server, serving either as a primary authentication mechanism or as an additional security signal. On the other hand, draft-ekahraman-oauth-attestation-authz-native-app document addresses a distinct layer: how verifier-issued Attestation Results are evaluated by the Authorization Server and how those evaluations subsequently influence the scopes issued to Native Applications. I will revise the "Related Works" section in the next iteration of the draft to include these details and better articulate this distinction. Best regards, Efe > On 12 Jun 2026, at 19:23, Emelia S. <[email protected]> > wrote: > > Hi Efe, > > Have you seen this oauth-wg draft? > https://drafts.oauth.net/draft-ietf-oauth-attestation-based-client-auth/draft-ietf-oauth-attestation-based-client-auth.html > > I think it's related to or doing a very similar thing to what you're > outlining? > > — Emelia > >> On 12 Jun 2026, at 16:28, 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]
