Delegation

After this lesson, the reader should understand:

• 01Model a delegation as an object linking a grantor, a holder, a scope, and a term.
• 02Trace a delegation chain and identify where it can be broken or exceeded.
• 03Handle expiry, revocation, and sub-delegation explicitly.

The chain nobody could draw

An agent acts 'on behalf of' a team lead, who holds a delegation from a director, whose delegation lapsed at a reorganisation six months ago. The agent's action is challenged. Who authorised it?

On the records, no one — the chain has a broken link, and nothing in the runtime checked the links. Delegation expressed in org charts and email approvals cannot be evaluated at machine speed, so the agent inherited an authority that no longer existed upstream. As objects, each delegation carries its grantor, its term, and its conditions; the runtime resolves the chain before it authorises, and a lapsed link fails closed. The institution's answer to 'who authorised it' should be a path it can print, not a reconstruction it attempts after the fact. A draft specification, NOMOS-SPEC-007, gives this a concrete form: one key certifies another to sign — within a stated scope, until an expiry — and a verifier resolves the whole chain offline against a root the caller pins, with no default root and no call home. Certificate scope is enforced rather than decorative: a delegation for one action does not carry to another. Revocation is keyed on the withdrawn key itself, not on a single certificate, so a revoked key is dead on every path a presenter might construct to it. A chain that does not resolve returns a distinct 'issuer not recognised' outcome, never a verdict — the fix for that is a better chain, and the fix for a denial is not.

• Should a delegation ever be open-ended, or must every one carry a term?
• When an upstream delegation is revoked, what happens to decisions already made downstream?
• May an agent sub-delegate authority it holds, and how is that bounded?
• Who audits the population of live delegations in an institution?

Draw one real delegation chain as objects.

1. 01Pick an action taken by a system or agent 'on behalf of' someone.
2. 02List each delegation link from the acting party back to the authority holder.
3. 03For each link, record grantor, holder, scope, conditions, and term.
4. 04Mark any link that is implicit, undated, or unrevocable.
5. 05State what the runtime should do when one link cannot be resolved.

• Agency law — actual, apparent, and ostensible authority.
• Capability-based security — delegation and attenuation of rights.
• Administrative delegation — sub-delegation and delegatus non potest delegare.
• Identity federation — delegation tokens and act-on-behalf-of semantics.
• Computable Authority, §15 — the governance lifecycle and delegation as a lifecycle stage.
• NOMOS-SPEC-007 (Draft) — key certificates with enforced scope and expiry, offline chain verification against a caller-pinned root, key-keyed revocation.