OAuth Authorization Request Delegation Chain

1.1. Relation to OpenID Federation

OpenID Federation [OpenID.Federation] defines mechanisms for establishing trust between entities using signed entity statements, trust chains, metadata, metadata policy, and federation authorities.¶

The authorization request delegation chain defined by this document is similar to OpenID Federation in that both mechanisms can involve signed statements about entities and can support trust decisions across organizational or administrative boundaries.¶

However, the two mechanisms address different layers of the problem.¶

OpenID Federation primarily addresses entity trust and metadata establishment. It can answer questions such as:¶

• Which entity controls this identifier?¶

• Which metadata applies to this entity?¶

• Which trust anchor or federation authority vouches for this entity?¶

• Which keys should be used to verify statements from this entity?¶

This document addresses the authrization request's specific delegation path. It can answer questions such as:¶

• Which downstream client initiated this redirect authorization request?¶

• Which brokers carried it?¶

• Which entity attested each hop?¶

• Was the visible authorization request delegation chain reordered, shortened at the tail, altered in the middle, or modified?¶

• Is the visible first node acceptable under local policy?¶

Deployments MAY use OpenID Federation to establish trust in the entities that appear in a delegation chain. For example, iss values in this profile can correspond to federated entity identifiers, and federation metadata can be used to discover keys or validate metadata policy.¶

This document does not replace OpenID Federation. Instead, it can consume or complement federation trust metadata while providing a per-request signed delegation chain suitable for OAuth authorization request processing.¶

1.2. Relation to OAuth Client ID Metadata Document

The OAuth Client ID Metadata Document draft (aka: CIMD) defines a mechanism by which an OAuth client can use a URL as its client_id, where the URL references a client metadata document that can be fetched by an authorization server [I-D.ietf-oauth-client-id-metadata-document].¶

This document is complementary to that mechanism and can reference CIMD-style client_id values when used.¶

A delegation node can use a CIMD-style client_id by setting client_ns to cimd and client_id to the metadata document URL. For example:¶

{
  "client_ns": "cimd",
  "client_id": "https://client.example.com/oauth-client-metadata.json"
}

In such deployments, CIMD can provide retrievable client metadata, while this profile provides a signed per-request authorization request delegation chain showing how that client was carried through brokers.¶

1.3. Relation to RFC 8693 Token Exchange and the act Claim

OAuth 2.0 Token Exchange [RFC8693] defines a token exchange grant and includes the act claim for representing an actor in issued tokens. The act claim can indicate that one party is acting on behalf of another party. Nested act claims can represent prior actors.¶

This document is related to the act claim because both mechanisms represent delegation. However, they apply at different phases of an OAuth deployment.¶

The act claim is a token-time representation. It appears in issued tokens or token introspection responses and is consumed after token issuance, typically by resource servers or downstream authorization servers.¶

This document defines an authorization-request-time representation. The delegation chain is carried in a RAR authorization_details object during the redirect authorization request, before the upstream authorization server has issued tokens.¶

The distinction is important for brokered redirect authorization flows. The upstream authorization server needs to know the downstream client and broker path before it can make a correct consent or authorization decision. A token claim such as act can describe delegation after issuance, but it does not by itself provide a redirect authorization request mechanism for presenting signed per-hop delegation evidence to the authorization endpoint before consent and token issuance.¶

This profile also differs from nested act claims in that:¶

• Each delegation node is signed by the authorization server or broker that attests that hop,¶

• Each node is hash-linked to the previous node,¶

• The chain is carried as JSON in RAR authorization_details,¶

• The chain is intended for authorization endpoint processing, and¶

• The upstream authorization server can bind consent to the terminal client and broker path before issuing tokens.¶

An authorization server MAY translate a validated delegation chain into issued-token claims, including act claims, after authorization succeeds. Such token representation is outside the scope of this document.¶

1.4. Relation to the OAuth Actor Profile for Delegation

The OAuth Actor Profile for Delegation draft defines a common profile for representing delegated actor relationships using the act claim across JWT assertion grants, JWT access tokens, Transaction Tokens, and Token Exchange inputs. It also defines actor classification through sub_profile and discovery metadata for advertising support [I-D.mcguinness-oauth-actor-profile].¶

