IETF 123 Madrid OAuth WG Day 2 Summary
Authorization Events FAPI identity IETF

IETF 123: OAuth WG Session 2 Summary (25th Japan time)

Nat 2025-08-01 No Comments

It's been a while, and my memory is a bit hazy... Below, I've compiled it in NotebookLM, so I'll try to remember it by rewriting it... (I hate how forgetful I get as I get older...)

Overview

The second session of the OAuth WG was held at IETF 7 Madrid on July 25th, Japan time. The agenda announced in advance is as follows:

Below we have summarized the main themes, important ideas, and facts. (Thanks NotebookLM!)

1. Token Status List

  • Scalable Revocation MechanismToken Status List is designed as a scalable revocation mechanism, with a focus on privacy properties, ease of understanding, and ease of implementation, while also being compatible with JOSE and COSE-based credential formats.
  • Extensive references and testing: It is currently referenced in ISO mDL and mDOC, and is listed as one of the status mechanisms in the European ARF. It has been tested in numerous test events and hackathons with good results.
  • Establishing an extension point and registry: This draft goes beyond a single mechanism and establishes an extension point and registry for status mechanisms in general.
  • Major changes:
    • Since the previous IETF, three revisions have been made, primarily editorial changes.
    • A major change is that the request header Accept when requesting a status list token from a client has been relaxed from "must" to "should."
    • The defined Key Usage OID fields are now available for use by other mechanisms in the IANA registry created by this draft.
  • Current status: All open issues and pull requests have been incorporated, currently awaiting shepherd review and seeking guidance on how to expedite this.

2. Backend Attested Client Authentication

  • the purpose: Due to the limitations of traditional confidential client authentication, we establish a mechanism that allows front-end instances to obtain attestation and use it directly as client authentication to the authentication server.
  • Flow Overview: A client instance generates an attestation key and executes a protocol (outside the scope of the draft) with the backend to obtain an attestation in the form of a JWT. This client attestation and its proof are jointly used to authenticate with the authentication server.
  • Changes since IETF 122:
    • Clarifications to client identity handling, client attestation usage, and general language.
    • Added OAuth error response values.
    • The most significant change is that we have deprecated the HTTP OPTIONS mechanism for obtaining the challenge in favor of a dedicated challenge endpoint that uses the HTTP POST verb, which solves the issue of multiple preflight requests in browser environments.
    • Updated security and implementation considerations (e.g., replay protection, use of JTI).
  • Discussion on optimization with DPoP:
    • If this client authentication mechanism is used in combination with DPoP (Demonstration of Proof-of-Possession), the authentication server must validate three JWTs: the client attestation, the client attestation PoP, and the DPoP attestation.
    • A possible optimization was discussed: if the Client Attestation PoP and DPoP attestation keys are the same, use DPoP attestation instead of Client Attestation PoP, which would reduce request headers and improve efficiency.
    • Regarding security concerns, opinions were expressed that there is no problem with reusing the same key to send signed messages to the same entity.
    • This optimization is not required, and clients should be prepared to work with or without DPoP.
  • Major unresolved issues:
    • The challenge endpoint is considered resolved and feedback is sought on adopting DPoP optimizations. The draft does not mention the use of attestation headers on resource servers, so feedback is sought on whether to expand on the details or remove them entirely.

3. Transaction Tokens

  • the purpose: A mechanism that maintains access tokens and allows for token exchange within a given trust boundary while preserving the context (subject, context, authorization details), reducing the risk of access token leakage and enabling the deployment of more fine-grained authorization.
  • Changes since IETF 122:
    • Scope consistency: The wording has been tightened to ensure that transaction tokens do not have a broader scope than the original access token.
    • Distinguishing between authentication and authorization: Clarified that transaction tokens are an authorization construct, not an authentication construct.
  • HTTP header formatting issues:
    • Feedback from IANA reviewers concluded that none of the existing HTTP structured header types were suitable for this purpose.
    • As a result, it was decided to keep it as an unstructured header, which eliminates the risk of future issues.
    • The discussion also suggested that a request for new structured headers could be submitted to the HTTP Working Group in the future, but this would not prevent the specification from moving forward.
  • Current status: The developers are aware of no major outstanding issues, and the HTTP header format issue is also considered resolved.Ready to proceed to WGLC.

