612 VIEWS
Pinterest LinkedIn LINE

Quite some time has passed, and my memory is already hazy… Below, I will see whether I can remember it while rewriting the summary that NotebookLM made for me. (Getting forgetful with age is no fun…)

Overview

On July 25 Japan time, at IETF 123 Madrid, the OAuth WG held its 2nd session. The agenda announced in advance was as follows.

The principal themes, important ideas, and facts are summarized below. (Thanks, NotebookLM!)

1. Token Status List

  • Scalable revocation mechanism: The Token Status List is designed as a scalable revocation mechanism with emphasis on privacy properties, understandability, and ease of implementation. It is also compatible with JOSE- and COSE-based credential formats.
  • Broad references and testing: It is currently referenced by ISO mDL and mDOC and is listed as one of the status mechanisms in the European ARF. It has been tested at numerous test events and hackathons, with good results.
  • Establishing extension points and a registry: The draft goes beyond a single mechanism and establishes extension points and a registry for status mechanisms generally.
  • Principal changes:
    • Since the previous IETF meeting, primarily editorial changes have been made across 3 revisions.
    • One major change relaxed the requirement for the Accept request header when a client requests a status-list token from “must” to “should.”
    • The defined Key Usage OID field can now be used by other mechanisms in the IANA registry created by this draft.
  • Current status: All outstanding issues and pull requests have been incorporated. The draft is now awaiting shepherd review, and the authors are seeking guidance on how to expedite it.

2. Backend Attested Client Authentication

  • Purpose: Because conventional confidential-client authentication has limitations, this establishes a mechanism by which a frontend instance obtains an attestation and uses it directly as client authentication to the authorization server.
  • Flow overview: A client instance generates an attestation key and executes a protocol with its backend, outside the draft’s scope, to obtain an attestation in JWT format. This client attestation and its proof are used together for authentication to the authorization server.
  • Changes since IETF 122:
    • Clarification of client-ID processing, client-attestation usage, and general language.
    • Addition of OAuth error response values.
    • Most importantly, the HTTP OPTIONS mechanism for obtaining a challenge was removed in favor of a dedicated challenge endpoint using HTTP POST. This resolves the problem of multiple preflight requests in browser environments.
    • Updates to security and implementation considerations, including replay protection and use of JTI.
  • Discussion of optimization with DPoP:
    • When this client-authentication mechanism is used with DPoP (Demonstration of Proof-of-Possession), the authorization server must validate 3 JWTs: the client attestation, client-attestation PoP, and DPoP proof.
    • When the Client Attestation PoP and DPoP proof use the same key, participants discussed the possibility of using the DPoP proof in place of the Client Attestation PoP. This would reduce request headers and improve efficiency.
    • Regarding security concerns, the view was expressed that there is no problem with reusing the same key to send signed messages to the same entity.
    • This optimization is optional, and clients must be prepared to operate with or without DPoP.
  • Major open issues:
    • The challenge endpoint is considered resolved, and feedback is being sought on adopting the DPoP optimization. Because the draft says little about using attestation headers at resource servers, feedback is also requested on whether to expand the discussion or remove it entirely.

3. Transaction Tokens

  • Purpose: A mechanism that enables token exchange within a given trust boundary while maintaining the access token and preserving context, such as the subject, context, and authorization details. It reduces the risk of access-token leakage and enables finer-grained authorization deployment.
  • Changes since IETF 122:
    • Scope consistency: The language was tightened to ensure that a transaction token never has broader scope than the original access token.
    • Distinguishing authentication and authorization: It was clarified that a transaction token is an authorization construct, not an authentication construct.
  • Issue with the HTTP header format:
    • Feedback from an IANA reviewer led to the conclusion that none of the existing HTTP structured-header types was suitable for this purpose.
    • It was therefore retained as an unstructured header, eliminating the risk of future problems from forcing an unsuitable structure.
    • The discussion suggested that a request for a new structured-header type might be submitted to the HTTP Working Group in the future, but this would not impede progress on the specification.
  • Current status: The developers believe that no major open issues remain and that the HTTP-header format issue has been resolved. The draft is ready to proceed to WGLC.

