724 VIEWS
Pinterest LinkedIn LINE

Overview

On July 24 Japan time, OAuth WG Session 123 at IETF 1 Madrid was held. The previously announced agenda was as follows, but a session on AI was inserted after the chairs update. The Chairs Update also reported the following.

  • Published RFCs
    • RFC 9728 – OAuth 2.0 Protected Resource Metadata – Mike, Phil, Aaron.
  • RFC Editor Queue
    • Selective Disclosure for JWTs (SD-JWT)
    • OAuth 2.0 for Browser-Based Applications
  • Waiting for Write-Up
    • Cross-Device Flows: Security Best Current Practice
    • Token Status List

Agenda

Key Topics

The main topics were the latest developments and security discussions concerning the OAuth protocol. Specifically, the group examined new challenges in AI agent authentication, particularly moving away from highly privileged service accounts and obtaining tokens that represent users. It also focused on progress on SD-JWT (Selective Disclosure JWT) and the continuing discussion about including decentralized identifiers (DIDs). In addition, participants discussed efforts to fix known security vulnerabilities caused by ambiguous audience values, updates to the Security BCP (Best Current Practice), and in particularcountermeasures against variants of audience injection and mix-up attacks. Finally, proposals were also introduced for cross-domain federation of OAuth identity and authorization, and for automatic OAuth client registration using Spiffe credentials.

Another session will be held today at half past 9 p.m. Japan time; it will be Session 2.

IETF 123: Briefing Document on OAuth (July 24, 2025)

(The following is a lightly edited version of a NotebookLM summary.)

1. AI Agent Authentication Challenges

Jonathan Rosenberg and Pat White sought assistance from the OAuth community on new authentication challenges arising from the emergence of AI and AI agents.

  • Challenge 1: The Privilege Problem for AI Chatbots and Voice Bots
    • Customer-support bots, including chatbots and voice bots, call APIs and perform actions on behalf of users (for example, reordering a prescription).
    • Today, these bots are generally built using highly privileged service accounts. “Today, most things are built with service accounts for these bots, and as you know, they are usually quite highly privileged, because they need to be able to act on behalf of any user who calls the company.”
    • The introduction of large language models (LLMs) increases the risk that bots will hallucinate or decide to make API calls based on incorrect information.
    • The goal is to move away from “god-like service accounts” and develop an authentication framework that gives a bot only a token representing the user.
    • When a user verifies their identity over the public switched telephone network (PSTN), using information such as the last 4 digits of an SSN or an address, the challenge is how to use that information to obtain a token for the user.
    • (Sakimura’s comment) Couldn’t CIBA be used for this?
  • Challenge 2: Privilege Elevation for Autonomous AI Agents
    • A UI-less autonomous agent (for example, a trading bot) may need to elevate its privileges temporarily under specific circumstances (for example, temporarily gaining permission to read email in order to respond to an urgent message).
    • “The bot needs to be able to request a token with the appropriate permissions to do what it needs to do.”
    • “The bot needs to request some kind of privilege elevation that is sent back to the user for human approval.” This should occur for limited time and duration.
    • (Sakimura’s comment) Couldn’t CIBA be used for this?
  • Related Security Issue: AI Confirmation Flows (Human-in-the-Loop)
    • A scenario in which human confirmation and approval are required before an AI agent calls an API. “The problem is that an AI agent wants to call an API, but we do not trust it to do it well. We want it to consult a human, have the human approve the operation, and then have the API called.”
    • This was recognized as an OAuth-adjacent issue, and a draft was submitted as “draft-rose-check-00.” Tim argued that it falls within the scope of OAuth.
  • Feedback from the OAuth Community
    • Jeff Lombardo (AWS) noted that existing OAuth capabilities, especially Client Initiated Backchannel Authorization (CIBA), may address much of this problem. “When you said not to give it a god-like token, I think that is exactly why OAuth was created.”
    • Hannes Tschofenig offered an interesting view that agents should not handle tokens directly and should be separated from the authentication infrastructure. “Ideally, the agent should never touch any token at all—neither a god-like token nor a temporary token, nor any token.”

2. SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials)

Brian Campbell described the progress of SD-JWT VC and an important discussion about the treatment of DIDs (Decentralized Identifiers).

  • Overview of SD-JWT VC
    • It defines a data format and validation and processing rules for representing verifiable credentials in JSON payloads.
    • It is based on the SD-JWT format and existing JWT content rules and extensibility model.
    • It describes SD.VC issuer metadata and key-resolution techniques similar to OpenID Connect.
    • It does not use the W3C Verifiable Credentials Data Model (VCDM) 1.1 or 2; it is neither required nor prohibited. When used together, OpenID for Verifiable Presentations references SD-JWT-VC-LD.
  • Recent Changes (Drafts 9 & 10)
    • Primarily editorial updates, encoding fixes, and updated examples.
    • The issuer signing-key validation section was renamed “Issuer Signing Mechanisms,” and extension points for signing-key validation options were clearly defined.
    • Web-based metadata resolution using a well-known URI and JWKS and an inline X.509 variant using the x5c JWS header were defined as 2 common mechanisms.
    • It was clarified that acceptable mechanisms depend on verifier policy, such as a trusted CA list, and that validating 1 mechanism is sufficient.
  • Discussion of Including DIDs in the SD-JWT VC Specification
    • Reasons for Exclusion (Brian Campbell’s Position):
      • Complexity and cognitive overhead: The DID method registry contains more than 200 methods, and it is unrealistic for most developers to implement all of them. This harms interoperability. “The proliferation of more than 200 DID methods is not reasonable for most developers—most average developers—to implement.”
      • Reputational risk: Including 200 inconsistent DID methods could damage the credibility and perceived seriousness of a standards-track IETF document. “The potential damage to the credibility and perceived seriousness of a standards-track IETF document from including 200 poorly governed DID methods that lack broad consensus within a particular community.”
      • Scope creep: Guidance on DIDs is beyond the expertise and scope of this working group and document. A specific profile should define DID-method selection and policy.
    • Reasons Inclusion Is Necessary (Marcus and Stefan’s Position):
      • In the previous 4 discussions, there was substantial opposition to removing DID support.
      • “We should revert this change.”
      • Stefan argued that the previous DID text had been requested to explain how to use the extension point, and that removing it was a step backward.
      • There is no need to implement all 200 DID methods, and DID-method standardization is under way at the European level. “Please stop repeating the information about 200 non-standardized DID methods. A standardization project is under way at the European level in San JC19. It will explicitly standardize these DID methods.”
      • DID support was previously mandatory and later became optional. As an optional feature, it should not burden developers who do not want to implement it.
    • Vote result: A vote was held on whether to include DIDs in the document.
      • In favor: 7; opposed: 40; no opinion: 9.
      • As a result, the group decided not to include DIDs in the main document. Proponents should publish a profile or a separate RFC for the DID work. “The proponents should take that option. Publish this RFC with what we have today, start a profile for the DID work, and publish that too.”

3. RFC 7523 BIS Update