This document is complementary to the OAuth Actor Profile but has a different scope.¶

The OAuth Actor Profile addresses token and assertion interoperability. It helps systems consistently express actor relationships in issued artifacts such as:¶

• JWT assertion grants,¶

• JWT access tokens,¶

• Transaction Tokens, and¶

• Token Exchange inputs and outputs.¶

This document addresses redirect authorization request delegation. It helps an upstream authorization server evaluate a brokered authorization request before token issuance by carrying a signed delegation chain in RAR authorization_details.¶

The two mechanisms can be used together. An authorization server can validate an oauth_request_delegation_chain authorization detail during the redirect authorization request and, after successful authorization, issue a token using the act claim profile defined by the OAuth Actor Profile.¶

In that combined model:¶

• This document provides pre-token authorization request evidence, and¶

• The OAuth Actor Profile provides post-authorization token representation.¶

1.5. Relation to OAuth Actor-Signed Hop Proofs

OAuth Actor-Signed Hop Proofs defines an optional companion profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces an actor_proofs claim containing a signed per-hop proof chain, where each visible actor signs its own participation and target binding [I-D.mcguinness-oauth-actor-proofs].¶

This document is similar in that it also uses signed per-hop evidence and hash linking. However, the placement and processing model are different.¶

OAuth Actor-Signed Hop Proofs is token-oriented. It defines claims and mechanisms for delegated tokens and associated token processing.¶

This document is authorization-request-oriented. It carries the signed chain in RAR authorization_details so that the upstream authorization server can evaluate the delegation path during redirect authorization request processing, before consent and token issuance.¶

A deployment could use both mechanisms:¶

• oauth_request_delegation_chain in the redirect authorization request to support upstream authorization server consent and policy decisions.¶

• act and actor_proofs in issued tokens to support downstream resource server enforcement and audit.¶

6.1. Delegation Chain Object

The delegation chain authorization details object has the following members.¶

The chain array MUST contain one or more delegation nodes.¶

6.2. Delegation Node

A delegation node is a JSON object with the following members.¶

Additional members MAY be included only if their signing-payload representation is defined by this document, a future specification, or a mutually understood extension. A receiver MUST reject unsupported extension members unless local policy explicitly allows them to be ignored.¶

The stable security identifier for an attested client depends on the client_ns value.¶

For client_ns value as, the stable identifier is:¶

AS issuer context + client_id

For client_ns value cimd, the stable identifier is:¶

client_id

For client_ns value as, the applicable AS issuer context is the iss value of the node that attests the client.¶

The client_name value is display-only and MUST NOT be used as a security identifier.¶

6.3. Proof Object

The proof object contains a detached JWS compact serialization.¶

Example:¶

{
  "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1jLWtleS0xIn0..MEUCIQD..."
}

The proof.jws value is a JWS Compact Serialization [RFC7515] with a detached payload. The payload segment is empty, resulting in the following form:¶

BASE64URL(UTF8(JWS Protected Header)) || "." || "" || "." || BASE64URL(JWS Signature)

The JWS Protected Header MUST contain an alg value and a kid value.¶

For example, the protected header could be:¶

{
  "alg": "ES256",
  "kid": "broker-c-key-1"
}

The detached JWS payload is the deterministic serialization of the delegation node excluding the proof member.¶

The key used to verify proof.jws is resolved from the attester identified by iss.¶

A verifier obtains the attester's verification key by resolving:¶

iss -> authorization server metadata -> jwks_uri -> JWK selected by kid

Because brokers in this profile are also authorization servers, a broker is expected to publish authorization server metadata [RFC8414] and a jwks_uri.¶

7.1. Signature Input

The wire format of a delegation node is JSON. The node is not a JWT and MUST NOT be processed as a JWT claims set.¶

Each node is signed using JSON Web Signature (JWS) [RFC7515] with a detached payload. The detached payload is the deterministic serialization of the delegation node excluding the proof member. The resulting compact detached JWS is carried in the node's proof.jws member.¶

The use of JWS provides standard JOSE header handling, including alg and kid, while preserving a JSON wire format that can be validated using typed schemas before cryptographic verification.¶

