Authority Documents and Scoped Authority for Agent-Action Evidence

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document follows the distinction between VERIFIED and ACCEPTED. Verification establishes cryptographic and structural facts given a key. Acceptance is a relying-party decision about which keys, issuers, authority sources, and policies are admissible. Existing systems use certificates, federation metadata, trust bundles, transparency services, and deployment configuration for portions of that decision. Agent-action evidence profiles still need a concrete way to bind those trust inputs to the issuer key and to the human authority being relied upon.¶

The design is deliberately not a universal public-key infrastructure. The relying party selects its trust anchors and acceptance policy. Domain control, log inclusion, and endorsement are evidence inputs, not authority by themselves. The goal is a reproducible answer to two narrower questions: which evidence key was valid at issuance, and what scoped authority did the approving subject hold for the exact action under review?¶

2. The Authority Document (EP-AUTHORITY-DOC-v1)

An authority document is a JSON object, served from the organization's own origin (RECOMMENDED: /.well-known/ep-authority.json) and registrable to a transparency service:¶

{
  "@version": "EP-AUTHORITY-DOC-v1",
  "org": { "id": "org1", "name": "...", "domain": "acme.example" },
  "seq": 3,
  "prev_doc_digest": "sha256:<core digest of doc seq 2>",
  "root_key": "<b64url SPKI>",
  "issuer_keys": [
    { "kid": "ep:authority-issuer-key:sha256:<64-hex>",
      "registry_issuer_id": "ep:authority-registry:acme-payments",
      "key": "<b64url SPKI>",
      "usages": ["evidence_issuer", "authority_proof_issuer"],
      "valid_from": "...", "valid_to": "...",
      "revoked_at": "<OPTIONAL>" }
  ],
  "issued_at": "...",
  "sig": "<root_key over the canonical core>",
  "continuity_sig": "<by a key from the PREVIOUS doc>",
  "endorsements": [ { "by_org": "...", "by_key": "...",
                      "doc_digest": "...", "sig": "..." } ]
}

The signed core is the document without sig, continuity_sig, and endorsements; its canonical digest is the document's identity. Endorsements are countersignatures over that digest by OTHER authorities -- third-party attestations that ride with the document without being part of it.¶

3. Scoped Authority Proof (EP-AUTHORITY-PROOF-v1)

An accepted issuer key with the authority_proof_issuer usage MAY sign a snapshot of one subject's authority. The proof records what the authority source asserted at issuance; it does not grant authority merely because it is carried with an action.¶

{
  "@type": "EP-AUTHORITY-PROOF-v1",
  "authority_id": "auth_cfo",
  "subject": "ep:approver:ada",
  "organization_id": "org1",
  "registry_issuer_id": "ep:authority-registry:acme-payments",
  "authority_document": {
    "head_digest": "sha256:<document core digest>",
    "head_seq": 3,
    "issuer_kid": "ep:authority-issuer-key:sha256:<64-hex>"
  },
  "role": "cfo",
  "scope": ["payment.release"],
  "limits": { "max_amount_usd": 50000, "currency": "USD" },
  "validity": {
    "from": "2026-01-01T00:00:00Z",
    "to": "2027-01-01T00:00:00Z"
  },
  "revocation": {
    "status": "not_revoked",
    "checked_at": "2026-07-14T16:00:00Z"
  },
  "registry_head": "sha256:<snapshot digest>",
  "registry_epoch": 17,
  "policy_hash": "sha256:<applicable policy digest>",
  "issued_at": "2026-07-14T16:00:00Z",
  "signature": {
    "algorithm": "Ed25519",
    "key_id": "ep:authority-registry-key:sha256:<64-hex>",
    "public_key": "<b64url SPKI>",
    "proof_digest": "sha256:<signed-body digest>",
    "signature_b64u": "<signature>"
  }
}