4. SPIFFE Client Authentication

  • Background: SPIFFE (Secure Production Identity Framework For Everyone) is a framework for establishing and verifying workload identities in cloud-native environments. Workloads currently use SPIFFE SVIDs (SPIFFE Verifiable Identity Documents, X.509 certificates or JWTs; notes appear at the end) to communicate with other workloads. Authentication to an authorization server, however, still requires manually provisioned, long-lived client IDs and client secrets.
  • Purpose of the proposal: Enable SVIDs, with short-lived certificates and key-attestation capabilities that SPIFFE provisions and rotates automatically, to be used to authenticate to authorization servers. This makes use of existing infrastructure and reduces the secrets that must be protected.
  • Proposal:
    • Profile the client-authentication portion of RFC 7523 for JWT SVIDs, and profile X.509 SVIDs using the mTLS client authentication in RFC 8705.
    • The authorization server obtains keys from the SPIFFE bundle endpoint, a SPIFFE specification similar to JWKS, and uses them to validate SVIDs.
  • Principal discussion points:
    • Requirement for the iss claim: Because SPIFFE JWT SVIDs do not include an iss claim by default, participants discussed whether the RFC 7523 requirement for iss could be relaxed or SPIFFE users should be required to enable the iss claim. This also raised the possibility of recommending an OpenID Connect Discovery-based key-distribution mechanism.
    • Audience handling: It was confirmed that SPIFFE can obtain a JWT for a specific audience. Under RFC 7523 and RFC 25 BIS, the authorization server is expected to be the audience.
    • Single draft vs. separate drafts: There was a view that further discussion is needed on whether JWT SVIDs and X.509 SVIDs should be covered in one draft or split into separate drafts according to their characteristics.
    • Current status: This is a new document, and review and feedback are requested.

5. Refresh-Token and Consent Expiration

  • Purpose: Introduce mechanisms for 2 distinct but related concepts: refresh-token expiration and user-consent expiration. This enables advance notice to users and proactive token rotation by clients.
  • Use cases:
    • Consent expiration: A request from Google’s client was to notify users in advance before consent expires, preventing service interruption.
    • Refresh-token rotation: When a client does not use a token frequently—for example, only when the user visits a site—it needs to know whether proactive rotation is required.
  • Proposal: Add 2 new parameters, refresh_token_expires_in and consent_expires_in, to the token-endpoint response. They may have different values.
  • Principal discussion points:
    • Parameter for requesting a time-limited token: Whether a parameter should be defined for a client to request a time-limited token, in an authorization-flow or token-endpoint request, for example.
    • expires_in vs. expires_at: RFC 6749 currently uses expires_in, a relative time, for access tokens. Participants discussed the convenience of expires_at, an absolute time, including avoiding a need for clients to check system time and allowing local caching. If expires_at is adopted, whether it should also be added to access tokens for consistency will need consideration.
    • Consent terminology: Because “consent” is not explicitly defined in the base OAuth specification, participants discussed whether it is appropriate to introduce the concept in a parameter name. Terms such as “grant” were suggested as alternatives.
    • Implementation note: Whether to add a non-normative implementation note on how an authorization server handles consent expiration.
  • Current status: The draft exists, and feedback and review are requested. Concerns were expressed particularly about consent terminology, use of expires_at, and its relationship with the Grant Management API.

6. Browserless App-to-App Federation

  • Background: OAuth RC8252, app-to-web, and the app-to-app model proposed in a blog post by Joseph Heenan, Authlete’s CTO, work well when the client and authorization-server apps belong to the same trust domain. In federation across several trust domains, however—at academic institutions or multinational companies, for example—a browser is required for intermediate redirects. This degrades user experience and creates potential problems such as cookie issues and deep-link prompts.
  • Problems:
    • Browser-mediated redirects degrade user experience through latency, fragmentation, and scattered tabs.
    • If a different browser, such as a WebView, is used, cookie inconsistencies may interrupt the flow.
  • Purpose of the proposal: Enable federation across multiple trust domains without a browser by making each app its own user agent and having it process redirects directly.
  • Proposal:
    • The client app becomes its own user agent and follows redirects as an HTTP client.
    • It detects each URL and checks whether an app corresponding to that URL exists on the device. If it does, the client calls that app directly.
    • After the user-authentication app authenticates the user and approves the operation, the deep-link URL is shared between the 2 apps. Contrary to best practice, the user-authentication app trusts this native callback URL and returns the callback together with the redirect URL.
    • Trust can be established through OpenID Federation, automatic client registration (which someone noted should be renamed because it differs from OpenID Federation’s Automatic Registration), or preregistered trust in a closed ecosystem.
  • Principal discussion points:
    • Authorization-server behavior: Feasibility of a scenario in which an authorization server returns a chain of 30xx redirects without user interaction.
    • Security considerations: Concern that not using a browser may reduce the user’s security awareness, including which origin is authenticating them. The proposal focuses on redirect chains without user interaction.
    • Fallback option: Always provide a browser fallback in case browserless operation is impossible.
  • Current status: The proposal was presented at OSW, and active use cases exist. Collaboration with the University of Stuttgart is planned for security analysis, and feedback and support are requested. A metadata option for an authorization server to declare support for this profile, by declaring a native authentication endpoint, was also proposed.

