No authority. No privileged action.

# Echo Authority Protocol — Draft 0.1

Status: Draft. Not final. Not "the universal standard." Draft 0.1.
License: Public. Implement it, fork it, audit it, write another verifier.

  "AI can propose anything. It can only execute what a human has
   cryptographically authorized."

## 0. The spine (three invariants)

- INV-1  NO AUTHORITY OBJECT  -> NO PRIVILEGED ACTION
- INV-2  NO VALID INVOCATION  -> NO EXECUTION
- INV-3  NO RECEIPT           -> NO VERIFIABLE CLAIM OF COMPLETION
         (the consequence may still occur; without a receipt there is no
          verifiable claim that it did — we govern evidence, not reality)

## 1. Five separations

A conformant system MUST NOT blur these:
Identity (who are you) · Authority (what may you do) · Invocation (what exact
action now) · Enforcement (does it fit the grant) · Proof (what returns after).

Identity MUST NOT imply authority. authenticated != authorized.

## 2. The human root

Every chain of authority MUST begin at a human-rooted key.
Human Root -> Device -> Session -> Agent. The root SHOULD sign rarely and
authorize bounded, short-lived delegates. Compromise of a leaf MUST be
containable by revoking that leaf without losing the identity.

## 3. The Authority Object

An Authority Object MUST be canonical, deterministic, and signed by its issuer.
It MUST carry: issuer, subject, capability, resource, scope, constraints
(not_before, expires, max_uses, rate, human_confirmation, offline policy,
revocation freshness), delegation policy, revocation reference, receipt
requirement, depth, and the issuer signature.

## 4. Attenuation only — the algebra

A delegated (child) Authority Object MUST be a provable subset of its parent.
"Provable" is defined here as a deterministic partial order, not as prose. Two
conformant verifiers MUST reach the same verdict on every input, so the rule is
stated per dimension with an explicit ordering direction.

Four rules govern the order:

  R1  DIMENSION-WISE.      child <= parent iff child <= parent on EVERY
                           dimension below, evaluated independently.
  R2  NO TRADES.           Narrowing one dimension MUST NOT permit widening in
                           another. There is no aggregate score.
  R3  DENY IF UNPROVABLE.  A dimension that cannot be proven narrower-or-equal
                           MUST be refused. Unrecognized fields, dropped
                           ceilings, and unparseable resources all refuse. The
                           burden of proof is on the child.
  R4  UNBOUNDED IS WIDEST. An absent ceiling means "no limit" and is the top of
                           its dimension. A child MUST NOT drop a ceiling that
                           its parent declared.

Ordering directions:

  ceiling   child <= parent      caps, uses, rates, depth, staleness windows
  floor     child >= parent      not_before — may start later, never earlier
  exact     child == parent      capability, revocation method
  refine    parent unset means any; if the parent pinned it, the child MUST match
  restrict  child >= parent      obligations — true is MORE restrictive
  permit    child <= parent      permissions — false is MORE restrictive
  subset    language containment for resource globs
  binding   structural identity, defined per field

### 4.1 The ten dimensions

  WHO         issuer MUST equal the parent subject                    (binding)
  WHAT        capability                                              (exact)
  RESOURCE    resource                                                (subset)
  AMOUNT      scope.max_per_action, scope.max_total                   (ceiling)
              scope.currency                                          (refine)
              any other scope key                                     (R3)
  TIME        constraints.not_before                                  (floor)
              constraints.expires                                     (ceiling)
  FREQUENCY   constraints.max_uses, constraints.rate_limit_per_hour   (ceiling)
  CONDITIONS  constraints.require_human_confirmation                  (restrict)
              constraints.offline_allowed                             (permit)
              constraints.offline_value_limit                         (ceiling)
  DELEGATION  delegation.allowed                                      (permit)
              delegation.max_depth, strictly shallower                (ceiling)
              depth MUST equal parent depth plus one                  (binding)
  REVOCATION  constraints.revocation_max_age_sec                      (ceiling)
              revocation.freshness_required_sec                       (ceiling)
              revocation.method                                       (exact)
  PROOF       receipt.required                                        (restrict)

A child that widens ANY dimension MUST be refused (DELEGATION_NOT_SUBSET).

### 4.2 Consequences a verifier MUST NOT miss

These follow from 4.1, and are called out because a prose reading of "narrow the
limits" misses every one of them:

- A child MUST NOT drop require_human_confirmation. Removing an obligation is an
  escalation even while every numeric cap shrinks.
- A child MUST NOT enable offline use, or raise an offline value limit, that its
  parent withheld.
- A child MUST NOT begin before its parent begins.
- A child MUST NOT change currency. A different unit is a different scope, not a
  smaller one.
- A child MUST NOT accept staler revocation data than its parent. Widening the
  window in which a revoked grant still works widens authority.
- A child MUST NOT drop the receipt requirement, which would leave it less
  accountable than its parent.
- A child MUST NOT introduce a scope key its parent never granted (R3).
- A child MUST NOT skip a depth level, and MUST be issued by the subject of the
  grant it descends from. A "child" issued by anyone else is a forged sibling.

### 4.3 Resource language

Resources are compared as segment sequences separated by "/". Within a resource:

  literal    matches itself
  *          matches exactly one segment
  **         matches one or more remaining segments, and MUST be final
  prefix*    matches within a single segment, e.g. merchant:*

Containment is language containment, NOT string prefixing. A verifier MUST NOT
implement this with a startsWith comparison: under prefix comparison the
resource vault/public-secrets/x falsely appears to sit inside vault/pub*,
crossing a segment boundary while reading as a narrowing. A child segment MUST
NOT be a wildcard where the parent named a literal, and MUST NOT be ** where the
parent admitted only a single segment.