The signed body is the proof without the signature member, domain-separated with the ASCII string "EP-AUTHORITY-PROOF-v1" followed by a zero octet, and canonicalized using JCS [RFC8785]. The public key carried in the signature envelope is a verification input only. It MUST NOT establish its own authority. A relying party MUST resolve it through an accepted Authority Document or match it to an independently pinned authority issuer key.¶

authority_id identifies the scoped authority GRANT. registry_issuer_id identifies the registry issuer. registry_head and registry_epoch identify the authority-registry SNAPSHOT. The authority_document object identifies the Authority Document and full issuer-key identifier used to introduce the signer. These identifiers name different objects and MUST NOT be substituted for one another.¶

The max_amount_usd field is the implemented v1 monetary limit. It permits no currency conversion: a proof denominated in USD MUST NOT satisfy a limit check for another currency. Profiles that need other monetary representations MUST define their canonical amount and comparison rules rather than relying on floating-point currency conversion.¶

4. Authority Document to Authority Proof Trust Join

A proof signature and an Authority Document chain are not an integrated trust result merely because each verifies separately. A relying party that resolves an Authority Proof signer through an Authority Document MUST perform the following join. Every input described as pinned or expected is supplied by the relying party, not by the presenter.¶

1. Verify the complete Authority Document chain, including every self-signature, strictly increasing document time, sequence number, previous-document digest, and continuity signature. Continuity is established only by the previous root or by a previous issuer key carrying authority_doc_rotation and valid at the successor document's issuance instant. An unexplained continuity break is a refusal.¶
2. Match the chain to an exact relying-party-pinned bootstrap digest or document-head digest. A self-signed document with no such anchor does not introduce its own trust.¶
3. Bind the document organization to the proof organization. The relying party MUST supply the expected organization identifier and domain. Every document in the chain MUST carry that domain; when org.id is present it MUST equal the expected identifier; and the proof's organization_id MUST equal it.¶
4. Require the signed authority_document object to identify a document digest and sequence that occur in the accepted chain, plus the full digest-derived issuer_kid. The bound document entry MUST carry the proof's signed registry_issuer_id and the relying party's expected registry issuer identity.¶
5. Obtain the proof issuance instant from independently authenticated relying-party evidence, and require an exact match to the signed issued_at. A presenter-provided issued_at alone is not a time anchor. Resolve the full issuer_kid through the newest Authority Document effective at that authenticated instant. Later documents may add terminal revocation evidence, but MUST NOT retroactively grant a new usage. The resolved key MUST equal both the key in the bound document and the public key carried in the proof signature envelope, MUST come from the exact bound document, and MUST include the authority_proof_issuer usage.¶
6. Verify the proof digest and signature under that resolved key, then independently apply the relying party's mandatory authority-registry head and minimum-epoch pins. An absent pin is a refusal, not a successful check. A document head is not a registry head, a registry issuer identity is not a grant identifier, and none of these values can substitute for another.¶

The Authority Document issuer-key kid is ep:authority-issuer-key:sha256:<64-hex>, derived from the complete SHA-256 digest of the SPKI bytes. The proof-envelope key_id likewise carries its complete SPKI digest; a truncated identifier is not sufficient for the trust join. The effective-document and authenticated-time rules in Section 7 apply during resolution. A later revocation does not invalidate a proof independently time-anchored before its effective instant; a proof at or after that instant is refused. The proof's own signed issued_at is not independent evidence that it predates compromise.¶

A successful join accepts only the REGISTRY ISSUER for proof issuance. It does not establish that authority_id is a member of the named registry snapshot, validate a delegation chain, or decide that the grant's scope, role, limits, validity, and revocation status authorize a particular action. Those are separate checks in Section 5.¶

5. Authority Evaluation

Given an action, its authorization evidence, an Authority Proof, and relying-party trust inputs, a verifier MUST perform all of the following checks. A missing or failed required check produces a refusal; no unknown value is treated as permission.¶