7. Client Extension Claims

  • Background: Include information on the use of OAuth security mechanisms, such as mTLS, DPoP, and Private Key JWT, in the access-token payload so that a resource server can use it in policy decisions. This information is currently scattered across HTTP headers such as DPoP, token types such as ID and access tokens, authorization grant-flow types such as Device Code and Client Credentials, and client-authentication methods, requiring complex processing.
  • Problems:
    • It is complicated to determine the token type, whether an ID token or access token.
    • Information about the authorization grant flow used is insufficient.
    • Information on key binding, including PKCE, RAR, and JAR, is insufficient.
    • Information on client-authentication methods such as Private Key JWT and mTLS is insufficient.
    • The information is distributed among HTTP headers, which causes problems when a backend policy decision point has access only to the payload.
  • Proposal: Introduce 4 new claims in 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 PKCE, DPoP, and JAR.
    • ccr (Client Credential Reference): The counterpart to a user’s ACR claim, providing a namespace for communicating trust between the AS and RS.
    • cmr (Client Method Reference): Describes the client-authentication method, such as mTLS, with values to be registered in an IANA registry.
  • Benefits:
    • Because no new request parameters are introduced, the authorization server can return these claims without changing existing APIs.
    • Introducing runtime_type_extension in authorization-server metadata can declare support for these functions.
  • Principal discussion points:
    • Similarity to Vectors of Trust: The relationship to Vectors of Trust, RFC 8584, an existing mechanism that represents various elements of a trust decision.
    • Standardizing gty values: Vendors such as Okta and Auth0 already use gty-like claims, but their values may differ, creating a need for standardization.
  • Call for reviewers: Review and feedback on the document are requested.

8. Step-Up Authentication at the Authorization Layer

  • Background: RFC 9470, step-up authentication, provided a mechanism for a resource provider to return additional information, such as a different ACR, through the WWW-Authenticate header to require stronger authentication from the client. It focuses on the authentication layer, however, and lacks a similar signal at the authorization layer, where access-control decisions are made.
  • Problems:
    • A resource provider lacks a way to tell a client in greater detail why it cannot proceed, including particular requirements or conditions.
    • Frameworks such as FAPI 2.0 and SMART on FHIR support client-authentication requirements and Rich Authorization Requests (RAR), but resource servers need a way to send more detailed signals guiding clients to the next step.
    • With the advent of the Shared Signals Framework (SSF), a resource provider’s decision may change dynamically, creating a need to give the client current information.
  • Proposal:
    • Introduce specific error codes and challenges to enable signaling at the authorization layer.
  • Specific challenges:
    • Allow a resource server to direct the client to its OAuth 2.0 Protected Resource Metadata.
    • Guide the client on what to do next using the RAR (Rich Authorization Request) format.
  • Response envelope: Because this concerns authorization, use RAR’s authorization_details format as the response envelope. This lets a client receive information such as specific payment requirements in a format conforming to the existing RAR specification.
  • Benefits:
    • The client can receive detailed guidance from the resource server, construct an appropriate authorization request, and obtain a new access token.
    • Improves integration with existing specifications such as FAPI 2.0, SMART on FHIR, and MCP.
  • Principal discussion points:
    • HTTP status code 401 vs. 403: RFC 9470 uses 401, while this proposal recommends 403 for an authorization-related problem. The OAuth framework and FAPI 2.0 formalize use of 401, however, and some servers may treat 403 as a final state, so feedback was requested.
    • Payload vs. header: Participants discussed whether to include the information in the payload or a header, such as putting a JWT in a header.
    • Alignment with GNAP: Alignment with GNAP (Grant Negotiation and Authorization Protocol) is another consideration.
  • Current status: The proposal has been streamlined from an earlier, more complex solution presented at OSW. Feedback and review are requested.

