Introduce OAuth2.0 Token Exchange (RFC 8693) support in CAMARA

[sfnuser]

Problem description
CAMARA is evolving towards richer authorization models through the use of Rich Authorization Requests RAR and persistent consent handling via the Consent API. These mechanisms enable fine-grained expression and storage of scope and purpose combinations agreed by the end user.

However, once consent has been obtained and an access token is issued via existing 3-legged flows (e.g. OIDC Authorization Code or CIBA), the resulting access token often needs to carry a broader set of scopes, purposes, and audiences in order to support multiple CAMARA APIs (For eg. a use case where the purpose is dpv:FraudIdentificationAndDetection and the required scopes are: location-verification:verify sim-swap:check number-verification:verify device-roaming-status:roaming that requires multiple API access). This increases the attack surface area of the token and limits the ability to enforce least-privilege access at runtime.

Obtaining narrowly scoped and audience-restricted access tokens for individual CAMARA APIs typically requires re-running authorization flows or relying on broad tokens, even when valid consent already exists. This creates unnecessary coupling between user interaction and backend resource access resulting in bad end user experience.

Possible evolution
OAuth 2.0 Token Exchange (RFC 8693) could be introduced as an optional capability within CAMARA to complement RAR and consent-based authorization flows. With this model:

• An initial access token is obtained after end-user authentication using existing CAMARA-aligned flows (OIDC Authorization Code or CIBA).
• This access token is subsequently used as a subject_token in a token exchange request.
• Backend services can exchange the subject token for access tokens that are:
  • Audience-restricted to a specific CAMARA API
  • Narrowly scoped to the minimum required scopes and purposes
• Additional CAMARA APIs can be accessed by performing further backend-only token exchanges, without additional end-user interaction.

This enables runtime enforcement of least-privilege access while preserving a seamless end-user experience. CAMARA already supports JWT bearer client assertions, which align naturally with Token Exchange.

It also supports enhanced auditability through the optional use of actor_token and the resulting act claim, allowing identification of the acting component within an API consumer, in addition to the client_id and sub claims. Note: actor_token not fully supported in Keycloak as of today I think.

Token Exchange would be additive and optional, not a replacement for existing CAMARA authorization flows. It can greatly improve end user experience and has greater scope for finer-grained runtime access control and auditability.

Alternative solution
N/A

Additional context
https://www.rfc-editor.org/rfc/rfc8693

[jpengar]

@sfnuser Thank you for the proposal! As discussed in yesterday's ICM meeting (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/431423509/2025-12-17+ICM+Minutes), let me add the following concerns raised during the call for the record:

Overlap with existing CAMARA mechanisms

Many of the benefits described in this proposal are already achievable today using existing CAMARA building blocks, in particular:

• JWT Bearer flow, which already enables backend-to-backend token acquisition without additional end-user interaction.
• Consent Info API, which allows consent to be captured and validated independently of token issuance.

By combining these mechanisms, an API consumer can:

• Capture all required consents upfront.
• Obtain new access tokens backend-to-backend without further user involvement.
• Validate that consent is still in effect before issuing each token.

As a result, the proposal appears to overlap significantly with existing CAMARA flows, rather than addressing a clearly uncovered use case.

Security considerations

One of the stated motivations is reducing over-scoped access tokens. However, the proposed flow introduces an initial “subject token” with broader privileges, which raises concerns:

• If the original subject token is not invalidated after token exchange, the security risk remains unchanged.
• The system still contains a high-privilege token that could be abused if compromised.

From a security perspective, this weakens the argument that token exchange inherently improves the attack surface unless strict lifecycle and invalidation rules are defined.

API Providers should issue short-lived access tokens to minimize risk.

Architectural consistency: broad vs. narrow tokens

This proposal also surfaces a broader architectural question for CAMARA:

• Do we want to move towards “one token to rule them all”, potentially enabled by RAR?
• Or do we want to enforce audience-restricted, narrowly scoped access tokens as a core principle?

Introducing token exchange without first resolving this question risks sending mixed signals in the architecture:

• On one hand, enabling broader authorization capture.
• On the other, trying to compensate by slicing tokens post hoc.

Interoperability impact

Finally, from an interoperability standpoint:

• If Token Exchange is introduced as an optional feature, different API providers may or may not support it.
• This would result in provider-specific behavior, increasing complexity for API consumers and aggregators.
• CAMARA has historically aimed to minimize such optionality in core authorization flows.

If a new authorization mechanism is introduced, it should:

• Address a clearly unmet use case.
• Be justified at the WG level.
• Be mandated, not optional, to preserve interoperability