Summary

  • draft-li-oauth-delegated-authorization-03 proposes an ordered chain of key-bound tokens: an authorization server signs the root, each client signs a narrower child, and the leaf client proves possession with DPoP.
  • Validating that chain can prove signature and key continuity, finite depth, narrowed permissions, audience and time, but it cannot prove why a particular delegate was chosen, what task a person intended, or whether an offline resource server has learned of revocation.
  • Daniel Kade proposes a separate delegation-intent receipt joining the root mandate, hop custody, task and effect boundary, revocation freshness, resource decision and closure. It is governance evidence outside the draft, not another token claim.

A green chain is a precise answer to one question

Imagine an orchestrator receiving authority to read an internal knowledge service. It delegates a research subset to one specialist and a testing subset to another. The resource server later receives a compact sequence of signed objects and a proof from the last key. Every signature is valid. Every audience still includes that server. Every expiry is within the parent’s. Every child permission is contained by what came before it.

That result should not be dismissed as mere plumbing. It establishes something many agent systems currently express only through configuration and trust: authority did not grow as it moved away from its root. The chain makes each handoff attributable to the key bound by the preceding token. A captured serialization is insufficient because the presenter must prove possession of the leaf key.

The individual Internet-Draft OAuth 2.0 Delegated Authorization specifies this model. The authorization server issues a root Delegated Authorization Token and binds it through cnf.jkt to a client’s public-key thumbprint. The holder can use the same bound private key to access a resource or, when delegation remains, sign a child token bound to the next client. Repetition produces an ordered root-to-leaf chain.

At the resource server, validation walks the entire sequence. The root signature comes from trusted authorization-server configuration or authenticated metadata. Each child carries the public key used for its signature; that key’s RFC 7638 thumbprint must equal the parent’s cnf.jkt. A DPoP proof from the leaf key binds the access request to the exact serialized chain. The proposed DA authentication scheme is deliberately distinct from Bearer and ordinary DPoP token presentation.

The cryptographic question is therefore sharp: did the holder of each bound key authorize the next constrained key, and does the final presenter possess the leaf key? Passing says yes. It does not answer every question containing the word “authorization.”

Monotonicity is more demanding than shorter JSON

The draft requires permissions, audiences, validity periods and remaining delegation depth to become no broader down the chain. For ordinary OAuth scope, set containment supplies a manageable test. If a child lists a scope absent from the parent’s effective set, validation fails. Omitting scope discards that permission component rather than inheriting a hidden grant.

Rich authorization details are harder. A payment object, document selector or infrastructure action may contain defaults, arrays, wildcards, resource identifiers and verbs whose meaning is not visible from generic JSON shape. The draft therefore requires a type specification to define deterministic containment semantics before a client-issued child can retain that authorization detail. Comparing raw text or matching only a type name is explicitly inadequate. A verifier unable to prove containment must fail closed.

That boundary matters operationally. “The child document is smaller” is not evidence that authority narrowed. A wildcard added under a default rule, an omitted limit that changes meaning, or a different resource identifier can enlarge effective power while producing fewer bytes. The chain is safe only to the degree that every authorization vocabulary supplies a real partial order and every intended verifier implements it consistently.

Extension claims receive the same treatment. A claim that influences authorization cannot be relied on unless every intended verifier understands its delegation semantics. This is a useful resistance to policy by decoration: an unimplemented restriction must not create the appearance of constraint while a resource server silently ignores it.

Depth counts edges, not consequences

Every root token carries a finite max_delegation_depth. If the effective value is zero, no child is valid. If it is a positive integer m, a child may explicitly choose zero through m-1; omission consumes one level and yields m-1. Authorization-server policy also imposes a configured maximum.

That field controls graph topology. It does not measure the sensitivity of the permitted act. One terminal delegation can authorize a high-impact operation; three narrow hops can end in a read-only query. A depth of zero says “this client cannot validly delegate again,” not “this client is low risk,” “the resource owner saw this client,” or “a human approved this transaction.”