9. Pushed Client Registration

  • Background: OAuth is built around client IDs, but the conventional concept of a persistent client ID does not always fit ephemeral clients such as SPA or native-app instances. Previous solutions, including dynamic registration and OpenID Federation, have created challenges in managing the lifecycle of client IDs after registration, such as accumulating large numbers of unused IDs.
  • Problems:
    • Proper management and lifecycle of client IDs for ephemeral clients.
    • The need to clean up surplus client IDs after dynamic registration.
    • The need to host client metadata.
  • Proposal: Building on PAR (Pushed Authorization Requests), allow a client to authenticate itself dynamically without explicitly using a client ID.
    • PAR request: The client makes a PAR request using a special keyword such as “dynamic” as the client_id parameter. It also pushes a client-metadata document.
    • PAR response: The authorization server returns no client ID, only the normal request_uri.
    • Authorization endpoint: The client accesses the authorization endpoint using the request_uri and again uses the “dynamic” keyword as client_id.
    • Token endpoint: After obtaining the authorization code, the client sends a request to the token endpoint. It again uses the “dynamic” keyword as client_id and proves possession of the key introduced in the original pushed authorization request.
  • Benefits:
    • Reduces the extra round trip for dynamic registration and eliminates the need to delete lingering client IDs.
    • There is no need to host client metadata, and instance-specific information can be pushed.
    • Information that can be tied to a client’s trust infrastructure, such as client attestations and software statements, can be pushed.
  • Principal discussion points:
    • Need to solve the problem: Whether this is a problem the community as a whole should solve.
    • Coexistence of several approaches: Several different solutions to the client-ID problem have been proposed. Participants discussed whether they can coexist or a unified approach is needed.
    • Guardrails for scope of application: Strict guardrails are needed for the use cases in which this approach makes sense.
  • Current status: A prototype implementation works, and no major security concerns have been found. Discussion is requested on whether the proposal is worth advancing toward standardization in the Working Group.

10. Deferred Key Binding

  • Background: Existing OAuth PoP mechanisms, including DPoP and mTLS, require proof of possession of a key before a token is issued. This prevents authorization-server impersonation attacks. Real-world use cases nevertheless exist in which proof of key possession must be presented after token issuance.
  • Problems:
    • When a key from a different domain must be bound, the target resource can validate the presenter, but the requesting entity cannot make the request in the same way.
    • A scenario in which a key, such as a hardware-issued key in an IoT device, is held on the device and a token is bound to it, but proof of key possession cannot be presented at issuance.
    • A scenario in which a SPIFFE agent issues a token on behalf of a workload and hands it to the workload, while the agent does not possess the workload’s private key.
  • Proposal and options for direction: The Working Group is asked to discuss how the problem should be addressed.
    • Option 0: Ignore it: Declare the practice “bad” and discourage it. In reality, however, some cases are already solved this way, so the practice cannot be stopped.
    • Option 1: Document existing patterns: Document existing patterns and use cases, placing guardrails around very bad practices so that they are applied only where they make sense.
    • Option 2: Build a protocol specification: Build a protocol extension formalizing how a verification key that the requester does not possess can be presented as part of a token request. This might integrate with existing signature-based mechanisms such as mTLS, DPoP, and HTTP Signatures.
    • Option 3: Add a token-data specification: Add a way for token-data specifications, such as JWT and introspection, to indicate that a token is bound to a key that was not presented at issuance.
  • Quote: “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”
  • Principal discussion points:
    • Urgency of the problem: The view that this problem appears elsewhere too and that failing to address it will leave everyone without help.
    • Security risks and potential misuse: Concern that this mechanism could be abused and may be dangerous.
    • Relationship with policy and dynamic behavior: It is unclear whether the problem can be solved completely without policy or dynamic behavior.
    • Similarity to SAML subject_confirmation_data: A conceptual similarity to SAML’s subject_confirmation_data (cnf) claim.
    • Community effort: Concern that building option 2 or 3 would require substantial effort.
    • Brian’s view: He expressed a preference for option 0, doing nothing, citing “laziness” and “concern about being consumed by the work.”
  • Current status: The draft is intended to raise the issue; adoption is not being requested. It was proposed that the Working Group build consensus on a direction through mailing-list discussion.

Recording of the OAuth WG Session

(I appear for a moment at the end, too, lol.)

Watch this video on YouTube.
Playing the video connects to YouTube.

(Notes on SVIDs)

An SVID (SPIFFE Verifiable Identity Document) is a digital certificate defined by SPIFFE that allows a workload, such as an application or service, to prove its identity. An SVID plays a role like a passport in the physical world.

Principal characteristics:

  • Contains a SPIFFE ID: It contains a unique identifier specific to the workload, a URI beginning with spiffe://.
  • Digitally signed: A certificate authority (CA) in the trust domain signs it, allowing third parties to verify its authenticity.
  • Formats: Standardized as an X.509 certificate (X.509 SVID) or as a JWT (JWT SVID).
  • Short-lived and automatically renewed: For security, its validity period is short, and it is rotated automatically.
  • Uses: It enables secure authentication and authorization for communication between workloads without relying on network information such as IP addresses, including mTLS communication between services and API authentication1345.

Conceptually, an SVID holds information such as:

  • A single SPIFFE ID
  • A public key, when needed
  • A digital signature

A service or workload obtains its own SVID through the SPIFFE Workload API and presents it to its peer, playing a central role in implementing a zero-trust environment.