**Session Date/Time:** 04 May 2026 17:00 # [OAUTH](../wg/oauth.html) ## Summary The OAUTH Working Group held an interim meeting on May 26, 2026, to discuss the progress of [draft-ietf-oauth-attestation-based-client-auth](https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/). The discussion focused on the recent restructuring of the document (versions -08 and -09), the introduction of a combined DPoP (Demonstrating Proof-of-Possession) mode, and several open GitHub issues regarding terminology, metadata, and the binding of OAuth artifacts to specific client instances. ## Key Discussion Points ### Working Group Status and Agenda **Rifaat Shekh-Yusef** opened the meeting and presented the [Chairs Slides](https://datatracker.ietf.org/meeting/interim-2026-oauth-01/materials/slides-interim-2026-oauth-01-sessa-chairs-slides-00). He noted the upcoming interim schedule: * Next week: Discussion on [draft-ietf-oauth-refresh-token-expiration](https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration/). * June 1st: Discussion on Agentic AI and OAuth. ### OAuth 2.0 Attestation-Based Client Authentication **Christian Bormann** and **Paul Bastian** presented updates on [draft-ietf-oauth-attestation-based-client-auth](https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/) using the slide deck [OAuth-ABC_interim_26](https://datatracker.ietf.org/meeting/interim-2026-oauth-01/materials/slides-interim-2026-oauth-01-sessa-oauth-abc-interim-26-02). #### Document Updates * **Restructuring:** Version -08 and the subsequent editors' draft (-09) involved significant restructuring to improve readability and clarify that the draft targets confidential clients. * **Combined DPoP Mode:** A new optional feature allows a client to use a single Proof-of-Possession (PoP) for both client attestation and DPoP, rather than two separate proofs. This is signaled via a new authentication method in the Authorization Server (AS) metadata. * **Reviewers:** **David Waite** and **Filip Skokan** volunteered to review the new combined DPoP mode and the latest editors' draft. #### Terminology and Scope * **Denis PINKAS** raised concerns regarding the terminology ("attester", "front-end", "back-end") and suggested that the document should more explicitly address unlinkability and interactions with Resource Servers (RS). He argued that the current model might lead to a duplication of attestations. * **Paul Bastian** and **Christian Bormann** clarified that the draft provides a general abstraction layer. While transitive trust (where the AS validates the attestation and the RS trusts the AS) is the primary model, the option to send attestations to the RS was included based on previous working group feedback. * **Denis PINKAS** also contested the alignment with RATS (Remote ATtestation ProcedureS) terminology. **Rifaat Shekh-Yusef** and **Paul Bastian** noted that the draft aims for alignment with the IETF RATS ecosystem and suggested that fundamental disagreements with RATS terminology should be addressed in that working group. #### Binding OAuth Artifacts to Client Instances * **Filip Skokan** argued for explicitly binding artifacts like the `device_code` or CIBA request IDs to a "client instance" to prevent the need for future extension drafts. * **Brian Campbell** cautioned against binding all artifacts by default, suggesting the working group be intentional about which artifacts (like the authorization code) actually require this binding, given existing protections like PKCE and DPoP. #### Metadata and DCR/CIMD * The group discussed the relationship between this draft and [draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) (CIMD). * **Aaron Parecki** and **Filip Skokan** expressed interest in exploring how client metadata can be used to signal support for attestation algorithms. * There was a debate on whether to reuse existing algorithm registries (e.g., `token_endpoint_auth_signing_alg_values_supported`) or define new ones. **Filip Skokan** volunteered to look into the technical implications of reusing registries versus creating separate ones for attestation. #### Implementation Guidance * The authors asked if the draft should include specific examples of platform attestations (e.g., Google Play Integrity, Apple App Attest). * **Pieter Kasselman** and **Tim Cappalli** advised against including platform-specific details in the normative text, noting that these technologies evolve rapidly and could lead to the specification becoming prematurely obsolete. The sense of those present was to keep the guidance abstract or non-normative. ## Decisions and Action Items * **Review Volunteers:** **David Waite** and **Filip Skokan** to review the latest editors' draft, specifically the combined DPoP mode. * **CIMD Integration:** **Aaron Parecki** and **Paul Bastian** to discuss the relationship between the attestation draft and [draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/). * **Algorithm Registries:** **Filip Skokan** to review whether to reuse existing `alg` metadata fields or define new ones for attestation. * **Issue 107 (Guidance):** The authors will refrain from adding platform-specific implementation examples to the normative sections of the draft to maintain technology neutrality. ## Next Steps * Authors to summarize the discussed GitHub issues and post them to the mailing list for broader consensus. * The working group aims to move toward Working Group Last Call (WGLC) once the remaining 17 GitHub issues are addressed and the new reviews are incorporated. * Next interim meeting scheduled for the following week to discuss [draft-ietf-oauth-refresh-token-expiration](https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration/).