7.2. Delegation Chain Signing Payload

The detached JWS payload is a UTF-8 string formed by joining name-value lines with line feed \n.¶

The first line is:¶

oauth-authorization-request-delegation-chain-v1

Then each supported member is serialized in the following fixed order when present:¶

iss
sub
aud
n
p_hash
client_ns
client_id
client_name
resource
omit_chain

The proof member is excluded.¶

Members not included in this signing-payload definition are not protected by the node signature. Security-relevant extensions therefore MUST define how they are included in the signing payload, or receivers MUST reject them.¶

Array values are serialized by joining each array element's JSON string serialization, in array order, with a comma character. No extra whitespace is inserted.¶

For example:¶

oauth-authorization-request-delegation-chain-v1
iss=https://broker-c.example.com
aud=https://as-domain-1.example.com
n=2
p_hash=Vh6U...
client_ns=as
client_id=broker-b-client
resource=https://api-domain-1.example.com

This UTF-8 string is used as the detached JWS payload.¶

The compact detached JWS is produced according to [RFC7515] by signing the payload with the algorithm identified by the JWS Protected Header alg value. The JWS Protected Header MUST contain alg and kid.¶

The compact detached JWS serialization stored in proof.jws MUST contain an empty payload segment:¶

protected-header || "." || "" || "." || signature

Future specifications MAY define alternative signing-payload schemes. Such specifications MUST identify the scheme unambiguously.¶

7.3. Hash Chain

Each delegation node is hash-linked to the previous signed node.¶

For node i, define:¶

signing_payload_i = deterministic detached JWS payload for node i
detached_jws_i = proof.jws value for node i
event_hash_i = BASE64URL(SHA-256(UTF8(signing_payload_i) || "." || ASCII(detached_jws_i)))

The following rules apply:¶

chain[0].p_hash = null
chain[i].p_hash = event_hash(chain[i - 1]) for i > 0
chain[i].n = chain[i - 1].n + 1

This construction cryptographically binds each node to the signed event that precedes it. Validation of the hash chain, sequence numbers, and audience continuity detects modification, insertion, deletion, reordering, and signature substitution within the visible chain.¶

7.4. Creating or Adding to a Delegation Chain

This section defines processing rules for an authorization server or broker creating a new delegation chain or adding a node to an existing chain.¶

"iss": "https://attester.example.com"

"aud": "https://next-broker.example.com"

"aud": "https://as-domain-1.example.com"

"client_ns": "as",
"client_id": "client-or-broker-identifier"

"client_ns": "cimd",
"client_id": "https://client.example.com/oauth-client-metadata.json"

"client_ns": "as",
"client_id": "client-123"

"client_ns": "cimd",
"client_id": "https://client.example.com/oauth-client-metadata.json"

"n": 0,
"p_hash": null

{
  "alg": "ES256",
  "kid": "attester-key-1"
}

"proof": {
  "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImF0dGVzdGVyLWtleS0xIn0..base64url-signature"
}

8.1. Step 1 - Schema Validation

The authorization server validates that the authorization detail object contains:¶

"type": "oauth_request_delegation_chain"

and that chain is a non-empty JSON array.¶

Each node MUST contain:¶

iss
aud
n
p_hash
client_ns
client_id
proof.jws

A receiver MAY reject nodes containing unsupported values or unsupported extension members.¶

8.2. Step 2 - Client Namespace Validation

The authorization server verifies that each node contains a supported client_ns value.¶

This profile defines:¶

as
cimd

If the authorization server does not support the client_ns value, it MUST reject the authorization detail object.¶

8.3. Step 3 - Terminal Node Checks

Let last be the index of the final node in the chain.¶

The authorization server performs the following checks on the final node before performing signature validation. These checks are fail-fast checks over unauthenticated input: failure is sufficient to reject the request, but success does not authenticate the node or the chain.¶

The authorization server verifies that the final node is intended for it:¶

chain[last].aud == receiving_authorization_server_issuer

If the final node's aud value does not identify the receiving authorization server, the authorization server MUST reject the chain.¶

The authorization server also verifies that the final node is plausibly bound to the OAuth client submitting the authorization request.¶

The exact binding is deployment-specific, but the receiving authorization server MUST be able to establish that:¶

