**Session Date/Time:** 06 Oct 2025 17:00

# [OAUTH](../wg/oauth.html)

## Summary

This interim meeting featured a presentation and discussion of the individual draft "OAuth 2.0 Client Authentication with SPIFFE". The draft proposes a method for workloads leveraging SPIFFE (Secure Production Identity Framework For Everyone) credentials to authenticate as OAuth 2.0 clients, building upon existing RFCs like 7523 and 8705. The discussion focused on the technical approach, industry interest, and the appropriate scope for an IETF document versus a SPIFFE-specific profile. The outcome was a call for reviews from the working group to inform future discussions.

## Key Discussion Points

*   **Introduction of "OAuth 2.0 Client Authentication with SPIFFE"**: Arnd presented the individual draft. The motivation stems from the widespread use of SPIFFE in enterprise environments for workload identity, providing automatically provisioned, short-lived, proof-of-possession credentials for inter-workload communication.
*   **Problem Statement**: While SPIFFE handles workload-to-workload authentication efficiently, current OAuth 2.0 client authentication often requires manually provisioned, long-lived client IDs and secrets, creating "secret sprawl" and security challenges for SPIFFE-enabled workloads interacting with OAuth 2.0 authorization servers.
*   **Proposed Solution**: The draft proposes leveraging existing SPIFFE credentials (X.509 SVITs and JWT SVITs) for OAuth 2.0 client authentication. This would eliminate the need for separate client secrets, streamline lifecycle management, and improve security.
*   **Technical Approach**:
    *   For JWT SVITs: Uses RFC 7523 (JWT Profile for Client Authentication and Authorization Grants).
    *   For X.509 SVITs: Uses RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate Bound Access Tokens).
    *   **SPIFFE Specifics**: The authorization server validates client assertions by fetching signing keys from a "SPIFFE bundle endpoint" which is a JWKS endpoint publishing X.509 and JWT signing keys, specific to SPIFFE's trust domain model.
*   **Clarification on "SPIFFE" in the Diagram (Hannes)**: Arnd clarified that "SPIFFE" in the context of the diagram refers to the SPIFFE Workload API, which delivers SVITs to workloads, abstracting the underlying SPIFFE architecture (e.g., Spire agents).
*   **Industry Adoption and Momentum**: Arnd noted significant interest and early implementations, including a preview feature in Keycloak 26.4. He demonstrated Keycloak using a SPIFFE ID as a client ID, validating assertions against a SPIFFE bundle endpoint, and employing a new `short-dash-spiffy` client assertion type.
*   **Scope and Applicability**: The draft focuses purely on client authentication, requiring pre-registration and trust establishment. It supports both human-involved (e.g., Authorization Code Flow with PKCE) and human-less (e.g., Client Credentials Grant) OAuth 2.0 flows.
*   **Discussion on IETF Scope vs. SPIFFE Profile (George, Aaron)**:
    *   George raised a question about the management change if client identification moves from individual pre-registered keys to trust domains, and whether the IETF should ratify a SPIFFE-specific implementation. Arnd confirmed that individual SPIFFE IDs *are* pre-registered as clients.
    *   George questioned the value of an IETF document for a SPIFFE-specific profile when SPIFFE could publish its own layering guidance.
    *   Arnd argued that the document profiles the *OAuth authorization server* (e.g., introducing a new client assertion type for SPIFFE-specific processing rules), not SPIFFE itself, thus justifying its placement within the IETF OAUTH working group to maintain consistency and security guarantees across OAuth standards.
    *   Aaron expressed a similar struggle in drawing the line between what belongs in the OAUTH WG versus a community-specific profile, acknowledging the lack of a clear pattern in this area historically.
*   **General Positive Feedback**: Fleming, Brian, and Aaron indicated general support for the document's goals and utility.

## Decisions and Action Items

*   **Action Item**: The chairs requested working group members to review the current draft ("OAuth 2.0 Client Authentication with SPIFFE") before the IETF 128 meeting in Montreal.
    *   **Volunteers/Commitments**: Brian, Aaron, Arnd, George, and Fleming committed to reviewing the document.

## Next Steps

*   The draft authors will incorporate feedback from the reviews into a new iteration of the document.
*   The updated draft will be presented at the OAUTH Working Group meeting at IETF 128 in Montreal.
*   Following reviews and the Montreal presentation, the working group will gauge interest in adopting the draft as a working group item.