Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

OAUTH

Summary

The OAUTH Working Group met to discuss the status of active working group documents, review security best practices, evaluate client metadata and SPIFFE-based client authentication, and explore agent authorization use cases and gaps. Key milestones include the transition of browser-based application guidance to the RFC Editor queue and growing implementation interest in cross-domain identity assertion. The session concluded with a panel on AI agent authentication, focusing on human-in-the-loop (HITL) patterns, non-deterministic API interactions, and credential governance, with plans to schedule an interim meeting to continue the agent authorization work.

Key Discussion Points

Chairs Update

• Presentation: Chairs Update (Presented by Rifaat Shekh-Yusef and Hannes Tschofenig)
• Document Status:
  • draft-ietf-oauth-first-party-apps: Working Group Last Call (WGLC) is complete; awaiting the shepherd write-up (expected post-Vienna).
  • draft-ietf-oauth-transaction-tokens: A third WGLC will start after Vienna.
  • draft-ietf-oauth-v2-1: Seeking reviewers. Nick Doty and Yaron Sheffer volunteered.
  • Browser-Based Apps: Aaron Parecki reported that the browser-based applications draft is in the RFC Editor queue with its RFC number assigned, and feedback is currently being processed.
• Prioritization of Presentation Requests: Due to an exceptionally high volume of presentation requests, the chairs emphasized that future slots will be heavily prioritized based on active mailing list discussions, proof of multi-party interest, and commitment to implement and deploy.

Identity Assertion JWT Authorization Grant

• Presentation: Identity Assertion JWT Authorization Grant (Presented by Aaron Parecki)
• Technical Details:
  • draft-ietf-oauth-identity-assertion-authz-grant profiles the token exchange and JWT authorization grant specifications to extend Single Sign-On (SSO) into API access (Cross-App Access or XAA).
  • Recent updates clarify cross-app access terminology, confirm applicability to non-enterprise use cases, and introduce a new metadata parameter for discovery.
  • To support SAML-based SSO environments, a JSON representation of SAML assertion values (including NameID) has been added to the Identity Assertion JWT (IDJAG) to facilitate user mapping at the Resource Server (RS) without out-of-band configurations.
• Discussion:
  • Authorization Details: Yaron Sheffer noted that clients require additional metadata to understand the structure of remote authorization details at the Resource Authorization Server (AS) for proper governance.
  • Document Clarity: Justin Richer requested clearer sequence diagrams and textual explanations detailing the order of the token exchange step (first) and the JWT authorization grant step (second).
  • Just-In-Time (JIT) Provisioning: This was identified as a major deployment pain point (Issue 83). Maxwell Gerber stated that failing to pass equivalent claims during the grant exchange will break JIT user creation. Paul Carlton suggested that granular error codes are needed to differentiate setup failures from invalid token assertions.
  • Key Binding: Aaron Parecki introduced two complementary drafts (draft-mcguinness-oauth-token-exchange-cnf and draft-parecki-oauth-jwt-dpop-grant) to address end-to-end key binding (e.g., using DPoP) from SSO to the final access token. Pieter Kasselman noted that clear terminology defining "whose keys" are bound in multi-party flows is critical.

Client ID Metadata Document

• Presentation: Client ID Metadata Document (Presented by Aaron Parecki)
• Technical Details:
  • draft-ietf-oauth-client-id-metadata-document defines a mechanism for clients to publish metadata at a URL, which then serves as the Client ID.
  • Editorial updates split the metadata definition from the fetching rules, and moved localhost/development-specific exceptions (such as relaxing SSRF checks) to a non-normative appendix.
• Discussion:
  • Mix-Up Attacks & ISS Parameter: To counter mix-up attacks where clients talk to arbitrary servers, the draft proposes copying the OAuth 2.1 requirement for the AS to return the iss parameter. Emelia Smith noted that requiring a .json file extension in the client metadata URL implicitly prevents certain mix-up vectors.
  • Dynamic Metadata Variation: The AS may need to serve different metadata versions depending on which AS fetches the document (e.g., indicating support for different client auth methods).
    • To facilitate this, Aaron Parecki proposed the AS identify itself (using its issuer URL) during the fetch.
    • Justin Richer, Emelia Smith, and Arndt Schwenkler objected to doing this via a query string parameter (as it mutates the Client ID URL) and recommended using an HTTP header (e.g., a custom header or referrer) instead.
    • Vittorio Bertocci cautioned against over-complicating the spec for interoperability edge cases and suggested utilizing existing OpenID Connect/Federation metadata features instead.
  • Issue Triage: Emelia Smith requested community assistance with GitHub issue triage due to bandwidth constraints. Vanshaj Singhania volunteered to assist.