chain[last].iss

identifies, or is authorized to speak for, the authenticated OAuth client submitting the request.¶

For example, if the request is submitted by an authenticated broker client, the authorization server can verify that the registered metadata for that OAuth client identifies:¶

chain[last].iss

as the broker authorization server or broker issuer for that client.¶

If the authorization server cannot bind the final node's iss to the OAuth client submitting the request, it MUST reject the chain.¶

The checks in this step are fail-fast checks. Until the final node's signature has been verified, the authorization server MUST treat the final node's iss, aud, and other members as unauthenticated input. A successful preflight check does not by itself authenticate the node or the chain.¶

The aud value identifies an authorization server or broker-AS, not a protected resource API. Protected resource identifiers are represented using the resource member.¶

A protected API endpoint MUST NOT appear in aud.¶

8.4. Step 4 - Signature Validation

For each node, the authorization server:¶

1. Reads iss. The iss value is untrusted until the node signature is verified. Before using iss for metadata retrieval, the authorization server MUST apply its normal issuer validation, discovery, allow-list, federation, or local trust policy.¶

2. Reads proof.jws.¶

3. Parses proof.jws as a compact detached JWS.¶

4. Verifies that the compact JWS contains an empty payload segment.¶

5. Decodes the JWS Protected Header.¶

6. Verifies that the JWS Protected Header contains alg and kid.¶

7. Resolves the issuer metadata for iss. The resolved authorization server metadata issuer value MUST match iss.¶

8. Obtains the issuer's jwks_uri.¶

9. Fetches the issuer's JWK Set.¶

10. Selects a key using the JWS Protected Header kid.¶

11. Constructs the deterministic detached JWS payload for the node by serializing the node excluding the proof member.¶

12. Verifies the detached JWS signature over that payload according to [RFC7515].¶

If a signature cannot be verified, the authorization server MUST reject the chain.¶

After signature validation succeeds, the authorization server treats the signed members of each node as authenticated statements by that node's iss.¶

In particular, the terminal preflight checks in Section 8.3 are then authenticated because the final node's signature covers the same iss, aud, client_ns, client_id, p_hash, and other signed members.¶

8.5. Step 5 - Backward Chain Validation

The authorization server validates the chain from the final node toward the first node. For every i from last down to 1, the authorization server verifies:¶

chain[i].p_hash == event_hash(chain[i - 1])
chain[i - 1].aud == chain[i].iss
chain[i].n == chain[i - 1].n + 1

where event_hash is computed over the previous node's deterministic detached JWS payload and its proof.jws value.¶

If any hash comparison fails, the authorization server MUST reject the chain.¶

If any audience-continuity check fails, the authorization server MUST reject the chain.¶

If any sequence-number check fails, the authorization server MUST reject the chain.¶

The authorization server then verifies the first node:¶

chain[0].n == 0
chain[0].p_hash == null

If either check fails, the authorization server MUST reject the chain.¶

The audience-continuity check ensures that every hop intentionally delegated to the next hop in the chain:¶

chain[i - 1].aud == chain[i].iss

Thus, for a chain:¶

node[0] -> node[1] -> node[2]

the following MUST hold:¶

node[0].aud == node[1].iss
node[1].aud == node[2].iss

8.6. Step 6 - Resource Consistency Validation

If multiple nodes contain resource, the authorization server SHOULD verify that the resource value is consistent across the chain, unless local policy explicitly permits resource transformation.¶

If local policy permits resource transformation, the authorization server SHOULD verify that each transformation is allowed for the issuer performing the transformation.¶

8.7. Step 7 - Delegation Relationship Validation

The authorization server SHOULD verify that adjacent nodes are semantically consistent.¶

The final node identifies the client that the immediate trusted broker is attesting. Prior nodes reveal what that client was itself carrying.¶

For example, if the final node is:¶

{
  "iss": "https://broker-c.example.com",
  "client_ns": "as",
  "client_id": "broker-b-client"
}

then the authorization server treats https://broker-c.example.com as attesting broker-b-client.¶

The authorization server then validates the prior node signed by broker-b to determine which client broker-b was carrying.¶

