IETF 123 OAuth WG Session 2
Authorization Events identity IETF

IETF 123: OAuth WG Session 1 Summary (24th Japan time)

Nat 2025-07-25 No Comments

Overview

The first session of the OAuth Working Group was held at IETF 7 Madrid on July 24th, Japan time. The agenda announced in advance is as follows, but a session on AI was inserted after the Chairs update. The following was also reported as a Chairs Update:

  • 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

Main topics

The main topics were:OAuth ProtocolDiscussion on the latest status and security ofAI Agent AuthenticationThe paper considers new challenges in the cloud, particularly the move away from highly privileged service accounts and obtaining tokens that represent users.SD-JWT (Selective Disclosure JWT) It highlights the progress of and the ongoing discussions regarding the inclusion of decentralized identifiers (DIDs). Audience valueEfforts to fix known security vulnerabilities due to ambiguity,Security BCP (Best Current Practice) Updates,In particularAudience injection and mix-up attacksVariants ofmeasures were discussed.Finally, OAuth identity and authorizationInter-domain integration, and Spiffe credentialsAutomatic OAuth client registrationSuggestions regarding this are also presented.

The second session will be held today at 9:30pm Japan time.

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

(The following is a slightly revised summary from NotebookLM.)

1. Challenges of AI Agent Authentication