Mike Jones described the status of the RFC 7523 bis update, particularly its response to known security vulnerabilities.

  • Objective: Address a vulnerability in which ambiguous audience values targeting authorization systems can be exploited.
  • RFCs covered: Updates 7521, 7522, 7523, and 9126 (Push Authorization Requests).
  • Change in approach: The original plan was to replace 7523 completely, but following discussion at IETF 122, the focus shifted to point updates to existing RFCs. “Instead of replacing 7523, we decided to make point updates.”
  • Key changes:
    • Removed the update to the signed JWT request format, since it already says implementations “should do the right thing.”
    • Added a reference to a University of Stuttgart paper describing the vulnerability.
    • With Deb’s support, it was confirmed that the IETF process would be expedited because this is a security fix.
  • Open issues:
  • Explicit typing: There is discussion about whether to require an explicit type so that authorization servers can distinguish the old 7523 from the updated 7523.
  • SAML authorization grant: Adjusting specific language concerning audience restrictions.
  • Enforcing a single-string audience: The current specification says the audience value should be a single string, but existing implementations such as Kubernetes use arrays, prompting discussion about whether a change is needed. “Audience values are supposed to be single strings, but Kubernetes has code that uses only arrays for audience values.”
  • Nuances of grant audience checking.
  • Document title: A change to the current title (“7523 BIS”) has been proposed, with new title suggestions from Mike Schwarz and Brian Campbell.
  • Next steps: Continue discussion, resolve issues, publish the draft, and ultimately proceed to Working Group Last Call. Because this is a security fix, rapid publication is the goal.

4. OAuth Security BCP Update

Pedram and Kaiuan presented the status of the OAuth Security BCP (Best Current Practice) update. The update aims to address 2 newly discovered attacks.

  • Background to the update:
    • To address 2 new attacks discovered after the BCP was finalized: an audience injection attack and a mix-up attack variant.
    • Following discussion at IETF 122, the group decided to add a new RFC to BCP 240 containing only considerations for the new attacks.
  • Audience Injection Attack (Pedram)
    • Attack overview: A detailed explanation of how an attacker can obtain a client-authentication assertion and impersonate the client. A list of specific endpoints, including pushed authorization and device authorization endpoints, is also provided.
    • Root cause and mitigation: The attack can be prevented only by the client; using a single audience value—the AS issuer identifier or the exact URI of the target endpoint—is recommended.
  • Mix-Up Attack Variant (Kaiuan)
    • Motivation: A new mix-up attack variant is widespread across platforms, including those of major vendors such as Google, Microsoft, Amazon, and Samsung. “We discovered a new mix-up attack variant that is prevalent almost everywhere.” This stems from the lack of clear standards or practices for platform configuration.
    • Focus of the attack: Rather than a single app federating with multiple IDPs, it focuses on an “integration platform” that works with many integrated apps.
    • Attack variant—Cross-Flow Account Takeover (C-FAT): The victim’s authorization code is leaked to the attacker.
    • Code Injection (CI): The attacker’s code is injected into the victim.
    • Root cause: Ambiguity when an OAuth client distinguishes integrated apps, such as relying only on sessions or redirect URIs.
    • The “shared issuer” concept: 2 integrated apps may legitimately share the same authorization server—for example, 2 Dropbox integrations on the same platform. In this case, the issuer identifier alone cannot uniquely identify each integration.
    • Mitigation: The OAuth client should distinguish each integrated app with a “distinct redirect URI.” This ensures that the app that starts OAuth is the same app that completes it. Many companies have adopted this defense.
  • Next steps:
  • Further discussion to make this a working-group draft, particularly offline coordination with the chairs.
  • Potentially hold a virtual interim meeting for detailed discussion.
  • Participants are asked to review the document and provide feedback.

5. JWT Security BCP Update

Yaron and Mike Jones presented an update to the RC8725 JWT Security BCP. This also addresses newly discovered attacks.

  • Motivation for the update: Numerous new attacks against JOT have been discovered, including attacks disclosed at Black Hat in the summer of 2023 and CVEs from researchers at Tsinghua University.
  • Proposed changes (5 pull requests):
  • Upper bound on iteration counts in password-based key generation: To prevent denial-of-service attacks.
  • JWS/JWE confusion: Addresses cases where a verifier accepts a JWE even though it expects a JWS. “This occurs especially when the JWE is encrypted with a public key and the verifier stores the public key together with the private key.” Normative language is added requiring confirmation that the object is a JWS.
  • Case sensitivity: Addresses attacks that manipulate letter case to bypass a blocklist for the “none” algorithm. Defensive coding, using an allowlist instead of a blocklist, is recommended.
  • Compression abuse: Addresses possible abuse of the compression feature supported by JWE.
  • Rejecting JSON-serialized JWS: Addresses the issue of some verifiers accepting JSON-serialized JWS even though the standard does not permit it.
  • Next steps: The document is in good shape, and the authors hope it will be adopted by the working group and advanced as soon as possible. Reviews from Aaron and Denny Pinkas have already been received. Brian Campbell noted that further updates may be needed and that this could become a larger effort, including retiring the PFB (Password Based Key Derivation Function 2) approach algorithm and coordinating with an existing document that deprecates the “none” algorithm.