1. Verify the proof digest and signature and establish that the signing key is accepted for authority-proof issuance, including the Authority Document trust join in Section 4 when that introduction method is used.¶
2. Match subject and organization to the approving identity and action context. A proof for one subject or organization MUST NOT be substituted for another.¶
3. Require the action type to be within scope and any required role to match.¶
4. Apply every material limit. If a capped action omits the amount or currency needed for comparison, refuse it.¶
5. Check that the action authorization time falls within the authority validity window and that the policy hash, when present, matches the policy being evaluated.¶
6. Check the registry head and minimum epoch required by the relying party. A stale or unavailable required authority view is not equivalent to an unbounded grant.¶
7. Apply revocation at its effective time. Terminal revocation evidence does not age out. A not_revoked snapshot establishes only the status observed at checked_at; current status is a separate, freshness-bounded input [I-D.schrock-ep-revocation-statement].¶

Portable profiles SHOULD express ceremony strength as verifier-visible proof predicates, such as user verification, named-human binding, or device binding. This document does not define a universal letter-grade assurance taxonomy.¶

6. Separation of Duties and Quorum

Authority and independence are different properties. An authority source can establish that a subject is eligible to approve an action; it cannot establish that the subject did not initiate that same action merely by asserting a flag. Initiator exclusion MUST be evaluated by joining the signed initiator and approver identities for the action. For a quorum, every counted approver MUST have its own accepted authority proof, and the authorization profile MUST separately enforce distinct-human and initiator-exclusion requirements.¶

7. Rotation, Continuity, and Time-of-Issuance

Documents chain: seq increments by one, prev_doc_digest names the previous core digest, and each rotation MUST carry a continuity signature by the previous document's root key or one of its issuer keys explicitly carrying authority_doc_rotation and valid at the successor document's issuance instant. Document issuance instants MUST increase strictly. A verifier walking the chain therefore needs exactly one leap - the first document it ever saw - and every subsequent rotation is mechanically checkable. A rotation without valid continuity MUST be flagged, never silently accepted; whether endorsements can substitute for continuity is the relying party's policy (Section 10), not a default.¶

Two invariants govern key resolution, and implementations that miss either will hurt someone:¶

1. Authenticated time of issuance. An artifact verifies against the key that was valid at an independently authenticated issuance instant, exactly matching its signed issued_at. Rotation never invalidates previously issued evidence, and a revocation voids a key only for signatures claimed at or after revoked_at - independently time-anchored honest history survives compromise. A proof's self-asserted issued_at alone cannot establish this.¶
2. Effective document plus terminal revocation. Key material and usages come from the newest document issued at or before the authenticated proof time. A later document cannot retroactively add authority_proof_issuer or another usage. Revocation is terminal across the observed chain: a revocation recorded in document N MUST NOT be undone by resolving the same key identifier against an older entry.¶

8. Anti-Equivocation

A malicious authority might show different documents to different relying parties. The hash chain exposes a fork when a verifier possesses both branches or a previously pinned head. Registration to a transparency service [RFC9943] can make revisions discoverable, but inclusion in one log view alone does not prove global consistency. Split-view resistance requires an independently checked consistency mechanism such as witnesses, gossip, or cross-logging. A profile MUST state which of those observations it requires; this document does not convert log inclusion into automatic acceptance.¶

9. Introduction as Evidence: Graded, Replayable Acceptance

Acceptance is not a boolean in a config file; it is a verdict over introduction evidence, evaluated under a RELYING-PARTY policy, using the same closed-verdict classification and replay-digest discipline as the evidence-sufficiency layer this family defines for actions ([I-D.schrock-ep-authorization-evidence-chain]). The evidence facts: the authority chain itself (consistent, signed, no unexplained continuity breaks); domain binding (the relying party's own attested observation that it fetched this document digest from the organization's origin); transparency-log inclusion and FIRST-LOGGED AGE (history can be a policy input, particularly when the history is independently witnessed); and endorsements, graded by whether the endorser is among the relying party's own pinned anchors.¶