Updates to OAuth 2.0 Security Best Current Practice

• Presentation: Updates to OAuth 2.0 Security Best Current Practice (Presented by Pedram Hosseini)
• Technical Details:
  • draft-ietf-oauth-security-topics-update details four core attacks: audience injection, cross-toolkit/account takeover, cross-user session fixation (particularly affecting Back-end-for-Front-end patterns), and brokered OAuth deployment attacks.
  • The brokered OAuth attack occurs when a broker mediates between downstream clients and upstream ASs; because upstream consent is bound to the broker's client ID, malicious downstream clients may inherit unauthorized access.
• Discussion:
  • Hannes Tschofenig, Emelia Smith, Justin Richer, and Arndt Schwenkler debated whether the "broker pattern" belongs in the security BCP or should be detailed in a standalone deployment architecture document. The broker acts as an AS to downstream clients but as a client to upstream servers, introducing multi-layered role complexities.
  • The authors plan to discuss splitting the broker pattern into a separate draft on the mailing list.

OAuth SPIFFE Client Authentication

• Presentation: OAuth SPIFFE Client Authentication (Presented by Arndt Schwenkler)
• Technical Details:
  • draft-ietf-oauth-spiffe-client-auth profiles existing client authentication specifications for workloads identified by SPIFFE IDs.
  • SPIFFE IDs represent infrastructure-level entities (e.g., containing regions, clusters, and instances), whereas OAuth client IDs traditionally represent service-level classes. This causes validation issues in RFC 7521 and draft-ietf-oauth-attestation-based-client-auth, which enforce strict equality matching between the client ID and the assertion subject.
  • The draft proposes relaxing this restriction to allow a SPIFFE-structured subject to map to a recognized client ID class.
• Discussion:
  • Hannes Tschofenig warned that loosening matching rules to allow fuzzy or subpart matching could introduce authorization vulnerabilities.
  • Aaron Parecki and Christian supported the distinction between "client instance" and "client class" as a recurring requirement across workload and agent scenarios.
  • Giuseppe De Marco noted that the attestation-based client auth working group has encountered the exact same issue and is considering introducing a distinct client_instance_id parameter to avoid solving it globally in OAuth.
  • Fredrik expressed concern that allowing arbitrary mapping of client IDs within SPIFFE could force normative changes in base specs that relax security rules for non-SPIFFE deployments.
  • Pamela Dingle noted a privacy concern: publishing granular SPIFFE ID mapping structures in Client Metadata could leak internal infrastructure topology and scaling metrics to external platforms.

OAuth Transaction Authorization Challenge

• Presentation: OAuth Transaction Authorization Challenge (Presented by Yaroslav Dobryakov)
• Technical Details:
  • This individual draft proposes a step-up authorization mechanism designed for AI agent scenarios requiring a "human-in-the-loop" (HITL) approval.
  • When an agent requests a high-risk operation (such as deleting a database) using an existing valid access token, the Resource Server (RS) challenges the transaction by returning a signed JWT. This challenge contains a transaction identifier (TXN), a human-readable reason, and an actor claim.
  • The agent relays the challenge to the client, which forwards it to the AS. The AS triggers a user consent flow (or external manager approval) and mints a new transaction-specific access token containing the bound TXN claim.
• Discussion:
  • A participant questioned why the transaction challenge must originate from the RS rather than the agent pre-emptively requesting consent. Yaroslav explained that the RS is best positioned to evaluate transactional risk and execute step-up policies dynamically, whereas pre-emptive consent requires agents to predict authorization needs precisely.

Agentic Use Cases and Gaps Panel

• Presentations:
  1. Self Driving Software (Presented by Dick Hardt)
  2. Agentic Use Cases and Gaps Informed by Experience with KYAPay Technologies (Presented by Mike Jones)
  3. Agent Authorization use cases and gap analysis (Presented by Mailing Huang)
• Key Use Cases and Gaps Identified:
  • Context-Driven Governance: Dick Hardt argued that agents operate non-deterministically, meaning appropriate access is highly context-dependent. He introduced "EAuth" (Eighth) as an alternative architecture designed to separate mission execution agents from independent policy governance agents.
  • Agent Commerce and Identity: Mike Jones presented "Know Your Agent" (KYA) requirements, stressing the need to bypass "are you human" tests for authorized agents and convey details about the authorizing human or organization. This work proposes new claims to represent updated authentication methods (AMR) and identity proofing methods.
  • Dynamic Scopes & Delegation: Mailing Huang analyzed gaps in Rich Authorization Requests (RAR is static by design), DPoP (assumes fixed key pairs, complicating sub-agent creation), and Client ID Metadata. Key requirements include dynamic scope expression, multi-hop delegation, and task-level revocation.
