Authority Documents and Scoped Authority for Agent-Action Evidence
draft-schrock-ep-authority-introduction-03

Network Working Group                                         I. Schrock
Internet-Draft                                     EMILIA Protocol, Inc.
Intended status: Informational                             4 August 2026
Expires: 5 February 2027

   Authority Documents and Scoped Authority for Agent-Action Evidence
               draft-schrock-ep-authority-introduction-03

Abstract

   Signature verification answers whether a key produced an artifact.
   It does not answer why a relying party accepts that key, or whether
   the key holder had authority for the action.  This document specifies
   two composable artifacts.  An Authority Document introduces and
   rotates an organization's evidence-issuing keys through a signed,
   hash-chained sequence.  A Scoped Authority Proof records the
   authority held by a subject at a registry snapshot, including role,
   action scope, material limits, policy binding, validity, and
   revocation status.  A relying party evaluates both artifacts under
   its own pinned trust inputs and policy.  The design does not make a
   self-presented key authoritative, does not turn log inclusion or
   domain control into automatic trust, and does not equate a valid
   signature with permission to act.  It also defines a source-
   resolution boundary: signing a statement does not give its underlying
   source data finer freshness or precision than that source actually
   provides.

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 5 February 2027.

Schrock                  Expires 5 February 2027                [Page 1]
Internet-Draft           Authority Introduction              August 2026

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The Authority Document (EP-AUTHORITY-DOC-v1)  . . . . . . . .   3
   3.  Scoped Authority Proof (EP-AUTHORITY-PROOF-v1)  . . . . . . .   4
   4.  Source Resolution and Claim Precision . . . . . . . . . . . .   5
   5.  Authority Document to Authority Proof Trust Join  . . . . . .   6
   6.  Authority Evaluation  . . . . . . . . . . . . . . . . . . . .   8
   7.  Separation of Duties and Quorum . . . . . . . . . . . . . . .   9
   8.  Rotation, Continuity, and Time-of-Issuance  . . . . . . . . .   9
   9.  Anti-Equivocation . . . . . . . . . . . . . . . . . . . . . .  10
   10. Introduction as Evidence: Graded, Replayable Acceptance . . .  10
   11. Compromise Recovery . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  Implementation Status  . . . . . . . . . . . . . . .  13
   Appendix B.  Changes since -02  . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

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.

Schrock                  Expires 5 February 2027                [Page 2]
Internet-Draft           Authority Introduction              August 2026

   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?

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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.

Schrock                  Expires 5 February 2027                [Page 3]
Internet-Draft           Authority Introduction              August 2026

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>"
     }
   }

Schrock                  Expires 5 February 2027                [Page 4]
Internet-Draft           Authority Introduction              August 2026

   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.  Source Resolution and Claim Precision

   A signature authenticates a statement by its signer.  It does not
   establish that every upstream fact used to construct that statement
   was observed at the signature time, or that an upstream record
   supports the same temporal or semantic precision as the signed
   statement.  This is especially important for role, employment,
   entitlement, delegation, and revocation data that may be synchronized
   from another system.

   Implementations and profiles MUST distinguish, when applicable, the
   following instants:

   *  the effective time asserted by the underlying authority record;

   *  the time at which the authority source was actually observed;

   *  the time at which the portable proof was issued; and

   *  the time at which the relying party evaluates the proof.

Schrock                  Expires 5 February 2027                [Page 5]
Internet-Draft           Authority Introduction              August 2026

   Issuing or re-signing a proof MUST NOT move the source observation
   time forward.  In particular, a producer MUST NOT set
   revocation.checked_at to issued_at unless the named revocation source
   was actually checked at that instant.  If no revocation observation
   was made, the implementation MUST represent that absence and MUST NOT
   synthesize not_revoked.

   A profile that relies on a fact derived from an upstream source MUST
   state the source or source class, the maximum accepted observation
   age, and any coarser resolution or synchronization bound that affects
   the claim.  A signed assertion MUST NOT claim finer resolution than
   the underlying source record supports.  For example, a proof issued
   at 12:00 cannot establish role validity at 12:00 when its only role
   source is a directory snapshot last synchronized at 06:00, unless the
   relying party's policy explicitly accepts that six-hour source bound.

   If a required source observation is absent, older than the relying
   party's bound, or unable to support the required claim precision, the
   authority leg is indeterminate.  The relying party MUST refuse an
   action that requires that authority leg; a fresh signature over stale
   or imprecise source data MUST NOT upgrade the result.  This rule
   applies equally to corporate authority records such as those linked
   by OMP [I-D.veridom-omp] and to standing role credentials such as the
   vLEI composition described by AGTP-LEI [I-D.hood-agtp-lei].  Those
   mechanisms retain their native verification and governance semantics;
   the relying party decides whether their source resolution is
   sufficient for the action under review.

