Network Working Group F. Alla Internet-Draft knownAs.dev (Authecity Systems LLC) Intended status: Informational 31 October 2026 Expires: 4 May 2027 The Agent Identity Document: A Hosted, Accountable Public Record for AI Agents draft-alla-agent-identity-document-02 Abstract 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. 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/. Alla Expires 4 May 2027 [Page 1] Internet-Draft Agent Identity Document October 2026 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 4 May 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Hostnames . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Accounts and accountability . . . . . . . . . . . . . . . 5 2.3. Authority over DNS . . . . . . . . . . . . . . . . . . . 5 3. The Agent Identity Document . . . . . . . . . . . . . . . . . 5 3.1. Location . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Members . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Provider-generated members (facts) . . . . . . . . . 6 3.2.2. Operator-asserted members (claims) . . . . . . . . . 6 3.3. Lifecycle status . . . . . . . . . . . . . . . . . . . . 7 3.4. The suspended document . . . . . . . . . . . . . . . . . 8 3.5. The owner block . . . . . . . . . . . . . . . . . . . . . 9 4. Provider practices . . . . . . . . . . . . . . . . . . . . . 10 5. Relationship to other work . . . . . . . . . . . . . . . . . 11 5.1. A2A Agent Cards . . . . . . . . . . . . . . . . . . . . . 11 5.2. Signed requests . . . . . . . . . . . . . . . . . . . . . 11 5.3. Hosted key directories . . . . . . . . . . . . . . . . . 11 5.4. Signature Agent Cards . . . . . . . . . . . . . . . . . . 12 5.5. Client classification . . . . . . . . . . . . . . . . . . 12 5.6. Domain-anchored identity . . . . . . . . . . . . . . . . 12 5.7. Compatibility . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 Alla Expires 4 May 2027 [Page 2] Internet-Draft Agent Identity Document October 2026 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Example documents . . . . . . . . . . . . . . . . . 17 Appendix B. Changes since -01 . . . . . . . . . . . . . . . . . 18 Appendix C. Changes since -00 . . . . . . . . . . . . . . . . . 18 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. 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 [ANS0] [I-D.narajala-courtney-ansv2] 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 [A2A] describes an agent's capabilities at /.well-known/agent- card.json. The Agent Discovery Protocol [I-D.pro-adp-agent-discovery] describes discovery metadata. Web Bot Auth [I-D.ietf-webbotauth-httpsig-protocol] 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. Alla Expires 4 May 2027 [Page 3] Internet-Draft Agent Identity Document October 2026 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. 1.1. 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 [RFC2119] [RFC8174] 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. 2. Model 2.1. 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.. is NOT used: a wildcard certificate covers exactly one label, and the nested form would require a certificate per identity. Alla Expires 4 May 2027 [Page 4] Internet-Draft Agent Identity Document October 2026 A MUST be a valid DNS label [RFC1035]: 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. 2.2. 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. 2.3. 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. 3. The Agent Identity Document 3.1. Location The Agent Identity Document is a JSON document [RFC8259] served over HTTPS [RFC9110] at the well-known URI [RFC8615] https:///.well-known/agent-identity.json Implementations that predate this document serve the same content at /.well-known/agent.json; see Section 5.7. 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. Alla Expires 4 May 2027 [Page 5] Internet-Draft Agent Identity Document October 2026 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 (Section 4). 3.2. 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. 3.2.1. 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 (Section 3.3). 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 (Section 3.5). OPTIONAL; absent when the identity is suspended, or when the account is not in good standing. 3.2.2. 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 Section 3.5 covers them. name: String, at most 120 characters. A display name; defaults to the slug. REQUIRED when not suspended. Alla Expires 4 May 2027 [Page 6] Internet-Draft Agent Identity Document October 2026 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 Section 5.2. 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. 3.3. Lifecycle status status takes one of the values below. It records decisions, not reachability. Alla Expires 4 May 2027 [Page 7] Internet-Draft Agent Identity Document October 2026 +==============+=======================================+ | 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 | +--------------+---------------------------------------+ Table 1 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. 3.4. The suspended document When status is suspended, the provider MUST serve exactly: { "version": "1", "status": "suspended", "fqdn": "alice.knownas.dev" } 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. Alla Expires 4 May 2027 [Page 8] Internet-Draft Agent Identity Document October 2026 3.5. 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: "owner": { "verifications": [ { "type": "email", "verified_at": "2026-09-21T14:02:11+00:00" }, { "type": "domain", "value": "acme.example", "method": "dns-txt", "verifier": "knownas.dev", "verified_at": "2026-10-02T09:00:00+00:00", "expires_at": "2026-11-01T09:00:00+00:00" } ], "standing": { "account_since": "2026-09-21", "status": "active" } } 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 [RFC3339] 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 [RFC3339] 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 Alla Expires 4 May 2027 [Page 9] Internet-Draft Agent Identity Document October 2026 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 [RFC3339] 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. 4. 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. resolve. 2. *Restricts certificate issuance* for the base domain with CAA [RFC8659] 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. Alla Expires 4 May 2027 [Page 10] Internet-Draft Agent Identity Document October 2026 6. *Enforces quotas* on identities per account and per day, and on failure SHOULD suspend rather than bill. 5. Relationship to other work 5.1. A2A Agent Cards An A2A card at /.well-known/agent-card.json [A2A] 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. 5.2. Signed requests Where an agent signs its requests with HTTP Message Signatures [RFC9421] as profiled by Web Bot Auth [I-D.ietf-webbotauth-httpsig-protocol], 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. 5.3. Hosted key directories [I-D.singh-webbotauth-hosted-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. Alla Expires 4 May 2027 [Page 11] Internet-Draft Agent Identity Document October 2026 5.4. Signature Agent Cards [I-D.meunier-webbotauth-registry] 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. 5.5. Client classification [I-D.jovancevic-vicdm] 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 (Section 5.2) 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. 5.6. Domain-anchored identity ANS [ANS0] [I-D.narajala-courtney-ansv2] 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 (Section 3.3) 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. Alla Expires 4 May 2027 [Page 12] Internet-Draft Agent Identity Document October 2026 5.7. 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 [RFC9745] and Sunset [RFC8594] header fields and a Link header field with the successor-version relation [RFC5829] pointing at the new path; the reference implementation does so. 6. 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. Section 4 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. Alla Expires 4 May 2027 [Page 13] Internet-Draft Agent Identity Document October 2026 7. 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 (Section 5.2), 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 [I-D.ietf-webbotauth-httpsig-protocol]). 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. 8. IANA Considerations IANA is requested to register the following well-known URI suffix in the "Well-Known URIs" registry [RFC8615]: 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 [KNOWNAS]. 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Alla Expires 4 May 2027 [Page 14] Internet-Draft Agent Identity Document October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 9.2. Informative References [A2A] The Linux Foundation, "Agent2Agent (A2A) Protocol Specification", 2025, . [ANS0] Agent Name Service project, "ANS-0: Identity (Agent Name Service specification, draft v1.0, version 0.2.0)", 20 August 2026, . Alla Expires 4 May 2027 [Page 15] Internet-Draft Agent Identity Document October 2026 [I-D.ietf-webbotauth-httpsig-protocol] Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-ietf-webbotauth-httpsig-protocol-01, 29 October 2026, . [I-D.jovancevic-vicdm] Jovancevic, S., "Verifiable Identity Claims and Delegation Model (VICDM)", Work in Progress, Internet-Draft, draft- jovancevic-vicdm-10, 28 August 2026, . [I-D.meunier-webbotauth-registry] Guerreiro, M., Kirazci, U., and T. Meunier, "Registry and Signature Agent card for Web bot auth", Work in Progress, Internet-Draft, draft-meunier-webbotauth-registry-04, 27 October 2026, . [I-D.narajala-courtney-ansv2] Courtney, S., Narajala, V. S., Huang, K., Habler, I., and A. Sheriff, "Agent Name Service v2 (ANS): A Domain- Anchored Identity Layer for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-narajala-courtney- ansv2-02, 26 October 2026, . [I-D.pro-adp-agent-discovery] Lian, B., "Agent Discovery Protocol (ADP) v1.1 -- Well- Known Metadata and Interaction Layer", Work in Progress, Internet-Draft, draft-pro-adp-agent-discovery-02, 23 June 2026, . [I-D.singh-webbotauth-hosted-directories] Singh, S., "Hosted Key Directories for Web Bot Auth", Work in Progress, Internet-Draft, draft-singh-webbotauth- hosted-directories-00, 19 July 2026, . [KNOWNAS] Authecity Systems LLC, "knownAs.dev: internet identity for AI agents (reference implementation)", 2026, . Alla Expires 4 May 2027 [Page 16] Internet-Draft Agent Identity Document October 2026 [RFC5829] Brown, A., Clemm, G., and J. Reschke, Ed., "Link Relation Types for Simple Version Navigation between Web Resources", RFC 5829, DOI 10.17487/RFC5829, April 2010, . [RFC8594] Wilde, E., "The Sunset HTTP Header Field", RFC 8594, DOI 10.17487/RFC8594, May 2019, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9745] Dalal, S. and E. Wilde, "The Deprecation HTTP Response Header Field", RFC 9745, DOI 10.17487/RFC9745, March 2025, . Appendix A. Example documents An active identity with two services and a verified domain: { "version": "1", "name": "Ada", "status": "active", "fqdn": "ada.knownas.dev", "endpoints": { "web": "https://ada.knownas.dev", "manifest": "https://ada.knownas.dev/.well-known/agent-identity.json", "api": "https://ada.api.knownas.dev", "mcp": "https://ada.mcp.knownas.dev" }, "description": "Answers questions about the Acme product catalogue.", "owner": { "verifications": [ { "type": "email", "verified_at": "2026-09-21T14:02:11+00:00" }, { "type": "domain", "value": "acme.example", "method": "dns-txt", "verifier": "knownas.dev", "verified_at": "2026-10-02T09:00:00+00:00", "expires_at": "2026-11-01T09:00:00+00:00" } ], "standing": { "account_since": "2026-09-21", "status": "active" } }, "contact": { "email": "agents@acme.example" }, "homepage": "https://acme.example/ada", "metadata": { "framework": "langgraph" } } Alla Expires 4 May 2027 [Page 17] Internet-Draft Agent Identity Document October 2026 The same identity, suspended: { "version": "1", "status": "suspended", "fqdn": "ada.knownas.dev" } 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. Appendix B. 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. Appendix C. 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"). Alla Expires 4 May 2027 [Page 18] Internet-Draft Agent Identity Document October 2026 Appendix D. Acknowledgements The design positions here were worked out as architecture decision records for the reference implementation [KNOWNAS] between September and October 2026. The author thanks the people who tested early versions. Author's Address Femi Alla knownAs.dev (Authecity Systems LLC) United States Email: ops@knownas.dev Alla Expires 4 May 2027 [Page 19]