The authorization server MAY reject the chain if the attested client relationship is inconsistent with registration metadata, federation metadata, or local policy.¶

8.8. Step 8 - Policy Validation

After cryptographic validation, the authorization server applies local policy.¶

Cryptographic validation proves the integrity of the visible chain. It does not prove that no upstream delegation context existed before chain[0].¶

In particular, a broker can originate a new chain beginning with itself as chain[0]. Such re-origination can produce a cryptographically valid chain. Whether that chain is acceptable is a local policy decision for the receiving authorization server.¶

Policy decisions can consider:¶

• the OAuth client authenticated to the authorization server,¶

• the final node's iss, whether it is allowed for the authenticated OAuth client,¶

• the first node's iss, whether it is allowed to appear as a first-node issuer,¶

• the full set of brokers in the chain,¶

• whether each broker is allowed to appear in its position in the chain,¶

• the client identified by the first visible client attestation,¶

• the resources identified by resource,¶

• the user subject identified by sub, if present,¶

• the full delegation chain hash, and¶

• deployment-specific expectations about allowed direct and indirect paths.¶

The final node's iss is used to validate the relationship between the authenticated OAuth client and the broker-AS or AS that produced the final delegation-chain node.¶

The first node's iss is used to evaluate whether the visible chain is allowed to begin with that issuer. This is the policy check that addresses head-truncation or re-origination. Cryptographic validation cannot prove that no upstream nodes existed before chain[0].¶

The authorization server MAY reject the request if any broker, client, namespace, resource, subject, first-node issuer, or path is not allowed.¶

10.1. Discovering Upstream Support

An authorization server acting as broker that intends to forward an authorization request to an upstream authorization server SHOULD determine whether the upstream authorization server supports the oauth_request_delegation_chain authorization details type before sending the authorization request.¶

The broker SHOULD retrieve the upstream authorization server metadata according to [RFC8414].¶

If the upstream authorization server metadata publishes in authorization_details_types_supported support for the oauth_request_delegation_chain RAR type, the broker SHOULD opt into this mechanism by including an authorization_details object of type oauth_request_delegation_chain in the authorization request.¶

For example, an upstream authorization server can advertise support as follows:¶

{
  "issuer": "https://as-domain-1.example.com",
  "authorization_endpoint": "https://as-domain-1.example.com/authorize",
  "token_endpoint": "https://as-domain-1.example.com/token",
  "jwks_uri": "https://as-domain-1.example.com/jwks.json",
  "authorization_details_types_supported": [
    "oauth_request_delegation_chain"
  ]
}

A broker that discovers upstream support SHOULD either:¶

• create a new oauth_request_delegation_chain authorization detail object, if no chain is already present; or¶

• validate and extend the existing chain, if a chain is already present.¶

A broker MAY still use this profile with an upstream authorization server when support is established by other means, such as bilateral configuration, federation metadata, contractual onboarding, or local policy.¶

If a broker is unable to determine whether the upstream authorization server supports this profile, the broker SHOULD apply local policy. Local policy can include forwarding the request without this authorization detail, aborting the transaction, or using an alternative delegation mechanism.¶

10.2. Upstream Support Failure

If a broker receives an authorization request containing an oauth_request_delegation_chain authorization detail object and determines that the next upstream authorization server does not support this profile, the broker MUST NOT silently discard the delegation chain.¶

The broker MUST either reject the transaction, use another trusted mechanism to preserve the delegation context, or forward the request without the chain only when doing so is permitted by local policy and by the signed chain requirement.¶

A delegation node MAY contain the following member:¶

omit_chain

OPTIONAL. String indicating whether a broker is allowed to forward the authorization request without the delegation chain if the next upstream authorization server does not support this profile. Defined values are forbidden and allowed. If omitted, the default value is forbidden.¶

If any validated node contains:¶

"omit_chain": "forbidden"

or omits omit_chain, then a broker that cannot forward the delegation chain to the next upstream authorization server, and cannot preserve equivalent delegation context by another trusted mechanism, MUST reject the transaction.¶

If every validated node contains:¶

"omit_chain": "allowed"

then the broker MAY forward the authorization request without the delegation chain, subject to local policy.¶