• Panel Discussion:
  • Dapeng Liu asked how e-commerce platforms verify the trustworthiness of a user-delegated agent token. Mike Jones responded that trust is established via signatures from designated token issuers.
  • Yaron Sheffer highlighted the risk of agent hallucinations (e.g., booking an expensive first-class flight instead of coach) and advocated for HITL validation at the API call level, guaranteeing that the actual tool call is verified by a human.
  • Peter noted that security incident response workflows require cross-domain orchestration, suggesting that batch authorization models are needed to prevent "consent fatigue" in human-in-the-loop systems.
  • Hannes Tschofenig observed that the proposed requirements span a wide spectrum ("a wish list to Santa Claus") and noted the lack of immediate overlap between the proposals, indicating a need for structured coordination.

Decisions and Action Items

• Triaging Volunteer: Vanshaj Singhania volunteered to assist Emelia Smith and Aaron Parecki in triaging the GitHub issue tracker for draft-ietf-oauth-client-id-metadata-document.
• Review Volunteers: Nick Doty and Yaron Sheffer volunteered to review draft-ietf-oauth-v2-1.

Next Steps

• WGLC Schedules:
  • The chairs will progress draft-ietf-oauth-first-party-apps to the AD once the shepherd write-up is finalized.
  • draft-ietf-oauth-transaction-tokens will enter a third WGLC post-Vienna.
• Security BCP Updates: The authors of draft-ietf-oauth-security-topics-update will discuss separating the "brokered OAuth" setting into its own deployment-oriented draft on the mailing list.
• SPIFFE Client Authentication: draft-ietf-oauth-spiffe-client-auth will remain on hold until its normative dependency in the WIMSE working group (workload identity token) completes WGLC.
• Agent Authorization Coordination: Due to the breadth of the use cases and overlapping proposals, the chairs plan to schedule a dedicated OAUTH interim meeting focusing on AI agent authentication, authorization, and HITL patterns.

Session Date/Time: 24 Jul 2026 07:00

OAUTH

Summary

The OAUTH Working Group met during IETF 126 on Friday. The session covered updates on active working group documents, presentations on multiple individual drafts (covering HTTP Message Signatures, Rich Authorization Request (RAR) Metadata, out-of-band client challenges, deferred token responses, envelope proof-of-possession, and SD-JWT delegation), an analysis of authorization policy languages in OAuth/AI environments, and a proposal to organize the working group's high volume of drafts using a clustering framework.

Key Discussion Points

Chairs Update

• Presenters: Rifaat Shekh-Yusef, Hannes Tschofenig
• Slides: Chairs Update
• Details: The chairs presented the Note Well, gave tips on meeting participation, and outlined the Friday agenda, highlighting the focus on individual drafts, policy languages, and draft clustering.

Attestation-Based Client Authentication

• Presenter: Daniel Fett
• Drafts: draft-ietf-oauth-attestation-based-client-auth, draft-ietf-oauth-spiffe-client-auth, draft-ietf-oauth-client-id-metadata-document
• Details: Daniel Fett presented updates on draft-ietf-oauth-attestation-based-client-auth and addressed three profiling issues raised by the SPIFFE client auth team (draft-ietf-oauth-spiffe-client-auth):
  1. Subject (sub) claim semantic: The current draft equates the subject to the client ID. The group debated if this should be relaxed. Justin Richer noted that a client ID is a value used by the Authorization Server (AS) to recognize the software and does not require strict string-comparison equality. Arndt Schwenkschuster favored keeping the current language to align with RFC 7521, RFC 7522, and RFC 7523.
  2. Workload Identity Key Rotation: Workload tokens rotate frequently. Binding refresh tokens to the client instance key (cnf claim) can prevent seamless rotation. Joseph Heenan suggested a key-rotation mechanism where the old key signs the new key to avoid needing a persistent client instance ID.
  3. JWT Type (typ claim): The draft currently fixes the JWT type. Arndt Schwenkschuster argued that other workload platforms (such as Kubernetes) will issue their own attested credentials and the working group should allow other key-bound types. Philip noted that changing the typ should also require changing the client authentication method name to preserve interoperability.
  • RFC 7521 compatibility: Daniel Fett suggested not referencing RFC 7521 to avoid confusion between HTTP body and header usage. Arndt Schwenkschuster recommended including a reference to explain why RFC 7521 is not being used.

HTTP Message Signatures for OAuth PoP

• Presenter: Justin Richer (with Aaron Parecki)
• Slides: HTTP Message Signatures for OAuth PoP
• Details: Justin Richer presented a general mechanism for applying HTTP Message Signatures (RFC 9421) to OAuth access tokens as a Proof-of-Possession (PoP) mechanism. Unlike DPoP, which relies on Jose, this is a detached signature system that handles HTTP's message-shuffling behavior. Key introduction can occur at registration time or dynamically at runtime.
• Discussion: Kathleen Moriarty expressed concern regarding potential scope creep. Justin Richer clarified that the draft's scope is strictly confined to applying signatures to OAuth access tokens and their immediate parameters. Philip recommended carrying the raw public key directly in the HTTP signature rather than double-encoding the JWK in base64.

RAR Metadata and Error Remediation

• Presenter: Yaron Sheffer
• Details: Yaron Sheffer presented a draft addressing how clients discover Rich Authorization Request (RAR) schemas and how a resource server (RS) can reject a request with an "insufficient authorization" error while providing a structured, remediable payload (base64-encoded JSON) detailing the exact RAR objects needed. The draft also proposes a GNAP-inspired authorization reference (such as a hash or UUID) so that clients do not have to parse complex domain-specific RAR semantics.
• Discussion: Nick Watson supported the error remediation mechanism but expressed mild skepticism about the practical utility of authorization references due to the hierarchical nature of RAR. Arndt Schwenkschuster agreed on the problem space but suggested resolving overlaps with other similar drafts. Justin Richer strongly supported the pass-by-value and pass-by-reference design, noting that the AS is responsible for resolving the reference's validity.
• Poll 1: Should the WG adopt the RAR Metadata and Error Remediation draft as a starting point?
  • Result: yes: 28, no: 4, no_opinion: 12 (total: 92)

OAuth Client Challenge Protocol (Out-of-Band Approval)

• Presenter: Tobias (presented by Judith)
• Details: Tobias presented a mechanism for "out-of-band" approval where a client needs to escalate privileges (step up authorization) when the resource owner is no longer present (such as in autonomous agentic scenarios). If challenged with an insufficient_client_authorization error, the client presents a pre-obtained proof artifact to the token endpoint to receive a higher-privileged token.
• Discussion: Aaron Parecki noted that this behavior is already fully supported in vanilla OAuth (RFC 6749) by issuing a broadly-scoped refresh token and letting the client request down-scoped access tokens as needed. Yaron Zehavi suggested that stepping up client authentication could instead be handled using resource server metadata (RFC 9728) to direct clients to distinct AS endpoints with differing client authentication policies. Pam Dingle queried how the scopes of the different tokens in the diagram were distinguished.

Deferred Token Response (DTR)

• Presenter: Max Gerber
• Details: Max Gerber presented a draft proposing an asynchronous token grant mechanism. It enables the AS to defer a grant decision (e.g., for high-risk transactions requiring manual auditing, physical passport verification, or multi-party approvals). The client opts in by sending completion_mode=deferred to the token endpoint; if deferred, the AS returns an authorization_pending error and a deferral_code, which the client uses to poll the token endpoint.
• Discussion: Yaron Sheffer, Paul Carleton, and Arndt Schwenkschuster spoke in favor of the draft, noting real-world use cases in banking, identity verification, and workload provisioning. Nick Watson suggested returning a deferral URL alongside the error to avoid requiring explicit client opt-in. Justin Richer recommended aligning the polling mechanism with prior asynchronous protocols such as CEBA, GNAP, and UMA. George Fletcher stressed the importance of ensuring the deferral code can be sender-constrained to the client instance.
• Poll 2: Should the WG adopt the Deferred Token Response as a WG document?
  • Result: yes: 35, no: 1, no_opinion: 1 (total: 91)

Envelope Proof of Position (EPoP)

• Presenter: Ashwin Abhakar
• Details: Ashwin Abhakar presented an "envelope" proof-of-possession approach designed for non-HTTP bound resource servers, service meshes, and zero-trust architectures. EPoP nests the access token inside an outer proof token. To prevent replay attacks on non-HTTP channels, it utilizes client-generated nonces (c-nonce) containing timestamps and key metadata.
• Discussion: Daniel Fett argued that extending OAuth to non-HTTP environments is outside the scope of the OAuth Working Group. Justin Richer agreed, stating that OAuth is fundamentally an HTTP-based protocol, and recommended that the authors bring this work to the WIMSE working group. Hannes Tschofenig also suggested aligning this work with the service-to-service communication efforts in WIMSE.