The distinction becomes important when product interfaces turn a structural limit into reassuring copy. The draft requires the resource-owner decision to cover the capacity for later client-issued delegation and the maximum depth. It also says that ordinary access-token approval must not be treated as approval to delegate. Yet it deliberately leaves the presentation of delegation capability and depth to the authorization server.

A technically correct consent screen could still be practically opaque. “Allow two further levels” does not tell a person which organizations, agents or workloads may appear, what out-of-band discovery chooses them, or what effects the final resource operation can cause. The protocol can bound a future branch without narrating its future occupants.

Local issuance moves the observation point

The draft’s central benefit is also its governance discontinuity. After the root token is issued, a client can create a child without returning to the authorization server. The server need not observe each specialist agent, downstream resource or multi-hop call. That reduces central coordination and limits the server’s view of workflow relationships.

But absence of central observation is not absence of an event. The delegation occurred at the client that signed the child. The complete chain later becomes visible to a resource server. Audit responsibility therefore moves across organizations and components: root issuance at the authorization server, child creation at delegating clients, chain interpretation and access decision at the resource server.

The draft recommends audit events for root issuance, local delegation, validation outcomes, effective authority and protected-resource decisions. It also warns against placing complete credentials in ordinary logs. One-way chain digests can correlate evidence while Authorization and DPoP headers are redacted. Authorization details and subject identifiers need protection because the chain can reveal issuer, relationships, audiences, permissions and workflow structure.

This is the policy mirror in protocol form. Each actor observes a different layer. A central server’s clean issuance record does not prove what later clients delegated. A resource server’s accepted chain does not reveal how the root consent was explained. A delegating client’s signature does not prove the resulting resource effect. Evidence has to be joined without pretending that one observer saw the whole system.

The task is deliberately outside the chain

The draft lists several functions outside its scope: discovering another client’s key, negotiating delegation out of band, binding a delivered chain to a particular request or task, defining containment for each application type, and distributing revocation status. Those are not minor deployment footnotes. They are the surfaces that connect a generic authority envelope to a specific operating decision.

Suppose an orchestrator is allowed to delegate document reading to a research service. A child token can narrow the audience to one knowledge API, retain only read scope, expire in ten minutes and prohibit further delegation. The chain still does not say whether the requested task was “summarize the approved project file” or “search every personnel record.” Application-specific authorization may reject the latter, but that judgment comes from resource policy and request context, not signature continuity.

The draft is explicit that chain validation alone does not authorize a protected-resource request. The resource server must additionally validate DPoP, request binding, audience and application permissions. Even that final allow decision is not completion evidence. An allowed write can fail; an allowed job can cause a secondary effect; a read can feed a later decision outside the resource server’s field of view.

The protocol correctly refuses to smuggle all those meanings into a generic token. Governance fails when operators put them back by inference.

Revocation exists in two clocks

The proposed revocation semantics are precise. Revoking a root invalidates every chain rooted in it. Revoking a child invalidates every chain containing that child and its descendants, while leaving the parent and siblings untouched. Targets need unambiguous identity, such as a collision-resistant digest of their exact serialization.

Recording revocation at the authorization server is only the first clock. A resource server doing offline validation does not learn that state automatically. Revision 03 defines no status-distribution mechanism. Until the deployment supplies one, a server can continue accepting a cryptographically valid but administratively revoked chain. Short lifetimes bound this window; they do not eliminate it or reveal its actual duration.

The second clock is therefore reliance time: which revocation view had reached the resource server when it acted? A post-incident database showing that revocation was recorded at 10:00 does not prove that an offline verifier knew at 10:01. Conversely, an unexpired token does not prove that no revocation existed. An audit needs the server’s received status version, freshness and fail-open or fail-closed policy.

Caching sharpens this distinction. A resource server may cache verified signatures and effective restrictions using a digest of the exact chain, but it must invalidate or expire entries according to time, key status, local policy and received revocation information. DPoP freshness and replay checks remain per request. A cached green chain is not a license to cache away current decision inputs.

One key can authorize use and reproduction of authority