4. Spiffe Client Authentication

  • back groundSpiffe (Secure Production Identity Framework For Everyone) is a framework for establishing and verifying the identity of workloads in cloud-native environments. Currently, workloads use Spiffe's SVID (SPIFFE Verifiable Identity Document, X.509 certificate or JWT (see note at the end of this article)) to communicate with other workloads, but require manually provisioned, long-lived client IDs and client secrets to authenticate with authentication servers.
  • Purpose of the proposal: Allows SVIDs to be used as a means of authenticating to authorization servers, with short-lived certificates and key attestations that are automatically provisioned and rotated by Spiffe, leveraging existing infrastructure and reducing the number of secrets that need to be protected.
  • Proposal Content:
    • We profile the client authentication part of RFC 7523 for JWT SVID, and the MTLS client authentication part of RFC 509 for the X.8705 SVID.
    • The authorization server verifies the SVID by fetching the key from the Spiffe bundle endpoint (similar to JWKS), a Spiffe specification.
  • Key discussion points:
    • ISS Claim Requirements: Spiffe's JWT SVID hasissRFC 7523issCould the requirements for claims be relaxed or could Spiffe usersissThere was discussion about whether claims validation should be required, which also raised the possibility of recommending an OpenID Connect Discovery-based key distribution mechanism.
    • Treating the audience: It has been confirmed that Spiffe can obtain a JWT with a specific audience, and based on RFC 7523 and RFC 25 BIS, the audience is expected to be the authentication server.
    • Single Draft vs. Split Draft: It was mentioned that there is room for discussion as to whether both JWT SVID and X.509 SVID should be addressed in a single draft or whether they should be split into separate drafts according to their respective characteristics.
    • Current status: This is a new document and your review and feedback is requested.

5. Refresh Token Expiration and Consent Expiration

  • the purpose: We introduce a mechanism for two different but related concepts: refresh token expiration and user consent expiration, which allows for proactive notification to users and proactive token rotation by clients.
  • Examples of usage:
    • Expiry of consent: Google's clients have requested that we notify users in advance before their consent expires to prevent service interruptions.
    • Refresh Token RotationIf your client uses tokens infrequently (e.g., only when a user visits your site), you may need to know whether aggressive rotation is necessary.
  • Proposal Content: Add two new parameters refresh_token_expires_in and consent_expires_in to the token endpoint response, which can have different values.
  • Key discussion points:
    • Time-Limited Token Request Parameters: Do you need to define parameters for clients to request time-limited tokens (e.g., in the authorization flow request or token endpoint request)?
    • expires_in vs expires_at: The current RFC 6749 uses expires_in (relative time) for access tokens, but the convenience of expires_at (absolute time) (clients do not need to check the system time, and local caching is possible) was discussed. If expires_at is adopted, it will be considered whether to add expires_at to access tokens for consistency.
    • Consent terminologySince the term "consent" is not explicitly defined in the base OAuth specification, the appropriateness of introducing this concept into parameter names was discussed. Terms such as "grant" were suggested as alternatives.
    • Implementation notes: Should we add a non-normative implementation note about how authorization servers should handle consent expiration?
  • Current statusA draft exists and is seeking feedback and review. In particular, concerns have been raised about the consent terminology, the use of expires_at, and its connection to the grant management API.