### 4.4 Order properties

The relation is irreflexive: no grant is its own child, because WHO cannot link
to itself and depth cannot advance. It is antisymmetric on distinct grants — if
child <= parent, then parent <= child MUST NOT also hold. Conformant
implementations SHOULD test both properties directly.

## 5. The Invocation Object

The Invocation Object describes the exact action attempted now. It MUST bind:
authority id, subject, capability, resource, parameters, audience (the gateway),
nonce, and time — and MUST be signed by the subject.

## 6. Border Control (enforcement)

Enforcement MUST be deterministic. No language model MAY sit inside it.
The verifier MUST check, in order, and stop at the first failure with an
EXACT reason code:

FORBIDDEN RULES · ISSUER · SUBJECT · AUTHORITY SIGNATURE ·
INVOCATION SIGNATURE · CAPABILITY · RESOURCE · PARAMETERS (value, currency,
total) · EXPIRY · MAX USES · RATE · DELEGATION CHAIN · REVOCATION ·
REVOCATION FRESHNESS + OFFLINE POLICY · AUDIENCE · NONCE · HUMAN CONFIRMATION.

## 7. Forbidden authority

Some capabilities MUST be structurally ungrantable — no consent can form them:
root.export, recovery.export, audit.disable, authority.exceed-owner,
history.rewrite. Border Control MUST reject these regardless of the request.

## 8. Revocation freshness

Offline verifiers MUST NOT pretend revocation is instant. Each Authority Object
MUST declare how stale revocation information MAY be. When offline and staler
than that bound, the verifier MUST deny (REVOCATION_STALE). The less fresh the
network state, the smaller the authority.

## 9. Replay protection

A verifier MUST reject a previously consumed invocation where the capability is
single-use (NONCE_REPLAY). Invocations MUST bind nonce, audience, id, time,
resource, parameters, and a usage counter.

## 10. Receipts

A gateway can prove exactly one thing: that it evaluated authority and returned
a decision. It cannot prove that a bank settled, that a door opened, or that a
message left the building. A single receipt claiming "it happened" therefore
asserts evidence the protocol never held.

Receipts are consequently SPLIT into three types. Each names its own ceiling,
and an implementation MUST NOT present one as another.

### 10.1 Authority Decision Receipt

Issued by the gateway for EVERY evaluation — ALLOW and DENY alike. A refusal is
evidence and MUST be receipted.

Fields: authority id, invocation id, subject, capability, decision, reason code,
evaluating gateway, evaluation time, opaque proof.

Proves: authority was evaluated against this invocation and this decision was
returned. Proves NOTHING about whether the action was then carried out.

### 10.2 Execution Receipt

Issued by the executor that acted on an ALLOW. It MUST cite the §10.1 receipt
that authorized it; an execution receipt that cites no decision, or cites a
DENY, MUST be rejected as malformed.

Fields: cited decision receipt, executor identity, dispatch time, result, data
disclosed, reversibility, opaque proof.

Proves: the attempt was dispatched. Proves NOTHING about whether it took effect.

### 10.3 Consequence Receipt

Issued only when an external attestor reports back. It MUST cite the §10.2
receipt it settles, and MUST name the attestor in settledBy. The attestor is
never the gateway.

The outcome field is exactly one of:

  CONFIRMED_SUCCESS   an attestor confirms the consequence occurred
  CONFIRMED_FAILURE   an attestor confirms it did not
  UNKNOWN             no attestor has reported

A verifier MUST NOT read UNKNOWN as either success or failure. UNKNOWN is the
correct and honest state for an action whose consequence has not settled, and it
is the default. The settledAt field MUST be null while outcome is UNKNOWN.

Proves: what the named attestor asserted. The protocol records the attestation;
it does NOT vouch for the attestor.

### 10.4 What the chain proves

The three types compose, and the ceiling of the whole chain is the weakest link
present — never the strongest:

  decision only            authority was evaluated and permitted
  + execution              the action was dispatched
  + CONFIRMED_SUCCESS      an attestor confirms it took effect

INV-3 holds across all three: no receipt means no VERIFIABLE claim of
completion. The consequence may still have occurred. We govern evidence, not
reality — and none of the three proves the action was WISE. Judgment stays human.

## 11. Reason codes (normative)

OK · FORBIDDEN_CAPABILITY · BAD_ISSUER · SUBJECT_MISMATCH ·
BAD_AUTHORITY_SIGNATURE · BAD_INVOCATION_SIGNATURE · CAPABILITY_MISMATCH ·
RESOURCE_MISMATCH · VALUE_LIMIT_EXCEEDED · TOTAL_LIMIT_EXCEEDED ·
CURRENCY_MISMATCH · NOT_YET_VALID · EXPIRED · MAX_USES_EXCEEDED ·
RATE_LIMIT_EXCEEDED · DELEGATION_INVALID · REVOKED · REVOCATION_STALE ·
OFFLINE_NOT_ALLOWED · OFFLINE_VALUE_EXCEEDED · AUDIENCE_MISMATCH ·
NONCE_REPLAY · HUMAN_CONFIRMATION_REQUIRED

## 12. The trust model

Every agent is untrusted by default. Every model is untrusted by default.
The model is not the security boundary. Border Control is.

## 13. Independence

The protocol MUST NOT depend on any single vendor. Money Musk implements it,
Echo demonstrates it, but the protocol belongs to everyone. Anyone MUST be able
to implement it, fork it, audit it, and verify the same test vectors.