6. Cross-Domain Federation of OAuth Identity and Authentication

Brian Campbell described a draft that combines RFC 8693 (Token Exchange) and RFC 7523 (Assertion Framework) to document a general pattern for maintaining identity and authentication information across domains without end-user interaction.

  • Objective: Profile 2 existing RFCs and explain how to maintain identity and authentication information across domains in a way that is already used in many places but is difficult for many people to understand.
  • Main approach: Use local RFC 8693 token exchange to obtain a token and facilitate obtaining cross-domain access authorization under RFC 7523.
  • Recent changes (Draft 05): Primarily editorial updates and the addition of metadata describing token types supported by the local AS.
  • Open issues: There are 4 open issues, most of them editorial. 1 concerns incorporating Mike’s change to the assertion profile, but its impact is expected to be minor.
  • Proposal for Working Group Last Call: The document is ready for Working Group Last Call (WGLC), and rapid progress is expected. “Please consider a Working Group Last Call.”
  • Related work by Aaron Perki (Identity Assertion Authorization Grant): Brian also mentioned related work by Aaron Perki, the Identity Assertion Authorization Grant. It is a profile for a more specific, meaningful use case of Brian’s document.
  • This work is increasingly relevant to Agentic AI use cases, especially in enterprise environments. It enables OAuth-based systems to obtain access tokens on behalf of users without explicit end-user authorization.
  • “This work began long before the emergence of Agentic AI, but it becomes particularly relevant and meaningful for Agentic AI use cases in an enterprise context. Here, end-user consent is effectively provided through the employment contract, and end-user consent is not required for each transaction.”
  • Aaron’s blog post and diagram showed how an AI agent logs in through an enterprise IDP and uses an SSO token to access applications such as Slack across domains.
  • Community response: There was little objection to the WGLC proposal. The work is important and directly relevant to enterprise environments.

7. OAuth Client ID Prefixes

Brian Campbell described the “OAuth Client ID Prefixes” draft being developed by Aaron, Daniel, and Joseph.

  • Objective: Provide a simple, practical way for clients to publish metadata and enable an authorization server to establish a client ID without preregistering the client. This is useful in many cases where preregistration is impractical, such as connecting open-source chat apps to self-hosted servers or apps to self-hosted services such as Mastodon and WordPress.
  • Relationship to the previous draft: It was split from and renamed from the previous “Client ID Metadata Document” draft.
  • Concept:
    • The client publishes a JSON document at a stable URL using the client-registration vocabulary—the fields defined by Dynamic Client Registration.
    • The authorization request passes that URL as the client ID.
    • The authorization server retrieves the JSON document from the URL and uses it to establish the client’s identity, including configuration parameters and public keys for authentication.
    • This provides an alternative approach to client onboarding that does not require preregistration.
  • Relevance to AI: This approach is also useful for Agentic AI. Agentic AI is not a new problem in the sense that it is software accessing resources, but its scale and potential problems highlight the longstanding issue that preregistration is an obstacle in many deployments.
  • Discussion and challenges:
    • Drawbacks: Benefits of preregistration, such as redirect URI validation, may be lost. Possible solutions include a hard binding between the client ID and document and showing users a verified URL.
    • Trust management: Similarities to OpenID Federation were noted, highlighting why OpenID Federation introduces complex trust-management mechanisms, such as automation in large deployments and trust marks. The lack of such trust-management mechanisms in this draft was identified as a concern.
  • Next steps: The document was judged not yet ready for WGLC. An interim meeting is planned for further discussion and resolution of issues.

