Network Working Group Internet-Draft Intended status: Informational Expires: 19 April 2027 Shawn Todd 19 October 2026 The SwarmSpeak Handshake Protocol, Version 1.1 draft-swarmspeak-handshake-00 Abstract AI agents are becoming some of the biggest users of the Internet. A site today has no neutral way to tell a good agent from a bot. The site sees either an anonymous request it cannot trust, or a request carrying a long-lived credential it cannot check. The result is blunt blocking on one side and unchecked abuse on the other. This document defines the SwarmSpeak Handshake, a protocol that lets an AI agent present a short-lived, narrowly scoped, signed statement of who it acts for and what it is allowed to do, and lets a site verify that statement cheaply before serving the request. The agent proves authority with a principal-signed capability certificate, a short-lived directory-signed status proof, and an HTTP Message Signature. The site sees only a per-origin pseudonym for the agent, never a global tracking identifier. Every completed session at a handshake-accepting site produces an itemized receipt, and receipted sessions are recorded in an append-only audit log. This is an individual submission. It is not a product of any IETF working group, it has not been reviewed by any IETF working group, and it does not represent IETF consensus. It is published to invite review and to record prior art for the shapes defined here: the capability certificate, the per-origin certificate view, the short-lived status proof, and the receipt. 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 19 April 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ............................................ 3 2. Terminology ............................................. 4 2.1. Requirements Language ............................. 4 2.2. Defined Terms ..................................... 4 3. Protocol Overview ....................................... 6 4. The Handshake Envelope .................................. 7 4.1. The SWS-Intent Header ............................. 7 4.2. The Unsigned Note ................................. 9 4.3. Receipts .......................................... 9 4.4. Revocation Signal ................................. 10 4.5. Discovery ......................................... 10 4.6. Rate-Limit Signal ................................. 10 5. Signatures .............................................. 10 5.1. RFC 9421 Envelope ................................. 10 5.2. Covered Components ................................ 11 5.3. Parameter Binding ................................. 11 5.4. The 2-Label Post-Quantum Form ..................... 11 5.5. Algorithm Negotiation and Pins .................... 12 6. Capability Certificates and Delegation ................... 12 6.1. The Certificate ................................... 12 6.2. Attenuation ....................................... 13 6.3. Delegation Chains ................................. 13 6.4. Break-Glass Emergency Elevation ................... 14 6.5. Principal Transfer ................................ 14 7. Pairwise Identities and Privacy ......................... 14 7.1. Per-Origin Aliases ................................ 14 7.2. Per-Origin Certificate Views ...................... 15 7.3. Per-Site Sub-Keys ................................. 15 7.4. Blinded Task Tokens ............................... 15 7.5. Budget Commitments ................................ 16 8. Revocation and Short-Lived Proofs ....................... 16 8.1. Staples ........................................... 16 8.2. Revocation Feeds .................................. 17 8.3. Device-Bound Staples .............................. 17 8.4. Blinded Revocation Handle (DRAFT) ................. 17 8.5. Replay Defense: Freshness Counters ................ 18 8.6. Revocation Bound .................................. 18 8.7. Verifier Cache Discipline ......................... 19 9. Security Considerations .................................. 18 10. Privacy Considerations .................................. 20 11. IANA Considerations ...................................... 21 12. References .............................................. 21 12.1. Normative References ............................... 21 12.2. Informative References ............................. 22 Appendix A. Directory API and Audit Records .................. 22 Appendix B. Conformance ...................................... 23 Appendix C. Open Items and Change Log ........................ 24 Author's Address ............................................. 24 1. Introduction AI agents now browse, shop, book, file, and fetch on behalf of people. A person tells an agent to do a job, and the agent makes dozens or hundreds of requests across many sites. Each site faces the same question: is this request from a legitimate agent acting for a real person with real limits, or is it a bot running an abuse script? Today the site has no good answer. It can block anything that looks automated, which blocks legitimate agents too. It can demand a login for every request, which breaks delegation: the agent is acting for the person, not as the person. Or it can accept requests with no proof at all, which invites abuse at machine scale. None of these options scale, and none of them respect the person's privacy. A single long-lived credential shown to every site becomes a tracking key that follows the person across the web. The SwarmSpeak Handshake gives the site a 4th option: verify a short-lived, narrowly scoped, signed statement before serving the request. The statement says 4 things: 1. This agent acts for a named principal, and the principal signed a certificate that caps what the agent may do. 2. This request fits inside that cap: the scopes, the spending limit, and the rate limits all hold. 3. This key is live right now: a directory signed a status proof no more than 300 seconds ago. 4. This request is for this site only, and it can be presented only once. The site checks those 4 claims with cryptography, not with trust in the agent. If any check fails, the site rejects the request. If all checks pass, the site serves the request inside the stated limits, meters what it served, and returns an itemized receipt. The agent records the session in an audit log. Later disputes are settled from receipts and log records, not from either side's word. 3 properties make the design worth taking seriously: Authority is separate from presentation. The agent's key presents the request. The principal's key authorizes it. The agent can only narrow the principal's grant, never widen it. A key that never had administrative scope can never mint administrative scope. Privacy is structural where the wire allows it, and labeled where it does not. Each site sees only its own per-origin pseudonym for the agent and its own view of the certificate. Cross-site correlation by sites via protocol identifiers is structurally impossible [CRYPTO], with 2 known exceptions documented as open defects: the binding endpoint discloses the long-lived principal key to each verifier (Section 8.2), and the wire certificate carries a Merkle root that is constant across origins (Section 7.2). Until per-origin blinding closes both (open items 9 and 10), 2 colluding sites can join on either field; the unlinkability claim for those 2 fields is [LEGAL]-backed, not [CRYPTO]-backed. Network and behavioral correlation (IP addresses, timing, TLS fingerprints) are outside this protocol's scope. The directory is a sighted aggregator by design: it sees per-principal velocity and spend across origins because it must, to enforce the caps. This document states that plainly instead of hiding it. See Section 10. Failure closes, never opens. There is no "close enough" mode. A missing proof, an expired proof, a scope outside the ceiling, or a replayed request all produce the same result: rejection. The protocol is designed so that the safe outcome is also the default outcome. This document specifies version 1.1 of the handshake. Version 1.1 is a repair release. Its predecessor, version 1.0, shipped 3 claims that the project's own 3rd red team falsified: the privacy claim (the wire certificate carried 3 fields that were byte-identical at every site, forming a perfect tracking key), the adoption math (a site paid a large integration cost for about 0 dollars of value at launch), and parts of the post-quantum plan. Version 1.1 fixes all 3: per-origin certificate views replace the global certificate, the site economics are published honestly with the residual gap named, and the post-quantum wire form is repaired. The fixes are described where they land in this document, and the full change record is in Appendix C. Relationship to prior work. This protocol reuses HTTP Message Signatures [RFC9421] unchanged: the signature envelope, the covered components, and the signature base are RFC 9421's, and this document adds only the handshake claim shapes carried inside it. Web Bot Auth [WBA] proves which bot made a request; this protocol answers the next question: what that bot is allowed to do, for whom, and within what limits. This document does not change Web Bot Auth and does not depend on it. Review of this document is welcome by email to the author (see Author's Address). This is an individual submission offered for public review and as prior art; it requests no working-group action. This document does not define an arbitration venue, a fraud court, or issuer business models. It defines the evidence artifacts those processes consume: headers, receipts, and log records. It does not define browser or DOM flows. It covers HTTP APIs and agent endpoints only. The project's own 52-vector conformance harness (authored against this specification, run over real HTTP on 2026-10-16) passes 52 of 52. The independent conformance corpus required by Appendix B is not yet published (open item 7); until it is, this number is a self-check of internal consistency, not a conformance claim. 2. Terminology 2.1. Requirements Language 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 [BCP14] when, and only when, they appear in all capitals, as shown here. Scope of normative language. This document's intended status is Informational. Its MUSTs describe the reference design and its conformance program: a "conformant implementation" is one that follows this design. IANA requests in Section 11 are contingent on the protocol advancing; the field-name guidance in Section 11.3 already follows that pattern. 2.2. Defined Terms Agent: A software program that makes requests on behalf of a principal. The agent holds its own keys and presents handshake headers. The agent never holds the principal's key. Principal: The legal person the agent acts for. The principal signs the capability certificate, sets the spending cap, and bears liability for in-scope acts up to that cap. The principal MUST be a legal person with capacity to contract. Where the beneficiary is a minor or an incapacitated adult, the principal MUST be the court-appointed guardian or conservator. Juridical persons (corporations, LLCs) MAY be principals; the unmasking instrument (Section 10) then reaches the named officer or agent for service, who bears the liability. Issuer: The party that verifies the principal, issues the agent identity, and registers the agent with a directory. The issuer MAY be the principal's own operator or an independent party. Directory: The trusted registry that holds key records, issues short-lived status proofs, publishes revocation feeds, and enforces per-principal velocity and spend caps. A deployment MUST have at least 1 accredited directory operator. Directory participation is MANDATORY for verification: there is no indefinite degraded mode in which verification proceeds without a directory. A staple-grace window (Section 9) permits cryptographic-only checks until staples expire. See Section 8. Capability certificate: A principal-signed document granting an agent identity a ceiling of scopes and a spending cap. The agent's header may only narrow it. Authority lives here. Section 6 defines the certificate. Per-origin alias: The wire-form pseudonym a site sees for an agent. It has the form "sws:agent::<64 hex characters, random>", generated fresh for each (agent, site) pair. The true agent identity NEVER appears on the wire. Per-origin certificate view: The form of the capability certificate presented to 1 site. It carries only that origin's material: the per-origin alias, a per-origin blinded subject reference, and a Merkle inclusion proof against the certificate's origin-set root. It carries no global identifier. Staple: A directory-signed status token proving a key is live right now. Shape: {kid, subkey_pub, alias, status, issued_at, exp, dir_sig}. The principal key is OFF the wire staple. A staple without subkey_pub, or with exp more than 420 seconds after the current time, is malformed and MUST be rejected. Status proof: A synonym for staple, used in prose where the mechanism matters less than the meaning: proof that the key is live right now. Receipt: An itemized, site-signed record of a completed session: what was served, how much was served, and what was charged. The site returns the receipt in-band in the SwarmSpeak-Receipt response header. A site that never receipted a usage claim in-band cannot bring that claim later. Verifier: Any party that checks a handshake header. Usually a site. An agent MAY also act as a verifier toward another agent's header; when it does, its authority to serve MUST appear in its own certificate ceiling under scope purpose "serve". Relying site: The site that receives, verifies, and serves a handshake-bearing request. Scope: A statement of what the agent is allowed to do: a resource pattern, methods, numeric limits, and optional time bounds. Header scopes MUST be a subset of the certificate ceiling. See Section 6.2. Attenuation: Narrowing only. Fewer scopes, lower numbers, shorter lifetimes. Attenuation is non-strict: equality is allowed, so a delegating agent may pass its exact grant unchanged to a sub-agent for fan-out. Audit record: A chained, signed log entry describing a session: a hash commitment to the action list, metered totals, an encrypted payload of per-action detail, and references to the site receipts. See Appendix A. Transparency log: An append-only, publicly auditable log of directory events: every record mutation, every staple-issuance batch, every revocation and key succession, every emergency attestation, and every algorithm pin. Independent monitors diff live directory state against the log on a published cadence of no more than 1 hour. Enforcement label: A tag on every security claim in this document naming what enforces it: [CRYPTO] (cryptography), [SITE] (the verifier's own checks), [AUDIT] (the log and receipts), or [LEGAL] (law, contract, or a trusted party's promise). A [LEGAL] label means the claim holds only because somebody can be held to account, not because breaking it is mathematically impossible. This document labels every security guarantee honestly; Section 9 carries the full matrix in prose. Merkle root: 1 hash that commits to a whole list, so that membership in the list can be proved without revealing the list. Used to hide the set of origins bound to a certificate (Section 7.2) and to prove log inclusion (Appendix A). Blinded token: A directory-signed token bound to 1 origin that lets cooperating agents correlate a shared task without exposing a global identifier to sites. See Section 7.4. Interrupt budget: The principal-set maximum number of human challenges per day. Beyond it, the protocol fails closed rather than interrupting the principal again. See Section 6.2. 3. Protocol Overview The handshake has 8 steps. Steps 1 through 4 happen per request. Steps 5 through 8 happen per session. Step 1. Discovery (OPTIONAL). The agent fetches the site's handshake description at "https://site/.well-known/swarmspeak.json". The description says whether the site accepts handshakes, which versions it accepts, which directory it uses, its velocity caps, its price schedule, and its terms version. The price schedule is MANDATORY for toll lanes. The terms version binds the handshake to the site's actual terms. An agent MAY skip discovery and present directly; a site that accepts handshakes MUST publish the discovery document. Step 2. Prepare. The agent fetches a fresh staple from the directory, valid for no more than 300 seconds. The agent SHOULD reuse a staple for subsequent requests until its expiry approaches; "fresh" means unexpired, not newly fetched. Per-request fetching would break the Appendix A.3 cost model. (The source specification is silent on the caching rule; flagged to its editors.) It builds the header inside its certificate ceiling: scopes at or below the ceiling, a budget commitment at or below the remaining spend cap, and a fresh nonce and freshness counter. It signs the header with its per-site sub-key. There is 1 header per request. Step 3. Present. The agent sends the request with the header set defined in Section 4: SWS-Intent, Signature-Input, and Signature. It MAY include the unsigned SWS-Intent-Note. There is no fallback envelope. A verifier MUST NOT accept any other envelope shape. Step 4. Verify. The verifier runs the verification algorithm in Section 8. Any failure means rejection, with no partial acceptance. The verifier MUST NOT serve first and verify later. Step 5. Serve with enforcement. The verifier serves the request while enforcing the granted scopes: method and resource match, counters, velocity caps, and spend. A breach produces a 429 response with a SwarmSpeak-Limit header. Verified agents SHOULD skip challenge pages: sites that offer the fast lane advertise "fast_lane": true in discovery (Section 4.5), and agents MAY prefer such sites. The conversion lift is the merchant's dollar reason to adopt the protocol. Challenge pages shown to verified agents are a conformance quality signal, not a protocol violation: no test vector defines a challenge page. Step 6. Receipt. For completed sessions at handshake-accepting sites, the site returns a SwarmSpeak-Receipt response header. The receipt is MANDATORY. See Section 4.3. Step 7. Terminate anytime. Either side MAY end the authority at any time by sending "SwarmSpeak-Revoke: ". Authority ends immediately. Step 8. Complete. On completion, records go to the directory-published log endpoint. The site confirms submission; the agent does not merely assert it. Agent-to-agent handshakes work the same way. Any agent identity MAY act as a verifier toward another agent's header, running full verification, enforcement, receipts, and records. Each hop in a multi-agent task performs a full handshake with its own credentials. Token transit across hops is explicitly forbidden. 4. The Handshake Envelope 4.1. The SWS-Intent Header The claims travel in the SWS-Intent HTTP header: a base64url JSON object, no more than 8 KB in Ed25519 mode, carried as a covered component of an RFC 9421 signature envelope (Section 5). The header carries NO "sig" field. A verifier MUST reject a header that carries a "sig" field inside the RFC 9421 path: that shape is a downgrade attack, not a legacy format. The predecessor bespoke envelope is DELETED, not sunset. The header carries the following fields: agent: The per-origin alias (Section 7.1). NEVER the true agent identity. kid: The per-site delegated sub-key identifier. It differs per origin. cert: The embedded capability certificate, in per-origin view (Section 6.1 and Section 7.2). staple: The directory-signed status token (Section 8.1). iat: Issued-at time, in UTC epoch seconds. exp: Expiry time. The rule is exp <= iat + 300. A header that lives longer than 300 seconds MUST be rejected. aud: The full origin the header is addressed to. It MUST equal the verifier's own origin, taken from the verifier's LOCAL CONFIG, never from the Host header or any forwarding header. scopes: The scopes claimed for this request. They MUST be a subset of the certificate ceiling (Section 6.2). A header that omits a numeric limit the ceiling sets is treated as unbounded (positive infinity), which is wider than any finite ceiling, and MUST be rejected. budget: A COMMITMENT, not an amount. Shape: {commit: "sha256(amount | currency | rail | salt)", rail: "", rail_attestation}. The preimage is SHA-256 over the JCS-canonicalized [RFC8785] JSON array [amount, currency, rail, salt_b64u]; the bars are not literal separators. The amount is revealed only to the payment rail at settlement, never to the site. The budget REQUIRES the certificate's spend_cap to cover it. The verifier MUST require a rail attestation of cap enforcement before accepting a budget, and MUST reject a budget where the rail attestation does not cover the principal's jurisdiction. The jurisdiction comparison MUST be implemented in code, not merely specified. Payment profiles key by the wire-form alias, never by any global certificate identifier. The salt MUST be at least 128 bits; rails MUST reject weak salts. task_token: OPTIONAL. A directory-issued per-site blinded task token (Section 7.4). When present, the verifier MUST validate it for its own origin, offline, using the directory key, with no per-request callback. nonce: A 128-bit random value. ONE NONCE, ONE PRESENTATION. A nonce presented twice for the same audience is a replay and MUST be rejected. ctr: The per-request signed monotonic counter from the per-site sub-key. This is the normative replay defense (Section 8.5). done: OPTIONAL completion description, including a callback_url. The callback URL MUST use https, MUST be on the operator's pre-registered allowlist, and MUST NEVER be taken from site content. Posting infrastructure MUST reject private, loopback, and link-local targets, with rebinding protection. chain_depth and root_cert: Present when the header is part of a delegation chain (Section 6.3). They let the verifier check depth against the maximum without resolving the chain. intent: OPTIONAL and UNSIGNED. See Section 4.2. 4.2. The Unsigned Note The human-readable annotation travels in a separate, uncovered header, SWS-Intent-Note. It is NEVER covered by the signature and NEVER trusted. The minimization rule applies: task category only, a ban list (no names, no account identifiers, no personal data), and no more than 140 characters. An implementation MUST NOT make any access, billing, or enforcement decision based on the note. 4.3. Receipts For completed sessions at handshake-accepting sites, the site MUST return a SwarmSpeak-Receipt response header with the following fields: version, header_hash, alias, requests_served, bytes_served, amount_charged (a list of {scope, units, price} entries), ts, nonce, exp, aud, limits_enforced, and the site's signature (site_sig). Receipt line items are capped: past 100 entries the receipt carries a summary plus the Merkle root over the full itemization, retrievable at the log endpoint. The estoppel rule (Section 9) applies to the summary receipt. The agent's countersignature does NOT travel in the receipt. It travels in the agent's own log record: the agent includes agent_sig, a signature over the receipt hash, in its log submission, and the log verifies it. The inclusion proof from the log, not a site-held countersignature, becomes the tie-break evidence in disputes. This placement is deliberate: it gives the agent an incentive to keep its own log complete, and it creates no cross-site state, no hostage, and no surface for manufactured strikes. The countersignature covers a projection that EXCLUDES limits_enforced: metered facts only. A site MUST NOT be able to get an agent to co-sign the site's own claim that it enforced limits. Countersigned receipts are normative where authority crosses an identity, that is, at delegation boundaries. Per-call coverage rides the existing commit.actions_root commitment in the audit record; mandatory full-tree receipts are NOT required, because they would multiply log-ingestion cost by 100 to 1000 times while duplicating actions_root. In-band delivery is an estoppel rule: no receipt the agent saw means the site brings no usage claim later. A site that serves past the limits and then claims overuse is estopped: it waived the claim by failing its duty to enforce. 4.4. Revocation Signal Either side MAY terminate authority at any time by sending "SwarmSpeak-Revoke: ". Authority ends immediately. Revokes are metered per site. An excessive revoke rate is a conformance signal, and agents MAY cite more than N revokes per hour as site-misbehavior evidence, where N is the site's published threshold. (ASSUMPTION: the exact numeric threshold for "excessive" is not named in the source specification and is left to the conformance program.) 4.5. Discovery Discovery is the document at "https://site/.well-known/swarmspeak.json". It carries: accepts_handshake, versions, directory, policy_url, max_header_bytes, receipts, velocity_caps, price_schedule, conformance, fast_lane, tos_version, revoke_endpoint, and supported_algs. The price_schedule is MANDATORY for toll lanes. The tos_version binds the handshake to the site's actual terms. Discovery MUST publish velocity_caps. "conformance" is a URI of the site's published conformance attestation (Appendix B); "fast_lane" is a boolean advertising the Section 3 fast-lane behavior. A site's advertised max_header_bytes MUST be at least the mode maximums it accepts (8 KB in Ed25519 mode, 32 KB in post-quantum mode, Section 5.1). 4.6. Rate-Limit Signal A breach of a scope, velocity, or spend limit produces a 429 response carrying a SwarmSpeak-Limit header. The header is a comma-separated list of token=value pairs with the fields: scope (the breached limit name), remaining (0 at breach), reset (seconds until the window resets), and policy (URI of the applicable velocity or metering policy). Example: SwarmSpeak-Limit: scope="velocity", remaining=0, reset=60. 5. Signatures 5.1. RFC 9421 Envelope All handshake signatures use HTTP Message Signatures [RFC9421]. No bespoke signature envelope exists. The header set, with field names case-insensitive on receipt, is: SWS-Intent: base64url JSON claims (Section 4.1), 8 KB maximum in Ed25519 mode and 32 KB maximum in post-quantum mode, no "sig" field. Signature-Input: one label, sws-sig1, with the covered components, created, expires, keyid, alg, and nonce parameters. In post-quantum mode a 2nd label, sws-sig2, appears; see Section 5.4. Signature: sws-sig1 with the base64 signature value. SWS-Intent-Note (OPTIONAL): the unsigned annotation. NEVER covered, NEVER trusted. Structured fields are pinned to [RFC9651], not the obsoleted RFC 8941. 5.2. Covered Components The covered components, in fixed order, are exactly these, no more and no fewer: "@method", "@authority", "@path", "@query", "sws-intent", and "content-digest" whenever a body exists. "@query" is ALWAYS covered: RFC 9421's "@path" excludes the query string, and the predecessor's fixed set left query and body mutation surviving the signature while claiming the signature was "bound to this request". That overclaim is fixed here. "content-digest" follows [RFC9530]. The signature base is constructed per RFC 9421 Section 2.5, from the ACTUAL request method, authority, path, and query and the received SWS-Intent value. The verification key is the per-site sub-key from the staple or directory, NEVER a key taken from the request. 5.3. Parameter Binding The verifier MUST check that the Signature-Input parameters bind to the claims: created equals claims iat; expires equals claims exp; nonce equals claims nonce; keyid equals claims kid; alg equals the staple-pinned required_alg for this kid (Section 5.5); and alg is in the protocol registry (an unknown alg means rejection). The covered "@authority" MUST equal the verifier's own origin authority from LOCAL CONFIG. Behind a reverse proxy or CDN, the edge verifier terminates the signature check against the as-received authority and asserts the origin mapping in its own signed attestation to the origin; the origin MUST verify that attestation. A site MAY instead register its proxy chain in local config. Claims aud MUST equal the full origin. Replay handling is this profile's answer to the question RFC 9421 delegates to profiles: one-nonce-one-presentation (Section 4.1) plus the freshness counters (Section 8.5). That policy is normative here. 5.4. The 2-Label Post-Quantum Form When required_alg names a post-quantum algorithm, the envelope carries 2 labels over the SAME covered components: sws-sig1 (Ed25519) plus sws-sig2 (ML-DSA-65, per [FIPS204]). The verifier MUST require both: AND-semantics. A header with only 1 of the 2 labels in post-quantum mode MUST be rejected. This form needs no new standardization: it is a 2-label use of RFC 9421. The wire cost is real and is priced honestly. An ML-DSA-65 signature is 3,309 bytes, and realistic post-quantum-mode headers run 12 to 16 KB. Implementers MUST NOT assume edge verifiers handle the 2-label form for free: AND-semantics must be implemented in edge verifiers, and both the edge path and the origin path must be priced. Post-quantum priority follows artifact lifetime. Permanent receipts and records come 1st. 30-day certificates come 2nd, in the 2-label form where negotiable. Log checkpoints come 3rd. 300-second headers come last. The reason is stated plainly: harvest-now-decrypt-later threatens confidentiality (encrypted payloads), not signature forgery. Short-lived headers are the least exposed artifact, so they are last in line, not 1st. 5.5. Algorithm Negotiation and Pins Every signature algorithm is named in a protocol registry and negotiated on the wire. Nothing is hard-coded. Discovery advertises supported_algs; the agent picks the strongest mutual algorithm and fails closed on empty intersection. The staple and directory pin required_alg per kid. Verifiers MUST reject a signature whose alg mismatches the pin. Pins are transparency-logged, so a directory cannot silently downgrade a principal. The current registry is small: Ed25519 for the classical label, ML-DSA-65 for the post-quantum label. Algorithm migration uses the 2-label transition form. 6. Capability Certificates and Delegation 6.1. The Certificate The capability certificate is issued by the principal, or by the issuer on the principal's delegated authority and countersigned by the principal for any transact, publish, or admin ceiling. There is 1 certificate per agent identity. It is refreshed when authority changes. The agent embeds the certificate in every header. The certificate carries: version ("1.1"), the Merkle root over (origin, commitment) leaves (cert_alias_root), the per-origin blinded subject reference for the presenting origin, the scope ceiling, the spend cap, optional sub-caps, the interrupt budget, the assurance tier, issued-at and expiry times, and the principal's signature over the canonical JSON of the certificate minus the signature (JCS canonicalization, see [RFC8785]). The scope ceiling is the MAXIMUM the agent may ever declare. Header scopes MUST be a subset. A key that never had admin can never mint admin. The spend cap is the principal-signed spending authority per window in seconds. Header budget commitments MUST NOT exceed the remaining cap. The directory tracks spend per certificate, from reports by rails and sites, for cap enforcement. Sub-caps, when present, are each no more than the top-level maximum. Budget commitments are checked against both the applicable sub-cap and the top-level cap. The interrupt budget is the principal-set maximum number of human challenges per day. It bounds the human half of risk-based step-up (Section 9). Without it, 1,000 tasks per day times a 1 percent anomaly rate means 10 interruptions per day: autonomy death by a thousand pings. The principal signature verifies against the principal_key returned by the authenticated binding endpoint (Section 8.2). The principal key is long-lived, ideally hardware-backed. It signs certificates rarely, never per request. Certificate lifetime is no more than 30 days. Refresh is cheap. Theft of the agent sub-key cannot extend authority beyond the certificate. Scope language. Scope objects carry a resource pattern, methods, numeric limits, and optional time bounds (not_before, not_after, valid_hours, time zone). Normative ceilings apply: max_requests no more than 1,000,000, max_bytes no more than 10,000,000, and max_per_minute MANDATORY for any purpose other than read. The no_store flag stays an unsigned, non-normative hint; sites MUST NOT rely on it for regulatory or contractual data-handling guarantees. All rate windows are rolling windows ending at evaluation time, measured in UTC epoch seconds. "Per day" means the 86,400 seconds preceding evaluation. Fixed calendar windows are forbidden: they invite boundary arbitrage. 6.2. Attenuation Attenuation is narrowing only. Every scope in the header MUST sit within 1 ceiling scope: same resource pattern, equal or narrower; methods a subset; every numeric limit less than or equal. A header that omits a numeric limit the ceiling sets is treated as unbounded and MUST be rejected when the ceiling is finite. In the predecessor, 1 omitted field defeated the principal's ceiling. It cannot here. The verifier rejects on any widening. The verifier MUST also compare the actual request against the granted scopes: the request method plus target URI MUST match at least 1 effective scope, else the verifier rejects. A valid header for "GET /catalog/widgets" does not verify on "DELETE /admin/users". Per-principal velocity is wired, not aspirational. Discovery MUST publish velocity_caps. The site meters per alias and reports aggregates per certificate to the directory. The directory maintains per-principal aggregates and MUST deny staples on breach. Sites MUST query the per-principal velocity endpoint before serving scopes above the threshold of 10,000 requests per day. Risk-based step-up. Velocity anomalies, first-time sites, and near-cap spend trigger step-up instead of hard rejection. A site is first-time for an alias if the verifier holds no cached binding (Section 8.7) and no prior receipt for the (alias, origin) pair within the last 30 days. The automatic half (fresh staple plus narrowed scopes) is pure win. The human co-signature half is bounded by the certificate's interrupt budget; beyond it, fail closed. Step-up is normative on the wire: a site that steps up returns 403 with a SwarmSpeak-Step-Up header naming the challenge type and a machine-readable retry_with directive (fresh-staple, narrowed-scopes, or human-cosignature). The agent retries with a fresh header satisfying the directive. The automatic half (fresh staple plus narrowed scopes) is fully specified here; the human co-signature channel beyond the retry_with directive is product work, not protocol work. 6.3. Delegation Chains An agent identity MAY act as a delegating principal for sub-agent identities only if its certificate carries "delegable": true and a "max_depth" value. Depth 3 stays the default. Principals MAY declare higher, up to an absolute normative ceiling of 5. A chain of user, orchestrator, specialist, tool gateway, and tool legitimately runs 4 hops, which is why the ceiling is 5 and not 3. The chain carries a decrementing remaining-depth budget. Sub-certificates are signed by the delegating agent key under that explicit grant. Each sub-certificate MUST attenuate (non-strict subset; equality is allowed for fan-out), MUST name the parent in parent_cert, and MUST be issuer-registered with full lineage in the directory record. The per-parent sub-certificate count cap is an operational anti-mistake limit, honestly labeled. It is NOT a security control. The load-bearing defenses are 3: the directory-enforced shared spend ledger (sub-certificates draw from the parent's spend_cap, so 1 identity with a 25.00 dollar per day cap cannot become N times 25.00 dollars per day by minting sub-certificates); strike propagation to the ROOT principal; and per-principal aggregation. The header carries chain_depth plus root_cert, so verifiers check depth against max_depth without resolving the chain. Any chain break means rejection. Strikes propagate to the ROOT principal: a strike against a sub-agent counts toward the root's tally, and a delegator's suspension counts as a strike on the root's tally. Each hop performs a full handshake with its own credentials: its own header, its own staple, its own sub-certificate. Token transit across hops is explicitly forbidden. Verifiers MAY cache chain-to-root validation results for up to 300 seconds. Per-hop full chain resolution without caching means N times directory reads per task, so this bound is normative. An informative encoding of delegation chains in the RFC 8693 "act" claim syntax [RFC8693] may be defined in a future revision; it is not normative here. 6.4. Break-Glass Emergency Elevation A principal MAY pre-sign 1 sealed emergency certificate: a wider ceiling, marked "emergency": true, encrypted to the agent's master key, with an explicit lifetime of no more than 24 hours from unseal. Unsealing is NOT self-attested. The agent MUST first file an emergency-intent notice with the directory, which publishes a transparency-logged emergency attestation. Verifiers MUST check the attestation and reject emergency certificates without one. Emergency certificates work for read immediately. The 1st transact-or-higher use is held 300 seconds: the site responds 429 with Retry-After: 300 and a SwarmSpeak-Hold header carrying the hold expiry and the emergency attestation reference. The agent re-presents after the hold with a fresh header (the held request's header expires mid-hold, since exp is at most iat plus 300; re-presentation is REQUIRED). The principal-notify fires on at least 2 independent channels (directory AND issuer). The principal can revoke inside the hold; revocation during the hold converts the hold to a rejection. The thief's gain is bounded to 300 seconds of wider read authority: low value, honest price. The principal is notified within 300 seconds. Every use is reviewable in the dispute process. Misuse means immediate revocation plus slash. Emergency certificates bypass the first-time-site step-up trigger during the 300-second hold. A break-glass certificate at a new site MUST NOT stack a hold plus a challenge into a freeze longer than the emergency allows. 6.5. Principal Transfer A certificate is void the moment the principal relationship ends. Transfer requires a NEW principal-signed certificate. The old certificate is revoked 1st. In-flight headers live at most 300 seconds from iat, then fail closed. Sites SHOULD terminate in-flight work with SwarmSpeak-Revoke. The directory MUST version principal_key changes and retain superseded keys for the issued-at-versus-revocation check (Section 8.2). A principal key is never rotated in place; it is recovered. The issuer re-verifies the principal at or above the original assurance tier and publishes a directory-signed key-succession record. Succession records MUST be transparency-logged. The directory MUST notify the principal's pre-succession contact and honor a 72-hour objection window before the new key becomes authoritative. Certificates under the old key remain valid only for headers with iat no more than succession_time plus 300 seconds. The old key joins the revocation feed. There is no grace overlap beyond 300 seconds. Compromise response is REVOKE, never rotate. Per-site sub-keys rotate freely; master rotation requires principal countersignature; a compromised key is revoked, not rotated into continued use. 7. Pairwise Identities and Privacy 7.1. Per-Origin Aliases The true agent identity has the form "sws:agent::". It is known to the issuer, the principal, and the dispute process. It NEVER appears on the wire. The wire identity is the per-origin alias: "sws:agent::<64 hex characters, random>", generated fresh per (agent, site) pair by the agent and registered with the issuer at first use. The mapping from alias to true identity is held under split-knowledge escrow: the directory stores only an issuer-encrypted blob (or M-of-N shares), never the plaintext true identity. Revelation happens only through the unmasking instrument (Section 10). The issuer-id MAY be a "did:" URI, but only for DID methods on the protocol's named allowlist. The 1-resolution-path rule covers agent-identity resolution only (handshake key material and transparency-log lookup). Wire aliases stay opaque pairwise pseudonyms. DID material at the issuer layer MUST NOT leak into per-site identifiers. The named allowlist is: did:webvh, did:key, and did:peer. did:ethr is RESERVED for compatibility and is not required. did:polygon exists in the W3C registry as an unmaintained provisional method and is irrelevant to this protocol. Per-agent DIDs on any blockchain as the identity layer are RETIRED: issuance is a local keypair plus a signed capability certificate, and no chain participates in verification. Verifiers MUST NOT perform chain reads during verification. An agent identity is bound to exactly 1 principal for its lifetime. Operators serving multiple principals provision 1 identity per principal. A certificate naming a different principal than the identity's bound principal is a conformance failure, and verifiers MUST reject it. 7.2. Per-Origin Certificate Views The wire-visible certificate carries ONLY per-origin material for the presenting origin: the per-origin alias, a per-origin blinded subject reference (unlinkable across origins), and a Merkle inclusion proof against the certificate's origin-set root. Binding commitments are a Merkle root over (origin, commitment) leaves. The agent presents a per-origin inclusion proof with each header. The verifier checks the proof against the root, then resolves its actual binding through the directory (Section 8.2). 20 aliases, 1 certificate, and 0 origin-set leakage: the verifier learns nothing about how many other origins the agent uses. Known defect (open item 10): the root itself is constant across origins and is wire-visible in every header, so 2 passive observers can join on it; cross-site leakage is NOT 0 for this field until it is per-origin-derived or removed from the wire certificate. The predecessor's 3 global tracking identifiers (a global certificate identifier, a constant subject reference, and the principal key on every header) are gone from the wire headers. The principal key is off the hot path, resolved through the directory only when needed, but the binding endpoint still discloses it in plaintext to every verifier (Section 8.2), and the wire certificate still carries a cross-origin-constant Merkle root (Section 7.2). Those 2 residual correlators are open items 9 and 10: the version 1.1 privacy fix is incomplete, and the privacy claim in this document is qualified accordingly (Sections 1, 9, 10). Bindings are appended by principal-signed refresh. Removing a binding publishes to the certificate-revocation feed and is a per-site delegation revocation. The wire-visible certificate MUST NOT carry the true agent identity. It carries the per-origin blinded subject_ref, meaningful only to the issuer and the directory for the presenting origin. Pairwise pseudonyms are available for greenfield deployments. There is no migration story for the installed base: legacy migration has no force term and depends on fleet demand instruments. This document does not claim otherwise. 7.3. Per-Site Sub-Keys Per-site delegated sub-keys are MANDATORY. The agent's master key never signs headers directly. It signs a delegation to a per-site sub-key, and the kid differs per origin. Compromise of 1 site's sub-key affects only that site. Delegations are short-lived (no more than 24 hours) and registered in the directory. Escrow and bootstrap credentials are never readable by operational sites. This is 1 normative sentence, and it is absolute. 7.4. Blinded Task Tokens Cooperating agents correlate a shared task WITHOUT a global cleartext identifier. The agent requests per-site BLINDED task tokens from the directory. Each token is bound to 1 origin and unlinkable across origins as seen by sites. The token's signed bytes bind (origin, wire-form alias, task_id, exp). The verifier checks that the token alias equals the claims alias; else it rejects. Headers carry only their own origin's blinded token. The directory is a sighted aggregator by design: it aggregates velocity and spend across all tokens of a task internally and enforces the shared caps. Correlation no longer depends on agent cooperation, and sites never see a global correlator. Token issuance requires the principal's task declaration: a principal-key-signed object naming task_id, the origin set, expiry, and the scope-ceiling reference, presented to the directory at token issuance. (The source specification does not define its shape; this minimum is the reference design's, flagged to the source editors.) Tokens are single-task-scoped and expire with the task. Offline verification is normative: the verifier checks the directory-signed blind token with the directory's key. No per-request callback. If validation needed a directory call, the blind-token privacy story would collapse. 7.5. Budget Commitments Budget amounts are hidden from sites by commitment (Section 4.1). The site sees the commitment, the rail profile, and the rail attestation. The rail verifies the amount at settlement against the revealed preimage. Settlement counts MUST NOT be used as reputation or trust evidence. The specification defines the challenge and attestation interface; rails plug in as named profiles. Version 1.1 ships 2 provisional reference profiles, x402 (crypto-native) and MPP (fiat and merchant, live merchants), evidence-gated, compared head-to-head at the 6-month re-sweep. The x402 volume metrics are wash-inflated: 0.6 percent to 7.5 percent plausibly agentic, 5,000 to 11,000 dollars per month of real agent volume, 90.8 percent of counted payments sub-cent. Naming x402 alone as the reference would steer implementers on contaminated metrics, so this document does not do that. Cap enforcement is exercised at settlement against the revealed preimage and is observable on settlement records without accrediting the rail. Per-(principal, cap, window) attestations survive. The earlier mechanism in which the rail published enforcement proofs for the directory to audit is killed: it was the interested party vouching for itself, twice removed. 8. Revocation and Short-Lived Proofs 8.1. Staples The staple is the directory-signed status token. Shape: {kid, subkey_pub, alias, status, issued_at, exp, dir_sig}. The principal key is OFF the wire staple; a staple carrying it is malformed and MUST be rejected. A staple without subkey_pub, or with exp more than 420 seconds after the current time (300 seconds maximum life plus 120 seconds of clock skew), is malformed and MUST be rejected. Staples carry issued_at. The directory's clock is bound to the same 120-second discipline as verifiers. Directory clocks alert on discipline breach. Clock-skew tolerance is capped at 120 seconds; above that, the party is non-conformant. A clock-check failure refuses handshake traffic (normal traffic keeps serving), alerts loudly, and pages. It never hard- crashes. If the staple is missing or invalid, the verifier MAY make 1 directory lookup, never cached for more than 300 seconds, and bypassing the cache for any purpose other than read. Fallback availability is the verifier's obligation: it MUST offer the 1-lookup path when the agent omits the staple. Fallback usage MUST be logged as an anomaly signal. A fallback rate above 1 percent is an agent-conformance signal the verifier MUST report, not a verifier violation: a missing staple is the agent's failure (Section 3, Step 2). 8.2. Revocation Feeds Verification uses 2 feeds, both polled at least every 60 seconds: The revocation feed: GET /v1/revoked?since=, with issuer signatures, a ?since= watermark discipline, and retention of at least 30 days plus margin. The directory MUST return a signed revocation acknowledgment with feed-inclusion proof on every accepted revocation. After a 60-second countersign timeout, the directory MAY list issuer-unresponsive entries itself, countersigned by the directory with an explicit issuer-unresponsive: true marker plus the timestamped hash of the unanswered countersign request. Verifiers SHOULD treat unresponsive-marked entries as revocation-effective; issuers MAY dispute them through the transparency log within 24 hours. The certificate-supersession feed: GET /v1/certs/revoked?since=, covering binding removals, principal transfers, and certificate replacements, with directory signatures, on the same 60-second poll. The verifier MUST compare the header iat against the directory's revocation timestamp for this kid. A header with iat after revocation MUST be rejected even if the signature is valid. This check applies to ALL staple classes, including 24-hour device staples. Certificate verification fetches the binding through the authenticated endpoint GET /v1/bindings/{alias}/{origin}, which returns the plaintext {alias, kid, principal_key} for the verifier's own origin only, plus the binding proof. Known defect (open item 9): the plaintext principal_key is long-lived and constant across origins, so any 2 verifiers can join on it; per-origin blinding is required. Verifiers MAY cache binding records for up to 300 seconds (the staple-lifetime bound). Staple refresh piggybacks binding revalidation. Every per-handshake directory fetch leaves an (alias, origin, time) triple at the directory: the directory is a full traffic observer by design. Fetch metadata is retained no more than 24 hours, aggregates only thereafter. Offline verification holds for the cryptographic checks (directory-signed blind tokens verify with the directory key, no per-request callback). The binding lookup is the 1 cached directory touch, and its retention is bounded as stated. Per-site delegation revocation is POST /v1/delegations/{kid}/revoke, signed by the sub-key or the principal key. The directory immediately stops issuing active staples for the kid and lists it in the revocation feed as delegation-revoked. The directory MUST cap the staple instead of refusing issuance: staple.exp = min(300 seconds, delegation_expiry). Expired delegations appear in the revocation feed as delegation-expired. 8.3. Device-Bound Staples For sub-keys held in device hardware, the directory MAY issue staples with lifetime up to 24 hours, on fresh hardware attestation binding the kid to the device. Attestation MUST be remote attestation by the device's attestation service, never a self-asserted flag. Device staples are valid ONLY for purpose read and non-transact certificates. A staple lifetime above 300 seconds is issued ONLY on fresh hardware attestation AND for purpose read non-transact certificates. 24-hour device staples close the revocation race ONLY through the MUST-grade issued-at-versus-revocation check (Section 8.2). The directory MUST support push revocation for device kids, and verifiers MUST subscribe to the push channel for device kids: without the feed, a revoked device staple survives to its 24-hour proof expiry. 8.4. Blinded Revocation Handle (DRAFT) DRAFT. The blinded revocation handle, unlinkable to sites and auditable by monitors, is a normative design constraint to be specified within 14 days of the version 1.1 gate closing. Until then, revocation checks ride the Section 8.2 binding path. This section is deliberately left incomplete rather than papered over: the binding path works, and the blinded handle is future work with a named deadline. Implementers MUST NOT ship a blinded-handle mechanism of their own invention and claim conformance with this section. 8.5. Replay Defense: Freshness Counters Each header carries a signed monotonic counter (ctr) from the per-site sub-key. The verifier keeps a counter store keyed by the wire-form alias, never by any global certificate identifier. A counter less than or equal to the last-seen value means replay: reject. A counter above the last-seen value plus a sane window triggers the desync protocol. The check-and-set on the counter store MUST be atomic at the shared cache. Concurrent duplicate presentations racing on different workers MUST NOT both pass. The conformance harness includes a concurrent-duplicate vector aimed at this path. The counters subsume the nonce cache for replay. The counter store is small: about 8 bytes per kid times 1,000,000 kids is 8 MB. The reference implementation MUST NOT implement both a nonce LRU and the counter store as parallel replay defenses. The counters are the 1 story. The nonce retains its one-nonce-one-presentation binding to the claims. Nonce uniqueness rides the counter store: the nonce is bound to the signed ctr (Section 5.3), so a repeated nonce arrives with ctr at or below last-seen and is rejected as a replay. No separate nonce store is needed or permitted. Desync and re-attestation. An agent that loses counter continuity (backup restore, device migration) MUST re-attest with the directory to open a new counter epoch before serving. Agents MUST NOT brick on backup restore. The directory publishes the epoch in the transparency log. Verifiers accept the new epoch only with the directory-signed epoch attestation. 8.6. Revocation Bound The maximum time a revoked certificate keeps working is a number, not a hope: 60 seconds for high-value actions, 300 seconds for standard actions, and about 15 seconds for a new session. Three stacked mechanisms bound it: 1. Push delta feed. The revocation service signs a delta of newly revoked certificate identifiers plus a sequence number every 5 seconds, or immediately on forced publish for compromise cases. Deltas travel on 2 channels: push and CDN pull. Verifiers apply deltas in sequence-number order and reject gaps. Publish-lag target: no more than 5 seconds normal, no more than 60 seconds forced (ASSUMPTION). 2. Local revocation filter. Once per feed cycle, the service publishes a compact filter (Bloom or Ribbon filter) covering the full revoked set. Verifiers download it and check revocation locally with 0 network calls per message. At 100,000 revoked entries the filter is about 122 KB at 10 bits per entry (ASSUMPTION). Filter false positives resolve by fetching the exact delta for that identifier: 1 fetch, never a false reject. 3. TTL backstop. Status proofs expire fast: 60 seconds for high-value actions, 300 seconds for standard. Even if the feed is fully down, a revoked certificate dies at its next proof expiry. Worst case is the maximum of the feed path and the TTL backstop. The feed path is about 15 seconds for a connected verifier on a new session. A revoked certificate for a low-value capability cannot authorize a high-value action during the window, because capability gating is per-action. Tripwire (normative dial, verifier-local): each verifier MUST implement the dial locally: if its own measured p99 accept-to-enforcement exceeds 60 seconds over a 5-minute window, it MUST shorten its accepted staple TTL to 30 seconds until the measurement recovers (ASSUMPTION fallback). Zero false rejects is the pass bar: a revocation mechanism that kills good traffic is broken. 8.7. Verifier Cache Discipline Verifiers cache in 2 layers: L1 in-process and L2 shared. Cached items and their time-to-live values (ASSUMPTION unless noted): - Capability certificate plus its directory entry: the earlier of certificate expiry or 300 seconds. A cache never outlives the proof it carries. - Revocation status ("not revoked" answer): 60 seconds. A stale "not revoked" dies fast. - Directory key binding (public key plus pairwise identity mapping): 300 seconds, matching the Section 8.2 staple-lifetime bound: a cache MUST never outlive the proof it carries. (The source specification names 900 seconds in one table against 300 seconds in its binding section; this draft follows the 300-second bound and flags the contradiction to the source editors.) - Inclusion proof for a cached entry: the same TTL as the entry it proves. A proof without its entry is useless. - Signed tree head (latest directory checkpoint): 300 seconds. - Negative result ("no such identity"): 60 seconds. Push invalidation: on a revocation-feed event, the verifier purges the matching certificate, binding, and revocation-status entries from BOTH layers immediately. Push latency target: under 10 seconds from feed publish to cache purge (ASSUMPTION). If push fails entirely, the TTLs bound it: a revoked certificate is accepted for at most 300 seconds after revocation, a stale "not revoked" for at most 60. Poisoning defense (fail-closed): NOTHING enters the cache unverified. The verifier checks the operator's signature on the tree head, the inclusion proof against that tree head, and the certificate's own signature before caching, stored WITH the proof and the signed tree head. Verifiers pin directory operators' public keys out-of-band at install; a cache entry signed by an unknown key is rejected. On any failed verification, the entry is deleted, never served, and the failure is logged. Stampede protection: (1) request coalescing: concurrent misses for the same key collapse into 1 upstream fetch; (2) TTL jitter plus or minus 10 percent so entries created together do not expire together; (3) stale-while-revalidate plus probabilistic early refresh: 1 reader refreshes a hot key early in the background while the rest keep serving the cached value. Memory caps: L1 100,000 entries (about 400 MB maximum, ASSUMPTION) with LRU eviction; L2 1,000,000 entries (about 4 GB maximum, ASSUMPTION) with LRU eviction. Hard caps are enforced: exceeding the cap evicts the coldest entries, never grows unboundedly. NORMATIVE: verifiers MUST NOT perform chain reads during verification. Verification is a local signature check plus a cached directory entry: 0 chain calls on the hot path, by construction. The anchor (Appendix A.14) is checked asynchronously by auditors, never by verifiers, at most hourly. 9. Security Considerations This section states what the protocol guarantees, what breaks each guarantee, and what the protocol does NOT solve. The honesty rule for this document is that a claim is stated with its enforcer and its failure mode, or it is not stated at all. Request bound to this request. [CRYPTO] The RFC 9421 envelope (Section 5), with the covered set including "@query" always and "content-digest" when a body exists, the 2-label AND-semantics in post-quantum mode, the per-kid algorithm pin, and the parameter-to-claims binding, proves the request was signed by the sub-key holder and bound to this request. What breaks it: key theft, with a blast radius of 1 site and no more than 300 seconds; or an envelope-to-claims mismatch, which the verifier MUST reject. Scopes within the principal's grant. [CRYPTO] The subset check against the principal-signed ceiling, including the rule that an omitted numeric is unbounded and therefore rejected, plus the request-versus-scope match, proves the header stays inside the grant. What breaks it: principal key theft. The principal key is rare, hardware-backed, and high-ceremony, which makes theft hard but not impossible. Budget within the principal's cap, amount hidden from the site. [SITE] plus rail-trust. The rail cap-enforcement attestation plus the spend_cap check at settlement enforces the cap. What breaks it: a rail without cap enforcement. A site MUST NOT accept a budget without the attestation. The amount-hiding property holds against the site, not against the rail: the rail sees the amount at settlement, by design. Key live right now. [CRYPTO] The staple (300 seconds, issued_at-bound, directory clock disciplined) plus the MUST-grade issued-at-versus-revocation check closes the revocation race. The revocation bound (Section 8.6) is 60 seconds for high-value actions, 300 seconds for standard, about 15 seconds for a new session on the push feed path. Worst case is the maximum of the feed path and the TTL backstop: 300 seconds standard. Device staples (up to 24 hours) are the exception: they close only through the feed-dependent MUST check, so the feed, not the TTL, is their backstop. The 300-second worst-case bound is the honest number for standard staples, not the 60-second headline; for device staples the honest bound is 24 hours. Header for this site, once. [CRYPTO] Audience binding plus one-nonce-one-presentation plus freshness counters. What breaks it: a verifier that skips the counter store. That is a conformance failure, not a protocol property. Requests stay within scopes. [SITE] Counters, velocity caps, and 429 responses enforce the limits. A verifier that does not count is a conformance failure, and its safe harbor is void (Section 10 and Appendix B). Site charges match service. [SITE] plus [AUDIT] Itemized mandatory receipts, mutual metering, and the log-based countersignature over the metered-facts projection enforce it. What breaks it: a site forging receipts. The tie-break rules answer that: countersigned receipts (site_sig plus log-record agent_sig over the metered-facts projection) beat one-sided evidence; conflicting records with no countersigned receipt mean the claim fails against the claimant; the site is estopped from claims it never receipted in-band. Each dispute claim stakes a bond, forfeited on failed claims. Cheater identified afterward. [AUDIT] plus [LEGAL] Records, receipts, and the unmasking instrument identify the cheater. What breaks it: no lawful unmasking path in that jurisdiction. The market shrinks honestly: where there is no lawful path, there is no issuance. Payload data erased on request. [LEGAL] Crypto-shredding (destruction of the record key) destroys record payloads, plus the retention schedule. Commitments (hashes, chain links, anchored roots) persist by design as existence proofs without content; whether commitments count as personal data is for counsel (see the Appendix A.14 drop rule). What breaks it: operator non-compliance. The operator is audited, and the transparency log makes non-compliance visible. Payment stayed within authorization. [SITE] plus rail. Rail reservation plus spend_cap, with settlement-record audit (no rail self-vouching). What breaks it: a rail without caps. A site MUST NOT accept a budget from such a rail. No site can track the agent across the web via protocol identifiers. [CRYPTO] against sites for the alias and subject_ref layers; [LEGAL] against the directory; and [LEGAL]-only for 2 known residual correlators: the binding endpoint's plaintext principal_key (Section 8.2, open item 9) and the wire certificate's cross-origin-constant Merkle root (Section 7.2, open item 10). Per-origin aliases, per-origin certificate views, and Merkle origin-set hiding make cross-site correlation by sites via protocol identifiers structurally impossible except through those 2 fields. Network and behavioral correlation (IP addresses, timing, TLS fingerprints) are outside this protocol's scope. Against the directory the claim is [LEGAL] only: the directory is a sighted aggregator by design, trusted not to correlate. Escrow logging is minimized (Appendix A). What the protocol does NOT solve: It does not make a malicious principal honest. A principal who authorizes abuse has authorized it; the protocol records the abuse and attributes it, it does not prevent the principal from signing. It does not make a compromised site honest. A site that verifies correctly and then misbehaves inside its own systems is outside this protocol's reach. Receipts and logs make the misbehavior provable afterward; they do not prevent it. It does not solve Sybil identity at zero cost. The bond and burn (Appendix A) raise the price of fake identities; they do not make fake identities impossible. A well-funded attacker can buy identities. The economics are designed so that 1 burned identity costs more than the expected payout of burning it, not so that burning is impossible. It does not protect confidentiality against a future quantum adversary for data encrypted today and kept for decades, except where the ML-KEM hybrid [FIPS203] is used (Appendix A). The lifetime ordering in Section 5.4 is the mitigation, not a cure. It does not adjudicate disputes. It produces the evidence artifacts a dispute process consumes. The arbitration venue is separate work, and the site economics in Section 10 name the gap that venue must close. It does not fix the site integration cost. Section 10 states the site economics honestly, including the residual gap. A reader who wants the adoption story must read that section before believing any adoption claim. Directory compromise. [AUDIT] plus [LEGAL] If the directory is compromised, the compromise is transparency-logged, monitors alert, and the directory key rotates. Directory down means staples keep working until their 300-second expiry, then verification stops. There is no fake degraded mode. Issuer rogue. [LEGAL] plus [AUDIT] A rogue issuer's bond is slashed to the audited reserve, the issuer is delisted, and its identities drop to unproven tier or revoked. Cross-issuer unlinkability is preserved by design. Agent key stolen. [CRYPTO] plus [SITE] Blast radius: 1 site's sub-key, no more than 300 seconds of scopes, spend capped by the certificate. The principal revokes. The audit shows exactly what happened. Agent lies in records. [AUDIT] Site receipts contradict the lie, and the contradiction is machine-detectable. Fabrication fails log ingestion (receipt cross-check plus agent_sig verification). Omission violates a MUST. 10. Privacy Considerations Wire identifiers are per-origin aliases. Per-site sub-keys are mandatory. Cross-site correlation by sites via protocol identifiers is structurally impossible [CRYPTO], with 2 known exceptions documented as open defects: the binding endpoint's plaintext principal_key (Section 8.2, open item 9) and the wire certificate's cross-origin-constant Merkle root (Section 7.2, open item 10). Cross-site correlation by the directory is possible and MUST be trusted not to happen [LEGAL]. The predecessor's claim ("structurally impossible", unqualified) was false and is withdrawn. The distinction between the 2 claims is the most important privacy sentence in this document. The certificate is a per-origin view: no global identifiers, no plaintext origin sets (Merkle-root commitments plus per-origin inclusion proofs), with 1 exception: the certificate-wide Merkle root cert_alias_root is constant across origins and wire-visible (open item 10). The principal key is not carried in the wire certificate. The intent note is optional, unsigned, and minimized: task category only, 140 characters maximum, with a ban list covering names, account identifiers, and personal data. Budget amounts are hidden from sites (commitment only). Aggregate settlement counts and volumes published by rails MUST NOT be used as reputation or trust evidence (wash-trading). Bilateral, countersigned payment proofs for completed work MAY count as cost-backed evidence. Logs use a commitment and payload split. Payloads expire by default after 90 days unless a dispute hold exists. Commitments are kept. Erasure is cryptographic destruction of the record key. Payloads are encrypted with the named ML-KEM hybrid [FIPS203] key encapsulation (Appendix A). Verifiers act as processors (GDPR Article 28) bound to the fraud-prevention purpose. Article 28-compliant terms are required at accreditation. Verifier-unlinkability limits. This document promises no verifier-unlinkability beyond the guarantees of SD-JWT [RFC9901] until BBS+ becomes an RFC (it is currently an IRTF draft only). Normative: SD-JWT-based mandates MUST NOT be accepted across merchants. ("AP2" in the source specification is undefined there and here; flagged to its editors.) SD-JWTs link through the issuer signature without BBS+, and cross-merchant reuse would regress the pairwise model. Reputation signals. The on-chain 0-to-100 reputation score is RETIRED: no literature supports it, and field data shows free ratings are Sybil-faked at zero cost (ERC-8004: 519,437 registrations, 6.05 percent with any feedback, 59 to 91 percent coordinated Sybil reviewers; figures per the source-specification analysis, 2026). Reputation in this architecture is off-chain, evidence-backed, and per-context (never 1 global number): only cost-backed evidence counts (countersigned receipts, payment proof, stake, verified attestations); free ratings, stars, self-claims, and unverified feedback count for nothing. Reputation NEVER authorizes any action alone: every action is gated by capability checks. The full reputation design ships after the red-team simulation passes. Any reputation leg inherits a normative constraint: reputation signals MUST NOT introduce cross-site linkability into pairwise pseudonyms. Any design that accepts a cross-registry linkable identifier fails conformance by construction. Safe harbor. Verifiers running the reference implementation (or passing the published conformance vectors, including the stateful harness and negative vectors) and keeping it updated within the 72-hour patch SLA are covered for documented design flaws. Until the trust-framework entity exists and the companion agreement is published, the harbor does not cover operational drift. Entity formation plus agreement publication are launch gates. Non-conformant verifiers expressly assume the risks in the right-hand column of Section 9. The specification's honesty is their notice. Unmasking instrument. Issuers disclose identity only under (a) a court order or subpoena in the issuer's jurisdiction, or (b) defined arbitration with notice, an objection right, and written findings. Each unmasking request stakes a filing bond, forfeited if denied. Standing is required: a concrete dispute. Per-issuer unmasking telemetry appears in the transparency log. Directory records carry jurisdiction. No lawful path means no issuance there, stated openly. Mutual indemnification between issuers, the directory, and conformant verifiers for documented modes WILL BE carried in the trust-framework agreement; until it is published, no mutual indemnification exists and each party bears its own documented-mode risk. The honest site economics. Site integration first cost is 80,000 to 800,000 dollars (custom stateful claims verifier, counter store, 60-second revocation polling, binding resolution, velocity metering, receipts, price schedule, abuse-report signing, 72-hour patch SLA, conformance harness, legal) plus 30 to 50 percent per year ongoing. Value-back at maturity: fraud signals 4,000 to 12,000 dollars per year for a medium site (thin at launch; the site is the signal supplier 1st), dispute evidence 0 dollars enforceable (the fraud court is out of scope), chargeback leverage about 1,250 dollars per year. At launch the value-back is about 0 dollars against the same upfront cost. Sequencing: the arbitration venue ships BEFORE sites are asked to integrate. Venue-first is necessary. Residual, named honestly: venue-real value-back (10,000 to 20,000 dollars per year) versus 80,000 to 800,000 dollars first cost is a 4 to 40 times residual gap. What MUST close the rest: demand-side force terms (volume-commitment instrument, handshake-preference in discovery consumed by agent frameworks, the fast-lane conversion lift, concentrated fleet pilots), or the specification admits the 3 to 7 year timeline. No sufficiency claim survives: operator value-back does not clear a site's integration cost, by 10 to 20 times, and this document says so. The honest target the posture work MUST hit: the 1st 50 merchants each at a positive profit and loss on their own adoption (fraud-signal plus fast-lane value above their toggle cost), at about 100,000 dollars total ecosystem cost through the edge toggle, versus 4,000,000 to 40,000,000 dollars under every other posture. Hosted conformant verifier. This document defines the shape of the thing to sell to an edge operator as an add-on: the claims verifier packaged as a hosted module. Edge signature checks stay free (RFC 9421); the module adds the claims layer (certificates, staples, counters, receipts). Merchant integration collapses to a toggle plus configuration (about 0 to 5,000 dollars). The partnership conversation is separate from this document; the module's interface is specified here. 11. IANA Considerations This document requests the following IANA actions. 11.1. HTTP Message Signatures Algorithm Registry (PENDING) PENDING. The registration of "ml-dsa-65" in the HTTP Message Signatures algorithm registry is prepared separately and is NOT part of this document. This document uses "ml-dsa-65" as the post-quantum label name for ML-DSA-65 per [FIPS204]. Until the registration completes, strict verifiers that require a registered algorithm will reject post-quantum-mode headers. That is the only hard cryptographic external clock on this specification: without the registration, the 2-label form cannot be verified by strict edge verifiers. Two further external clocks apply: the 14-day blinded revocation-handle design constraint (Section 8.4) and trust-framework entity formation (Section 10). The registration is tracked as a parallel version 1.2 item. This document does not claim the registration exists. 11.2. Well-Known URI Suffix This document requests registration of the well-known URI suffix "swarmspeak.json" for site handshake discovery (Section 4.5). This document uses the WBA-defined well-known path "/.well-known/http-message-signatures-directory" for the JWKS directory used in Web Bot Auth [WBA] interop (Appendix A); registration of that path is requested in [WBA]. The JWKS endpoint MUST be per-origin-partitioned: it MUST NOT publish an agent's full key set in 1 document, because per-origin sub-key kids in a single JWKS response would re-create the site-portfolio leak through the discovery channel. Key sets are per-origin-partitioned or requester-scored (requester-scored: the directory filters the key set to the authenticated requester's origin before responding; the source specification leaves the term undefined, flagged to its editors). 11.3. No Other Registrations This document requests no other IANA registrations. The "sws-sig1" and "sws-sig2" labels are signature labels inside RFC 9421 Signature-Input fields, not registered values. The SWS-Intent, SWS-Intent-Note, SwarmSpeak-Receipt, SwarmSpeak-Revoke, SwarmSpeak-Limit, SwarmSpeak-Step-Up, and SwarmSpeak-Hold header field names are defined here for use in this protocol; if the protocol advances, their registration in the HTTP Field Name Registry should be requested at that time. (ASSUMPTION: the registration status of the header field names is not stated in the source specification; this paragraph records the intended position rather than asserting a completed registration.) 12. References The labels [CRYPTO], [SITE], [AUDIT], and [LEGAL] are enforcement labels defined in Section 2.2. They are document-local and refer to no external document. 12.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, and Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [FIPS203] National Institute of Standards and Technology, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS PUB 203, August 2024. (ML-KEM; the named hybrid key encapsulation for audit payloads.) [FIPS204] National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024. (ML-DSA; the post-quantum signature label.) [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020. [RFC9421] Backman, A., Ed., "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024. [RFC9530] Pollard, J., "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024. [RFC9651] Nottingham, M., "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024. [RFC9901] "Selective Disclosure for JWTs (SD-JWT)", RFC 9901, DOI 10.17487/RFC9901, November 2025. (Unlinkability bound cited normatively in Section 10.) 12.2. Informative References [POPPY] Meta and Sierra, "Personal Agent Protocol (Poppy)", Draft 0.1, October 2026. Apache 2.0. The "extensions" map in poppy.json plus client metadata is the extension point relevant to this protocol. Posture toward Poppy is DRAFT: it awaits a founder decision, and this document specifies no Poppy interop mapping as normative. [WBA] Meunier, T. and S. Major, "Web Bot Auth", draft-ietf-webbotauth-httpsig-protocol-00, September 2026. IETF working-group document (Web Bot Auth WG). This document does not depend on Web Bot Auth; Appendix A defines a JWKS interop endpoint for it. [SPEC11] "SwarmSpeak Handshake Protocol -- SPEC v1.1 (DRAFT)", Version 1.1 draft, October 2026. The normative source for this Internet-Draft. Every protocol claim in this document traces to it. The source specification is itself a draft: it is not ratified, and it supersedes nothing until its version 1.1 gate closes. [RFC8693] Jones, M., Nadalin, A., and J. Richter, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020. (The "act" claim syntax is the informative annex form for delegation chains.) Appendix A. Directory API and Audit Records This appendix is normative: its MUSTs bind conformant implementations of the reference design (Section 2.1). A.1. Directory API (site-safe subset for verifiers; full records for issuers and disputes): GET /v1/keys/{kid} returns {kid, alias, public_key, issuer, status, assurance_tier, jurisdiction, scope_ceiling_hash, spend_cap, log_endpoint, instrument, strikes, required_alg}. No true agent identity, no principal identity, and no spend_cap amount detail beyond the site-safe need. GET /v1/status/{kid} returns the staple (Section 8.1). GET /v1/bindings/{alias}/{origin} returns {alias, kid, principal_key, binding_proof} for the verifier's own origin only, authenticated to conformant verifiers. GET /v1/revoked?since= and GET /v1/certs/revoked?since= return the feeds in Section 8.2. GET /v1/velocity/{cert_alias} returns per-certificate aggregate meters, keyed by alias. GET /v1/velocity/principal/{principal_ref} returns per-principal aggregate meters across all certificates, under an opaque reference. The directory MUST maintain these aggregates and MUST deny staples when per-principal caps are breached. GET /v1/issuers returns per-issuer telemetry: issuance velocity, revocation rate, tier distribution, anomaly flags. Anomaly thresholds are normative: issuance velocity above 3 standard deviations versus the issuer's 30-day baseline means flagged. Verifiers MUST treat flagged-directory staples as unproven tier (read-only) until cleared. GET /.well-known/http-message-signatures-directory returns JWKS for Web Bot Auth interop, per-origin-partitioned (Section 11.2). The directory recognizes the Signature-Agent header. A.2. Issuance economics (normative minimums; the Sybil fix): Every identity posts a slashable stake or bond, with a RECOMMENDED floor equivalent to 10 dollars in USD, priced to exceed the expected payout of 1 burned identity, reviewed annually. A portion is non-recoverable at issuance (a burn-on-mint fee). The bond is a fee AND a fine. Burn MUST be verifiable. A bare "burned_at_issuance = true" flag is dead: a rogue issuer's 50,000-identity farm would burn 0 dollars while claiming 100,000 dollars of deterrence. Burn means a verifiable settlement artifact in the directory record plus the transparency log, settled to the audited reserve. Monitors verify. Unverifiable burns verify at unproven tier. Cross-rail artifact standards are deferred. Bonds are strictly non-tradable and non-speculative. No token economics of any kind. Denomination is USD by default; crypto-denominated only with a named conversion rule. Custodian: independent, never the operator. Interest accrues to the reserve fund, never the operator. Cross-rail slash settlement is bond-per-rail with a shared cap ledger, or a defined conversion rule: named, not assumed. Slash on revocation-with-cause: identities revoked for cause forfeit the recoverable portion. Proven abuse additionally slashes to compensate victims through the dispute process. Escalating bond requirements apply to high-velocity issuers. Principal-strike rule: 3 revoked kids under 1 principal within 30 days means the principal is suspended directory-wide. Strikes propagate to the ROOT principal through delegation chains. Per-principal revocation counters are public in the record. Assurance tiers are (attestor, verified relationship, verified identifier authorization) triples: the STIR/SHAKEN ladder shape, not any vendor's API. The Play Integrity and App Attest ladder (app, device, strong hardware-backed) is the top of the ladder. C-tier (gateway-level, minimal verification) is honestly usable, not a failure. Per-tier relying-party policies are normative. Tier attestations carry an auditor-verifiable evidence hash. The directory runs random spot-challenges: produce evidence in 72 hours or drop to unproven tier plus an issuer strike. Per-issuer tier-distribution telemetry is published. Verifiers MUST require at least verified tier for transact, publish, or admin. New issuers' identities verify at unproven tier (read-only) until 90 days of clean history. Issuer accreditation minimums: a security bond posted before listing; public issuance-velocity telemetry; new issuers' identities verify at unproven tier (read-only) until 90 days of clean history. A.3. Operator requirements (normative): the directory operator MUST be a named legal entity in a stated jurisdiction, carry financial responsibility (insurance or bond sized to budget-rail flow), undergo annual audit against a named standard with public reports, publish liability caps and terms of reliance, and run the transparency log as a MUST with a monitoring SLA. Transparency-log contents: every directory record mutation, every staple-issuance batch, every revocation and succession, every emergency attestation, every required_alg pin; each as a signed, timestamped entry. Independent monitors diff live state against the log on a published cadence of no more than 1 hour. Staple-fetch metadata is retained no more than 24 hours, aggregates only thereafter. Log inclusion proofs use the Merkle direction: proofs against signed tree checkpoints, with at least 2 cosignatures from distinct organizations, which are a federation-membership duty. Operators cosign each other's logs. No new funded role. Directory economics (corrected). Bottom-up modeling (ASSUMPTION until measured): pilot 99,000 dollars per year (33,000 dollars per operator times 3 operators), growth 204,000 dollars per year, web scale under 600,000 dollars per year all-in (includes audit and legal). Per-identity infrastructure: about 0.002 dollars per agent per month at 100,000 agents. The older 5,000,000 to 15,000,000 dollar figure stands only as a plausible 3-year FULL-COMPANY budget (staff, legal, business development, marketing), NOT a directory operating cost. Funding: federation dues (base; each operator self-funds its node) plus a ratings business (growth) with a hard firewall: the ratings entity is legally separate; no pay-for-inclusion, no pay-for-removal, no pay-for-rank; verifiers pay, never the rated agents. The fix, in the source specification: (1) foundation or consortium seed for years 1 to 3, sized against the fixed-cost floor below; (2) recurring revenue matching the cost shape, 2 to 5 dollars per identity per year from issuers, never sites; one-time burn becomes recurring burn; (3) a fixed-cost floor: a fixed-versus-variable cost split is published so the seed is sized against the fixed audit, legal, and insurance costs the directory loses money on below about 500,000 identities; the seed MUST explicitly cover the sub-scale years; (4) float custody: independent custodian, interest to the reserve fund, never to the operator. Launch circularity, named: the 1st issuer is operator-affiliated, so "issuers pay the directory" is the operator paying itself until independent issuers exist. Issuer business models beyond the accreditation minimums and this recurring-revenue shape stay out of scope. A.4. Directory federation: the protocol MUST support at least 3 accredited operators. Accreditation criteria are public and MUST NOT require incumbent approval. Governance is separated from operation. Each identity is bound to its HOME directory. Verifiers accept staples and feeds for a kid ONLY from its home directory. Cross-directory failover happens only through a transparency-logged, directory-signed handoff record. Directory participation is MANDATORY for verification. There is no fake degraded mode: directory down means staples keep working to their 300-second expiry, then verification stops. Key-transparency log: every key binding is published as a leaf in an append-only Merkle tree. Inclusion proofs let anyone verify a binding against the signed tree root. Independent monitors diff live directory state against the log on a published cadence of no more than 1 hour. Witnesses cosign signed tree checkpoints (at least 2 distinct organizations). Operators gossip checkpoints to each other; lies are detectable with cryptographic proof. Stapled directory proofs: the sender staples its own directory inclusion proof plus its capability certificate to its message. The verifier checks the stapled proof against its locally cached signed tree head: local math, 0 cryptographic directory fetches per message. Meter and velocity checks (Sections 6.2, A.8) are per-policy directory queries on the hot path at high-velocity scopes. The source specification asserts both unconditionally; flagged to its editors. The directory is fetched in the background: 1st sight of an unknown agent, cache expiry, or a revocation-feed signal. Cache values (ASSUMPTION): hot cache TTL 60 seconds, stale-while-revalidate window 300 seconds, maximum stale on directory outage 24 hours with a logged warning, negative-cache TTL for unknown identities 10 seconds. Exit is open: any operator can leave; any verifier can switch directories; no agent re-enrolls. A.5. Audit records: each record carries version ("1.1"), header_hash (SHA-256 of the canonical header), alias (per-origin, never the true identity, never any global certificate identifier), log (the bound, signed log endpoint), commit ({actions_root: Merkle root of the action list, bytes_total, count}), payload (an encrypted blob of per-action detail), payload_kem (ML-KEM-768 hybrid), payload_key_id, receipt_refs (SHA-256 of each site receipt), agent_sig (agent sub-key over the receipt hash), prev_hash, completed, ts, and sig (agent sub-key over the JCS of the record minus sig). Commitment fields (hashes, chain links, counters) are kept forever, publicly verifiable. Payload fields are encrypted per record with the named ML-KEM hybrid key encapsulation: this is the actual harvest-now-decrypt-later surface. Erasure means cryptographic destruction of the record key ("crypto-shredding"). Payloads expire by default after 90 days unless a dispute hold exists. Commitments are kept. Ingestion rules (normative): authenticate the submitter (envelope signed by the alias's key); dedup on record hash; reject records with ts outside a 24-hour ingestion window; fork resolution is first-seen-wins with checkpoint arbitration; verify receipt_refs against site-registered receipts; verify agent_sig over the receipt hash. The ingestion batching bound is 1 normative number shared with the per-principal velocity meters. DRAFT: the numeric value of that batching bound is not yet named in the source specification and is an open item (Appendix C). Submission is MUST for callback and receipt flows. The site confirms submission (pushes its side); the agent does not merely assert it. Records are indexed by alias AND certificate (cross-header aggregation), not just header_hash. If the log endpoint is unreachable, the site MUST spool records and retry for at least 72 hours. Service already rendered is unaffected. The in-band receipt remains the claim artifact. The agent MUST NOT be penalized for outage-caused late submission. The spool timestamp counts for the 24-hour ingestion window. The log MUST return a signed proof-of-inclusion on every accepted submission. Inclusion proofs use the Merkle direction: proofs against signed tree checkpoints, with at least 2 cosignatures from distinct organizations (a federation-membership duty). One-sided absence is decidable: an agent holding an inclusion proof whose records the log later "loses" wins against the operator. A.6. Identity escrow logging minimization: the identity escrow MAY log only issuance and revocation events, unmasking requests and their dispositions, and aggregate counts. It MUST NOT log per-handshake alias-to-origin triples. Retention: event logs no more than 1 year; unmasking records per the dispute hold. Compulsion disclosure: the escrow discloses ONLY under the unmasking instrument (Section 10). Gag-ordered bulk disclosure is reported in the transparency log as a compulsion-event within 30 days of the gag's expiry. No [CRYPTO] mitigation exists for compelled bulk disclosure: after-the-fact reporting is the whole defense, and the data is already gone. A.7. Enrollment: new agent instances present a factory-or-operator credential and receive a BRSKI/MASA-style voucher pinning their operator domain BEFORE any per-site keys are minted. No pre-provisioned secrets are assumed. No-CA path: at the self-asserted tier, the issuer mints the instance credential directly. Voucher enrollment MUST NOT price out solo developers. The voucher design MUST include an instance-identity slot: each running instance is individually attestable. The instance credential inherits the identity's burn: 1 burn covers N declared instances, or a per-instance burn. The issuer MUST name which, in the directory record. A.8. Fleet issuance profile: accreditation class "fleet" for operators running at least 1,000 identities: 1 aggregate bond (at least 10 dollars times identity count), a fleet_id, GET /v1/velocity/fleet/{fleet_id} aggregate meters, and batched staple issuance (no more than 100 kids per call). Pairwise-per-site identity is unchanged. Per-identity economics are preserved. Slash: 1 proven abuse slashes a pro-rata share of the aggregate bond PLUS a fleet-level penalty. The fleet MUST restore the bond to its floor within 7 days of any slash. Fleets MUST query the meter endpoint for transact-or-higher scopes. A.9. Regulatory disclosure tiers: identity_disclosure is a per-jurisdiction map (pseudonymous, disclose-to-verifier, disclose-to-directory-only). Issuers in disclosure-mandate jurisdictions MUST set it and MUST NOT issue pseudonymous identities there. Verifiers MUST enforce the tier before serving transact scopes. A.10. Principal death or dissolution: issuers MUST report a principal's death or dissolution within 7 days. The directory sets status principal-deceased, treated as revoked. Budgets already revealed to a rail settle normally. No new headers verify afterward. Audit payloads go under a 1-year dispute hold. Heirs re-establish authority through transfer (Section 6.5), never by inheriting the certificate. A.11. Directory operator succession: M-of-N escrow of the directory signing key, at least daily data escrow to a named successor, 90 days of continuity funding. M-of-N holders MUST span jurisdictions (no single jurisdiction holds at least M shares) and include parties outside the operator's legal control. Release happens through a published 72-hour time-locked governance event. Periodic public ceremony proves the escrowed shares still reconstruct the live key. Escrowed identity-mapping data is encrypted: the successor holds ciphertext, and decryption requires the M-of-N ceremony. Acquisition or change of control is a re-accreditation event. A.12. Site abuse-report channel: conformant sites MAY file signed abuse reports (kid, evidence hash, scope). The directory MUST publish them transparency-logged. N reports from distinct conformant sites within 24 hours means an automatic strike, where N is the directory's published threshold. (ASSUMPTION: the exact numeric value of N is not named in the source specification and is left to the conformance program.) A.13. Graduated issuer delisting: freeze new issuance 1st. Existing identities get a 90-day migration window to re-home with assurance tiers preserved. Delist last. A.14. Chain Anchor (Audit Integrity) Purpose (plain terms): 1 background process writes a small fingerprint of the audit log to a blockchain once an hour. It is NOT for verification: verifiers never touch it (Section 8.7). It is for audit integrity. It closes 3 holes a directory-only design leaves open: witness capture (all witnesses collude to rewrite history), late-joiner history rewrite (a new participant cannot tell what the log used to say), and cheap-check (a lightweight auditor cannot verify history without trusting someone). Cost is about 2 dollars per month (ASSUMPTION), with 0 hot-path impact. If the anchor ever fails or proves worthless, it is dropped at 0 cost and the design degrades to the directory-only design. Payload (84 bytes, fixed): 32-byte Merkle root plus 8-byte sequence plus 8-byte timestamp plus 32-byte previous-anchor hash plus 4-byte version (version = 1). Designed to carry no personal data: no DID, no key, no pairwise identifier, no capability, no reputation, no revocation entry, no per-agent hash. Whether the payload is linkable to a person is a determination for counsel in each jurisdiction (see the drop rule below). The anchor is a commitment, not a record. Cadence: 1 anchor per hour, on the hour, every hour, INCLUDING empty hours. An hour with 0 real entries still anchors (a tree of dummy leaves). This proves liveness, keeps the previous-hash chain unbroken, and makes the anchor stream constant-rate and constant-size: an observer cannot distinguish an empty hour from a busy hour. Multiple anchors per hour ONLY when real entries exceed 1,024. Batching: fixed-size padded batches of 1,024 leaves. Padding leaves are deterministic dummies: dummy = SHA-256 ("swarmspeak-anchor-pad" || sequence || leaf-index) (ASSUMPTION: domain-separation string). Dummies are verifiably dummy (anyone can recompute them), never confused with real entries, never correspond to an agent. A variable batch size would leak volume; fixed padded batches fix that. Sequence: strictly plus 1 per anchor, never skipped. Gap procedure: monitors expect the next sequence within 10 minutes after the anchor hour (ASSUMPTION). Transaction still pending: wait 1 more hour. Reorged out or never landed: the anchorer re-submits the IDENTICAL payload. Anchorer silent: a backup anchorer submits the same sequence number (anchorers are redundant; the payload is determined by the log, not by the anchorer). Monitors publish a public gap log: every gap, its cause, its resolution time. Previous-hash: points to the last LANDED anchor, not the last attempted one. An attempted-but-never-landed anchor is marked VOID in the directory log with its reason (reorged, never mined, or superseded). An anchor whose previous-hash does not match the last landed anchor is REJECTED. Multi-anchorer: 2 to 3 independent parties. The anchorer is UNTRUSTED: wrong roots are publicly detectable, not a matter of opinion. Disagreement resolution is arithmetic, never a vote: each published root is checked against the root independently recomputed from the public log; the matching root wins. After 2 wrong roots in 30 days (ASSUMPTION), an anchorer is removed from the set. Finality (chain-agnostic 3-state rule): anchor states are SEEN (transaction observed in a block), then PROVISIONAL (confirmations accumulating), then FINAL (acceptance rule met), then VOID (reorged out before FINAL) or FROZEN (reorged out after FINAL: attack or catastrophic chain failure suspected). An anchor is FINAL only when all 4 checks pass: (1) the chain's own finality signal covers the anchor block; (2) payload integrity: exactly 84 bytes, version = 1, timestamp within 600 seconds of the anchor block's timestamp (ASSUMPTION), sequence = previous accepted plus 1 (or gap procedure fired); (3) chain continuity: previous-anchor hash equals the hash of the last FINAL anchor; (4) root match: the anchored root equals the Merkle root independently recomputed from the public directory log for that batch. Chain choice: chain-AGNOSTIC by design. The choice is an implementation decision, not architecture. The chain is never part of live request verification (Section 8.7). Gas-ceiling pause rule (normative): if per-transaction cost exceeds 0.10 dollars (ASSUMPTION), the anchorer pauses and alerts. Verifier relationship: an OPTIONAL anchor check for verifiers may be added later. NO wire change for agents. No re-enrollment. Drop rule: if counsel rules the anchor payload linkable to a person, the anchor is dropped at 0 cost. If a strong, funded, independent witness set matures and makes the anchor redundant, the anchor is dropped at 0 cost. Auditor caching: auditors MAY cache FINAL anchor roots permanently until superseded. Verifiers MUST NOT cache or read anchor roots during verification (Section 8.7). Appendix B. Conformance The reference verify() is 1 indivisible function. There is no verify-lite API. Signatures MUST verify before the response is committed: no serve-now-verify-later. The boolean ACCEPT decision for a presentation MUST be recomputed per presentation and MUST NOT be memoized across presentations. Cached inputs to verification (Section 8.7) are permitted; each input's TTL bounds its reuse, and revocation and validity inputs MUST be rechecked per the stated disciplines. The conformance program MUST include a stateful harness: fake directory, mid-run revocation, replay under cache pressure, velocity breach, cross-worker replay, and concurrent duplicates (aimed at the freshness-counter path). It MUST include a negative vector rejecting the bespoke envelope, and a lifetime-threshold-to-revocation-feed-check vector. Static vectors alone are insufficient. Vector corpora MUST be independently authored from the reference implementation. Site verifies wrong means conformance failure: the site loses safe harbor (Section 10) and expressly assumes the risks in the right-hand column of Section 9. The reference implementation's negative conformance vectors fail loudly. DRAFT: the conformance program's full vector corpus and the public conformance challenge are not yet published in the source specification. The harness shape above is normative; the corpus itself is an open item (Appendix C). Appendix C. Open Items and Change Log Open items (each marked DRAFT in the body where it lands): 1. Blinded revocation handle (Section 8.4). Normative design constraint: specified within 14 days of the version 1.1 gate closing. Until then, revocation checks ride the Section 8.2 binding path. 2. Ingestion batching bound (Appendix A.5). 1 normative number, shared with the per-principal velocity meters. The numeric value is not yet named in the source specification. 3. "Excessive" revoke rate (Section 4.4) and the abuse-report strike count N (Appendix A.12). Thresholds are left to the conformance program; this draft does not invent them. 4. Poppy posture [POPPY]. The ranked recommendation (edge-led pilot 1st, open adapter in parallel, adopt as named Phase-2 conditional; compete and bridge dead) awaits a founder decision. Nothing in this document is decided on posture, and no Poppy interop mapping is normative here. 5. IANA ml-dsa-65 registration (Section 11.1). Prepared separately. Marked PENDING. This document claims no registration that does not exist. 6. Version 1.1 gate. The source specification [SPEC11] (SPEC v1.1 draft) is not ratified. It supersedes nothing until its version 1.1 gate closes. This Internet-Draft describes version 1.1 as specified in that draft; if the gate changes the source, this draft MUST be revised to match before submission. 7. Conformance vector corpus (Appendix B). Harness shape is normative; the published corpus is an open item. 8. Chain anchor chain choice (Appendix A.14). The anchor is chain-agnostic by design; the concrete chain, the gas budget, and the pause-rule values are implementation decisions pinned before any anchor is published. 9. Per-origin principal-key blinding (Sections 7.2, 8.2, 10). The binding endpoint discloses the long-lived plaintext principal_key to every verifier: a cross-origin correlator. Candidate directions: per-origin principal sub-keys (the Section 7.3 delegation pattern), or directory-attested verification that discloses neither the key nor the attestation target. Protocol surgery in the source specification; this draft records the defect honestly until it lands. 10. Per-origin certificate root (Sections 4.1, 6.1, 7.2). cert_alias_root is constant across origins and wire-visible in every header: a passive cross-site correlator. Candidate directions: remove the root from the wire certificate (verifiers obtain it through the authenticated per-origin binding endpoint), or a per-origin-derived root attested by the directory. Protocol surgery in the source specification; this draft records the defect honestly until it lands. Change log for this draft: -00: Initial version. Transcribes SPEC v1.1 draft into Internet-Draft form. No protocol changes from the source. Per-origin certificate views, the 2-label post-quantum form, the freshness-counter replay defense, the honest site economics, and the [LEGAL] privacy relabel are carried over as specified. Items the source leaves unfinished are marked DRAFT, not papered over. -00 (realignment): Aligned to the decided v1.1 architecture: chain anchor (new Appendix A.14), verifier cache discipline (new Section 8.7), revocation bound (new Section 8.6), named DID allowlist with retired chain DIDs (Section 7.1), corrected directory economics (Appendix A.3), 3-operator federation with key-transparency log (Appendix A.4), retired on-chain reputation (Section 10), running-code evidence (Section 1), updated Web Bot Auth reference. No protocol changes from the source; every new claim traces to it. -00 (redteam): Applied the independent red-team report (DRAFT-REDTEAM.md, 45 attacks): qualified the privacy claim to name 2 known residual correlators (open items 9, 10), defined the step-up/hold/rate-limit wire behavior, fixed reference hygiene (RFC 9901 normative), and reconciled 12 internal contradictions. No protocol changes from the source; spec-side defects are flagged to the source editors in the text. Author's Address Shawn Todd SwarmSpeak Email: hello@swarmspeak.org This Internet-Draft will expire on 19 April 2027.