horton audit

Horton: Delegating Responsibility in Digital Systems

Mark S. Miller (Google), James E. Donnelley (NERSC/LBNL), Alan H. Karp (HP Labs) HotSec '07

Abstract

OCap systems excel at proactive control — delegating narrow authority so damage is limited by construction. But their anonymous bearer-right semantics seem to rule out reactive control: you can't tell who to blame when something goes wrong. This has been a standing criticism of the ocap paradigm since the TCSEC (Orange Book) era.

Horton (Higher-Order Responsibility Tracking of Objects in Networks) refutes that criticism. It interposes proxy/stub pairs between mutually suspicious parties, logging each message with a whoBlame identity. The key induction: when Alice delegates access to Carol's resource to Bob, Carol creates a new stub tagged with Bob's identity, so Carol can blame Bob (not Alice) for misuse — without involving Carol in every subsequent message.

The protocol uses the sealer/unsealer pattern (already in vattr97/src/sealer.ts) for gift-wrapping: Carol seals a provide function so only Bob can unwrap it, Bob creates a fill function sealed for Carol, and they exchange these to establish a trusted channel. This prevents Alice from forging blame onto Bob or Carol.

Relevance to governance

Our M1 stories (decision recording, chain of delegation, revocation) are exactly what Horton provides. The proxy/stub pattern maps to steward intermediaries: a lead steward's proxy logs outgoing delegations; a domain steward's stub logs incoming requests. The whoBlame identity corresponds to the steward role capability.

Horton shows we don't need to abandon ocap discipline for audit — we need the right interposition pattern.

References

• Paper: https://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/
• Implementations in Java and E: http://erights.org/download/horton/
• See also: capability-patterns-and-endo.md — sealer/unsealer, CareTaker patterns