8. OAuth Client Registration Using Spiffe Credentials

Pieter Kasselman presented 2 drafts on automatic OAuth client registration using Spiffe credentials.

  • The Need for Automatic Client Registration:
  • Operational challenges: Manually managing clients and secrets, rotating secrets, and storing them securely is time-consuming, error-prone, and can cause downtime. “Managing clients and secrets, rotating secrets, and securely storing them takes a great deal of time and tends to be manual. Otherwise, you need to create many processes to follow.”
  • Heterogeneous environments: Manual work across different organizations and technology stacks creates substantial coordination and overhead between developers and identity administrators.
  • Exponential growth: Growth in workloads, particularly driven by AI, is causing exponential growth in clients and secrets, making them difficult to manage in large organizations.
  • Introduction to Spiffe:
    • Spiffe (Secure Production Identity Framework For Everyone) aims to solve this “turtles-all-the-way-down problem” by bootstrapping credentials without provisioning secrets to workloads.
    • It works through attestation and continuous lifecycle management.
    • It can be deployed at scale, and open-source and commercial solutions are available.
    • Spiffe benefits OAuth deployments by shifting client-management responsibility to the platform level and focusing on workloads. OAuth servers can thereby rely on Spiffe infrastructure for credential issuance, lifecycle management, and identity proofing.
  • 2 proposed approaches:
    • 1. Register on First Use approach:
      • When a client presents Spiffe credentials, the authorization server already trusts the issuer, so it validates the credentials and automatically trusts and registers the client ID.
      • No additional registration protocol is required, making this efficient and low-latency.
      • It is suitable for the client credentials flow.
      • Redirect flows require an additional metadata-management strategy, with possible coordination with Brian and Aaron’s earlier work also suggested.
    • 2. Using a Spiffe JWT as a Software Statement (Dynamic Client Registration):
      • A Spiffe JWT is used as a software statement within the Dynamic Client Registration protocol.
      • No new protocol is required, and it is compatible with existing Dynamic Client Registration.
      • It is useful for Dynamic Client Registration adopted by MCP (Mobile Connect Profile).
      • It supports only JWTs but could be generalized to other credential types.
  • Next steps:
    • Seek views on whether automatic client registration is of interest to the OAuth community.
    • Discuss whether the Spiffe approach is of interest.
    • If interested, participants are invited to contribute through comments, issues, and PRs.
    • This would provide a simple, scalable, and secure client-registration mechanism and help move away from the problem of proliferating secrets.
  • Community response:
    • Where Spiffe is used in OAuth deployments, this work is viewed as highly relevant because it can simplify the registration process.
    • Jeff Lombardo (AWS) agreed that the working group should take on this work.
    • Mike Jones suggested using a different term because “automatic client registration” is already clearly defined in OpenID Federation.
    • Joseph noted that the classification into redirect and non-redirect flows may be inaccurate, and that the first case could also apply to a redirect flow when Pushed Authorization Requests (PAR) are used.
    • Tony Nadlin expressed concern that the document does not explain how to establish trust domains or how to use Spiffe in a specific instance.
    • Brian Campbell acknowledged the overlap with the “Client ID Prefixes” work he presented and emphasized the need for coordination.
Watch this video on YouTube.
Playing the video connects to YouTube.

Related posts

JWS and JWT Are Now RFCs!

It took a very long time[1], but JSON Web Signature (JWS) and JSON Web Token (JWT) have finally become Standards Track RFCs[2]. They are [RFC 7515]…

OAuth · 2015-05-20

OAuth PKCE Published as RFC7636

OAuth PKCE (pronounced “pixy”), for which John Bradley (Ping), Naveen Agarwal (Google), and I are credited as co-authors, has been published as [RFC 7636]. It was…

OAuth · 2015-09-18