Policies are per action class. A relying party can require stronger introduction evidence for money movement than for a low-impact action. New observations, such as an endorsement from an already pinned anchor or a longer witnessed history, may satisfy an unchanged policy, but they never alter that policy and never compel acceptance. The replay result MUST identify the policy and observations used so another evaluator can reproduce the decision.¶

10. Compromise Recovery

If an authority loses its keys entirely, continuity breaks by construction. The recovery path is explicit rather than exceptional: the successor document is published with no (or invalid) continuity signature, the break is flagged by every verifier, and the relying party's policy decides what substitutes - typically an endorsement threshold (a quorum of the relying party's pinned anchors countersigning the successor document) plus a revocation statement over the compromised keys. A relying party with no such policy simply continues to refuse: fail closed is the default, recovery is opt-in.¶

11. Security Considerations

Nothing creates trust from nothing, and this document does not claim to. It makes the bootstrap and scoped-authority inputs explicit and permits their checks to be replayed. The residual assumptions are named: domain binding inherits the Web PKI and is worth exactly that; log-backed consistency is as strong as the log's operator or the cross-log witnessing above it; endorsements are as strong as the endorser and mean nothing until a relying party pins one. A presenter-supplied key cannot establish its own authority. Key-resurrection (resolving a revoked key through an older document) is defeated by the newest-document-authoritative rule. Component-level verification is not composition: an Authority Document and Authority Proof that each verify independently still provide no integrated result unless the proof signer is joined to the accepted document at issuance time with the required key usage and organization binding. Even that join accepts only the issuer: a verifier that omits the separate grant/action and delegation checks can accept a genuine proof that does not authorize the action under review. Hash chaining detects conflicting branches only when the verifier has a comparison point; a single log view is insufficient to prove non-equivocation. Rotation-based history rewriting is constrained by time-of-issuance resolution. No combination of missing observations grades toward acceptance.¶

12. IANA Considerations

This document has no IANA actions. A well-known URI registration (ep-authority.json) is anticipated for a future revision.¶

Appendix A. Implementation Status

Three Apache-2.0 reference components are published in the EMILIA Protocol repository. lib/authority/authority-doc.ts covers document creation, rotation, chain verification, time-of-issuance key resolution, endorsement verification, and introduction-policy replay. lib/authority/proof.ts and lib/authority/resolver.ts cover signed scoped-authority proofs and closed authority verdicts. lib/authority/document-proof-join.ts performs the integrated, fail-closed Authority Document to Authority Proof trust join. The authority vector suite contains 27 cases, including unpinned-key, issuer-substitution, amount, currency, scope, role, lifecycle, policy, delegation, malformed-time, registry-head, and stale-epoch refusals. A separate language-neutral join catalogue contains 26 scenarios and is executable by the JavaScript reference implementation. It covers accepted resolution, missing or mismatched document anchors, continuity failure, unauthorized or expired rotation keys, non-monotonic document time, organization and domain substitution, missing and wrong-usage signer keys, refusal of a usage added only by a later document, key validity and revocation at issuance, honest historical verification before a later revocation under an authenticated time anchor, missing or mismatched proof-time anchors, mandatory registry pins, registry-issuer substitution, document-head versus registry-head confusion, full issuer-key mismatch, registry-head and epoch failures, and proof tampering. The join result explicitly marks grant/action and delegation evaluation as not performed. This is one team's reference implementation. The repository includes both the scenario catalogue and 26 fixed serialized fixtures carrying exact document chains, proofs, relying-party pins, and expected results. No second implementation has yet reported results over those fixtures, so they are interoperability inputs rather than an independent or cross-language agreement claim.¶

Appendix B. Changes since -01

This revision makes the document-to-proof trust join explicit, strengthens historical verification and anti-equivocation requirements, updates the evidence-chain and revocation references, and records the current TypeScript reference implementation. It does not make an independent-interoperability claim.¶

Author's Address