The same bound private key can prove leaf possession and sign another child when depth remains. This gives the chain clean continuity, but compromise has two dimensions: an attacker can exercise existing authority and mint narrower descendants. The draft recommends non-exportable keys and signing interfaces that distinguish token issuance from proof creation, even when one key underlies both operations.

There is another subtlety. A client-issued token does not contain a parent identifier. It can be valid in another chain whose preceding token binds the same signing key and whose restrictions encompass the child. This is intentional in revision 03. If a deployment needs a child usable only with one parent chain, it must separate parent keys or add an application-specific restriction.

Key identity is therefore not institutional identity, and continuity is not exclusivity. The parent thumbprint proves which key authorized a hop. It does not, without external records, prove which process controlled that key at the time, whether its signing interface enforced the intended operation class, or which parent workflow the operator believed it was serving.

A delegation-intent receipt

I propose a delegation-intent receipt. It is Daniel Kade’s governance design, not a field required by the Internet-Draft and not a credential that resource servers must consume.

The receipt begins at the root. It records a safe digest of the authorization event and the exact consent presentation version; the issuer and trusted-metadata snapshot; the authorized delegation capability; effective scopes or authorization details; audiences; lifetime; and maximum depth. It does not store the token, private key, DPoP proof or raw subject data.

For each local hop, it records the chain digest, parent and child public-key thumbprints, the effective restrictions before and after, the containment rule and version used, the signing service identity, and the client-selection evidence. It marks whether a distinct key was used and whether the child was intended for one parent context.

Then it adds what the generic chain omits: a digest of the concrete task, acceptable output and effect boundary; a decision owner; transaction or environment limits where relevant; and conditions requiring renewed human or authorization-server interaction. This material should be minimal and privacy-preserving. Its purpose is to stop “validly delegable” from becoming “wanted in every context.”

At reliance time, the receipt records the resource server’s chain digest, policy version, containment implementation, received revocation-state version and age, DPoP outcome, effective authorization and final allow or deny decision. Closure records the observed operation class, completion or failure, material secondary effects and rollback or incident reference.

None of these records upgrades the protocol. They create a narrow bridge between cryptographic authority and operational purpose. A deployment can start with the smallest useful set: root mandate, hop digest, task/effect digest, revocation freshness and final decision. Later profiles can specialize evidence without changing the token’s job.

What validation should be allowed to mean

Revision 03 is an individual draft, not an OAuth Working Group document or IETF consensus. Its proposed IANA values are requests, not live registrations. No implementation or adoption claim follows from its detail or its use of normative language.

Within that boundary, the proposal makes a serious contribution. It gives local delegation a verifiable lineage and requires effective authority to contract. It identifies where semantic comparison must be explicit, where proof of possession matters, and where offline revocation fails to travel by itself.

The governance mistake would be to ask the chain for a different kind of truth. A signature shows that a bound key authorized a narrower key. Depth shows how many more such moves are permitted. DPoP shows that the requester controls the leaf key and binds a proof to a request. None records the human purpose that made the operation desirable.

After a resource action changes data, starts infrastructure or discloses information, later reconstruction cannot manufacture that missing intent. The safe statement is both narrower and stronger: the chain can prove who had cryptographic authority to narrow and exercise a grant. The receipt must preserve why this exercise belonged to the intended task.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, revision 03
  5. Datatracker record for OAuth 2.0 Delegated Authorization
  6. History of the Delegated Authorization draft
  7. OAuth Working Group charter
  8. RFC 6749: The OAuth 2.0 Authorization Framework
  9. RFC 7009: OAuth 2.0 Token Revocation
  10. RFC 7638: JSON Web Key Thumbprint
  11. RFC 8414: OAuth 2.0 Authorization Server Metadata
  12. RFC 8707: Resource Indicators for OAuth 2.0
  13. RFC 8725: JSON Web Token Best Current Practices
  14. RFC 9396: OAuth 2.0 Rich Authorization Requests
  15. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
  16. RFC 9700: Best Current Practice for OAuth 2.0 Security
  17. RFC 9728: OAuth 2.0 Protected Resource Metadata