Lecture 4.3
Authority is rarely exercised by the body that holds it. It is delegated — to an office, a person, a system, and now to an agent that may sub-delegate again. This lecture treats delegation as a first-class object with a grantor, a holder, a scope, conditions, and an expiry, and examines what breaks when a chain of delegations is implicit.
Learning objectives
After this lesson, the reader should understand:
Concept framework
Anatomy of a delegation
Case study
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[1]: 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. The strongest objection comes from agency law, which has managed broken chains for centuries without failing closed. A third party who reasonably relied on the appearance of authority is protected even when the actual authority had lapsed[2], and a principal can ratify an unauthorised act after the fact, curing it. Institutions run on these doctrines; a runtime that refuses every action with a stale link would halt half of them the morning after a reorganisation. The objection is right about the cost and wrong about the model. Apparent authority and ratification are remedies — they allocate loss after something has gone wrong, and ratification still requires a person with authority to decide. They are not a way to operate at machine speed. The practical answer is to treat the lapsed link as an escalation to whoever can ratify, rather than a silent allow or a flat refusal, and to make reorganisations re-issue delegations as part of the change, not months later. Explicit chains also do not solve a problem that has been known in computer security since the 1980s. An agent that holds a valid delegation can be induced to use it on behalf of someone who holds none — the confused deputy[3]. The chain proves the agent was entitled to act; it does not prove the agent acted for the party it was entitled to act for. Capability-based designs answer this by making the authority travel with the specific request rather than reside with the agent[4], and an agent architecture that takes delegation seriously has to inherit that discipline.
Discussion questions
Discussion (0)
No responses yet. Be the first to answer one of the questions above.
Start the course to join the discussion.
Exercise
Draw one real delegation chain as objects.