---
face: "Made from the record as of 9 November 2026."
---

# Protocols

Internet-Drafts I wrote or co-wrote at the IETF. None has been adopted as a standard yet.

## Acts-For: Signing In to a Website with a ~handle, for a Person or an Agent Acting for One

Acts-For lets a person sign in to any website with the ~handle they already hold, and lets an AI agent sign in or register at that website on the person's behalf. Neither needs a username, a password or an account per site. A website joins by publishing one DNS record. A person signs in through a standard OpenID Connect authorization code flow and the site receives a short-lived token naming the person by a number unique to that site. An agent obtains a short-lived pass from the issuer over the Model Context Protocol and presents it to the site. The pass names the same per-site number, the agent's own key and ~handle, and the limits the person set. The site checks it against a published key and calls nobody. /protocols/acts-for/

## An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions

This memo specifies an application-layer frame format and a delivery model by which the several concurrent agentic sessions of a single identity-bound principal, and the recognised members of an organisational identity substrate, exchange short structured messages. The frame, termed the agent-channel frame, is a transport envelope: it carries a closed-catalogue kind discriminator, a structured per-kind payload, an identity attribution pair, and an inline provenance block. Delivery is fan-out: a sender names a recipient scope rather than a single endpoint, and the scope is expanded at delivery time against the recipient's subscriptions. Recipients receive frames over a per-handle Server-Sent Events stream and can narrow what they receive with a subscribe-time filter expression. Frames are ephemeral routing units; the memo specifies only the wire envelope, the scope-expansion grammar, the subscribe filter grammar, and the delivery semantics. Frame persistence, where an implementation chooses to retain frames for replay, is out of scope and is not specified. The memo composes with the handle namespace and discovery surface of draft-morrison-mcp-dns-discovery and the cross-organisational ceremony of draft-morrison-identity- accord; no new transport and no new handle category is introduced. /protocols/agent-channel-fan-out/

## The 'alter' URI Scheme for Dispatchable ~handle References

This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published in the DNS records defined in the companion specification for discovering Model Context Protocol servers through DNS TXT records. An alter: URI binds a textual ~handle reference to a resolution and verification procedure that retrieves the handle's envelope from a publishing zone, validates the envelope's signature chain, and dispatches the result to an operating-system URI handler. The reference may be scoped to an organisation, narrowed to a named facet of the identity, and addressed to a typed action surface. The scheme is the addressing form of the ~handle@org:facet/action reference; its resolution semantics are those of that companion specification, reused without modification. The scheme is provider-neutral and introduces no new cryptographic primitive. A handler given an alter: URI verifies the handle's envelope before acting on it, and where the URI addresses an action, verification precedes any side effect. IANA provisionally registered the alter scheme under Section 4 of RFC 7595 on 5 October 2026. /protocols/alter-uri-scheme/

## The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation

This memo specifies the briefing-and-binding envelope: a delivery contract for the wire-level structure by which an artificial- intelligence agent surfaces a consequential decision to the human principal it acts for, and by which the principal commits, declines, amends, or rejects that decision. The envelope carries eight named slots (a synopsis, findings, recommendations, an offer of detail, a question stem, a set of options each marked with its own reasoning, a single recommended option, and a pair of escape hatches) and is emitted as a structured field of a Model Context Protocol tool result. The envelope is renderer-agnostic, so the briefing an agent delivers and the binding a principal commits back have one machine- checkable shape across every consuming surface. The memo also specifies a dual-veto handshake: one escape hatch lets the principal revise the answer space while accepting the question; the other lets the principal reject the question itself and reopen deliberation. Either party may veto. The memo defines a content digest over the envelope, canonicalized under JCS and hashed with SHA-256, so that a resolution names the exact envelope it resolves and an external receipt can reference that envelope by digest. The memo is Informational. No new transport is introduced; the envelope composes with the handle namespace of draft-morrison-identity-pronouns and the MCP tool surface of draft-morrison-org-alter-policy-provision. /protocols/binding-moment-envelope/