A broker MUST NOT silently discard a delegation chain. Forwarding without the chain is an explicit degradation of delegation evidence and is permitted only when allowed by the validated chain and by local policy.¶

11.1. Chain Integrity

The hash chain, per-node detached JWS signatures, sequence numbers, and audience continuity checks are intended to detect modification, insertion, deletion, reordering, and signature substitution within the visible delegation chain.¶

A receiver MUST reject a chain if any required validation check described in Section 8 fails.¶

A valid signature proves only that the identified issuer signed the node. It does not imply that the issuer is trusted for the requested delegation.¶

11.2. Truncation and Re-origination

Truncation has three relevant cases.¶

Tail truncation is detected by the terminal audience check: a shortened chain will not end in a node whose aud identifies the receiving authorization server.¶

Middle removal is detected by the hash-chain and audience-continuity checks: removing an intermediate node breaks the successor's p_hash and the adjacent issuer/audience relationship.¶

Head truncation, or re-origination, is different. A broker can create a fresh chain beginning with itself as chain[0]. Cryptographic validation proves the integrity of the visible chain, but cannot prove that no upstream context existed before chain[0].¶

Authorization servers MUST handle re-origination through local policy, including whether chain[0].iss is allowed to appear as the first visible issuer for the requested client, resource, and deployment context.¶

11.3. Replay

This profile does not define expiration, nonce, or replay-cache claims in the base structure.¶

Deployments that require replay protection MAY add such claims as deployment-specific extensions and validate them according to local policy.¶

11.4. Display Names

client_name is intended only for display.¶

Authorization servers MUST NOT use client_name as a security identifier.¶

The stable security identifier depends on client_ns, client_id, and the applicable issuer or namespace context.¶

11.5. Trust in Attesters

A valid chain establishes integrity and provenance of the visible attestations. It does not establish that the attesters, clients, resources, subjects, or path are acceptable.¶

Authorization servers MUST apply local trust policy before accepting a delegation chain.¶

11.6. Trust in Broker Client Metadata

The client_roles client metadata member can indicate that a client is expected to act as an OAuth broker.¶

An authorization server MUST NOT treat self-asserted client_roles metadata as proof that the client is trustworthy, authorized to broker authorization requests, or authorized to represent downstream clients.¶

An authorization server MUST rely on client_roles for security decisions only when the metadata was established through a trusted mechanism, such as administrative registration, trusted dynamic client registration, a trusted software statement, federation metadata, or local trust policy.¶

11.7. Metadata Resolution

This profile assumes that attesters publish verification keys through authorization server metadata and jwks_uri.¶

If metadata cannot be resolved, is not trusted, or does not contain the key identified by kid, the receiver MUST reject the affected node.¶

11.8. Immediate Client Authentication

The delegation chain does not replace OAuth client authentication.¶

An authorization server MUST still authenticate the immediate OAuth client according to its normal OAuth processing rules.¶

The authorization server MUST verify that the authenticated immediate client is consistent with the final delegation node.¶

11.9. Privacy

A delegation chain can reveal intermediaries, downstream clients, resources, and possibly subjects.¶

Deployments SHOULD minimize included data and avoid including unnecessary personally identifiable information.¶

12.1. OAuth Dynamic Client Registration Metadata Registration

This document requests registration of the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591].¶

Client Metadata Name:

client_roles¶

Client Metadata Description:

JSON array of strings identifying roles the OAuth client is expected to perform when interacting with the authorization server. The value oauth_broker indicates that the client may act as an intermediary between the authorization server and one or more downstream clients, applications, agents, relying parties, resource servers, or trust domains.¶

Change Controller:

IETF¶

Specification Document:

This document.¶

12.2. OAuth Authorization Details Type

This document defines the oauth_request_delegation_chain authorization details type.¶

A future standards-track version of this document may request registration of the oauth_request_delegation_chain authorization details type in the applicable IANA registry.¶

13.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

13.2. Informative References

[I-D.ietf-oauth-client-id-metadata-document]

"OAuth Client ID Metadata Document", n.d., <https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/>.

[I-D.ietf-oauth-security-topics-update]

"OAuth 2.0 Security Best Current Practice Update", n.d., <https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics-update/>.

[I-D.mcguinness-oauth-actor-profile]