6. Browserless App-to-App Federation

  • back groundThe models proposed in OAuth RC8252 (app-to-web) and Joseph Heenan's (Authlete's CTO) "app-to-app" blog work well when the client app and the authorization server app belong to the same trust domain. However, in federated scenarios across multiple trust domains (e.g., academic institutions or multinational corporations), the browser is required for intermediate redirects, resulting in a poor user experience and potential issues (cookie issues, deep link prompts, etc.).
  • problem:
    • Redirects through the browser create a poor user experience (delays, stuttering, cluttered tabs).
    • If a different browser (such as a Web View) is used, the flow may be interrupted due to cookie inconsistencies, etc.
  • Purpose of the proposal: The app acts as its own user agent and handles redirects directly, bypassing the browser, enabling federation across multiple trusted domains.
  • Proposal Content:
    • The client app acts as its own user agent and follows redirects as an HTTP client.
    • It finds each URL, checks if there is an app on the device that corresponds to it, and if so, calls that app directly.
    • After the Authentication app authenticates the user and authorizes the operation, it shares a deep link URL between the two apps, and the Authentication app, contrary to best practices, trusts this native callback URL and returns a callback along with a redirect URL.
    • Trust can be established using OpenID Federation, Automatic Client Registration (←someone suggested that this should be renamed as it is different from OpenID Federation's Automatic Registration), or pre-registered trust in a closed ecosystem.
  • Key discussion points:
    • Authentication server behavior: The feasibility of a scenario where the authentication server returns successive 30x redirects without user interaction.
    • Security Considerations: Concerns about the user's security awareness (which origin they are authenticating with) decreasing due to not using a browser. The proposal focuses on redirect chains that do not result in user interaction.
    • Fallback OptionsAlways provide a browser fallback option in case browserless is not possible.
  • Current status: It was announced at OSW and there are active use cases. We are planning to collaborate with the University of Stuttgart for security analysis and are seeking feedback and support. A metadata option (Declaration of Native Authentication Endpoint) has also been proposed for authentication servers to declare that they support this profile.

7. Client Extension Claims

  • back ground: By including information about the use of OAuth security mechanisms (e.g., MTLS, DEOP, Private Key JWT) in the access token payload, resource servers can use this information for policy decisions. Currently, this information is scattered across various locations, such as HTTP headers (e.g., DPoP), token types (ID token and access token), authorization grant flow types (e.g., Device Code, Client Credentials), and client authentication methods, which requires complex processing.
  • problem:
    • It is complicated to determine the type of token (ID token or access token).
    • There is insufficient information about the authorization grant flow used.
    • Lack of information about key bindings (PKCE, RAR, JAR).
    • Lack of information about client authentication methods (Private Key JWT, MTLS).
    • The problem arises when this information is scattered across HTTP headers and backend policy decision points only have access to the payload.
  • Proposal Content: Introduces four new claims to the access token payload.
    • gty (Grant Type): A single string describing the type of grant flow used.
    • cxt (Client Extension Type): An array of strings describing the combination of client authentication extension methods used, such as Pixie, DPoP, or JAR.
    • ccr (Client Credential Reference): Corresponds to a user's ACR claim and provides a namespace for conveying trust between ASs and ARSs.
    • cmr (Client Method Reference): We plan to describe client authentication methods (e.g., MTLS) and register values in the IANA registry.
  • 利 点:
    • Because it does not introduce any new request parameters, authorization servers can return these claims without modifying their existing APIs.
    • You can declare support for these features by introducing a runtime_type_extension in your authorization server's metadata.
  • Key discussion points:
    • Similarities with Vectors of Trust: The relationship to Vectors of Trust (RFC 8584), an existing mechanism for representing various elements of a trust decision.
    • Standardization of gty valuesThere are vendors, such as Okta and Auth0, that already use claims like gty, but the values may vary, so standardization is needed.
  • Call for reviewers: Documentation review and feedback is requested.

8. Step-up Authentication at the Authorization Layer

  • back groundRFC 9470 (Step-Up Authentication) provided a mechanism for resource providers to request stronger authentication from clients by returning additional information (e.g., a different ACR) via the WWW-Authenticate header, but this was focused on the authentication layer and lacked the ability to send a similar signal at the authorization layer (access control decisions).
  • problem:
    • There is a lack of a way for resource providers to communicate to clients more detailed information (e.g., specific requirements or conditions) about why they cannot proceed.
    • Frameworks like FAPI 2.0 and Smart on FHIR support client authentication requirements and Rich Authorization Requests (RARs), but they require the ability for resource servers to send more detailed signals to guide clients through the next steps.
    • With the advent of the Shared Signal Framework (SSF), resource provider decisions can change dynamically, making it necessary to keep clients updated.
  • Proposal Content:
    • To enable signaling at the authorization layer, certainError codeとChallengeIntroduce.
  • Specific Challenges:
    • The ability for a resource server to instruct a client to refer to its own OAuth 2.0 Protected Resource Metadata.
    • The ability to guide clients on what to do next in the form of a Rich Authorization Request (RAR).
  • Response envelopeAs it relates to authorization, we use the RAR authorization_details format as the response envelope, which allows us to communicate information to the client, such as specific requirements for payment, in a format that conforms to the existing RAR specification.
  • Benefit:
    • The client receives further guidance from the resource server to construct the appropriate authorization request and obtain a new access token.
    • It strengthens alignment with existing specifications such as FAPI 2.0, Smart on FHIR, and MCP.
  • Key discussion points:
    • HTTP status code 401 vs 403: While RFC 9470 uses 401, this proposal suggests using 403 for authorization-related issues. However, the use of 2.0 is formalized in the OAuth framework and FAPI 401, and some servers may consider 403 to be a final state, so we are seeking feedback on this point.
    • Payload and HeadersThere was some discussion about whether to include the information in the payload or in the header (e.g., including the JWT in the header).
    • Consistency with GNAP: Consistency with GNAP (General Authorization and Negotiation Protocol) is also a consideration.
  • Current status: It has been streamlined from the previous complex solution presented at OSW. We are looking for your feedback and reviews.

9. Pushed Client Registration

  • back ground: OAuth is built around client IDs, but the traditional concept of persistent client IDs doesn't necessarily apply to ephemeral clients like SPAs or native app instances. Previous solutions (dynamic registration, OpenID Federation, etc.) have had challenges, such as managing the lifecycle of client IDs after registration (e.g., accumulating a large number of unused client IDs).
  • problem:
    • Proper management and lifecycle of client IDs for ephemeral clients.
    • The need to clean up excess client IDs after dynamic registration.
    • Client metadata hosting needs.
  • Proposal Content: Based on PAR (Pushed Authorization Requests), it proposes a way to authenticate itself dynamically without explicitly using a client ID.
    • PAR RequestThe client makes a PAR request and uses a special keyword like "dynamic" in the client_id parameter, and also pushes a client metadata document.
    • PAR response: The auth server does not return a client ID, only the regular request_uri.
    • Authorization EndpointThe client accesses the authorization endpoint using the request_uri, again using the "dynamic" keyword as the client_id.
    • Token EndpointAfter obtaining the authorization code, the client makes a request to the token endpoint, again using the "dynamic" keyword as the client_id and providing proof of the key introduced in the original pushed authorization request.
  • Benefit:
    • It eliminates the extra round trip of dynamic registration and the need to remove lingering client IDs.
    • You can push instance-specific information without having to host client metadata.
    • You can push information that can be bound to your client's trust infrastructure, such as client attestations and software statements.
  • Key discussion points:
    • The need to solve the problem: Is this a problem that needs to be solved by the community as a whole?
    • Coexistence of multiple approaches: Regarding the current situation where multiple different solutions to the client ID problem have been proposed, the possibility of coexistence and the need for a unified approach.
    • Coverage Guardrails: The need to set strict guardrails for use cases where this approach makes sense.
  • Current statusThe prototype implementation is functional and has not identified any significant security concerns. Discussion is requested on whether this proposal merits moving forward with the Working Group for standardization.

10. Deferred Keybinding

  • back groundExisting OAuth PoP mechanisms (DPoP and MTLS) require proof of possession of a key to be presented before a token is issued, preventing authentication server spoofing attacks. However, there are real-world use cases where proof of possession of a key must be presented after a token is issued.
  • problem:
    • If keys from different domains need to be bound, the target resource can validate the presenter, but the requesting entity cannot make the request in the same way.
    • Scenarios where a key is held on the device and a token is bound to that key, such as hardware-issued keys on IoT devices, but proof of possession of the key cannot be provided at the time of issuance.
    • A scenario in which the Spiffe agent issues tokens on behalf of a workload and hands them over to the workload, but the Spiffe agent does not possess the workload's private key.
  • Proposal content and direction options: A working group has been asked to discuss how to address this issue.
    • Option 0: Ignore: Declare this behavior as a "bad practice" and discourage it, but in reality there are cases where this has already been done, so it cannot be stopped.
    • Option 1: Document an existing patternDocument existing patterns and use cases, put guardrails around egregious bad practices, and ensure they are only applied where it makes sense.
    • Option 2: Build a protocol specificationBuild a protocol extension that formalizes how unheld confirmation keys can be presented as part of a token request, potentially integrating with existing signature-based mechanisms such as MTLS, DEOP, or HTTP SIG.
    • Option 3: Add a token data specification: Add a way to token data specifications such as JWT and introspection to indicate that a token is a bound key but was not presented at the time of issuance.
  • 引用The basic idea boils down to allowing the client to say “Hey I have my identity that I can prove but the token that you give me I want it bound to somebody else's keys.” And so I want you to give me back the token that is bound to somebody else's keys And trust me I am allowed to do this”
  • Key discussion points:
    • The urgency of the problem: The opinion is that this problem has been seen elsewhere and that if it isn't addressed, no one will be helped.
    • Security risks and potential misuse: Concerns that this mechanism could be abused and is dangerous.
    • Relationship to policies and dynamic behavior: It is unclear whether this problem can be fully solved without policies or dynamic behavior.
    • Similarities with SAML subject_confirmation_data: Conceptually similar to the SAML subject_confirmation_data (cnf) claim.
    • Community Man-Hours: Concerns that building options 2 or 3 would require a lot of effort.
    • Brian's opinion: Expressed preference for option 0 (doing nothing) due to "laziness" and "concern about being exhausted by the work."
  • Current status: The draft is intended to raise issues, not to be adopted or rejected. It is proposed that the Working Group reach a consensus on the direction to move forward through discussion on the mailing list.

OAuth WG Session Recording

(I also appear briefly at the end lol)

(Note about SVID)

SVID (SPIFFE Verifiable Identity Document) is a document defined by SPIFFE.Digital certificates that allow workloads (such as applications and services) to prove their "identity"The SVID acts like a "passport" in the real world.

Major features:

  • Includes SPIFFE ID: Contains a unique identifier specific to the workload (a URI beginning with spiffe://).
  • Digitally signed: It is signed by a Certificate Authority (CA) within a trusted domain, so that a third party can verify its authenticity.
  • 形式: Standardized as X.509 certificate format (X.509 SVID) or JWT format (JWT SVID).
  • Short-term validity & auto-renewal: For security reasons, the validity period is short and it is automatically rotated.
  • Use: Securely authenticate and authorize communications between workloads, such as mTLS (mutual TLS) communications between services and API authentication, without relying on network information such as IP addresses.1345.

To give you an idea, the SVID contains the following information:

  • A single SPIFFE ID
  • If necessary, the public key
  • Digital signature

A service (workload) obtains its own SVID via the SPIFFE Workload API and presents it to the other party.Zero Trust EnvironmentIt plays a central role in making it a reality.

Pin

Leave a comment

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