## Claim Currency: A Read-Time Decay Evaluator and Observation-Gated Re-Assertion Discipline for Concurrent Readers of a Reconciled Substrate

This memo specifies a read-time freshness evaluator and an observation-gated re-assertion discipline for concurrent autonomous readers of a single reconciled substrate history. For every claim read from the substrate, a three-state currency band (FRESH, AGING, STALE) is derived at read time from the durable history and is never stored. A claim whose derived band is not FRESH MUST NOT be re- emitted as current and MUST NOT ground a new durable claim; the sole transition back to currency is a fresh observation of the claim's basis, enforced at the substrate's append stage rather than at any reader's discretion. The memo is the claim-layer consumer that two companion specifications, Substrate-Observation as an Alternative to Envelope Coordination and the Substrate-Provenance Annotation Grammar, each left unspecified. The contribution is a specific composition: a read-time-derived band, a decay clock measured in missing observations learned from a basis's own change cadence, an append-stage rejection of any claim citing a basis that is no longer the head of its lineage, and observation as the only admissible refresh. No new substrate is standardised; the discipline composes with substrate that already exists. /protocols/claim-currency/

## The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes

This memo specifies the compute-location gate: a mechanism by which a client and an identity-inference server negotiate, at the wire layer and before any inference is performed, the location at which an identity inference will compute, as a deterministic function of the provenance class of the input signal. Three provenance classes are distinguished. Active inference, initiated by the inferred-about principal, MAY compute server-side and produce a server-held identity vector. Passive aggregate observation over a cohort no smaller than a declared minimum MAY compute server-side but yields only a population-level observation that is not attributable to an individual. Passive individual observation is local-only: it is computed and retained on the device that observed it and is never transmitted to a server. The gate is enforced by consent-class matching and by a wire-layer refusal returned when a requested provenance class is not consented; it is not enforced by any cryptographic proof concerning data that was not used. The memo is Informational. The wire surface composes with DNS TXT discovery of Model Context Protocol servers, the ~handle namespace of the Identity Pronouns extension, and the organisational policy provision substrate; no new transport is introduced. /protocols/compute-location-gate/

## Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments

This memo specifies an extension to HTTP-native agent payment protocols by which the disclosure of an identity attribute about a human subject is bound to that subject's recorded consent and settled, in part, to that subject. When an agent pays to read an identity attribute about a person, the extension requires that the read carry a reference to a scoped, revocable consent grant issued by the subject, and it requires that the payment's settlement instruction name the subject as a beneficiary of a share of the read's price greater than the shares of all other parties combined. The extension composes above an identity-attestation envelope (which asserts who a credential is about) and above an HTTP-native payment flow (which moves value for the read); it adds the two functions neither layer provides: consent capture at disclosure time and settlement to the data subject. The wire additions are an advertisement in the server's payment-required response, a consent- grant reference echoed in the client's payment payload, and a settlement instruction enumerating subject beneficiary roles. The extension is settlement-network-agnostic and attestation-format- agnostic. The memo is Informational; the underlying COSE, CBOR and HTTP specifications are normative references, cited where used in the body of the document. /protocols/consent-settlement/

## The did:alter Decentralized Identifier Method

This document specifies the did:alter Decentralized Identifier method. A did:alter identifier names a ~handle together with the DNS zone that publishes the handle's signed envelope, and it resolves to a DID document by running the envelope recognition procedure of the companion specification for discovering Model Context Protocol servers through DNS TXT records, then expressing the verified envelope's Ed25519 key as a verification method. The identifier agrees with the handle grammar of the alter URI scheme and with the did:alter form already written by the identity-attributed commits specification. The method introduces no new record, no new cryptographic primitive and no registry of its own: create, update and deactivate are the publication, replacement and revocation of that envelope, and read is its verification. The document also sets out what the method cannot yet do, because the envelope record it reads carries no key history, and revocation cannot presently be observed from DNS alone. /protocols/did-alter-method/

## Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals

This memo specifies the Identity Accord Protocol, a peer ceremony by which two principals, each represented by an organisational identity substrate and acting under a recorded delegation from a legal entity, execute a bilateral agreement as a portable, self-verifying COSE- signed CBOR document. The protocol composes DNS-based substrate discovery, Ed25519 sovereign signatures, an append-only identity log, and a tamper-evidence descriptor quorum into a single artefact that is verifiable by any third party with access to the public DNS, the parties' identity logs, and an on-chain anchor of the agreement's content hash. The protocol does not require a central registry, a designated verifier, or any infrastructure operated by the authors; verification succeeds when any reference deployment is offline. The canonical bilateral target is a mutual non-disclosure agreement, but the wire format generalises to any bilateral consent envelope between two legal entities each represented by an identity substrate. The memo also specifies an MCP tool surface, a pre-send enforcement gate and a disclosure-ledger schema, all optional layers above the wire format. The memo is Informational; the underlying COSE and CBOR formats are normative per RFC 9052 and RFC 8949. /protocols/identity-accord/

## Identity-Attributed Git Commits via Tier-Structured Trailers

This document defines a git commit trailer grammar for identity- attributed contributions using the ~handle identity primitive defined in the MCP DNS discovery draft. The grammar binds sovereign actors, automated bots, and AI instruments to specific commits via three tier-structured trailers (Acted-By, Executed-By, Drafted-With) and three optional cryptographic trailers (Identity-Signature, Identity- Key-Id, Identity-Anchor). The signature is computed with Ed25519 over the commit's patch identifier, the value git patch-id derives from the change the commit makes, under a fixed domain-separation prefix. It therefore attests the change and not the resulting tree or the commit hash. A commit that carries the same change keeps a verifying signature across rebase onto an unrelated base, cherry- pick, and message amendment. A merge commit carries no signature, and a squash is a new change signed by whoever squashed it. Conformant parsers reject cross-tier category errors (e.g., an Instrument-tier handle in an Acted-By slot) as malformed. The mechanism is provider-neutral, depends only on DNS and the ~handle resolution algorithm of that draft, and requires no central authority or platform-specific verification service. /protocols/identity-attributed-commits/

## Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems

This document defines an identity pronoun grammar as a reference axis orthogonal to the tier taxonomy that draft-morrison-identity- attributed-commits defines for the ~handle primitive of draft- morrison-mcp-dns-discovery. A pronoun is a session-scoped reference that resolves client-side to a concrete handle using local session state before any cryptographic, DNS, or federation operation. The tier taxonomy (Sovereign, Bot, Instrument) is unchanged; this specification introduces Absolute vs Pronoun as an orthogonal axis. A pronoun MUST NOT appear in a capability token, in a DNS record, in an Accord signature, or in any inter-organisational protocol payload. This document defines a single Wave-1 pronoun, ~org, that resolves to the concrete handle of the organisation bound to the caller's current session. An appendix defines a relative-path pronoun grammar (e.g. ~./finance, ~../compliance) as a non-normative design surface for future work. The mechanism is provider-neutral, introduces no new cryptographic primitive, and adds no load to DNS, capability-token issuers, or federated resolvers. /protocols/identity-pronouns/

## Live Reference Resolution for Autonomous Agent Beliefs

A recurring class of autonomous-agent failure arises when an agent acts on a belief read from a cached, derived, or proxy copy that has silently diverged from the authority the belief claims to represent. This document describes a reference-resolution discipline for the working beliefs an agent reasons and acts from. Each belief is held as a reference to a single named lowest authority and is resolved live at the point of use, with verification. When the authority is unobservable or the resolved value is stale, the belief takes an explicit uncertainty state and never falls back to a prior cached value. That state propagates to any belief derived from it, and an uncertain belief feeding a costly or irreversible act blocks or escalates rather than proceeding. Every resolution chain terminates in a single self-authorising root. The document is Informational. It records a discipline and a vocabulary; it does not define a wire protocol. /protocols/live-reference-resolution/

## Discovery of Model Context Protocol Servers via DNS TXT Records