5.  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.

Schrock                  Expires 5 February 2027                [Page 6]
Internet-Draft           Authority Introduction              August 2026

   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 8 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 6.

Schrock                  Expires 5 February 2027                [Page 7]
Internet-Draft           Authority Introduction              August 2026

6.  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 5 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].  Apply the source-
       resolution requirements in Section 4; a newly signed proof does
       not refresh an older source observation.

   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.

Schrock                  Expires 5 February 2027                [Page 8]
Internet-Draft           Authority Introduction              August 2026

7.  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.

8.  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 11), 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.

Schrock                  Expires 5 February 2027                [Page 9]
Internet-Draft           Authority Introduction              August 2026

9.  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.

10.  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.

11.  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.

Schrock                  Expires 5 February 2027               [Page 10]
Internet-Draft           Authority Introduction              August 2026

12.  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.

   A valid signature can authenticate an over-precise claim.  A verifier
   that compares only artifact issuance time to its freshness bound can
   accept stale role, entitlement, or revocation data that was merely
   re-signed.  The source-resolution rules in Section 4 prevent that
   freshness laundering.

13.  IANA Considerations

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

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Schrock                  Expires 5 February 2027               [Page 11]
Internet-Draft           Authority Introduction              August 2026

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

14.2.  Informative References

   [I-D.hood-agtp-lei]
              Hood, C., "AGTP-LEI: Binding the Agent Transfer Protocol
              to the Verifiable Legal Entity Identifier", Work in
              Progress, Internet-Draft, draft-hood-agtp-lei-00, 28 June
              2026,
              <https://datatracker.ietf.org/doc/draft-hood-agtp-lei/>.

   [I-D.schrock-ep-authorization-evidence-chain]
              Schrock, I., "Authorization Evidence Chains: Composing
              Heterogeneous Agent-Action Evidence (EP-AEC)", Work in
              Progress, Internet-Draft, draft-schrock-ep-authorization-
              evidence-chain-04, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-ep-
              authorization-evidence-chain/>.

   [I-D.schrock-ep-revocation-statement]
              Schrock, I., "Revocation Statements for Agent-Action
              Authorization Evidence", Work in Progress, Internet-Draft,
              draft-schrock-ep-revocation-statement-01, July 2026,
              <https://datatracker.ietf.org/doc/draft-schrock-ep-
              revocation-statement/>.

   [I-D.veridom-omp]
              Adebayo, T. and O. Apalowo, "Operating Model Protocol
              (OMP) Core -- Version 02: Invariant 3 -- Verifiable
              Delegation Binding", Work in Progress, Internet-Draft,
              draft-veridom-omp-02, 13 May 2026,
              <https://datatracker.ietf.org/doc/draft-veridom-omp/>.

   [RFC9943]  Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", RFC 9943,
              DOI 10.17487/RFC9943, June 2026,
              <https://www.rfc-editor.org/info/rfc9943>.

Schrock                  Expires 5 February 2027               [Page 12]
Internet-Draft           Authority Introduction              August 2026

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.

   The reference signer does not manufacture a positive revocation
   state.  When the caller supplies no observation, the signed proof
   carries revocation as null; an explicit unknown observation remains
   unknown.  Only an explicit status and strict RFC 3339 checked_at
   instant can enter the revocation object.  Regression tests cover
   omitted, unknown, malformed, fresh, stale, and revoked cases.  The
   authorization-server confirmation adapter applies the same source-
   resolution rule to directory snapshots: a fresh confirmation cannot
   make an older directory observation fresh.

Schrock                  Expires 5 February 2027               [Page 13]
Internet-Draft           Authority Introduction              August 2026

Appendix B.  Changes since -02

   This revision defines the source-resolution boundary for authority
   evidence, distinguishes source observation from artifact issuance and
   relying-party evaluation, prohibits freshness laundering by re-
   signing, and records the fail-closed reference behavior for absent,
   unknown, and stale revocation observations.  It adds informative
   composition context for OMP and AGTP-LEI without changing either
   mechanism's native verification or governance semantics.

Author's Address

   Iman Schrock
   EMILIA Protocol, Inc.
   United States of America
   Email: team@emiliaprotocol.ai

Schrock                  Expires 5 February 2027               [Page 14]