SD-JWT Delegation

• Presenter: Gareth Oliver
• Details: Gareth Oliver presented an extension to Selective Disclosure JWTs (SD-JWTs) to support delegation chains (e.g., delegating payment authority to an autonomous agent, or power-of-attorney). The holder's Key Binding JWT (KB-JWT) is transformed into a new SD-JWT that carries its own disclosures, constraints, and confirmation claims for the delegate holder. This process can be chained indefinitely.
• Discussion: Anton asked about the nature of the disclosures added during delegation. Gareth Oliver explained they represent new delegation policies or runtime constraints. Frederic and Christian Bormann supported the draft, pointing to strong industry demand for delegation. Nai questioned whether the verifier needs to obtain and trust public keys for every entity in the chain; Gareth Oliver clarified that the trust anchor remains solely with the initial issuer, as each key is progressively endorsed down the chain.

Policy Language in OAuth (AI and Agentic Authorization)

• Presenter: Yaroslav (AWS)
• Details: Yaroslav presented a joint analysis (with Jeff Lombardo) evaluating the feasibility of putting policy languages (such as Rego) directly into OAuth tokens or requests (as proposed in recent individual drafts). The authors analyzed the problem across five pillars: transaction goals, schemas, envelopes, signaling, and async confirmation. They concluded that shipping policy code inside tokens introduces severe security risks (such as policy provisioning and default-allow bugs). Instead, they advocated using native OAuth mechanisms—specifically Rich Authorization Requests (RAR), metadata schema discovery, error remediation, and deferred token responses.
• Discussion: Arndt Schwenkschuster clarified the distinction between deferring authorization decisions versus encoding the results. George Fletcher suggested that user-defined constraints (e.g., limiting a transaction to a specific geographic area) can resemble policy statements and must be carefully evaluated.
• Poll 3: Are you interested in discussing this in an interim?
  • Result: yes: 26, no: 0, no_opinion: 1 (total: 87)

Clustering of OAuth Work

• Presenters: George Fletcher, Aaron Parecki
• Details: With over 70 active individual drafts in the OAuth Working Group, the presenters proposed a framework to organize the work into nine functional "clusters" (e.g., Client Identity, Token Security, User-to-AS, etc.). This system would require authors to self-categorize their drafts, allowing the chairs to better group topics for interim meetings and identify overlapping drafts for potential consolidation.
• Discussion: Deb Cooley (Responsible Area Director) strongly endorsed the proposal and recommended documenting the categories on the WG Wiki. She noted that she has resisted pressure to charter a separate working group for "agentic AI" authentication, arguing that agentic use cases should be mapped directly into the existing OAuth and WIMSE frameworks. Aaron Parecki agreed, stating that drafts should be evaluated by their technical mechanics rather than their association with "AI". Pam Dingle recommended exposing these classifications to specification consumers to help navigate the large library of OAuth documents.

Decisions and Action Items

• Decision: The working group agreed to adopt the RAR Metadata and Error Remediation draft as a starting point.
• Decision: The working group agreed to adopt the Deferred Token Response as a WG document.
• Action Item: Chairs to confirm the adoption of the RAR Metadata and Error Remediation draft and the Deferred Token Response on the mailing list.
• Action Item: Chairs to schedule an interim meeting to discuss Agentic OAuth, Policy Languages, and Asynchronous/Deferred mechanisms.
• Action Item: George Fletcher and Aaron Parecki to set up the draft clustering framework on the OAuth WG Wiki to help authors self-categorize their submissions.

Next Steps

• Attestation-Based Client Authentication: The authors of draft-ietf-oauth-attestation-based-client-auth will work with the SPIFFE profiling team to resolve the feedback on the sub claim, key rotation, and JWT types to prepare the document for Working Group Last Call (WGLC).
• Deferred Token Response: The authors will collaborate with the authors of the transaction challenge and asynchronous interaction drafts to align polling mechanisms and explore merging overlapping drafts.

Related Documents

draft-ietf-oauth-attestation-based-client-auth, draft-ietf-oauth-client-id-metadata-document, draft-ietf-oauth-first-party-apps, draft-ietf-oauth-identity-assertion-authz-grant, draft-ietf-oauth-security-topics-update, draft-ietf-oauth-spiffe-client-auth, draft-ietf-oauth-transaction-tokens, draft-ietf-oauth-v2-1, draft-mcguinness-oauth-token-exchange-cnf, draft-parecki-oauth-jwt-dpop-grant