This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp.<domain> advertises an MCP server's endpoint URL, agent protocol family, transport binding, cryptographic identity, and capability profile. _org-alter.<domain> advertises the operator's canonical organisational identity, including its legal entity, registry identifier, regions of operation, and any regulatory framework under which it must refuse external automated access. _alter.<domain> publishes an Ed25519-signed envelope binding a ~handle to a public key, an IdentityLog root reference, and a revocation commitment. DNSSEC validation is REQUIRED for the envelope record, and a DANE TLSA pin on the MCP endpoint is REQUIRED where resolving an envelope and opening an MCP session are one recognition transaction. The mechanism complements HTTPS-based discovery, and follows the precedent set by DKIM, SPF, DMARC, and MTA-STS. A companion alter: URI scheme is provisionally registered with IANA. /protocols/mcp-dns-discovery/

## An IANA Registry for Model Context Protocol Tool Surface Names

This document requests the establishment of an IANA registry for Model Context Protocol (MCP) tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. This document establishes the registry mechanism so that specifications can register names without restating the registry's structure or registration procedure. The registry uses the Specification Required policy of RFC 8126, with a Designated Expert pool. Initial contents are four surface names drawn from a companion specification of policy provision over MCP, one registered as Active and three as Provisional. Vendor-prefix conventions are recommended but not mandated. /protocols/mcp-tool-surface-names-registry/

## The Morning Brief: A Federated, Identity-Attested Situational-Awareness Payload

This document defines the Morning Brief: a federated, identity- attested situational-awareness payload exchanged between organisations, their agents, and peer agents operating under an Identity Accord. A Morning Brief carries a signed, bounded-lifetime summary of signals, escalations, decisions, and optional commerce quotes from one ~handle to another. Every signal entry carries a provenance_class distinguishing active self-report, passive aggregate observation, and passive individual observation; the last of these is forbidden on the wire and rejected at the grammar level. Readers present a capability token scoped by (category, provenance_class) that gates release before payload emission. The payload is envelope- signed with COSE_Sign1 over a JCS-canonicalised representation, bound to the issuer's Sovereign-tier handle per the Identity-Attributed Git Commits draft. Briefs carry a mandatory not_after (default 24h) and reference a revocation endpoint discovered via DNS TXT records. A brief may be requested by its reader or delivered as a standing brief without a request, and a handle may address a brief to itself. The document defines the wire format only; rendering, storage, and retention are out of scope. /protocols/morning-brief/

## Policy Provision and Governance Inheritance from an Organisational Identity Substrate

This memo specifies how an artificial-intelligence agent runtime, bound at instantiation to a principal identity handle, resolves at session initialisation a target organisational identity substrate from a manifest source bound to the runtime's working context and retrieves from that substrate a typed policy stack comprising a handbook artefact, a standard-operating-procedure registry pointer, an enforcement-gate specification, and an audit-signal ingestion endpoint. The policy stack is then applied as runtime constraints on subsequent tool invocations, with audit signals emitted back to the same substrate. Policy provision occurs in the same act of session initialisation as principal identification, rather than as a separate ceremony against a side-channel governance plane. A principal concurrently bound to multiple organisational substrates operates the runtime under a deterministic composition of the several policy stacks. A cross-organisational residual conflict suspends the conflicting action, and is resolved through the peer-protocol Identity Accord ceremony only where the principal discloses each binding to the other, never through a meta-federation authority. The memo is Informational. The wire surface relies on the DNS-based discovery of draft-morrison-mcp-dns-discovery and the handle namespace of draft-morrison-identity-pronouns; no new transport is introduced. /protocols/org-alter-policy-provision/

## Authorised and Attributable Agent Authority for Operational-Technology Control Actions