"OAuth Actor Profile for Delegation", n.d., <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/>.

[I-D.mcguinness-oauth-actor-proofs]

"OAuth Actor-Signed Hop Proofs", n.d., <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-proofs/>.

[OpenID.Federation]

OpenID Foundation, "OpenID Federation 1.0", n.d., <https://openid.net/specs/openid-federation-1_0.html>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

A.1. Full Authorization Details Object

{
  "type": "oauth_request_delegation_chain",
  "chain": [
    {
      "iss": "https://broker-a.example.com",
      "aud": "https://broker-b.example.com",
      "n": 0,
      "p_hash": null,
      "client_ns": "as",
      "client_id": "client-123",
      "client_name": "Client 123",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1hLWtleS0xIn0..sig0"
      }
    },
    {
      "iss": "https://broker-b.example.com",
      "aud": "https://broker-c.example.com",
      "n": 1,
      "p_hash": "hash-of-node-0-event",
      "client_ns": "as",
      "client_id": "broker-a-client",
      "client_name": "Broker A",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1iLWtleS0xIn0..sig1"
      }
    },
    {
      "iss": "https://broker-c.example.com",
      "aud": "https://as-domain-1.example.com",
      "n": 2,
      "p_hash": "hash-of-node-1-event",
      "client_ns": "as",
      "client_id": "broker-b-client",
      "client_name": "Broker B",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1jLWtleS0xIn0..sig2"
      }
    }
  ]
}

A.2. Interpretation

Node 0 says:¶

broker-a attests to broker-b that client-123 is the delegated client.

Node 1 says:¶

broker-b attests to broker-c that broker-a-client is the delegated client
for this hop.

Node 2 says:¶

broker-c attests to as-domain-1 that broker-b-client is the delegated
client for this hop.

The upstream AS validates the final trusted hop first:¶

broker-c -> broker-b-client

Then walks the prior signed nodes:¶

broker-b -> broker-a-client
broker-a -> client-123

The terminal client is therefore:¶

{
  "client_ns": "as",
  "client_id": "client-123",
  "client_name": "Client 123",
  "attested_by": "https://broker-a.example.com"
}

The resource is constant across the chain:¶

["https://api-domain-1.example.com"]

B.1. Full Authorization Details Object

{
  "type": "oauth_request_delegation_chain",
  "chain": [
    {
      "iss": "https://broker-a.example.com",
      "aud": "https://broker-b.example.com",
      "n": 0,
      "p_hash": null,
      "client_ns": "cimd",
      "client_id": "https://client-123.example.com/oauth-client-metadata.json",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1hLWtleS0xIn0..sig0"
      }
    },
    {
      "iss": "https://broker-b.example.com",
      "aud": "https://broker-c.example.com",
      "n": 1,
      "p_hash": "hash-of-node-0-event",
      "client_ns": "cimd",
      "client_id": "https://broker-a.example.com/client",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1iLWtleS0xIn0..sig1"
      }
    },
    {
      "iss": "https://broker-c.example.com",
      "aud": "https://as-domain-1.example.com",
      "n": 2,
      "p_hash": "hash-of-node-1-event",
      "client_ns": "cimd",
      "client_id": "https://broker-b.example.com/client",
      "resource": ["https://api-domain-1.example.com"],
      "proof": {
        "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImJyb2tlci1jLWtleS0xIn0..sig2"
      }
    }
  ]
}

B.2. Interpretation

Node 0 says:¶

broker-a attests to broker-b that the CIMD-identified client is the
delegated client.

Terminal client:¶

{
  "client_ns": "cimd",
  "client_id": "https://client-123.example.com/oauth-client-metadata.json",
  "attested_by": "https://broker-a.example.com"
}

Node 1 says:¶

broker-b attests to broker-c that broker-a is the delegated client for
this hop, identified by https://broker-a.example.com/client.

Node 2 says:¶

broker-c attests to as-domain-1 that broker-b is the delegated client for
this hop, identified by https://broker-b.example.com/client.

The upstream AS sees the immediate trusted path as:¶

broker-c -> broker-b -> broker-a -> client-123

And the resource remains:¶

["https://api-domain-1.example.com"]