OAUTH

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. 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. He noted the upcoming interim schedule:

Next week: Discussion on 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 using the slide deck OAuth-ABC_interim_26.

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 (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.
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.

Automatic IETF Minutes