Jonathan Rosenberg and Pat White asked for help from the OAuth community on new authentication challenges raised by the emergence of AI and AI agents.

  • Issue 1: Privilege issues with AI chatbots and voice bots
    • Customer support bots (chatbots and voice bots) call APIs and perform actions on behalf of users (e.g. reordering a prescription).
    • Today, these bots are typically built with highly privileged service accounts. “Most things today are built with service accounts for these bots, and they’re, you know, typically pretty highly privileged, because they need to be able to act on behalf of any user that’s calling into your company.”
    • The introduction of large language models (LLMs) increases the risk that bots will "hallucinate" or make misinformed API calling decisions.
    • The goal is to move away from "god-like service accounts" and develop an authentication framework that grants bots only tokens that represent the users themselves.
    • When a user identifies themselves over the public switched telephone network (PSTN) (e.g., the last four digits of their SSN, address), the challenge becomes how to use that information to obtain a token for the user.
    • (Sakimura's opinion) Wouldn't it be better to use CIBA for this?
  • Challenge 2: Privilege Escalation in Autonomous AI Agents
    • Autonomous agents with no UI (e.g. trading bots) that need to temporarily elevate their privileges under certain circumstances (e.g. temporarily elevating email viewing privileges to reply to an urgent email).
    • "The bot needs to be able to request a token with the appropriate permissions to do what it needs to do."
    • "This means that the bot needs to request some sort of privilege escalation that is sent back to the user for human approval." This should be done for a limited time and duration.
    • (Sakimura's opinion) Wouldn't it be better to use CIBA for this?
  • Related security issue: AI verification flow (Human-in-the-Loop)
    • Scenarios where a human needs to review and approve before an AI agent can call an API. "The problem is that an AI agent wants to call an API, but can't be trusted to do it right. It wants to consult with a human, have the human approve the operation, and then the API can be called."
    • This has been identified as an OAuth adjacent issue and a draft has been submitted as "draft-rose-check-00". Tim has argued that this is within the scope of OAuth.
  • Feedback from the OAuth community
    • Jeff Lombardo (AWS) pointed out that existing OAuth features (specifically Client Initiated Backchannel Authorization (CIBA)) could address many of these issues: "When we say we're not going to give you some god-like token, I think that's exactly why OAuth was created."
    • Hannes Tschofenig made an interesting observation in that agents should not manipulate tokens directly and should be decoupled from the authentication infrastructure: "Ideally, agents should not touch tokens at all - not god-like tokens, not ephemeral tokens, not any tokens."

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

Brian Campbell discussed the progress of SD-JWT VC and the important discussions surrounding the handling of DIDs (Decentralized Identifiers).

  • Overview of SD-JWT VC
    • It defines the data format, validation, and processing rules for representing verifiable credentials in a JSON payload.
    • It is based on the SD-JWT format and existing JWT content rules and extensibility model.
    • Describes SD.VC issuer metadata and key resolution technology similar to OpenID Connect.
    • It does not utilize the W3C Validable Credential Data Model (VCDM) 1.1 or 2, nor does it require or prohibit it. When used in conjunction with OpenID for Verifiable Presentations, it references SD-JWT-VC-LD.
  • Recent Changes (Draft 9 & 10)
    • Mostly editorial updates, encoding fixes, updated examples.
    • The Issuer Signing Key Verification section has been renamed to "Issuer Signing Mechanisms" to clearly define the extension point for signing key verification options.
    • Two general mechanisms have been defined: Web-based metadata resolution (using well-known URIs and JWKS) and an inline X.509 variant (using the x5c JWS header).
    • It was clarified that the acceptable mechanisms depend on the verifier's policies (e.g., trusted CA lists), and validation of one mechanism is sufficient.
  • Discussion on including DID in SD-JWT VC spec
    • Reasons for non-inclusion (as argued by Brian Campbell):
      • Complexity and cognitive overhead: The DID method registry has over 200 methods, making it impractical for most developers to implement them all. This hurts interoperability: "The proliferation of over 200 DID methods makes it unreasonable for most developers, most average developers, to implement them."
      • Reputation risk: The inclusion of 200 unconventional DID methods could damage the credibility and perceived seriousness of standards-track IETF documents: "The potential damage to the credibility and perceived seriousness of standards-track IETF documents by the inclusion of 200 poorly curated DID methods that do not have broad consensus in any given community."
      • Scope deviation: Guidance regarding DID is beyond the expertise and scope of this Working Group and document: specific profiles should define DID method choices and policies.
    • The need for inclusion (as argued by Marcus and Stefan):
      • In the past four debates, there has been strong opposition to removing DID support.
      • "This change should be reversed."
      • Stefan argued that the previous statement about DID was requested to explain how the extension was used, and that removing it was a retrograde step.
      • There is no need to implement all 200 DID methods, and standardization of DID methods is underway at European level: "Please stop repeating information about the 200 non-standardized DID methods. There is a standardization project underway at European level San JC19, where they will explicitly standardize these DID methods."
      • DID support used to be required and then became optional, so we shouldn't burden developers who don't want to implement it.
    • Voting results:A vote was taken on whether to include DID in the document.
      • 7 votes in favor, 40 votes against, 9 no opinion.
      • As a result, it was decided not to include DID in the core document. The proponents should publish a profile or a separate RFC for the DID work. "That option should be taken by the proponents: publish this RFC with what we have today, start a profile for the DID work, and publish that as well."

3. Updates to RFC 7523 BIS

Mike Jones discussed the updates to RFC 7523 bis, particularly in addressing known security vulnerabilities.

  • Purpose: Addressing a vulnerability that exploits ambiguous audience values targeted at authorization systems.
  • RFCs covered: Updates 7521, 7522, 7523, and 9126 (Push Authorization Requests).
  • Change in approach: It was previously envisioned as a complete replacement for 7523, but discussions at IETF 122 led to the decision to focus on being a point update to existing RFCs. "Instead of replacing 7523, we're going to do a point update."
  • Main changes:
    • Removed the update to Signed JWT request format (as it was already the "right thing to do").
    • Added reference to the University of Stuttgart paper describing the vulnerability.
    • Expediting the IETF process (for security fixes) has been confirmed with Deb's help.
  • Open issues:
  • Explicit Typing: There is some debate about whether to require an explicit type so that authorization servers can distinguish between old and updated 7523s.
  • SAML Authentication Grant: Specific language adjustments regarding audience restrictions.
  • Enforce single string audience: The current spec says that audience values should be single strings, but there is debate about the need for change because existing implementations like Kubernetes use arrays: "Audience values should be single strings, but Kubernetes has code that only uses arrays for audience values."
  • The subtleties of grant audience checking.
  • Document Title: There have been suggestions to change the current title ("7523 BIS"), and Mike Schwarz and Brian Campbell have suggested new titles.
  • Future steps: The goal is for ongoing discussion, issue resolution, public draft release, and eventual Working Group Final Call. As this is a security fix, the goal is to release it quickly.

4. Updates to OAuth Security BCP

Pedram and Kaiuan presented updates to the OAuth Security Best Current Practice (BCP), which are intended to address two newly discovered attacks.

  • Why this happened:
    • To address two new attacks (Audience Injection attack and a variant of the Mix-Up attack) that were discovered after the BCP was finalized.
    • As a result of discussion at IETF 122, the decision was made to add it to BCP 240 as a new RFC, and to include only the considerations of new attacks.
  • Audience Injection Attacks (Pedram)
    • Summary of the attack: A detailed explanation of how an attacker can obtain a client authentication assertion and pose as a client, including a list of specific endpoints (e.g. push authentication endpoint, device authentication endpoint, etc.).
    • Root causes and solutions: The attack can only be prevented by the client, which is encouraged to use a single audience value (either the issuer identifier of the AS or the exact URI of the target endpoint).
  • Mix-Up attack variant (Kaiuan)
    • Motivation: The widespread presence of new Mix-Up attack variants affecting platforms including major vendors such as Google, Microsoft, Amazon and Samsung. "We have discovered new Mix-Up attack variants that are rampant almost everywhere," which is due to a lack of clear standards and practices in platform configurations.
    • Attack Focus: Instead of a single app that works with multiple IDPs, we focus on an "integration platform" that works with many integrated apps.
    • Attack variant: Cross-Flow Account Takeover (C-FAT): The victim's authorization code is revealed to the attacker.
    • Code Injection (CI): The attacker's code is injected into the victim.
    • Root cause: Ambiguity in how OAuth clients distinguish between integrated apps (e.g., relying solely on session or redirect URIs).
    • The "shared issuer" concept: If two integrating apps can legitimately share the same authentication server (e.g. two Dropbox integrations on the same platform), then the publisher identifier alone cannot uniquely identify each integration.
    • countermeasure: OAuth clients should distinguish each integrated app with an unambiguous redirect URI, which enforces that the app that initiates OAuth must be the same one that completes it. This defensive measure is adopted by many enterprises.
  • Future steps:
  • Further discussion (especially offline coordination with the Chair) to advance this document to a Working Group Draft.
  • Possibility of holding a virtual interim meeting to hold in-depth discussions.
  • Document review and feedback is requested from participants.

5. Updates to the JWT Security BCP

Yaron and Mike Jones announced an update to the RC8725 JWT Security BCP, which also addresses newly discovered attacks.

  • Motivation for the update: A number of new attacks against JOT have been discovered, including one disclosed at Black Hat in the summer of 2023 and a CVE by researchers at Tsinghua University.
  • Proposed changes (5 pull requests):
  • Maximum number of iterations for password-based key generation: To prevent denial of service attacks.
  • JWS/JWE confusion: To address the case where a verifier accepts a JWE when expecting a JWS. "This occurs especially when the JWE is public key encrypted and the verifier stores the public key together with its private key." Add normative language to ensure it is a JWS.
  • Case Sensitive: To combat attacks that manipulate capitalization to circumvent the "none" algorithm's blocklist, we recommend coding defensively (using allowlists instead of blocklists).
  • Compression Abuse: To address potential abuse of the compression functionality supported by JWE.
  • Rejecting a JSON-Serialized JWS: To address an issue where some verifiers would accept a JSON-serialized JWS even though the standard does not allow it.
  • Future steps: The document is in good condition and we hope to have it adopted and progressed by the Working Group as soon as possible. Reviews have already been received from Aaron and Denny Pinkas. Brian Campbell noted that further updates may be necessary and that this could be a larger undertaking, including deprecating the Password Based Key Derivation Function 2 (PFB) approach algorithms and aligning with existing documentation on deprecating the "none" algorithm.

6. Cross-domain federation of OAuth ID and authentication

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

  • Purpose: To profile two existing RFCs and explain how identity and authentication information can be persisted across domains in a way that is done in practice in many places but is difficult for many to understand.
  • Main approaches: It uses a local RFC 8693 token exchange to obtain tokens and facilitates RFC 7523 cross-domain access permission grants.
  • Recent changes (Draft 05): Mostly editorial updates, plus adding metadata to describe the token types supported by the local AS.
  • Open issues: There are four open issues, most of which are editorial: one is about reflecting Mike's changes in the assertion profile, but the impact is expected to be small.
  • Proposals for the Working Group Final Call: The document is ready for Working Group Final Call (WGLC) and rapid progress is expected. "Consider the Working Group Final Call."
  • Related work by Aaron Perki (Identity Assertion Authorization Grant):Brian also mentioned Aaron Perki's work, which is related to Brian's own paper, the Identity Assertion Authorization Grant, which is a profile of Brian's paper for a more specific and meaningful use case.
  • This work is increasingly relevant for Agentic AI use cases, especially in enterprise environments, as it allows OAuth-based systems to obtain access tokens on behalf of users without the end-user's explicit permission.
  • "This work began long before the advent of Agent AI, but is particularly relevant and meaningful for Agent AI use cases in an enterprise context, where end-user consent is effectively provided through the employment contract, without the need to obtain end-user consent for each transaction."
  • Aaron's blog post and diagrams were presented showing how an AI agent can log in from an enterprise IDP and use the SSO token for cross-domain access to applications like Slack.
  • Community Response: There was little opposition to the WGLC proposal: this work is important and directly relevant to the enterprise environment.

7. OAuth Client ID Prefix

Brian Campbell discussed the "OAuth Client ID Prefixes" draft that Aaron, Daniel and Joseph are working on.

  • Purpose: It provides a simple and practical way for clients to publish metadata, allowing authorization servers to establish client identities without the need for pre-registration of clients. This is useful in many use cases where pre-registration is impractical, such as connecting an open source chat app to a self-hosted server, or an app connecting to a self-hosted service like Mastodon or WordPress.
  • Relationship to previous drafts: It has been split off and renamed from the previous "Client ID Metadata Document" draft.
  • concept:
    • Clients publish JSON documents to a stable URL using the client registration vocabulary (fields defined in the dynamic client registration).
    • In your authorization request, pass that URL as the client ID.
    • The authorization server retrieves the JSON document from that URL and uses it to establish the client's identity (configuration parameters, public key for authentication, etc.).
    • It offers an alternative approach to client onboarding that does not require pre-registration.
  • AI relevance: This approach also lends itself to Agentic AI, which, while not a new problem in terms of software accessing resources, its scale and potential problems highlight a long-standing issue: pre-registration is a roadblock to many deployments.
  • Discussions and challenges:
    • Disadvantage: The benefits of pre-registration (e.g. redirect URI validation) may be lost. Solutions being considered include hard-binding client IDs to documents and showing verified URLs to users.
    • Trust Management: The similarity with OpenID Federation was noted and the reasons why OpenID Federation has implemented complex trust management mechanisms (automation in large scale deployments, trust marks, etc.) were highlighted, and the lack of such trust management mechanisms was cited as a challenge in this draft.
  • Future steps: It was determined that the document is not yet ready for the WGLC, and an interim meeting will be held for further discussion and resolution of issues.

8. OAuth Client Registration with Spiffe Credentials

Pieter Kasselman presented two drafts on automatic registration of OAuth clients using Spiffe Credentials.

  • Need for automatic client registration:
  • Operational challenges: Manual management of clients and secrets, rotating secrets, and securely storing them can be time-consuming, error-prone, and lead to downtime. "Managing clients and secrets, rotating secrets, and securely storing them can be time-consuming and manual, or you have to create a lot of processes to follow."
  • Heterogeneous environment: Manual work across different organizations and technology stacks creates a lot of coordination and overhead between developers and identity administrators.
  • Exponential growth: Increased workloads, especially the contribution of AI, have led to an exponential increase in clients and secrets, making them difficult to manage for large organizations.
  • About Spiffe:
    • Spiffe (Secure Production Identity Framework For Everyone) aims to solve this "turtle at the bottom problem" by bootstrapping credentials without provisioning secrets to workloads.
    • It works through attestation and ongoing lifecycle management.
    • It can be deployed at scale and open source and commercial solutions are available.
    • Spiffe benefits OAuth deployments by shifting client management responsibilities to the platform level and focusing on workloads, allowing OAuth servers to rely on the Spiffe infrastructure for credential issuance, lifecycle management, and identity proofing.
  • Two approaches are proposed:
    • 1. Register on First Use approach:
      • When a client presents a Spiffe credential, the authentication server, since it already trusts the issuer, validates the credential and automatically trusts and registers that client ID.
      • No additional registration protocols are required, making it efficient and low latency.
      • Suitable for client credential flow.
      • The redirect flow requires an additional metadata management strategy (possibly aligning with Brian and Aaron's previous work).
    • 2. Using Spiffe JWT as a Statement of Software (Dynamic Client Registration):
      • Spiffe uses JWT as a statement of software as part of its dynamic client registration protocol.
      • No new protocols are required and it is compatible with existing dynamic client registrations.
      • This is useful for dynamic client registration as adopted by MCP (Mobile Connect Profile).
      • It only supports JWT, but can be generalized to other credential types.
  • Future steps:
    • We would like to hear input on whether automatic client registration is something that is of interest to the OAuth community.
    • Discuss whether the Spiffe approach is interesting.
    • If you're interested, invite participation through comments, issues, or PRs.
    • This provides a simple, scalable, and secure mechanism for client registration, and helps address the problem of secret proliferation.
  • Community Response:
    • This work is seen as highly relevant if Spiffe is adopted in OAuth deployments, as it can simplify the registration process.
    • Jeff Lombardo (AWS) seconded that this is something that the Working Group should address.
    • Mike Jones suggested using a different term, "Automated Client Enrollment," since that term is already clearly defined in OpenID Federation.
    • Joseph pointed out that the classification into redirect and non-redirect flows may not be accurate, commenting that redirect flows may also fall into the first case if a push authentication request (PAR) is used.
    • Tony Nadlin raised concerns that the documentation does not explain how to establish trust domains and how to use Spiffe in certain instances.
    • Brian Campbell recognized the overlap with the "Client ID Prefixes" work he announced and emphasized the need for alignment.
Pin

Leave a comment

This site uses Akismet to reduce spam.For details of how to process comment data, please click here.