]> knownAs.dev (Authecity Systems LLC)

United States ops@knownas.dev

AI agents identity well-known URI DNS accountability Autonomous software agents increasingly act on the public internet with no name that a counterparty can check, no published party that answers for them, and no way to learn that an operator has withdrawn an agent. This document specifies the Agent Identity Document, a small JSON document served at a well-known URI on a hostname assigned to one agent, and the practices an identity provider follows when it hosts such names for operators who do not run their own domain. The document records what the provider knows to be true (the hostname, its service endpoints and the identity's lifecycle status) separately from what the operator asserts (a description, a contact, a homepage, a public key), and publishes the provider's dated, expiring checks on the operator rather than a single trust level. Lifecycle status is distinct from availability. A suspended identity publishes a deliberately minimal document. Every identity is held by an accountable person or organisation; an agent is never itself an account holder, and agents are never given authority over DNS. This document describes a practice in production at one provider. It is published so that the format can be reviewed, implemented by others and mapped onto related work, and it requests registration of a well-known URI suffix.

Introduction Websites solved a version of this problem years ago. A certificate says who a site is. A published security contact says where to report a problem. A revoked certificate stops being trusted everywhere at once. Software agents that call APIs, serve tools and receive webhooks on the open internet have none of this by default. They borrow their operator's credentials, run from addresses nobody can trace, and carry no name that another system can look up. Several efforts address parts of the gap. The Agent Name Service anchors an agent to a domain name whose control its operator proves, and lets the operator hold separately proven identities such as a decentralised identifier or a Legal Entity Identifier, sealed in a transparency log. The A2A Agent Card describes an agent's capabilities at /.well-known/agent-card.json. The Agent Discovery Protocol describes discovery metadata. Web Bot Auth lets an agent sign its requests with a key a verifier can fetch. Each of these assumes the operator already has something: a domain, a certificate, a key directory. Most people who build agents have none of them, and have no wish to run DNS or PKI. This document describes the missing layer for them: an identity hosted by a provider, created in one request, with the name, TLS, service endpoints and a public record supplied by the provider, and with a person or organisation accountable for it from the first minute. It also records four design positions that distinguish this format from related work:

1. Facts and assertions are kept apart. The provider publishes what it made true (name, endpoints, status) and labels what the operator merely claims.
2. Checks on the operator are itemised, dated and expiring. There is no level and no badge; each check says what was checked, how, by whom, when, and until when.
3. Lifecycle is not liveness. status records the operator's and provider's decisions about the identity. It never reports whether the agent is online.
4. A person stays accountable. An identity belongs to an account held by a natural person or legal entity. An agent acts under an account; it is never one. Agents never hold DNS or registrar authority.

Conventions 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 when, and only when, they appear in all capitals, as shown here. The terms "identity provider" and "provider" mean the party that assigns hostnames under a base domain it controls and serves Agent Identity Documents for them. "Operator" means the account holder responsible for an agent. "Relying party" means any system that reads an Agent Identity Document to decide how to treat an agent.

Model

Hostnames The provider controls a base domain. Each identity receives one identity hostname, a single DNS label under the base domain: . e.g. alice.knownas.dev ]]> Each service the identity offers receives a service hostname with the service label leading the base domain, so that every hostname is exactly one label below a name the provider can cover with a wildcard certificate: .api. an HTTP API .mcp. a Model Context Protocol endpoint .hooks. inbound webhooks ]]> The nested form api.<slug>.<base-domain> is NOT used: a wildcard certificate covers exactly one label, and the nested form would require a certificate per identity. A <slug> MUST be a valid DNS label : lowercase ASCII letters, digits and hyphens, not beginning or ending with a hyphen. This specification RECOMMENDS a minimum of 3 and a maximum of 63 characters. The provider MUST refuse slugs that collide with its own infrastructure names (such as api, mcp, hooks, www) and SHOULD refuse names that impersonate protected brands, including when a brand appears as a word inside a longer slug ("combosquatting"). Refusal lists are the provider's; this document requires only that they exist and are enforced before any DNS record is written.

Accounts and accountability An identity is created and held by an account. An account MUST be held by a natural person or a legal entity, and the provider MUST verify at minimum that the account holder controls the e-mail address used to create it. The provider MAY require a minimum age. An agent MAY manage identities through a credential scoped to an account, and MAY be the thing that creates an identity. An agent MUST NOT be able to create an account. This keeps a person or organisation answerable for every identity, however it was created.

Authority over DNS Agents MUST NOT receive credentials that can modify DNS. The provider's own provisioning component SHOULD be limited, by the DNS service's access control rather than by application code alone, to writing address records under the base domain and nothing else.

The Agent Identity Document

Location The Agent Identity Document is a JSON document served over HTTPS at the well-known URI /.well-known/agent-identity.json ]]> Implementations that predate this document serve the same content at /.well-known/agent.json; see . The document MUST be served with Content-Type: application/json, X-Content-Type-Options: nosniff and Access-Control-Allow-Origin: *, so that a browser-based relying party can read it. The same headers MUST be sent on a 404 response for an unallocated or deleted identity, so that a relying party can distinguish "no such identity" from a network failure. A relying party MUST treat a 404 at this URI as "no identity is published here", and MUST NOT treat it as evidence that the hostname was never allocated: a deleted identity's document is removed before its DNS records are, and a tombstoned name may still resolve to the provider for a time ().

Members The top level is a JSON object. Members fall into two classes, and the class decides how a relying party may use the value.

Provider-generated members (facts) These are projected by the provider from its own records at render time. They are never writable by the operator; a provider MUST ignore any attempt to set them.

version:

String. The schema version. This document defines "1". REQUIRED.

fqdn:

String. The identity hostname. REQUIRED.

status:

String. The lifecycle status (). REQUIRED.

endpoints:

Object mapping an endpoint name to an absolute https URL. REQUIRED when status is not suspended. The provider MUST include web (the identity hostname) and manifest (this document's URL). It MUST include one member per service the identity offers and that the provider routes to a live origin, named api, mcp or webhooks (note: the member is webhooks; its DNS label is hooks). A service hostname that is reserved but not yet routed MUST NOT be listed, so that a relying party can tell "this name is reserved" from "this service answers". Every value MUST begin with https://.

owner:

Object. The provider's published checks on the account holder and the account's standing (). OPTIONAL; absent when the identity is suspended, or when the account is not in good standing.

Operator-asserted members (claims) These are supplied by the operator. The provider validates their form and MUST NOT present them as verified unless a check described in covers them.

name:

String, at most 120 characters. A display name; defaults to the slug. REQUIRED when not suspended.

description:

String, at most 500 characters. OPTIONAL.

contact:

Object with an email member, at most 254 characters. OPTIONAL.

homepage:

String, an absolute https URL of at most 2048 characters. OPTIONAL.

public_key:

String, at most 4096 characters. An opaque key the operator publishes. This document assigns it no verification semantics; see . OPTIONAL.

metadata:

Object of at most 20 members. Keys MUST match ^[a-z0-9][a-z0-9_.-]*$ and be at most 40 characters; values MUST be strings of at most 200 characters. OPTIONAL.

All string values in the document MUST be free of C0 control characters other than those JSON itself requires to be escaped, and the provider MUST reject input that contains them. All URLs MUST use the https scheme; a provider MUST reject http, javascript, data and every other scheme. The provider MUST NOT dereference any URL an operator supplies.

Lifecycle status status takes one of the values below. It records decisions, not reachability.

Value	Meaning
pending	Created; provisioning has not started
provisioning	DNS records are being written
active	Provisioned, and in good standing
suspended	Withdrawn from public view by the operator or the provider; restorable
failed	Provisioning did not complete
archived	Retired by the operator; the name is kept
deleting	Removal in progress; the document disappears shortly

A relying party MUST NOT infer from active that the agent is reachable or running, and a provider MUST NOT change status because an agent's own endpoints went unreachable. An agent that sleeps at night keeps its name. Availability, if a relying party needs it, is measured by the relying party.

The suspended document When status is suspended, the provider MUST serve exactly: No endpoints, no description, no contact, no owner block. The namespace stays allocated and DNS stays in place, so the name cannot be taken by someone else, but nothing the operator wrote continues to be advertised. Suspension is therefore visible to every relying party within the document's cache lifetime, which the provider SHOULD keep short (the reference implementation uses 60 seconds). Suspension of an account MUST stop every credential under it and MUST suspend every identity it holds.

The owner block The owner member publishes the provider's checks on the account holder. There is deliberately no level, score or badge. Each check is its own record: Each member of verifications is an object with:

type:

String. This document defines email (the account holder controlled the sign-up mailbox), domain (the account holder controls a DNS name) and github (the account holder controls a GitHub account; see below). Further types, such as a check on a legal entity or a natural person, MAY be defined; a relying party MUST ignore types it does not understand.

verified_at:

String, an timestamp. REQUIRED.

value:

String. What was checked, where that is public (a domain name, a GitHub login). For email the address itself MUST NOT be published. OPTIONAL.

method, verifier:

Strings naming how and by whom the check was made. OPTIONAL.

expires_at:

String, an timestamp after which the check MUST be treated as stale. OPTIONAL; a check without it does not expire.

A github check says that the account holder authorized the provider, as the GitHub account named in value, at verified_at; method is oauth. The provider binds the account's numeric id, which GitHub keeps fixed, and publishes its login, which the holder can change: value is the login as the provider last read it, and a reader that resolves the login on GitHub MAY find it re-used by someone else between a rename and the provider's next read. expires_at bounds how stale the login can be, as a check is renewed only by re-reading the account by id. A provider publishes the login only when the account holder asked for the check; it MUST NOT publish an email address, name or account age read from GitHub. standing carries account_since (an full-date) and status, which is active whenever the block is present; a provider MUST omit the whole owner block rather than publish any other standing. Relying parties MUST interpret checks by type and date. The absence of a check is the absence of information and MUST NOT be presented as a negative finding; many legitimate operators cannot or will not complete deeper checks. Human-facing presentations SHOULD say what was checked ("owner controls the domain name acme.example") and SHOULD NOT say "verified" or "trusted" without an object.

Provider practices A document is only as good as the namespace behind it. A provider that serves Agent Identity Documents:

1. Writes explicit DNS records, never a wildcard. An unallocated name MUST return NXDOMAIN. A wildcard would make paypal.<base-domain> resolve.
2. Restricts certificate issuance for the base domain with CAA to the authority it uses, so that no one else can obtain a certificate for a hosted name.
3. Removes the document before the DNS records when an identity is deleted, and changes only the document on suspension. Everything the public can read goes through the document; only reachability goes through DNS, and DNS removal may be slow.
4. Tombstones released names for a cooling period (the reference implementation uses 30 days) during which no new account may take the name, while the previous holder may reclaim it at once. A leftover record during that period points only at the provider, which answers 404.
5. Keeps an append-only audit trail of every change to every identity, recording whether a person or an agent made it. The application that serves the API MUST NOT be able to alter or delete entries.
6. Enforces quotas on identities per account and per day, and on failure SHOULD suspend rather than bill.

Relationship to other work

A2A Agent Cards An A2A card at /.well-known/agent-card.json declares that a URL speaks A2A over a stated binding. A provider MUST NOT generate a card from the Agent Identity Document alone, because it does not know what the operator's server speaks. A provider MAY serve a card the operator declares, beside this document, and when it does the endpoints object SHOULD carry an agent_card member pointing to it. A suspended identity MUST serve no card.

Signed requests Where an agent signs its requests with HTTP Message Signatures as profiled by Web Bot Auth , the natural Signature-Agent value is the identity hostname as an https origin, and the key directory is served by the provider at /.well-known/http-message-signatures-directory on that origin. A verifier that resolves the signature then already knows where the Agent Identity Document is. When an identity is suspended, the provider SHOULD serve an empty key set at that directory with a success status, so that a verifier that re-fetches replaces its cached keys rather than retaining them; the reference implementation does so. The public_key member of this document is unrelated to that directory and carries no verification semantics of its own.

Hosted key directories describes the hosted (multi-tenant) key directory model, in which a provider serves key directories for many agent operators who keep their own private keys. A provider following this document in that model serves one directory per identity hostname (the first remedy in Section 4 of that document), and the Agent Identity Document on the same hostname is where the provider publishes, per agent, the operator verification practices that its Section 8 asks a hosted directory operator to make legible.

Signature Agent Cards defines the Signature Agent Card, in which a signature agent describes itself: its identity, purpose, rate expectations and keys. An Agent Identity Document differs in who speaks. Apart from the operator-asserted members, its statements (the lifecycle status and the checks in owner) are the provider's, about an operator who may hold no domain and no key. A provider MAY serve both on the identity hostname; neither replaces the other.

Client classification classifies a client by the strength of the evidence a server can verify about it. An Agent Identity Document is an input to such a classification, not a class: it carries no grade, only itemised, dated checks. A bare claim to an identity hostname is no stronger than any other unverified claim; a request signed with a key published in the identity's directory () gives a verifier evidence it can check; and on suspension the provider empties that directory, so the agent's claims fall back to unverified at the next fetch.

Domain-anchored identity ANS anchors every agent registration to one fully qualified domain name whose control the operator proves at registration time, and lets an operator hold Verified Identities (a did:web or did:key identifier, a Legal Entity Identifier or an ENS name), each proven by a control proof, sealed in a transparency log and linked to the operator's agents. An operator with a Legal Entity Identifier is therefore anchored to it directly, not through optional metadata. This document is complementary: a hosted identity is for operators who have no domain, and an operator who later proves control of a domain publishes that as a domain check in the owner block. Nothing here prevents a provider from also issuing ANS records. The lifecycles differ in one respect worth naming. ANS has a soft DEPRECATED state for a superseded version of an agent and the terminal states REVOKED and EXPIRED; it has no reversible suspension by the operator or the registry. The suspended status of this document () is reversible by design, and a relying party MUST NOT read it as terminal. A provider signature over the Agent Identity Document, and where the history of a document's changes would be recorded so that an unauthorised change is detectable afterwards, is under discussion with the ANS project and is not specified in this revision.

Compatibility The reference implementation has served this document at /.well-known/agent.json since 2026. That path was also used by A2A before its version 0.3.0 and has been proposed for other formats. Providers SHOULD serve this document at /.well-known/agent-identity.json and MAY continue to serve it at /.well-known/agent.json during a transition; a relying party SHOULD try the former first. A provider that continues to serve the old path SHOULD mark it with the Deprecation and Sunset header fields and a Link header field with the successor-version relation pointing at the new path; the reference implementation does so.

Security Considerations Operator-asserted members are claims. A relying party MUST NOT treat contact, homepage, description, public_key or metadata as verified because they are served over HTTPS from the provider's domain. Only the checks in owner are the provider's statements, and each is bounded by its dates. The provider is a trust anchor. A hosted identity is only as trustworthy as the provider's own controls: who may create accounts, how names are policed, how suspension is applied, and whether the audit trail can be altered. lists the minimum. Relying parties SHOULD form a view of a provider as they do of a certificate authority. Caching bounds suspension. A relying party that caches the document for longer than the provider's Cache-Control may keep trusting a suspended identity. Providers SHOULD keep the lifetime short; relying parties making consequential decisions SHOULD re-fetch at decision time. The document is a surface for injection. It is operator-controlled content served from a provider hostname. Length caps, control-character rejection and the https-only rule exist so that a document cannot carry a javascript: link or terminal escape into a relying party's logs or UI. Relying parties MUST still treat every string as untrusted data. Identity is not intent. A deliberately malicious operator can decline to identify an agent at all. This format changes the default for responsible operators and makes anonymous agent traffic stand out; it does not stop an attacker.

Privacy Considerations The document publishes: a hostname, endpoints, a status, the operator's chosen descriptive text, and the provider's checks. For an email check the address is not published, only that a check occurred and when. For a domain check the domain name is published, since control of a public name is itself public. For a github check the login is published, a pseudonym by GitHub's own design, and only because the account holder asked; nothing else read from GitHub is published. account_since reveals when the account was created and nothing else about the holder. A provider MUST let an account holder export and erase their data, and MUST remove an identity's document promptly on deletion; what the append-only audit trail retains is the provider's documented retention decision. Where an identity also signs its requests (), each signed request names the identity hostname, so receivers can recognise that agent's requests and correlate them across origins, whatever key it uses (see Section 7.1 of ). When the account holder is a natural person, a provider SHOULD tell them so before enabling signing, and SHOULD NOT publish the person's name in the document unless they put it in operator-asserted text themselves.

IANA Considerations IANA is requested to register the following well-known URI suffix in the "Well-Known URIs" registry :

URI suffix:

agent-identity.json

Change controller:

Authecity Systems LLC, until a standards body adopts the format

Specification document:

This document

Status:

provisional

Related information:

The JSON Schema and worked examples are maintained at the repository referenced in .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Informative References This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. The Deprecation HTTP response header field is used to signal to consumers of a resource (identified by a URI) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides further information about planned or existing deprecation. It may also provide ways in which client application developers can best manage deprecation. This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset. This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes. Cloudflare Google This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. Airlock Protocol Web Bot Auth authenticates automated clients to origins using HTTP Message Signatures, with verification keys published in a key directory at a well-known URI. Current drafts assume that each agent operator hosts its own key directory. A large and growing population of agents is operated by individuals and small organizations for whom hosting a directory is impractical, and whose legitimate traffic is otherwise indistinguishable from abusive automation. This document describes the hosted (multi-tenant) key directory deployment model, in which a registry operator publishes key directories on behalf of many independent agent operators while the operators retain exclusive custody of their private keys. It analyzes principal mapping, proof of key possession, freshness, and accountability in this model; reports interoperability observations from an independent implementation; and offers operational guidance for hosted directory operators and for verifiers. It is intended as input to the Web Bot Auth working group's operational and deployment guidance. Cloudflare Amazon Cloudflare This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using HTTP Message Signatures for bots publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry, the same namespace used by OAuth Client ID Metadata Documents, extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members. SKGO, IKT Support This document defines a conceptual framework for handling identity assertions in application-layer protocols. It introduces a model in which identity on the Internet is optional, but any asserted identity MUST be verifiable. It further defines a delegation mechanism that allows entities to authorize third-party infrastructure to act on their behalf in a verifiable and transparent manner. The goal is to reduce identity misrepresentation while fully preserving the ability for anonymous and pseudonymous interaction. This document does not define a protocol; it defines the principles that protocol specifications SHOULD follow when addressing agent identity. A concrete protocol implementation of these principles is defined in [SAIP]. GoDaddy OWASP DistributedApps.ai OWASP Cisco Systems Autonomous AI agents now invoke one another across organizational boundaries over protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A). A relying party has no interoperable way to bind a discoverable agent endpoint to the holder of its domain (optionally verified as a legal entity), a specific software release, and an auditable issuance history. This document specifies the architecture of Agent Name Service version 2 (ANS v2), an identity layer, anchored in DNS domains, that binds an agent endpoint to its domain holder, its release, and its history. ANS v2 composes systems the Internet already runs (the DNS with DNSSEC; the Web PKI, with DANE where operators publish it; and an append-only transparency log) and introduces no new root of trust. Every ANS v2 agent carries a versioned name rooted in a DNS domain that the registrant controls. When a registrant registers an agent, the Registration Authority (RA) checks the registrant's control of that domain, can issue an Identity Certificate that binds the versioned name to the agent's key, and submits a signed registration record to a Merkle-tree transparency log. Under the current specifications, a new version is a new registration and a new log entry, so a verifier can pin an agent to a specific release. Any third party can detect a rewritten log by computing, from the log's public tiles, a consistency proof between two of its signed checkpoints. For discovery, ANS v2 adopts the SVCB records and SvcParams of DNS for AI Discovery (DNS-AID) as its default format, and keeps an older TXT-based format only as an opt-in profile. Beyond those discovery records, ANS v2 specifies one DNS record, an "_ans-badge" TXT record that points to the agent's transparency-log entry; the log seals the fingerprint of the agent server's certificate, and operators can add DANE records. With these records, a verifier resolves an agent, authenticates its TLS endpoint, and confirms that the presented name, version, and key match a logged registration. This document also states a threat model covering agent impersonation, DNS spoofing, CA and Registration Authority compromise, version rollback, agent card tampering, and log rewriting, and names what each ANS check does and does not prevent. The reference registry, transparency log, verifier, JSON Schemas, SDKs, and CLI are open source. aipair.ai This document defines the Agent Discovery Protocol (ADP) v1.1, a layered protocol for discovering, verifying, and interacting with AI Agents on the Internet. ADP delegates DNS discovery to DNS-AID (SVCB records) and defines a Well-Known JSON metadata format, an Ed25519-based identity model, and the Agent Gateway Protocol (AGP) for real-time WebSocket messaging. The protocol is designed to be decentralized, standards-based, and incremental — clients escalate from DNS to HTTP to WebSocket only as needed. Agent Name Service project The Linux Foundation Authecity Systems LLC

Example documents An active identity with two services and a verified domain: The same identity, suspended: The hostnames are the reference implementation's real base domain rather than the reserved example domains of RFC 2606, because the document describes a practice in production there.

Changes since -01

• The source no longer declares a submission type: the document has no stream.
• The Agent Name Service is described per ANS-0: an agent is anchored to a domain name whose control is proven, and an operator may hold separately proven identities (a decentralised identifier, a Legal Entity Identifier, an ENS name). ANS-0 is cited beside the Internet-Draft, which has expired. The lifecycle difference (ANS has no reversible suspension) is named.
• New subsections under "Relationship to other work": "Hosted key directories" (draft-singh-webbotauth-hosted-directories), "Signature Agent Cards" (draft-meunier-webbotauth-registry) and "Client classification" (draft-jovancevic-vicdm).
• "Domain-anchored identity" notes that a provider signature over the document, and a record of its change history, are under discussion with the ANS project and not specified here.
• "Signed requests": on suspension the provider SHOULD serve an empty key set with a success status.
• "Compatibility": the old path SHOULD carry Deprecation, Sunset and a successor-version link.
• The owner block defines a third check type, github, and the privacy considerations say what it publishes.
• "Privacy Considerations": signed requests make an agent recognisable across origins; a natural person SHOULD be told before signing is enabled.

Changes since -00

• endpoints lists a service only while the provider routes it to a live origin; a reserved but unrouted service hostname is not listed (previously "one member per service hostname the identity owns").

Acknowledgements The design positions here were worked out as architecture decision records for the reference implementation between September and October 2026. The author thanks the people who tested early versions.