Summary

  • Revision 01 of draft-zehavi-oauth-authz-req-del-chain was announced on 10 September 2026 as an individual Internet-Draft, not an adopted OAuth Working Group document or an RFC.
  • Its detached JWS signatures, previous-node hashes, positions and audience checks are designed to protect the integrity of the broker path that is visible to an upstream authorization server.
  • Tail and middle removal should break validation. A broker can nevertheless create a fresh valid chain beginning with itself, so the chain cannot prove that no earlier context existed.
  • The draft assigns that re-origination decision to local policy. A useful operational record should capture why a given first issuer was allowed, not pretend that cryptography answered the question.

The clean chain may start too late

Imagine an authorization server receiving a neat sequence of three signed broker statements. Every signature verifies. Every position is consecutive. Every audience leads to the next issuer. The final node is addressed to the server that is about to request consent and issue a token.

That is strong evidence about the sequence in hand. It is not evidence that the sequence contains the whole history.

This is the most important boundary in revision 01 of OAuth Authorization Request Delegation Chain. The proposal addresses redirect flows in which a downstream client reaches an upstream authorization server through one or more brokers. Each intermediary acts as an authorization server toward the party below it and as an OAuth client toward the party above it. Without extra evidence, the terminal server may know only its immediate broker.

The draft carries that evidence in a proposed Rich Authorization Requests authorization_details object. Each node identifies the attester, its audience, its place in the sequence and the client it is attesting. A detached JWS covers a deterministic representation of the node. The p_hash value commits the node to the signed event immediately before it.

Validation is deliberately anchored at the receiving server and moves backward. The last node must name that server as its audience. Its issuer must be bound to the authenticated OAuth client making the request. The server then checks signatures, keys, positions, hashes, namespaces and continuity between one node's audience and the next node's issuer.

Those tests give the visible chain structure. The word visible carries the governance weight.

Three forms of truncation, two cryptographic answers

Revision 01 separates truncation into three cases. Removing the tail should leave the shortened chain ending at the wrong audience. Removing a node from the middle should break the successor's previous-node hash and the adjacent issuer-to-audience relationship.

Removing the head is different. A broker can discard earlier context and construct a new chain in which it appears at position zero with a null previous hash. That new chain can be internally impeccable. The draft calls the act re-origination and says cryptographic validation cannot prove that nothing existed before chain[0].

This is not a flaw accidentally exposed by criticism. It is a candid statement of scope in the proposal's security considerations. A hash chain can make a declared beginning internally consistent; it cannot summon an external witness to certify that the declared beginning is historically complete.

The receiving authorization server therefore has to decide whether that issuer is allowed to be the first visible one for this client, resource and deployment context. The draft makes local policy authoritative at precisely the point where mathematical verification runs out.

The same discipline applies elsewhere. A valid signature proves that the named issuer signed a node, not that the issuer may broker this delegation. The new client_roles metadata can mark a client as an oauth_broker, but self-asserted metadata is not proof of trust or authority. The immediate OAuth client must still authenticate normally, and the last node must match that client.

Revision 01 also names the downgrade

The revision does more than add a warning. It adds a way for authorization-server metadata to advertise support for the chain type and tells brokers to discover that support before forwarding. It also describes what happens when the next upstream server does not support the profile.

A chain must not be silently dropped. The broker must reject the transaction, preserve the context through another trusted mechanism, or forward without the chain only when local policy and the signed chain permit that degradation. An optional omit_chain value can be allowed or forbidden; omission defaults to forbidden, and every validated node must allow omission before chainless forwarding becomes an option.

That makes evidence loss an explicit decision rather than an invisible side effect. It still does not cure the origin problem. omit_chain governs whether a chain already in view may disappear at a later hop. It cannot say whether a broker omitted context before it created the first visible node.

Revision 01 also asks IANA to register client_roles as dynamic-client-registration metadata and describes oauth_broker as one role value. These are proposals in an active individual draft. The document is not an RFC, has not been adopted by the OAuth Working Group, and supplies no evidence of implementation, deployment or an attack.

Sources