If ok is true, the entry is verified. Otherwise, the entry is unverified. There is no third state.

§33What Canonicalization Is NOT For {#canon-not-for}

Canonical JSON in v0 is ONLY for signing. It is not the format the agent uses to consume the payload. A reader parses the payload through its standard JSON parser, on whatever bytes are in the document. Two implementations may both be conformant readers and both observe the same feed even if they sort their internal representations differently, as long as each reconstructs the canonical bytes exactly when verifying.

A publisher's canonical bytes are the only thing that must match across producer and consumer for a given entry. A pretty-printed copy of the same logical object, if it ever appeared in <content>, would not verify; that is not a bug. That is the protocol working.

§34XML Namespace {#xml-namespace}

The XML extension namespace for v0 is:

https://agent-feed.dev/ns/v0

It is conventionally bound to the prefix af. A reader MUST recognize the namespace by its URI, NOT by its prefix; a publisher MAY use any prefix, including the empty default.

The elements defined in this namespace are:

• af:type (in <entry>): one of the type tokens defined in {{entry-types}}.

• af:sig (in <entry>): the base64url-encoded detached signature. Carries the attribute type="ed25519" for v0.

• af:signer (in <entry>): optional; the verification method id from did.json whose key signed this entry.

• af:spec-version (in <feed>): the integer protocol version. For v0, the value is 0.

• af:feed-status (in <feed>): one of active, terminated, migrated.

• af:migrated-to (in <feed>): present when af:feed-status is migrated. Its value is the new feed URL.

No other element in this namespace is meaningful in v0. Readers handle unknown af: elements per {{unknown-types}} (skipped, surfaced, never inventing semantics).

§35Example Feed Document {#example-feed}

The following non-normative example illustrates the structural shape of a v0 feed document. The signatures, timestamps, and key material are illustrative only.

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:af="https://agent-feed.dev/ns/v0">
  <id>https://example.com/.well-known/agent-feed.xml</id>
  <title>example.com agent-feed</title>
  <updated>2026-04-27T14:00:00Z</updated>
  <af:spec-version>0</af:spec-version>
  <af:feed-status>active</af:feed-status>

  <entry>
    <id>urn:af:example.com:1745755200000</id>
    <updated>2026-04-27T12:00:00Z</updated>
    <title>endpoint-announcement</title>
    <af:type>endpoint-announcement</af:type>
    <content type="application/json">{"asserted-at":"2026-04-27T12:00:00Z","endpoint":"https://example.com/a2a/v1","endpoint-id":"a2a","protocol":"a2a","version":"1.0"}</content>
    <af:sig type="ed25519">RGV0YWNoZWRFZDI1NTE5U2lnbmF0dXJlR29lc0hlcmUuLi4=</af:sig>
  </entry>

  <entry>
    <id>urn:af:example.com:1745758800000</id>
    <updated>2026-04-27T13:00:00Z</updated>
    <title>schema-change</title>
    <af:type>schema-change</af:type>
    <content type="application/json">{"effective-at":"2026-04-27T13:00:00Z","endpoint-id":"orders-api","from-version":"1.0","migration":{"add":["/currency"],"rename":{"/amount":"/total"}},"to-version":"1.1"}</content>
    <af:sig type="ed25519">QW5vdGhlckRldGFjaGVkRWQyNTUxOVNpZ25hdHVyZS4uLg==</af:sig>
  </entry>

</feed>

Versioning and Termination {#versioning}

This section specifies how a v0 reader handles feed-level metadata that controls protocol-version compatibility and feed lifecycle.

§36af:spec-version {#spec-version}

Every v0 feed MUST carry an af:spec-version element at the feed level (a direct child of <feed>) whose integer value is 0.

A v0 reader MUST accept any feed with af:spec-version of 0. A reader MAY accept feeds with higher integer values if it has been extended to do so. A v0 reader encountering a feed with af:spec-version greater than 0 MUST treat the feed as if it had af:feed-status: terminated for the duration of the session, NOT because the feed is in fact terminated, but because the reader cannot vouch for any of its semantics.

This is forward-pessimism: a v0 reader does not know what a v1 entry type means, what a v1 migration delta operator means, or what a v1 trust field means. It declines to guess. The forward path is for readers to be upgraded; the protocol does not provide a fallback that silently downgrades semantics.

A publisher migrating from v0 to a future version SHOULD continue to serve a v0-compatible feed for an overlapping window, either at a different URL or by emitting af:feed-status: migrated with af:migrated-to (see {{feed-status-migrated}}). v0 readers can then continue working until they upgrade.

§37af:feed-status {#feed-status}

Every v0 feed MUST carry an af:feed-status element at the feed level whose value is exactly one of:

• active
• terminated
• migrated

These are the only legal values. An unknown value is a v0 violation; readers SHOULD treat it as terminated.

active {#feed-status-active}

The publisher is currently asserting this feed. The reader proceeds normally per {{reader-contract}}.

terminated {#feed-status-terminated}

The publisher is revoking trust in this feed at this URL. As of the moment a reader sees terminated, the per-origin trust flag becomes false per {{reader-state}}. All applied state from this origin ceases to influence future agent queries. The publisher is asserting, in effect, "forget what I told you here."

A terminated feed MAY still contain <entry> elements; v0 readers MUST NOT apply them. The publisher is permitted to continue serving the document for forensic purposes. The feed is dead at the level of agent trust; it is not necessarily dead at the level of the artifact.

A publisher SHOULD NOT toggle a feed back from terminated to active in v0; doing so does not automatically restore reader trust. Readers MAY require an out-of-band signal -- a human operator -- to re-trust an origin after termination. This asymmetry is to prevent a compromise followed by a quiet recovery from also quietly re-trusting the compromised origin.

migrated {#feed-status-migrated}

The publisher has moved to a new feed URL. When af:feed-status is migrated, the feed MUST also contain an af:migrated-to element at the feed level whose value is the new feed URL.

A reader observing migrated:

1. MUST treat the current feed URL as effectively terminated for trust purposes -- the per-origin trust flag at this URL becomes false.

2. SHOULD attempt to fetch the feed at the URL given in af:migrated-to.

3. MUST resolve identity afresh at the new URL. That is, a new DID document fetch under the DID that the new URL implies. The same key MAY sign at the new URL, but the new feed MUST be verified on its own terms.

4. MUST NOT carry the old feed's applied state forward implicitly. The new feed bootstraps state from its own entries.

A reader MAY refuse to follow af:migrated-to if the new URL is on a different hostname under different DNS authority. That is a reader policy decision, not a protocol mandate.

§38The Kill Switch Contract {#kill-switch}

feed-status: terminated is the kill switch. It exists in v0 because:

• A compromised key or stolen domain is a real risk, and the protocol must give the publisher a way to tell readers "stop trusting me here."

• Without it, the only kill mechanism is "remove the file", which a reader cannot distinguish from a routine outage.

• A signed terminated document is itself a verifiable revocation: it asserts, "this revocation came from the same key that signed everything else; trust the revocation as you trusted the rest."

The kill switch is intentionally one-way at the protocol level. A publisher that terminated by mistake does not get to un-terminate by flipping the value back. Recovery requires an out-of-band conversation with each reader operator and (typically) a key rotation and a fresh start.

That asymmetry exists because the cost of a false-negative termination (reader continues trusting a compromised origin) is far higher than the cost of a false-positive termination (operators have to re-trust a recovered origin manually). The protocol picks the side of safety under uncertainty.

§39Versioning of Internal Vocabularies {#vocab-versioning}

af:spec-version versions the protocol as a whole: entry types, canonicalization rules, signing rules, kill-switch semantics. It does NOT version:

• the publisher's own schema versions, which appear inside payloads (e.g. version, from-version, to-version) and are opaque to this protocol;

• the migration-delta sub-language inside schema-change, which is handled by the conservative posture of {{migration-delta}}: readers preserve unknown keys but do not use them;

• the DID method or signature algorithm. v0 is fixed at did:web and Ed25519. A future spec version MAY permit alternatives.

When a future version of this protocol ships, it will carry a new integer value of af:spec-version. A reader supporting both versions detects which to apply by the integer. There is no negotiation, no content-type dance, no probe sequence. The number is the contract.

Security Considerations {#security}

This section enumerates threats relevant to v0, what the protocol mitigates, and what it explicitly does not.

§40Signature Scope and What It Proves {#sec-sig-scope}

A v0 signature proves origin: the bytes of an entry's canonical JSON payload were signed by the holder of the private key whose public counterpart was at did.json at the moment the reader resolved it.

A v0 signature does NOT prove truth. The publisher MAY assert a false schema-change (a field name that does not exist), a stale one (the schema reverted but no new entry was published), or a malicious one (a publisher who wishes to confuse a competitor's agents). The detection of such lies is outside the protocol; see {{sec-lying-publisher}}.

A v0 signature does NOT prove continuity of the holder. A key may have been compromised or transferred. The protocol cannot tell.

A v0 signature does NOT prove any property of the live API. Live behavior may differ from the announced behavior; the reader's disagreement detection in {{disagreement}} surfaces this, but the agent's policy decides what to do with the surface.

§41Lying Publisher {#sec-lying-publisher}

A signed feed entry binds bytes to origin, not to truth. A sufficiently motivated publisher can sign:

• a stale schema-change ("I changed the schema back, but I haven't updated the feed");

• a wrong one ("I think the new field is currency but it is in fact cur");

• a deliberately misleading one ("I will sign nothing about my recent breaking change in order to keep dependents broken").

The protocol does not detect any of these. Detection requires cross-referencing live behavior against announced behavior across many readers and possibly many publishers, which is a layer above this protocol. The disagreement event in {{disagreement-mismatch}} is the substrate on which detection can be built; it is not detection itself.

A reader observing repeated mismatches against a single publisher has the data to escalate -- to a human, to an aggregator, to a reputation service. The action is not specified by this protocol. v0 ships the substrate; detection lives above v0.

§42Sybil Resistance {#sec-sybil}

This protocol binds identity to DNS through did:web. An adversary who controls a domain controls its feed. An adversary who controls many domains controls many feeds. The protocol does not pretend otherwise.

Sybil resistance -- making it costly to be many indistinguishable publishers -- is a different problem with different primitives (proof-of-work, stake, attestation, social graph). It is addressed by ecosystems built on top of this protocol, not within this protocol.

A reader MUST NOT depend on signature verification under this protocol for sybil resistance. Two distinct domains both serving valid did.json documents are, from this protocol's standpoint, two distinct publishers. Whether they are operated by the same human, organization, or attacker is not knowable from the protocol alone.

§43Replay and Idempotency {#sec-replay}

An adversary serving a copy of the publisher's feed (for example, a caching CDN under their control, or an in-path proxy) cannot forge entries because Ed25519 signatures are bound to the canonical payload bytes. The adversary CAN, however:

• replay entries that were once valid but have since been logically superseded;

• delay delivery of newer entries to specific readers;

• omit entries entirely, allowing readers to fall behind without signaling.

The reader's idempotency contract per {{idempotency}} mitigates replay-of-old-entries: an <id> whose canonical payload matches prior application is silently skipped, and an <id> whose payload differs triggers replay-mismatch. The protocol does not mitigate selective omission or delay; mitigation requires either a push transport with delivery acknowledgments (deferred to a future version) or out-of-band cross-checking among readers.

§44Key Compromise and Rotation {#sec-key-compromise}

If a publisher's private key is compromised, an attacker can sign entries that verify under the published verification method. The publisher's mitigations within v0 are:

• publish a new verificationMethod in did.json (rotation per {{key-rotation}});

• emit af:feed-status: terminated to revoke trust in the feed under the compromised key (per {{kill-switch}}).

v0 acknowledges that the rotation ceremony is minimal. The protocol does not specify:

• a key revocation list separate from feed-status;

• a delegation hierarchy by which a parent key can revoke a child key;

• a notarization or transparency log binding the publication time of a public key to a wider trust system.

Future versions of this protocol may address these. v0 readers mitigate by re-resolving the DID document on each ingestion (per {{key-rotation}}), so a compromised key removed from did.json stops verifying further reads on the next poll.

A reader MUST NOT cache a public key past the freshness window indicated by the DID document HTTP response. A publisher in the middle of a rotation SHOULD set a short Cache-Control: max-age on did.json for the duration of the transition, to bound the window in which stale keys verify.

§45Privacy and Public Visibility {#sec-privacy}

Feed entries are PUBLIC. They are integrity-protected (signed) but not confidentiality-protected. Anyone who can fetch /.well-known/agent-feed.xml can read every entry.

Origins operating private or internal-only agent surfaces MUST NOT publish feed entries describing them under this protocol. The protocol deployment surface is the public web. Selective disclosure is a different problem with different primitives (capability tokens, encrypted payloads, separate confidentiality channels) and is not in scope.

A publisher publishing a feed implicitly accepts that:

• the feed will be archived by third parties;

• entries will be readable indefinitely once published, even after a feed-level termination;

• the feed's contents are part of a public record about the origin's surface.

A publisher who needs to retract a public assertion can publish a follow-up entry that supersedes it, but the original signed entry remains in archives forever. The protocol cannot retroactively unpublish a signed fact.

§46Polling Load on Origins {#sec-polling-load}

A naive deployment in which N readers poll an origin's feed with high frequency creates load proportional to N. This protocol mitigates by:

• specifying a 60-second floor on poll frequency per {{polling}};

• specifying a 24-hour ceiling so that aggressively long cache windows do not create starvation;

• requiring readers to honor Cache-Control and ETag within those bounds, so a publisher serving max-age=600 (ten minutes) limits reader poll-throughput accordingly;

• reading from a static file behind a CDN, which absorbs nearly all the load for typical deployments.

Origins without CDN access at scale will need to raise their cache ceilings or move to a future push transport when one is defined. Readers MUST NOT use this protocol's poll endpoint as a heartbeat or liveness check; the cadence rules are bounds on legitimate use, not permissions for arbitrary use.

A publisher experiencing abuse SHOULD:

• return HTTP 429 (Too Many Requests) with appropriate retry headers per [RFC9110];

• consider IP-level or token-level rate limiting outside the protocol scope.

A reader receiving 429 responses MUST respect the response, MUST NOT retry sooner than the response indicates, and SHOULD raise an event for operator visibility. Retry storms following 429 are out of specification.

§47Snapshot/Stream Disagreement {#sec-snapshot-disagreement}

If the snapshot at /.well-known/agent-card.json disagrees with the most recent applicable feed entry (for example, the feed asserts a new canonical URL but the snapshot still points to the old one), the inconsistency is a publisher bug per {{snapshot-artifact}}. From the reader's standpoint, the feed is authoritative for the temporal record, and disagreement is a hint that the snapshot is stale.

A reader MAY surface a snapshot-feed-disagreement event for operator visibility. The reader MUST NOT silently pick the snapshot's value over the feed's value -- the feed is the temporal source of truth. Silent reconciliation hides the publisher bug.

§48DID Document Tampering on Resolution {#sec-did-tamper}

The DID document is fetched over HTTPS. The protocol relies on HTTPS for resolution integrity. An adversary capable of intercepting or rewriting the DID document at fetch time can substitute a verification method whose key the adversary controls; they can then sign entries that verify under that method.

Mitigations:

• HTTPS certificate validation MUST succeed against the origin's hostname; a reader MUST NOT accept invalid or self-signed certificates as if they were valid.

• Operators concerned about DNS hijacking SHOULD pin DNS resolution through DNSSEC and SHOULD subscribe to certificate transparency log monitoring for their hostnames. These mitigations are out of scope but are noted because did:web deliberately relies on the existing web PKI and DNS infrastructure.

§49Threat Model Boundary {#sec-threat-boundary}

This protocol's threat model is bounded as follows:

• IN scope: a passive network observer; an active man-in-the-middle defeated by HTTPS; an adversarial publisher within the bounds of signature integrity (i.e., publishing false-but-signed entries); replay of stale entries; selective omission of newer entries from individual readers.

• OUT of scope: compromise of the publisher's signing key (mitigated only by rotation and termination); domain takeover (the protocol does not detect that the holder of the domain has changed); compromise of the underlying TLS/PKI/DNS infrastructure; sybil attacks; reputation systems; lying-but-signed publishers; agent- level decisions about how to react to mismatch events.

Implementers SHOULD make clear in their documentation which of these threats are mitigated by their stack and which are not, and operators SHOULD compose this protocol with whatever additional mitigations are appropriate for their context.

IANA Considerations {#iana}

This document requests IANA registration of two well-known URI suffixes per [RFC8615].

§50Well-Known URI: agent-feed.xml {#iana-agent-feed}

URI suffix: : agent-feed.xml

Change controller: : IETF

Specification document(s): : This document.

Related information: : The artifact is an Atom 1.0 [RFC4287] document extended with the namespace https://agent-feed.dev/ns/v0. Content-type application/atom+xml. The document is the append-only stream artifact described in {{stream-artifact}}.

§51Well-Known URI: agent-card.json {#iana-agent-card}

URI suffix: : agent-card.json

Change controller: : IETF

Specification document(s): : This document.

Related information: : The artifact is a JSON [RFC8259] document. Content-type application/json. The schema of the document is not specified by this protocol; the document is the snapshot artifact described in {{snapshot-artifact}} and is constrained only by consistency with the most recent applicable feed entry.

§52Well-Known URI: did.json (informative) {#iana-did}

The did.json well-known URI is registered under [W3C-DID-WEB] and is not requested again here. This document references the existing registration.

§53Media Types {#iana-media-types}

This document does not request a new media type. The feed is served as application/atom+xml. The DID document and snapshot are served as application/json.

§54XML Namespace {#iana-xml-namespace}

This document defines an XML namespace for use in extending Atom feeds:

URI: : https://agent-feed.dev/ns/v0

Registrant Contact: : A. Abdi (abdullahiabdi1233@gmail.com)

XML: : See {{xml-namespace}} for the elements defined in this namespace.

References

§55Normative References

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

[RFC3339] : Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, https://www.rfc-editor.org/info/rfc3339.

[RFC4287] : Nottingham, M. and R. Sayre, Eds., "The Atom Syndication Format", RFC 4287, December 2005, https://www.rfc-editor.org/info/rfc4287.

[RFC4648] : Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, https://www.rfc-editor.org/info/rfc4648.

[RFC6454] : Barth, A., "The Web Origin Concept", RFC 6454, December 2011, https://www.rfc-editor.org/info/rfc6454.

[RFC6901] : Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, April 2013, https://www.rfc-editor.org/info/rfc6901.

[RFC8032] : Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, https://www.rfc-editor.org/info/rfc8032.

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

[RFC8615] : Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, https://www.rfc-editor.org/info/rfc8615.

[RFC9110] : Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022, https://www.rfc-editor.org/info/rfc9110.

[W3C-DID] : Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, 19 July 2022, https://www.w3.org/TR/did-core/.

[W3C-DID-WEB] : Terbu, O., Ed., Sabadello, M., Ed., et al., "did:web Method Specification", W3C Community Draft, https://w3c-ccg.github.io/did-method-web/.

§56Informative References

[RFC8259] : Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

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

[IEEE-754] : IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, July 2019.

[MCP] : Anthropic, "Model Context Protocol", 2024, https://modelcontextprotocol.io/.

[A2A] : Google, "Agent2Agent (A2A) Protocol", 2025, https://google.github.io/A2A/.

[ANP] : "Agent Network Protocol", 2025, https://agent-network-protocol.com/.

[ERC-8004] : Ethereum, "ERC-8004: Trustless Agents", Ethereum Improvement Proposal, 2025.

[WEBSUB] : Genestoux, J. and A. Parecki, "WebSub", W3C Recommendation, 23 January 2018, https://www.w3.org/TR/websub/.

Acknowledgements

{:numbered="false"}

The author thanks the participants in the design roundtable that shaped this work: Paul Graham, John Carmack, Nassim Nicholas Taleb, and Rich Hickey, whose scrutiny over multiple rounds tightened the contract surface and the threat model. Specific contributions include Hickey's argument for placing the reader contract before the producer schema, Carmack's pressure on signature scope and what the bytes actually cover, Taleb's framing of the kill switch and asymmetric recovery cost, and Graham's pressure on bootstrapping order and the question of who commits first in a federation protocol.

The author thanks the broader IETF and W3C communities for the primitives this document composes: Atom, well-known URIs, Ed25519, JSON Pointer, JSON canonicalization, and the DID core and did:web work. None of the components in this document are novel; the composition is.

Author's Address

{:numbered="false"}

Abdullahi Abdi : Independent : Email: abdullahiabdi1233@gmail.com

Appendix A: Conformance Categories {#appendix-conformance}

This appendix is non-normative. The conformance obligations are distributed across the body of the document; this appendix gathers them by implementation category for convenience.

§57A.1 Publisher Conformance {#publisher-conformance}

A conformant publisher:

• MUST publish did.json at /.well-known/did.json over HTTPS, with fields per {{did-fields}}.

• MUST publish a feed at /.well-known/agent-feed.xml whose top-level element is the Atom <feed> element with the agent-feed namespace declared per {{xml-namespace}}.

• MUST include af:spec-version (value 0 for v0) and af:feed-status at the feed level per {{versioning}}.

• MUST emit each entry with <id>, <updated>, <title>, af:type, <content type="application/json">, and <af:sig type="ed25519"> per {{entry-envelope}}.

• MUST sign each entry's <content> text bytes per {{canonicalization}}.

• MUST canonicalize JSON per {{canonical-json}} before signing.

• MUST keep af:type values within the v0 vocabulary per {{entry-types}}.

• MUST keep entry <id> values stable across re-emissions of the same semantic event per {{idempotency}}.

• MUST NOT reuse an entry <id> for a different canonicalized payload per {{stream-artifact}}.

• MUST publish a snapshot at /.well-known/agent-card.json consistent with the most recent applicable feed entries per {{snapshot-artifact}}.

• SHOULD use HTTPS with valid certificates that match the origin's hostname.

• SHOULD set sensible Cache-Control headers on the feed and the DID document.

• SHOULD serve content-type application/atom+xml for the feed.

• SHOULD serve content-type application/json for did.json and agent-card.json.

• MAY archive older entries off-stream once they are no longer needed to reconstruct current state from a fresh reader join, subject to the dependency rules in {{stream-artifact}}.

• MUST emit af:feed-status: terminated (or migrated with af:migrated-to) when revoking trust in the current feed per {{kill-switch}}.

§58A.2 Reader Conformance {#reader-conformance}

A conformant reader:

• MUST resolve /.well-known/did.json per {{key-resolution}} before applying any entry from a feed.

• MUST verify each entry's signature per {{reader-verify}} before applying it.

• MUST NOT apply unverified entries per {{unverified}}.

• MUST handle unknown entry types per {{unknown-types}}: skip and surface, never invent semantics.

• MUST apply verified entries in document order per {{on-receipt}}.

• MUST honor af:feed-status: terminated by setting the per-origin trust flag to false and ceasing to use applied state for that origin per {{feed-status-terminated}}.

• MUST handle af:feed-status: migrated by treating the current URL as terminated and SHOULD follow af:migrated-to per {{feed-status-migrated}}.

• MUST emit a mismatch event for live-vs-feed disagreements per {{disagreement-mismatch}}; MUST NOT silently coerce.

• MUST be idempotent on re-ingestion by entry id per {{idempotency}}.

• MUST respect polling cadence bounds per {{polling}}.

• MUST NOT cache public keys past DID document freshness per {{key-rotation}}.

• SHOULD support each entry type's reader effect as specified in {{apply-by-type}}.

• SHOULD rate-limit unverified-entry and unknown-entry-type events per {{unverified}} and {{unknown-types}}.

• MAY consult the snapshot at /.well-known/agent-card.json for fields the feed does not provide per {{snapshot-artifact}}; MUST NOT use the snapshot for historical reconstruction.

§59A.3 Test Categories {#conformance-tests}

Implementations seeking to claim conformance SHOULD pass tests in each of the following categories. The categories are normative; the specific tests are documented with reference implementations.

1. Canonicalization. Identical JSON inputs in different surface forms produce identical canonical bytes. Non-finite numbers are rejected on emission.

2. Signing roundtrip. Sign-then-verify against the same key succeeds. Verify against a different key fails. Verify against a tampered payload fails. Verify against a tampered signature fails.

3. DID resolution. A published did.json is fetched, the verification method is located by id (or by default if no <af:signer>), the public key is decoded, and a feed entry signed by the matching private key verifies. A feed entry signed by an unrelated key does not verify.

4. Entry application.

   • endpoint-announcement records and overwrites prior announcements for the same (protocol, endpoint-id).

   • schema-change records migrations and updates the current version. A schema-change of an unknown endpoint synthesizes a record.

   • deprecation is honored before and after sunset; replacement resolves to the latest endpoint-announcement for that id.

5. Disagreement detection. The mismatch event fires when the live response lacks an announced added field and does not fire when the announced added field is present. Retype-mismatch fires per {{disagreement-mismatch}}.

6. Forward compatibility.

   • Unknown entry types are skipped, not applied, not failed.

   • Unknown migration-delta keys are preserved in recorded migrations but not used for {{disagreement}} detection.

   • A future af:spec-version integer causes a v0 reader to back off per {{spec-version}}.

7. Kill switch.

   • feed-status: terminated causes the per-origin trust flag to become false, and applied state stops influencing queries.

   • Toggling back to active does not re-trust automatically.

   • feed-status: migrated with af:migrated-to causes the reader to follow per its policy, and the new feed bootstraps fresh identity and state.

8. Idempotency.

   • Re-fetching a feed without changes applies nothing new and emits no events.

   • A reused entry <id> with a new payload triggers replay-mismatch and is not applied.

A reference test suite is published alongside the reference implementation. Implementations claiming conformance SHOULD reference the version of the suite they pass against.

§60A.4 What Conformance Does Not Certify {#conformance-non-claims}

Passing the v0 conformance categories does NOT certify:

• security against any threat model beyond what {{identity}} binds;

• interoperability with any specific MCP, A2A, or other consumer surface;

• correct behavior under load, network partition, or adversarial publishers beyond the threat model in {{sec-threat-boundary}};

• agent-level decisions about what to do with a mismatch event. The protocol specifies the report; agent policy specifies the response.

Conformance is a narrow claim. It is not a seal of robustness.

Appendix B: Glossary {#appendix-glossary}

This appendix is non-normative.

Active feed: : A feed whose af:feed-status is active. Reader proceeds normally.

Agent: : A program acting on behalf of a principal that consumes agent-feed entries to maintain a model of an origin's machine-readable surface.

Append-only: : A property of the stream per {{stream-artifact}}: the multiset of (entry-id, canonical-payload, signature) tuples grows monotonically and never shrinks.

Canonical JSON: : The deterministic byte-encoding defined by {{canonical-json}}.

Detached signature: : Signed bytes and signature transported separately. The v0 <af:sig> is a detached Ed25519 signature over the canonical payload bytes.

Document order: : The order in which entries appear in the parsed XML feed document. See {{on-receipt}}.

Endpoint: : A URL serving a particular protocol surface for an origin.

Endpoint-id: : A stable identifier within an origin for an endpoint, used as the cross-entry key. May or may not equal the URL.

Entry: : An Atom <entry> element carrying one v0 fact, signed independently per {{canonicalization}}.

Feed: : The stream artifact at /.well-known/agent-feed.xml.

Migrated feed: : A feed whose af:feed-status is migrated. Treat as terminated for trust at the present URL and follow af:migrated-to per {{feed-status-migrated}}.

Origin: : An (HTTPS scheme, host, port) triple per [RFC6454], inferred here from the URL where did.json is served.

Publisher: : The party operating an origin and signing its feed.

Reader: : The library or service that ingests feeds on behalf of an agent and exposes the contract in {{reader-contract}}.

Snapshot artifact: : The current-state document at /.well-known/agent-card.json. The schema is not specified by this protocol; existence and consistency are.

Stream artifact: : The append-only feed at /.well-known/agent-feed.xml.

Terminated feed: : A feed whose af:feed-status is terminated. Per-origin trust flag becomes false per {{feed-status-terminated}}.

Verified entry: : An entry whose detached signature successfully validates under the resolved DID public key against the canonical payload bytes.

Appendix C: Design Rationale {#appendix-rationale}

This appendix is non-normative. It records the load-bearing design choices and the tensions they were chosen against, so future revisions of this protocol know what they are reconsidering, not just that they are.

§61C.1 Reader Contract Before Producer Schema {#rationale-reader-first}

The conventional ordering of a protocol document is to specify the wire format first and the consumer behavior second. This document inverts the order. The reader's behavioral contract in {{reader-contract}} appears before the producer schema in {{entry-types}} because the contract surface for this protocol is the reader, not the wire.

A producer can change the wire format substantially -- adding elements, reordering attributes, changing whitespace within Atom -- and a conformant reader will continue to behave correctly so long as the canonical payload bytes verify. A producer cannot change reader behavior by changing the schema. The schema is a vehicle; the contract is the cargo.

Putting the reader contract first also forces the producer schema into a derivative role. A field that the reader does not consume is not a field; if it were, the contract would have specified a behavior for it. This discipline keeps the producer schema small.

§62C.2 Snapshot and Stream as Distinct Artifacts {#rationale-two-artifacts}

The snapshot at /.well-known/agent-card.json and the stream at /.well-known/agent-feed.xml could in principle be combined: a single artifact carrying current state and a tail of recent changes. They are not combined for several reasons.

First, the artifacts have different time-constants. The snapshot changes whenever any field in the origin's surface changes; the stream changes when a discrete event the publisher chooses to announce occurs. Combining them would force one rate of change on both, mismatching one of them.

Second, the artifacts have different consumers. A reader that cares only about "what does the origin look like right now?" is satisfied by the snapshot in one fetch. A reader that cares about "when did the origin assert each thing?" is satisfied only by the stream. Combining them forces every consumer to pay the cost of the larger artifact.

Third, history cannot be reconstructed from samples. A polled snapshot's adjacent samples can disagree, but disagreement does not encode timing, count of events, or structural delta. The stream encodes all three.

The cost of two artifacts is publisher discipline: the publisher must keep them consistent. The protocol specifies that consistency is required ({{snapshot-artifact}}) and that the feed is authoritative on disagreement ({{sec-snapshot-disagreement}}).

§63C.3 Atom Over a Custom Format {#rationale-atom}

The stream artifact is an Atom 1.0 document because Atom has been deployed at web scale for two decades, has well-understood extensibility via XML namespaces, has an <id>/<updated> semantics that match the v0 entry contract closely, and has tooling in every language that matters. A custom format would have to re-derive each of those properties.

The cost of using Atom is XML overhead and the slight awkwardness of embedding canonical JSON inside an XML text node. Both are accepted trade-offs against the cost of inventing a new format.

§64C.4 Detached Ed25519 Over an Envelope Format {#rationale-detached-ed25519}

The signature is detached, raw 64-byte Ed25519 [RFC8032], not wrapped in JOSE [RFC7515], JWS, or COSE. This choice has three motivations:

• Algorithm simplicity. Ed25519 has a fixed 32-byte public key and fixed 64-byte signature. There is no algorithm negotiation, no parameter set, no curve selection.

• Implementation simplicity. A detached signature is the minimum information needed to verify integrity; the envelope is transport metadata. By keeping them separate, the signature can verify across envelope changes (re-emission, archive, reformat).

• Scope clarity. Detached signatures make the signature scope obvious: the bytes signed are precisely the bytes you point at, and nothing else. JWS-style envelopes blur this with header inclusion rules.

The cost of bypassing JOSE is that v0 cannot tunnel through systems that expect JWS. v0 accepts that cost. JWS support, if useful, can be added in a future version as an alternative encoding without disturbing the signature semantics.

§65C.5 did:web Over Other DID Methods {#rationale-did-web}

did:web was chosen over more elaborate DID methods (such as did:key, did:ion, blockchain-rooted methods, or PKI-rooted methods) because:

• It binds identity to DNS, the trust system the public web already uses.

• It requires no additional infrastructure beyond an HTTPS-served static file.

• It is unambiguous: there is exactly one DID per host, fetched at one URL.

• It is debuggable: the document is human-readable JSON.

The cost is that did:web inherits the limitations of DNS and PKI: domain takeover compromises identity; DNS hijacking compromises resolution; certificate authority compromise compromises HTTPS. v0 accepts these costs because the alternative (introducing a new trust root) is significantly more expensive to deploy and to verify independently.

did:web is also intentionally non-portable across hostnames. An origin that changes hostname must publish a new feed at a new location; the kill switch and migrated mechanism in {{versioning}} exist to support this.

§66C.6 Polling Over Push {#rationale-polling}

v0 is poll-only. WebSub [WEBSUB] is the mature standard for Atom push and is acknowledged as a future extension in {{security}}. v0 defers it for two reasons:

• Polling is the simpler-to-deploy half. A static file behind a CDN is sufficient infrastructure for a publisher; WebSub adds a hub dependency that is harder to make universal.

• Polling has a single concurrency story. Push delivery requires retry semantics, idempotency at the delivery layer, and authentication of the hub-to-subscriber channel. Each of these is a source of complexity that v0 does not need.

The cost of poll-only is that readers cannot observe events at the moment they are published; they observe events when they next poll. Two readers polling at different phases observe the same event at different times. v0 accepts that. A future extension MAY add push delivery as opt-in, with conformance for both modes.

§67C.7 Three Entry Types, Not Five or Ten {#rationale-three-types}

v0 defines exactly three entry types because each was demanded by a concrete consumer behavior in {{reader-contract}} and no fourth was. A protocol with too many entry types fragments reader implementation and makes the conformance surface ill-defined; a protocol with too few cannot express the events of interest.

The shortlist that did not make v0: status entries (operational telemetry), policy entries (pricing, rate limits), capability entries (which would duplicate the snapshot), sybil entries (attestation), reputation entries. Each was excluded for the reasons in {{stream-nongoals}}, summarized as: different time-constants, different consumers, different blast radii.

Future versions may add entry types if and when concrete consumer behaviors demand them. The bar is the same: a new entry type must be supported by a documented reader behavior, not a producer convenience.

§68C.8 Termination as One-Way at the Protocol Level {#rationale-one-way-termination}

The kill switch in {{kill-switch}} is intentionally one-way. A publisher that has emitted feed-status: terminated cannot, within the protocol, restore reader trust by toggling back to active. This seems heavy; it is heavy on purpose.

Cost-asymmetry analysis: the worst case for "a recovered origin must be re-trusted by hand" is operator inconvenience, scaling with the number of readers. The worst case for "a compromised origin can quietly recover trust by toggling a flag" is silent persistence of compromise. The first is a coordination cost; the second is a security failure. The protocol picks the side of safety.

This choice forecloses one feature (cheap recovery) to keep the guarantee on the other side (visible recovery). Future versions may add a notarized recovery mechanism if and when it can be defined without weakening the asymmetry.

§69C.9 No Registry, No Aggregator, No Discovery {#rationale-federation}

v0 is a federation specification. Every origin publishes for itself. Every reader fetches what it cares about. There is no central index, no aggregator endorsed by the protocol, no discovery layer that identifies which origins exist.

This omission is deliberate. A registry would become a centralization point: a thing to compromise, to capture, to gate. The protocol's trust root is DNS; the protocol's discovery is whatever the reader already knows about which origins matter. Building an aggregator on top of v0 is permitted and likely useful; specifying one in the protocol would add a different trust dependency that v0 does not need.

The cost is that readers must come to v0 with a list of origins. Bootstrapping a reader requires either operator configuration or external discovery. v0 accepts that cost.

§70C.10 Multi-domain Delegation Deferred {#rationale-multidomain}

A single legal entity often operates across many domains (shopify.com, myshopify.com, shop.app, customer-bound subdomains). It would be useful for one entity to publish one feed authoritative across all its domains. v0 does not support this.

Cross-origin delegation requires a hierarchy of keys and a delegation method that this protocol does not specify. Adding it to v0 would require committing to a delegation primitive (key parent, DID controller chains, or federated trust roots) that has known trade-offs and ongoing standardization work in adjacent communities. v0 declines to commit. An operator running N domains in v0 publishes N feeds.

A future version of this protocol may add cross-domain delegation when the delegation primitive is settled. Until then, the federation unit is the origin.

Appendix D: Implementation Notes {#appendix-implementation}

This appendix is non-normative.

§71D.1 Reader State Sketch

A minimal reader's state for a single origin can be represented as: