PRIOR ARTAn invention claim that ignores what came before is not a strong claim — it is an unchecked one.the core laws →
AUTHORITY CANON · PRIOR ART & DESIGN LINEAGE

We did not invent delegated authority. We inherited it.

Naming the lineage is what makes the contribution checkable.

Almost every mechanism in the Echo Authority Protocol has an ancestor, and most of those ancestors are older than this project by decades. Attenuated delegation, authorization separated from identity, append-only proof logs, offline verification — all of it was worked out by people whose names belong on this page.

Why publish this at all? Because a protocol that hides its lineage is asking to be trusted, and this one is supposed to be checkable instead. If the interesting part of EAP is real, it survives being placed next to SPKI, macaroons and UCAN. If it does not survive that, we would rather find out here than have someone else discover it later.
The ancestors

Where each piece actually came from

Read the right-hand line of each entry as an admission, not a citation. It says what we took.

  1. 1966

    The object-capability model

    Dennis & Van Horn; later Mark Miller's work on robust composition and the E language

    Authority is an unforgeable reference you hold, not a claim about who you are. Designation and permission are the same act, which is where the principle of least authority comes from.

    what we tookThe root idea that a grant is an object a principal holds — never a lookup on identity.

  2. 1996

    PolicyMaker & KeyNote

    Blaze, Feigenbaum & Lacy — later RFC 2704

    Trust management: the decision comes from evaluating signed assertions against a specific request, rather than consulting an access-control list.

    what we tookThe verifier evaluates signed statements about this action — it does not consult a table of who is allowed.

  3. 1999

    SPKI / SDSI

    Ellison, Frantz, Lampson, Rivest, Thomas & Ylönen — RFC 2692 / 2693

    Authorization certificates instead of identity certificates: the holder of this key may do X. A five-tuple carrying issuer, subject, authorization, validity, and an explicit delegation control bit.

    what we tookThe separation this whole protocol rests on — identity is not authority — plus delegation as an explicit, bounded field rather than an implicit consequence of holding a token.

  4. 2012

    OAuth 2.0

    IETF — RFC 6749

    Delegated access at internet scale. The reason a billion people already understand letting an app act for them without handing over a password.

    what we tookThe goal, and a clear negative lesson: server-defined coarse scopes, bearer tokens, and no way to narrow a grant you have been handed.

  5. 2013

    Certificate Transparency

    Laurie, Langley & Kasper — RFC 6962

    An append-only Merkle log with inclusion and consistency proofs, signed checkpoints, and independent witnesses gossiping to catch a split view.

    what we tookEcho's Transparency Log is this design, applied to authority decisions instead of certificates. The witness quorum is the same idea.

  6. 2014

    Macaroons

    Birgisson, Politz, Erlingsson, Taly, Vrable & Lentczner (Google)

    Credentials with caveats, chained through HMAC so a holder can only ever narrow what they were given — never widen it. Plus third-party caveats for discharge.

    what we tookAttenuation-only delegation. This is the direct ancestor of the rule that a child grant can never exceed its parent.

  7. 2016

    OpenTimestamps

    Peter Todd

    Bitcoin as a neutral timestamping notary, reachable through public calendar servers, proving a commitment existed before a given block.

    what we tookExactly how the authority-log tip gets anchored — no new chain, no token, no trusted operator.

  8. 2019

    DIDs, Verifiable Credentials & ZCAP-LD

    W3C and the W3C Credentials Community Group

    Identifiers the subject controls, signed attribute claims that verify offline, and — in ZCAP-LD — object capabilities with invocation, delegation and caveats.

    what we tookThe subject-controls-the-key root. Note the boundary: a credential asserts an attribute, which is not the same thing as permission to act.

  9. 2021

    Biscuit

    Clever Cloud

    Datalog-based authorization tokens: offline attenuation, public-key verification, and policy checks expressive enough to reason about formally.

    what we tookThe standard we are measured against for formal rigour — and currently fall short of.

  10. 2021

    UCAN

    Fission and collaborators

    User Controlled Authorization Networks: DID-rooted authority, attenuated delegation chains, invocation separated from delegation, and revocation — all offline-verifiable.

    what we tookThe closest thing to this protocol that already existed. It deserves its own section below.

  11. 2024

    GNAP

    IETF — RFC 9635

    OAuth's intended successor: richer grant negotiation, multiple key-bound instances, and a cleaner separation between the requesting party and the client.

    what we tookConfirmation that the industry is already moving from access toward negotiated authority — and a reminder of how much process a real standard takes.

The closest relative

UCAN, side by side

If you already know UCAN, you will recognise most of this protocol, and you should be told that plainly rather than left to discover it. Here is the honest reckoning.

What is the same
  • Authority is rooted in a subject who holds a key, not in a server's permission table.
  • Delegation attenuates: a child grant can only narrow what its parent already held.
  • Invocation is a distinct signed object from the grant that authorizes it.
  • Grants carry expiry and support revocation.
  • A verifier can evaluate a chain offline, with no call home.
Where this protocol diverges
The root must be a humanA UCAN root is a DID, which may belong to a person, a service, or a machine — that is a deployment choice. This protocol makes human-rooted authority a normative requirement: no machine may originate authority, only transmit it.
Presence is separate from permissionPrior authority is always required. Whether a human must also be present in the moment is consequence-dependent, on an explicit step-up ladder. Capability systems generally have no vocabulary for 'this one needs a person right now'.
Some authority cannot be formedIn most capability systems, anything expressible is delegable. Here a forbidden set — export a root key, disable the audit log, rewrite history — cannot be minted by any principal at any depth. The object refuses to exist.
The verifier is pinned downUCAN leaves evaluation order largely to implementations. Border Control fixes the order of checks, closes the reason-code vocabulary, and ships conformance vectors, so two independent verifiers must return the identical verdict — not merely a compatible one.
And the part that favours UCAN: it is further along as a standard than we are. It has a public specification process, multiple independent implementations, and real deployments. We have a Draft 0.1 and two implementations that we wrote ourselves. Being earlier is not the same as being better, and being newer is not a virtue.
The contribution

What is actually new here

Six things, stated narrowly enough to be argued with. Not “we built a capability system” — that was done in 1966.

01

Ten dimensions as normative semantics

Prior art specifies a mechanism — caveats, Datalog, JSON-LD proofs — and leaves the dimension vocabulary to each application. This protocol names all ten (who, what, resource, amount, time, frequency, conditions, delegation, revocation, proof) as normative, then projects them into eight questions a person can actually read.

02

A human root by construction

Not a recommendation about how to deploy it. A requirement that every chain terminates in a person, with the machine-to-machine case defined as transmission rather than origination.

03

Consequence-dependent step-up

One ladder covering standing bounded grants through to fresh signatures for irreversible actions — so 'buy groceries under thirty euros until six' and 'transfer the house' are governed by the same model without collapsing into either extreme.

04

Structural refusal

A defined class of authority that cannot be granted regardless of consent, enforced at mint time rather than checked at use time. Consent is not treated as unlimited.

05

Verdict-level determinism

A fixed evaluation order, a closed reason-code set, and a shared hostile vector suite, so agreement between implementations is testable rather than asserted.

06

Evidence discipline

Proof-never-data as a structural boundary that throws rather than logs, plus revocation freshness stated as an explicit per-risk-class policy instead of a best-effort CRL check.

The other column

What prior art still does better

A lineage page that only listed our additions would be marketing wearing a bibliography. These are places where the work above is ahead of us.

No general policy logic, and no machine-checked proof

Attenuation is no longer prose. It is now a deterministic partial order over all ten dimensions, with explicit ordering directions and deny-if-unprovable semantics — and writing it down caught twelve escalations the old prose rule accepted, including a child that dropped its parent's human-confirmation requirement. But Biscuit still has something we do not: Datalog expresses arbitrary policy rules, while our order is fixed to ten dimensions, so a condition outside that vocabulary cannot be stated at all. And our order properties are covered by tests, not by a proof assistant. It is a specified algorithm now, not yet a theorem.

No third-party discharge

Macaroons can require a caveat be discharged by an independent party before a credential is valid. That is genuinely useful and we do not have it.

No DID, VC or KERI mapping

The identity layer the rest of this field standardised on, and we have not yet written the bridge. It is the largest gap we name about ourselves.

No standards process

SPKI, OAuth, GNAP and Certificate Transparency went through the IETF. DIDs, VCs and ZCAP-LD went through the W3C. This is a Draft 0.1 published by one project, which is a much weaker thing.

No independent implementers

Two implementations agree, and both were written by us. Implementation diversity is not third-party adoption.

No zero-knowledge proofs

Every verification reveals the signed terms to the verifier. Selective-disclosure credential work is well ahead of us here.

Falsify this page

How to prove us wrong

Point at a system that already does one of the six things listed as contributions. If you are right, that row moves out of the contribution column and into the lineage above, with a credit. That is not a rhetorical gesture — the six are written narrowly precisely so the check is possible, and a shorter honest list is worth more than a longer flattering one.

The same standard applies to the ancestry itself. If a description above misrepresents someone else's work, that is a defect in this document, and it should be fixed here rather than defended.