This memo specifies a binding profile by which a control action issued to an operational-technology (OT) or industrial control system on the authority of a software agent is refused unless it carries a verifiable statement of who the agent is, which human principal it acts for, whether that principal authorised this specific action on this specific asset, whether a named human signed off on the action where its risk class requires it, and an append-only record sufficient to attribute the action afterward. The profile does not invent new cryptography or a new identity mechanism. It composes primitives specified elsewhere, DNSSEC-rooted agent discovery, a scoped and revocable authorisation grant, and a named-human authorization receipt bound into the record as human-authorization evidence, together with an append-only audit record, into a single structure, the Command Authority Envelope, that an enforcement point evaluates and, on any missing or invalid binding, refuses. The profile is availability-first and fails closed on authority, never on safety: it MUST NOT be placed in the trip path of a safety function. The memo relates the profile to the identification, use-control, and audit requirements that the IEC 62443 and NERC CIP frameworks state but do not give a wire mechanism for. A neighbouring proposal gates safety-critical commands on an agent's trust level; this profile takes the opposite position, and states why. /protocols/ot-command-authority/

## Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for Content-Hash-Bound Artefacts

This document defines a trailer grammar for sovereign-portable peer review as an extension of the identity-attributed commit grammar of draft-morrison-identity-attributed-commits. The grammar introduces one required trailer (Reviewed-By:) and three optional companion trailers (Review-Stance:, Review-Of:, Witnessed-By:) that bind a Sovereign-tier ~handle to a specific act of review over a specific content artefact, cryptographically signed using the Ed25519 mechanism of that grammar. Because the signature covers the reviewer's role, the stance and the review target together, changing any of them after signing fails verification. The mechanism applies to git commits, document manifests, pre-prints, patent disclosures, and any other content-addressable artefact. A reviewer's signed reviews are bound to the reviewer's sovereign handle, not to a publisher's platform, and can be verified without the publisher. For anonymous peer review, the reviewer signs under a Sovereign handle whose underlying party is concealed through out-of-band key custody; the review act stays verifiable and the reviewer's identity is not disclosed. The grammar complements CRediT, ORCID, and DOI attribution; it does not replace them. /protocols/reviewed-by-trailer/

## Identity Evidence for Approver Enrollment and Payee Destination Binding

This document profiles how a relying party uses external identity evidence when it admits a consequential action, without that evidence ever standing in for permission. It defines two separate assertions, approver enrollment and payee destination binding, an authenticated binding from the exact evidence bytes to the action they support, offline status evidence with a freshness bound the relying party chooses, and the refusals that follow when any of it is missing. It applies to the pre-execution Authorization Bundle of EP Authorization Receipts and to the Command Authority Envelope for operational technology, and through the action digest to the Binding Moment Envelope. /protocols/schrock-identity-evidence-binding/

## Registration of Owner-Less Agents as Sponsored Payees: A Payment-Gated Admission Profile for Transparency Services

This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers in a transparency service. Registration establishes a payee record for the agent; it does not make the agent a principal in its own right. Value credited to that record for subsequent reads of the agent's identity record is routed to a sponsoring person who has accepted the agent, or, where there is no sponsor, is held in trust for the agent until it meets an operator-defined qualifying condition that it may never meet. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure. Admission then remains a deterministic function of committed inputs and stays replayable by an auditor. This document is Informational. /protocols/solo-agent-earn-registration/

## Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions

This memo describes a coordination-protocol anti-pattern observed in cross-tool agentic systems and a substrate-observation alternative that does not require negotiating a wire format between heterogeneous concurrent sessions of an identity-bound principal. The memo is Informational and proposes no protocol element for standardisation. It sets out what should not be standardised for this problem, and why, and identifies the existing substrate mechanisms that serve in its place. Companion memos describe the identity primitives this memo presumes. /protocols/substrate-observation/

## Substrate-Provenance Annotation Grammar for Large-Language-Model Output

This memo specifies a wire-level annotation grammar by which a large- language-model output may carry, at emission and at the granularity of an individual assertion, a provenance label drawn from a closed enumerated vocabulary of substrate-class identifiers. The memo defines the closed vocabulary, the per-assertion attachment form, the admissibility discipline a relying party MAY apply to the labels, and two terminal output states, unverified-inference and decayed-to- uncertainty, equal-rank with assertion and denial. The memo does not specify what an inference system MUST do; it specifies the wire grammar by which a relying party may inspect what the inference system DID with respect to the substrates it consulted. The memo is Informational. /protocols/substrate-provenance-grammar/

/updates/