DNSOP A. Ferro Internet-Draft ApertoID Intended status: Standards Track 10 August 2026 Expires: 11 February 2027 ApertoID: DNS-Based Agent Identity Declaration Protocol draft-ferro-dnsop-apertoid-02 Abstract This document defines ApertoID, a DNS-based protocol that enables domain owners to declare authorized AI agents acting on their behalf, publish cryptographic keys for agent identity verification, and specify enforcement policies for unauthorized agents. ApertoID uses existing DNS TXT records under the "_apertoid" underscore-scoped domain name to provide a decentralized, standards-based mechanism for AI agent identity declaration and verification. ApertoID defines two record types: a Policy Record analogous to DMARC that specifies domain-level enforcement behavior, and Agent Declaration Records analogous to DKIM key records that bind agent endpoints to Ed25519 public keys with mandatory expiration. A companion document [APERTOID-SIG] defines the HTTP request signing mechanism that enables agents to cryptographically prove their identity on each request. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Ferro Expires 11 February 2027 [Page 1] Internet-Draft ApertoID August 2026 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. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Comparison with Existing Approaches . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. When ApertoID Applies . . . . . . . . . . . . . . . . . . 6 3.2. When ApertoID Does Not Apply . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 6. Record Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. ABNF Definition . . . . . . . . . . . . . . . . . . . . . 9 7. Policy Record . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Record Location . . . . . . . . . . . . . . . . . . . . . 11 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Policy Tags . . . . . . . . . . . . . . . . . . . . . . . 12 8. Agent Declaration Record . . . . . . . . . . . . . . . . . . 13 8.1. Record Location . . . . . . . . . . . . . . . . . . . . . 13 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. Agent Declaration Tags . . . . . . . . . . . . . . . . . 13 8.4. Record Size Considerations . . . . . . . . . . . . . . . 15 9. Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Key Publication . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Ed25519 Key Format . . . . . . . . . . . . . . . . . . . 16 10.2. Key Lifecycle . . . . . . . . . . . . . . . . . . . . . 16 11. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Immediate Revocation . . . . . . . . . . . . . . . . . . 17 11.2. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 17 12. Verification Procedure . . . . . . . . . . . . . . . . . . . 18 12.1. Verification Inputs . . . . . . . . . . . . . . . . . . 18 12.2. Verification Algorithm . . . . . . . . . . . . . . . . . 18 12.3. Result Values . . . . . . . . . . . . . . . . . . . . . 19 12.4. URL Matching Rules . . . . . . . . . . . . . . . . . . . 20 13. Operational Considerations . . . . . . . . . . . . . . . . . 20 13.1. Deployment Guidance . . . . . . . . . . . . . . . . . . 20 13.2. CDN and Reverse Proxy Interaction . . . . . . . . . . . 20 13.3. TTL Recommendations . . . . . . . . . . . . . . . . . . 21 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14.1. Authorization vs. Identity Verification . . . . . . . . 21 Ferro Expires 11 February 2027 [Page 2] Internet-Draft ApertoID August 2026 14.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.3. Key Compromise . . . . . . . . . . . . . . . . . . . . . 22 14.4. Delegation Abuse . . . . . . . . . . . . . . . . . . . . 22 14.5. Agent Enumeration . . . . . . . . . . . . . . . . . . . 22 14.6. DNS Amplification . . . . . . . . . . . . . . . . . . . 22 14.7. Threat Model and Non-Goals . . . . . . . . . . . . . . . 22 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 16.1. Underscore-Scoped Domain Name Registration . . . . . . . 24 16.2. ApertoID Agent Type Registry . . . . . . . . . . . . . . 25 16.3. ApertoID Key Type Registry . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 17.1. Normative References . . . . . . . . . . . . . . . . . . 25 17.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Complete Examples . . . . . . . . . . . . . . . . . 28 A.1. Basic Deployment . . . . . . . . . . . . . . . . . . . . 28 A.2. Third-Party Delegation . . . . . . . . . . . . . . . . . 28 A.3. Emergency Revocation and Key Rotation . . . . . . . . . . 29 Appendix B. Integration with Application-Layer Protocols . . . . 29 Appendix C. Changes from -01 . . . . . . . . . . . . . . . . . . 29 Appendix D. Changes from -00 . . . . . . . . . . . . . . . . . . 31 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction The rapid proliferation of AI agents acting autonomously on the internet has created a fundamental identity gap. When an AI agent claims to act on behalf of a domain (e.g., "I represent example.com"), no standard protocol exists to verify this claim. The current internet infrastructure — designed for human users operating browsers — provides no mechanism to distinguish legitimate AI agents from impersonators, to verify which domain authorized an agent, or to enforce policies when verification fails. This gap is not hypothetical. Agents already act on behalf of domains in interactions with services that have no way to confirm the claim, and the volume of such interactions is growing rather than shrinking. ApertoID addresses the narrow, verifiable question at the root of the problem: has the domain actually declared this agent as acting on its behalf? Ferro Expires 11 February 2027 [Page 3] Internet-Draft ApertoID August 2026 Email faced an analogous identity problem two decades ago: any server could send email claiming any sender address. The solution was a layered DNS-based authentication framework: SPF [RFC7208] declared authorized sending IPs, DKIM [RFC6376] provided cryptographic signatures, and DMARC [RFC9989] unified them with enforcement policies. ApertoID applies the same proven architectural pattern to AI agent identity. ApertoID is designed to complement, not replace, existing agent discovery mechanisms such as DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] and agent authentication frameworks such as [I-D.klrc-aiagent-auth]. It also complements application- layer agent protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol. DNS-AID provides discovery ("find the agents for this domain"); [I-D.klrc-aiagent-auth] provides a composable authentication framework; ApertoID provides DNS-based authorization and identity declaration ("verify that this agent is genuinely authorized by this domain"). The ApertoID protocol builds on the same DNS infrastructure philosophy as the ApertoDNS Protocol [I-D.ferro-dnsop-apertodns-protocol], which modernized Dynamic DNS updates using well-known URIs and RESTful patterns. Both protocols demonstrate that DNS infrastructure can be extended through lightweight, deployable mechanisms without requiring changes to DNS servers or resolvers. Additionally, the EU AI Act (Regulation 2024/1689), Article 50, requires AI systems interacting with natural persons to identify themselves as AI in a machine-readable format, effective August 2, 2026. ApertoID's optional "type" field provides a DNS-based mechanism to satisfy this requirement. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Comparison with Existing Approaches Several related efforts address aspects of AI agent identity and discovery. ApertoID is designed to complement these efforts, not replace them: DANE (RFC 6698) DANE [RFC6698] authenticates TLS certificates for Ferro Expires 11 February 2027 [Page 4] Internet-Draft ApertoID August 2026 servers via TLSA DNS records. However, DANE binds identity to a TLS endpoint (server), not to an agent. Multiple agents may share a server, and a single agent may operate across multiple servers. ApertoID binds identity to the agent itself, independent of the underlying TLS infrastructure. DNS-AID (draft-mozleywilliams-dnsop-dnsaid) DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] provides DNS-based discovery of agents associated with a domain, primarily using SVCB records (and optionally DNSSEC and DANE TLSA records for endpoint security). It answers "what agents does this domain have?" Its cryptographic material authenticates connection endpoints rather than binding an identity to a specific agent, and it does not define domain-level enforcement policies. ApertoID answers "is this specific agent genuinely authorized by this domain?" and pairs that with a policy record. The two are complementary. AI Agent Authentication and Authorization (draft-klrc-aiagent- auth) This work [I-D.klrc-aiagent-auth] describes best practices for authenticating and authorizing AI agent interactions by composing existing standards such as SPIFFE, WIMSE, and OAuth 2.0. It operates at the layer of credentials and authorization flows between agents and services. ApertoID operates at a different layer: a DNS-published, domain-level declaration of which agents a domain authorizes, verifiable by a party starting from only the domain name. A token-based framework of this kind can use an ApertoID declaration as a domain-level anchor for the agents it authenticates. HTTP Message Signatures (RFC 9421) HTTP Message Signatures [RFC9421] provide a general-purpose HTTP signing framework. ApertoID- Signature (defined in the companion document [APERTOID-SIG]) is a deliberately simplified, single-purpose mechanism optimized for AI agent identity verification with Ed25519 only. It is designed to be implementable in minimal code without requiring the full complexity of RFC 9421's component identifiers and algorithm negotiation. WIMSE workload identity (draft-ietf-wimse-arch) The WIMSE architecture [I-D.ietf-wimse-arch] describes workload credentials -- the Workload Identity Token and the Workload Identity Certificate, defined in the companion WIMSE service-to-service protocol -- whose identifiers are scoped within a trust domain; the architecture states that the protocol for obtaining credentials varies with deployment. The primary difference from ApertoID is how trust is established between the parties, not whether the parties are in the same organization. In WIMSE, a relying party validates a credential using the trust anchors and Ferro Expires 11 February 2027 [Page 5] Internet-Draft ApertoID August 2026 issuer configuration it holds for the credential's trust domain, obtained through a secure mechanism. In ApertoID, a relying party starts from nothing but the domain name and reads the domain's public DNS declaration, with no issuance step and no prior configuration on either side. The two are complementary: a workload may hold a WIMSE credential for its identity within a trust domain and, separately, be publicly declared by a domain via ApertoID so that parties which share no trust configuration with that domain can still verify the declaration. HTTPS well-known trust discovery (draft-schwenkschuster-wimse- trust-domain-discovery) Trust-discovery mechanisms that derive a location from a domain name and retrieve trust material over HTTPS -- the WIMSE Trust Domain Discovery work [I-D.schwenkschuster-wimse-trust-domain-discovery] is the current example, retrieving a metadata document from a well-known URL under the trust domain name and then a trust bundle from an endpoint that the metadata names -- require the domain owner to serve HTTPS content for that name and validate the TLS server certificate against the Web PKI. ApertoID requires only DNS records and roots in DNS directly. The trade-off cuts both ways: retrieving trust material over HTTPS is not subject to the size limits of DNS TXT records and does not depend on DNS caching behavior, whereas DNS publication requires no server to be operated and reuses existing zone administration. Neither is strictly better; they root trust in different infrastructures (the Web PKI versus DNS). 3. Applicability This section states where ApertoID is intended to be used, and where it is not, so that a reader can decide early whether it fits their deployment. 3.1. When ApertoID Applies The design target is agent identity on the open web: a domain publicly declaring which agents act on its behalf, verified by parties that have no prior relationship with that domain. ApertoID fits when all of the following hold: * The relying party and the declaring domain have no pre-existing federation, shared authority, or out-of-band trust configuration; the relying party must be able to start from nothing but the domain name. Ferro Expires 11 February 2027 [Page 6] Internet-Draft ApertoID August 2026 * Neither party operates workload-identity infrastructure -- no token issuance service, no authorization server, no SPIFFE or WIMSE deployment -- and does not wish to adopt one for this purpose. * The declaring domain can publish DNS records and nothing else: no HTTPS endpoint, no running server, and no hosted resource is required for the protocol itself. (An Agent Declaration Record's "url" names the agent's own endpoint; it is a value compared during verification, not infrastructure the declaring domain must operate for ApertoID.) * Verification must be possible from a DNS query plus a local signature check, with no call to any authorization service or other authority. This is the same shape SPF, DKIM, and DMARC took for email: publishing an ApertoID declaration requires control of the domain's DNS and nothing more. (Full cryptographic identity verification additionally requires the agent to sign each request, per the companion document [APERTOID-SIG]; that is a capability of the agent, not additional infrastructure the declaring domain must operate.) Worked examples of the records involved appear in Appendix A, and a staged deployment progression in Section 13.1. 3.2. When ApertoID Does Not Apply ApertoID is not the right tool in the following cases: * Where the parties already share trust configuration through an issuance-based system -- SPIFFE, OAuth authorization servers, or WIMSE workload identity [I-D.ietf-wimse-arch] -- that system establishes trust directly between issuer and relying party and can carry richer context than a DNS declaration. ApertoID targets the case where no such shared configuration exists and a relying party must start from nothing but the domain name. * When per-action authorization is needed -- what a given agent may do, rather than who it is -- ApertoID provides identity and attribution only. An authorization layer must sit above it; see the authorization-versus-identity boundary in Section 14.1. * When full message integrity or header integrity is required, TLS and HTTP Message Signatures [RFC9421] are the appropriate mechanisms; ApertoID-Signature binds identity to a specific action and payload, not to the whole message. Ferro Expires 11 February 2027 [Page 7] Internet-Draft ApertoID August 2026 * Where DNS is not an acceptable trust anchor for the deployment. Without DNSSEC, the assurance ApertoID provides is authorization- level -- comparable to SPF and DKIM -- rather than cryptographic proof of the resolution path; see Section 14.2. 4. Terminology Agent A software system that acts autonomously on behalf of a domain, typically an AI-powered service that interacts with external systems via HTTP-based protocols (e.g., MCP, A2A, REST APIs). Declaring Domain The domain that publishes ApertoID DNS records to declare its authorized agents. Analogous to the "domain owner" in SPF/DKIM/DMARC. Agent Selector A label that uniquely identifies an agent within a declaring domain. Used as the leftmost label in the agent declaration record name (e.g., "leadhunter" in "leadhunter._apertoid.example.com"). Analogous to the DKIM selector. Verifier An entity that queries ApertoID DNS records to determine whether an agent is authorized by the claimed domain and, optionally, to verify the agent's cryptographic identity. Policy Record A DNS TXT record at "_apertoid." that specifies the domain's ApertoID enforcement policy. Analogous to a DMARC record. Agent Declaration Record A DNS TXT record at "._apertoid." that declares an authorized agent with its endpoint URL, public key, and metadata. Analogous to a DKIM key record. 5. Protocol Overview ApertoID operates in two layers, both implemented as DNS TXT records under the "_apertoid" underscore-scoped name: 1. *Policy Layer:* A single record at "_apertoid." declares that the domain participates in ApertoID and specifies the enforcement policy (reject, warn, or none) for agents that fail verification. This is analogous to DMARC. Ferro Expires 11 February 2027 [Page 8] Internet-Draft ApertoID August 2026 2. *Identity Layer:* One record per authorized agent at "._apertoid." declares the agent's endpoint URL, Ed25519 public key, type classification, and expiration. This is analogous to DKIM key records. A companion document [APERTOID-SIG] defines a third layer: the ApertoID-Signature HTTP header that agents attach to outgoing requests to prove their identity cryptographically. This document focuses exclusively on the DNS records and their semantics. The verification flow proceeds as follows: 1. An agent makes a request claiming to represent a domain (e.g., via the ApertoID-Signature header or an out-of-band claim). 2. The verifier queries "_apertoid." to obtain the policy record. 3. The verifier queries "._apertoid." to obtain the agent declaration record. 4. The verifier checks that the agent's endpoint URL matches the declared URL, that the public key has not expired, and optionally that the agent's presented key matches the declared key. 5. If verification fails, the verifier applies the enforcement policy specified in the policy record. Note: Without the cryptographic signature mechanism defined in [APERTOID-SIG], ApertoID provides authorization-level assurance only — the domain has declared which agents are authorized, but agents cannot actively prove their identity on each request. This is analogous to how SPF provides authorization (which IPs may send) without DKIM's cryptographic proof. Full identity verification requires both this document and [APERTOID-SIG]. 6. Record Syntax Both ApertoID record types use the same syntax: a DNS TXT record containing semicolon-separated tag-value pairs. This section defines the formal grammar using ABNF [RFC5234]. 6.1. ABNF Definition Ferro Expires 11 February 2027 [Page 9] Internet-Draft ApertoID August 2026 apertoid-record = version-tag *( *WSP ";" *WSP tag-value ) version-tag = "v" "=" "APERTOID1" tag-value = tag "=" value tag = 1*ALPHA value = 1*value-char value-char = %x21-3A / %x3C-7E ; VCHAR excluding ";" (%x3B) WSP = SP / HTAB ; Policy Record specific tags policy-tag = "p" "=" ( "reject" / "warn" / "none" ) rua-tag = "rua" "=" "mailto:" email-address email-address = local-part "@" domain-name ; Mailbox syntax, see RFC 5321 Section 4.1.2 local-part = dot-atom dot-atom = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" ; Agent Declaration Record specific tags url-tag = "url" "=" https-uri keytype-tag = "k" "=" "ed25519" pubkey-tag = "pk" "=" base64-ed25519 exp-tag = "exp" "=" 1*DIGIT type-tag = "type" "=" ( "ai" / "human" / "hybrid" ) include-tag = "include" "=" domain-name status-tag = "status" "=" "revoked" prev-tag = "prev" "=" "sig:" base64-ed25519-sig ; Value format definitions base64-ed25519 = 43*43(BASE64CHAR) ; 32 bytes, unpadded = 43 chars base64-ed25519-sig = 86*86(BASE64CHAR) ; 64 bytes, unpadded = 86 chars BASE64CHAR = ALPHA / DIGIT / "+" / "/" https-uri = "https://" 1*URI-CHAR URI-CHAR = ALPHA / DIGIT / "-" / "." / "_" / "~" / ":" / "/" / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "=" / "%" ; ";" (the tag separator) is NOT permitted; any ";" ; in a URL MUST be percent-encoded as "%3B". "%" ; enables percent-encoding per RFC 3986. domain-name = label *("." label) label = ldh-label / underscore-label ldh-label = alnum *(alnum / "-") ; RFC 1035 preferred; LDH, ; leading digit allowed, no ; leading/trailing hyphen underscore-label = "_" 1*(alnum / "-") ; RFC 8552 underscore-scoped alnum = ALPHA / DIGIT Ferro Expires 11 February 2027 [Page 10] Internet-Draft ApertoID August 2026 Tags are case-insensitive. Values are case-sensitive unless otherwise specified. Any amount of whitespace (WSP) on either side of a ";" separator is OPTIONAL and MUST be ignored by parsers. The ";" character is reserved as the tag-value separator and MUST NOT appear literally within a value; a ";" that is part of a value (for example a matrix or path parameter in a URL) MUST be percent-encoded as "%3B" per [RFC3986]. The "%" character is permitted in "url" values to allow percent-encoding. Unknown tags MUST be ignored by verifiers to allow forward compatibility. The email-address production follows the Mailbox / Local-part syntax defined in [RFC5321] Section 4.1.2; the "local-part" here uses the dot-atom form and, unlike a bare 1*VCHAR, does not include "@", removing any ambiguity in locating the domain. A "label" is either an ordinary letter-digit-hyphen label following the preferred name syntax of [RFC1035], or an underscore-scoped label beginning with "_" as defined in [RFC8552]; the latter is REQUIRED so that "include" targets such as "agent1._apertoid.salesforce.com", which contain the "_apertoid" node name, are grammatical. A tag defined by this specification MUST NOT appear more than once in a single record. If a verifier encounters a duplicated known tag (for example two "url" tags or two "p" tags), it MUST treat the record as malformed and return "permerror" (see Section 12), rather than choosing one occurrence. This matches the handling of duplicate tags in DKIM [RFC6376] and DMARC [RFC9989]. This rule applies only to the tags defined here; because unknown tags are ignored for forward compatibility, a repeated unknown tag does not by itself invalidate the record. For the purpose of this rule, "known tag" is absolute: it means any of the tags defined by this specification ("v", "p", "rua", "url", "k", "pk", "exp", "type", "include", "status", "prev"), regardless of the record type implied by the DNS name. This duplicate-detection check is purely syntactic and is applied before, and independently of, the record-type-relative semantic interpretation described in Section 7.1: a tag that is semantically irrelevant at a given record type (and therefore ignored as if unknown when interpreting the record) is nonetheless a duplicated known tag for syntax purposes if it appears more than once. 7. Policy Record 7.1. Record Location The ApertoID Policy Record is a DNS TXT record published at: _apertoid. Ferro Expires 11 February 2027 [Page 11] Internet-Draft ApertoID August 2026 The underscore-scoped name "_apertoid" MUST be registered per [RFC8552]. A domain MUST NOT publish more than one ApertoID Policy Record. If multiple TXT records exist at this name, the verifier MUST select the record whose first tag is a valid version tag with the value "APERTOID1" (that is, the record parses as an ApertoID record per Section 6.1) and discard the others. This selection MUST be performed on the parsed version tag, NOT by a literal byte-prefix match on the string "v=APERTOID1": because tag names are case- insensitive and optional whitespace may precede the first tag, a record beginning "V=APERTOID1" or " v=APERTOID1" is equally valid and MUST NOT be rejected merely because its leading bytes differ. The two ApertoID record types are distinguished solely by the DNS name at which they are published, NOT by their content: a Policy Record is the record at "_apertoid.", and an Agent Declaration Record is a record at "._apertoid.". Both begin with "v=APERTOID1" and share the same tag-value grammar. A verifier MUST determine which record type it is processing from the query name it used, and MUST NOT attempt to infer the record type from the presence or absence of particular tags. Policy tags ("p", "rua") appearing at an agent name, or agent tags ("url", "k", "pk", etc.) appearing at the policy name, MUST be ignored as unknown tags for that record type in accordance with the forward-compatibility rule of Section 6.1. This "ignore as unknown for that type" rule is a semantic-interpretation rule and is distinct from the purely syntactic duplicate-tag rule of Section 6.1: a tag ignored here because it is irrelevant at this record type is still a "known tag" for duplicate detection, so a record that repeats any such tag remains malformed ("permerror"). 7.2. Example _apertoid.example.com. 3600 IN TXT "v=APERTOID1; p=reject; rua=mailto:apertoid@example.com" 7.3. Policy Tags v (REQUIRED) Protocol version. MUST be "APERTOID1" for this specification. This tag MUST be the first tag in the record. p (REQUIRED) Enforcement policy for agents that fail verification. Valid values: reject The verifier SHOULD reject requests from agents that fail verification. warn The verifier SHOULD accept but flag requests from agents that fail verification. Ferro Expires 11 February 2027 [Page 12] Internet-Draft ApertoID August 2026 none The verifier SHOULD take no specific action on failure. Used for monitoring and gradual deployment. Domain owners SHOULD deploy with "p=none" initially and progress to "p=reject" after confirming that legitimate agents pass verification. rua (OPTIONAL) Reporting URI for aggregate verification reports. MUST be a "mailto:" URI. Verifiers that support reporting SHOULD send periodic aggregate reports to this address. The format of aggregate reports is outside the scope of this document. 8. Agent Declaration Record 8.1. Record Location Each authorized agent is declared in a separate DNS TXT record at: ._apertoid. The is a label chosen by the domain owner to identify the agent. Selectors MUST conform to the syntax of a DNS label: 1-63 characters, consisting of alphanumeric characters and hyphens, not starting or ending with a hyphen. Selectors are case-insensitive. 8.2. Example leadhunter._apertoid.example.com. 3600 IN TXT "v=APERTOID1; url=https://agent.example.com/mcp; k=ed25519; pk=2TmyMjizLUEeS0F9GJvGedF4syZFYvrWl+oFHv56VSY; type=ai; exp=1759276800" Note: The record above is shown on multiple lines for readability. In practice, it is a single TXT record string. If the record exceeds 255 bytes, it MUST be split into multiple character-strings within a single TXT RDATA as specified in [RFC1035] Section 3.3.14. 8.3. Agent Declaration Tags v (REQUIRED) Protocol version. MUST be "APERTOID1". MUST be the first tag. url (REQUIRED in non-revocation records, mutually exclusive with include) The canonical endpoint URL of the authorized agent. MUST Ferro Expires 11 February 2027 [Page 13] Internet-Draft ApertoID August 2026 be an HTTPS URI. Required in every Agent Declaration Record except a revocation record (see "status" below and Section 9); a record MUST contain either "url" or "include" unless it carries "status=revoked". The verifier compares this URL against the agent's actual endpoint. URL matching is performed as specified in Section 12.4. k (RECOMMENDED) Key type. MUST be "ed25519" for this specification. Additional key types MAY be registered via the ApertoID Key Type Registry (Section 16.3). If "k" is present, the "pk" tag MUST also be present, and the "exp" tag MUST also be present. The dependency is one-directional: "k" requires "pk", but "pk" MAY appear without "k" (see below). pk (RECOMMENDED) The agent's raw 32-byte Ed25519 public key, encoded as unpadded Base64 per [RFC4648] Section 4 (i.e., without the trailing "=" padding). For Ed25519, this is exactly 43 characters (32 bytes encoded unpadded). The value is the raw public key, NOT a DER SubjectPublicKeyInfo (SPKI) wrapping. This key is used by verifiers to authenticate the agent's identity via the ApertoID- Signature mechanism defined in [APERTOID-SIG]. A "pk" tag MAY be present without a "k" tag; in that case the key type defaults to "ed25519", which is the only type defined by this specification. A record MAY legitimately carry neither "k" nor "pk": for example, the "url"-only deployment stage described in Section 13.1, in which the agent is authorized by URL but publishes no cryptographic key and consequently has no "exp" (such a record does not expire at the DNS layer), or a revocation record (see Section 11), which carries only "v" and "status=revoked". exp (REQUIRED when k is present) Key expiration as a Unix timestamp (seconds since 1970-01-01T00:00:00Z). Verifiers MUST reject keys whose expiration has passed. Domain owners SHOULD set expiration to no more than 90 days in the future and rotate keys before expiration. type (OPTIONAL) Agent type classification. Valid values are registered in the ApertoID Agent Type Registry (Section 16.2). Initial values: ai Autonomous AI agent. human Human-operated tool or interface. hybrid AI-assisted system with human oversight. This field supports compliance with regulations that require AI systems to identify themselves, such as EU AI Act Article 50(2). Ferro Expires 11 February 2027 [Page 14] Internet-Draft ApertoID August 2026 include (OPTIONAL, mutually exclusive with url) Delegation to a third-party agent declaration. The value is a fully qualified domain name pointing to an Agent Declaration Record published by the third party. See Section 9. status (OPTIONAL) Agent status. If set to "revoked", verifiers MUST treat this agent as unauthorized regardless of other fields. A record carrying "status=revoked" is a revocation record: it MUST contain "v" and "status=revoked", and is exempt from the "url"- or-"include" requirement (it need not, and typically does not, carry either). See Section 11. prev (OPTIONAL) Key rotation continuity proof. Contains a signature of the new public key made with the old private key, prefixed by "sig:". See Section 11.2. 8.4. Record Size Considerations A typical Agent Declaration Record with all recommended fields is approximately 170 bytes, fitting comfortably within a single 255-byte TXT character-string and well within the practical UDP DNS response size limit. Each agent has its own record at a distinct DNS name, so the number of agents per domain is not constrained by record size. 9. Delegation When a domain uses third-party AI agent services, the domain owner delegates agent authorization by publishing an Agent Declaration Record with an "include" tag pointing to the third party's own ApertoID record. ; Domain delegates to a Salesforce agent salesforce._apertoid.example.com. 3600 IN TXT "v=APERTOID1; include=agent1._apertoid.salesforce.com" ; Salesforce publishes the actual agent declaration agent1._apertoid.salesforce.com. 3600 IN TXT "v=APERTOID1; url=https://agents.salesforce.com/crm; k=ed25519; pk=Hr4Z0cjlqCxFhRYKi2uEOkznCCXMELANsOif7KRkhJk; type=ai; exp=1759276800" Verifiers MUST follow "include" references to resolve the final Agent Declaration Record. To prevent abuse and excessive DNS lookups: * A verifier MUST follow at most TWO "include" delegations: the original Agent Declaration Record plus at most two delegated target records. A chain that would require a third "include" hop MUST be treated as a verification failure (result "temperror"). Ferro Expires 11 February 2027 [Page 15] Internet-Draft ApertoID August 2026 * A verifier MUST NOT follow more than 10 "include" references in total per verification attempt. * Circular "include" references MUST be detected and treated as a verification failure. * The revocation check of Section 11.1 MUST be applied to EACH record resolved through an "include" reference, not only the original Agent Declaration Record. If any record in the delegation chain carries "status=revoked", the verifier MUST treat the agent as unauthorized (result "revoked") and MUST NOT continue following the chain. The "include" tag is mutually exclusive with the "url" tag: a record MUST NOT contain both. Every Agent Declaration Record that is NOT a revocation record MUST contain either "url" or "include". A revocation record (a record containing "status=revoked", see Section 11) is exempt from this requirement: it MUST contain "v" and "status=revoked" and MUST NOT be required to carry "url" or "include". Verifiers MUST NOT treat the absence of "url" and "include" as a syntax error when "status=revoked" is present. 10. Key Publication 10.1. Ed25519 Key Format ApertoID uses Ed25519 [RFC8032] as its mandatory-to-implement key type. Ed25519 was chosen for compact key size (32 bytes / 43 Base64 characters, unpadded), compact signature size (64 bytes / 86 Base64 characters, unpadded), fast verification (the cost of verifying a signature is negligible relative to the DNS lookup it accompanies), and wide implementation support across all major cryptographic libraries. The public key is published as the raw 32-byte Ed25519 public key encoded in unpadded Base64. Implementations MUST support Ed25519. Future specifications MAY define additional key types via the ApertoID Key Type Registry (Section 16.3). 10.2. Key Lifecycle Keys published in Agent Declaration Records MUST have an expiration timestamp in the "exp" field. Domain owners SHOULD set key expiration to no more than 90 days in the future, rotate keys at least 7 days before expiration, and use TTL values of 3600 seconds (1 hour) for Agent Declaration Records to balance caching efficiency with timely key rotation. Ferro Expires 11 February 2027 [Page 16] Internet-Draft ApertoID August 2026 11. Revocation ApertoID provides two revocation mechanisms: immediate revocation via status record and key rotation with continuity proof. 11.1. Immediate Revocation To immediately revoke an agent, the domain owner replaces the Agent Declaration Record with a revocation record: leadhunter._apertoid.example.com. 300 IN TXT "v=APERTOID1; status=revoked" Verifiers MUST check for "status=revoked" BEFORE performing any other verification steps. If "status=revoked" is present, the verifier MUST treat the agent as unauthorized. The TTL for revocation records SHOULD be 300 seconds (5 minutes) to minimize the window during which cached records may allow a revoked agent to pass verification. 11.2. Key Rotation When rotating keys, the domain owner publishes a new Agent Declaration Record with the new key and a "prev" tag containing a signature proving continuity: leadhunter._apertoid.example.com. 3600 IN TXT "v=APERTOID1; url=https://agent.example.com/mcp; " "k=ed25519; pk=QV8LAsXQn7cwPMrfpSs/1CbTXO6uTPdq0y9IOUGpAIQ; " "prev=sig:bxX1qXatIGHLYDyXAZw6T2VIAWGBuwkNxGHyYJO+UPO2uWPI" "35gzIdsi9tg1xa6Y0lUW3PDcZJ9b6OYPMjEgDQ; type=ai; exp=1762000000" This record exceeds 255 octets once the "prev" signature is included, so it is shown as multiple TXT character-strings; per [RFC1035] Section 3.3.14 the character-strings are concatenated with no separator to form the single logical record, and the split point (mid-value, inside the Base64 signature) carries no semantics. The "prev" tag value is constructed as follows: (1) Let "new_pubkey" be the raw 32-byte new Ed25519 public key. (2) Sign "new_pubkey" using the old Ed25519 private key, producing a 64-byte signature. (3) Encode the signature as unpadded Base64. (4) Prepend "sig:" to form the "prev" tag value. Ferro Expires 11 February 2027 [Page 17] Internet-Draft ApertoID August 2026 Verifiers that have cached the previous public key SHOULD verify the "prev" signature to confirm that the key rotation was authorized by the holder of the previous key. If the "prev" signature is invalid, verifiers SHOULD treat this as a potential key compromise and apply the domain's enforcement policy. The "prev" tag is OPTIONAL. When absent, verifiers accept the new key based solely on DNS authority (i.e., the domain owner's control of the DNS zone). 12. Verification Procedure This section defines the procedure for verifying an agent's authorization via DNS records. Cryptographic signature verification on individual HTTP requests is defined in the companion document [APERTOID-SIG]. 12.1. Verification Inputs The verifier receives: "claimed_domain" (the domain the agent claims to represent), "selector" (the agent selector), "agent_url" (the URL from which the request originates), and optionally "agent_pubkey" (the agent's presented public key). If no selector is available (e.g., no ApertoID-Signature header is present), the verifier can only confirm that the domain publishes an ApertoID policy by querying "_apertoid.", but cannot verify a specific agent. Full per-agent verification requires a selector, which is typically obtained from the ApertoID-Signature header defined in [APERTOID-SIG]. 12.2. Verification Algorithm Ferro Expires 11 February 2027 [Page 18] Internet-Draft ApertoID August 2026 VERIFY_APERTOID(claimed_domain, selector, agent_url, agent_pubkey): 1. Query TXT record at "_apertoid." 2. If no record found: Return result="none" (domain does not publish ApertoID) 3. Parse policy record; extract p= value 4. Query TXT record at "._apertoid." 5. If no record found: Return result="permerror", apply policy p= 6. Parse agent declaration record 7. If status=revoked: Return result="revoked", apply policy p= 8. If record contains include= tag: Follow delegation (see Section 8 for the limits). For EACH record resolved through an include= reference, re-apply step 7: if a resolved record has status=revoked, Return result="revoked", apply policy p= (a revoked delegation target stops the chain and is NOT followed further). If delegation otherwise fails (depth or lookup limit exceeded, circular reference, or a resolved record cannot be obtained): Return result="temperror". Continue verification with the final resolved record. 9. Check exp= timestamp: If exp= is present and current_time > exp: Return result="expired", apply policy p= (A record with no exp= does not expire at the DNS layer; see Section 7.3.) 10. Compare agent_url with record url= value: Match rules per Section 11.4. If no match: Return result="url_mismatch", apply policy p= 11. If record contains a pk= tag AND agent_pubkey is provided: Compare agent_pubkey with record pk= value (the key type is that of k=, defaulting to ed25519 when k= is absent; see Section 7.3) If mismatch: Return result="key_mismatch", apply policy p= 12. Return result="pass" 12.3. Result Values pass The agent is authorized by the domain and, if applicable, the cryptographic key matches. none The domain does not publish ApertoID records. revoked The agent has been explicitly revoked. Ferro Expires 11 February 2027 [Page 19] Internet-Draft ApertoID August 2026 expired The agent's key has expired. url_mismatch The agent's URL does not match the declared URL. key_mismatch The agent's presented key does not match the declared key. permerror A permanent error occurred (e.g., no agent record found, malformed syntax). temperror A temporary error occurred (e.g., DNS timeout, delegation failure). 12.4. URL Matching Rules When comparing the agent's URL against the declared URL: the scheme MUST be "https" (HTTP MUST NOT be accepted); host comparison is case- insensitive per [RFC3986]; path comparison is case-sensitive; before the path comparison, any trailing "/" characters are removed from the path component of BOTH URLs (so "/x", "/x/" and "/x//" compare equal, and a root path "/" compares equal to an empty path), while interior "/" characters are left unchanged; query strings and fragments are ignored; port numbers, if present, MUST match (default HTTPS port 443 is assumed when absent). 13. Operational Considerations 13.1. Deployment Guidance Domain owners deploying ApertoID SHOULD follow this progression: (1) Publish a Policy Record with "p=none" and a "rua=" address to begin collecting verification data without affecting agent operations. (2) Publish Agent Declaration Records for all known authorized agents, initially without cryptographic keys (url= only). (3) Monitor aggregate reports to identify unauthorized agents. (4) Add Ed25519 keys (k= and pk= tags) to agent records. (5) Progress to "p=warn" and then "p=reject" as confidence grows. 13.2. CDN and Reverse Proxy Interaction When agents operate behind CDNs or reverse proxies, the agent's apparent URL may differ from the URL in the Agent Declaration Record. Domain owners MUST ensure that the "url=" value matches the URL as seen by verifiers, not the internal origin URL. Ferro Expires 11 February 2027 [Page 20] Internet-Draft ApertoID August 2026 13.3. TTL Recommendations The following TTL values are RECOMMENDED: Policy Records: 3600 seconds (1 hour), as these change infrequently. Agent Declaration Records: 3600 seconds (1 hour), balancing caching with timely key rotation. Revocation Records: 300 seconds (5 minutes), minimizing the vulnerability window after revocation. 14. Security Considerations 14.1. Authorization vs. Identity Verification This document alone provides authorization-level assurance: the domain declares which agents are authorized. Without the cryptographic signature mechanism defined in [APERTOID-SIG], a verifier can confirm that an agent's URL appears in the domain's DNS records but cannot confirm that the requester is genuinely that agent. An attacker with network access could potentially proxy requests through an authorized URL. Full identity verification — where the agent proves on each request that it possesses the private key corresponding to the public key published in DNS — requires implementation of both this document and [APERTOID-SIG]. 14.2. DNSSEC ApertoID records SHOULD be protected by DNSSEC [RFC4033] [RFC4034] [RFC4035]. Without DNSSEC, an attacker capable of DNS cache poisoning can inject fraudulent ApertoID records, including false public keys. ApertoID provides two levels of assurance: without DNSSEC, it provides authorization-level assurance comparable to SPF and DKIM records (the common case today); with DNSSEC, it provides cryptographic-level assurance where the public key in DNS is authenticated by the DNSSEC chain of trust. Verifiers SHOULD validate DNSSEC when available and MAY treat DNSSEC- validated results with higher confidence. DNSSEC is REQUIRED for full cryptographic verification of agent identity. Ferro Expires 11 February 2027 [Page 21] Internet-Draft ApertoID August 2026 14.3. Key Compromise If an agent's Ed25519 private key is compromised, the domain owner MUST immediately publish a revocation record (Section 11.1) with a low TTL (300 seconds). The window of vulnerability equals the TTL of the previously cached Agent Declaration Record. Domain owners SHOULD use TTL values no higher than 3600 seconds to limit the maximum vulnerability window to one hour. 14.4. Delegation Abuse Attackers may attempt to abuse the delegation mechanism to create excessively long resolution chains, circular references, or to keep a revoked agent alive behind a delegation. The limits and checks defined in Section 9 bound this risk: the "include" delegation limit, the total-lookup cap, and circular-reference detection together bound the work a single verification can be made to perform, while the per- hop revocation re-check ensures a "status=revoked" record anywhere in the delegation chain is honored rather than bypassed by delegation. Verifiers MUST enforce all of these; a violation of the depth, lookup, or cycle limits is a temporary error ("temperror"), and a revoked record in the chain yields "revoked". 14.5. Agent Enumeration An adversary may attempt to enumerate a domain's agents by querying common selector names. Domain owners who wish to limit enumeration SHOULD use non-predictable selector names. DNSSEC-signed zones using NSEC3 [RFC5155] provide resistance against zone walking. 14.6. DNS Amplification ApertoID records are TXT records of moderate size (typically 170-250 bytes), comparable to DKIM key records. Standard DNS amplification mitigations (response rate limiting, BCP 38 source address validation) apply. 14.7. Threat Model and Non-Goals This subsection consolidates what ApertoID does and does not defend against, so that deployers can reason about residual risk. Several limitations are described in more detail elsewhere and are not repeated here: the boundary between authorization-level and identity- level assurance is covered in Section 14.1; and, for deployments that also use the HTTP request signing mechanism, the lack of recipient binding and cross-service replay (the "Action Binding Scope" considerations), the fact that HTTP headers other than method and target are not signed (the "HTTP Headers Not Signed" considerations), Ferro Expires 11 February 2027 [Page 22] Internet-Draft ApertoID August 2026 and header stripping of unsigned requests (the "Signature Stripping" considerations) are covered in the Security Considerations of [APERTOID-SIG]. The threats below are specific to the DNS trust root defined in this document. Hostile or compromised resolver: A verifier obtains both the agent's declared URL and its public key from DNS. A recursive resolver, forwarder, or on-path attacker that can control the answers returned to the verifier can therefore substitute a fraudulent public key (and a matching forged signature) or a fraudulent URL, and the verification will succeed. This is the same trust dependency that SPF, DKIM, and DMARC place on DNS. The standard mitigation is DNSSEC (Section 14.2): a verifier that validates DNSSEC will reject forged records, and DNSSEC is REQUIRED for full cryptographic assurance of agent identity. Verifiers that do not validate DNSSEC obtain only authorization-level assurance and MUST NOT treat a passing result as cryptographic proof of the resolver path. Registrar compromise and domain takeover: ApertoID roots all trust in control of the domain's DNS zone. An attacker who gains control of the zone -- through registrar-account compromise, a malicious or coerced DNS operator, or a successful social-engineering attack against the registrant -- can publish arbitrary ApertoID records, including new agent keys that will verify correctly. This is inherent to any DNS-based trust anchor and is not something ApertoID can detect or prevent from within the protocol; it mirrors the honest framing in the Trust Domain Discovery work, which accepts the same dependency on the naming and registration system. ApertoID accepts this as a foundational assumption: whoever controls the zone controls the domain's declared agent identities. Deployers who require assurance beyond zone control must layer an out-of-band mechanism (for example, registry lock, DNSSEC with offline key management, or Certificate-Transparency-style external monitoring of published records) on top of ApertoID. Domain expiry and re-registration: A special case of the previous threat is a domain that lapses and is re-registered by a different party. The new registrant gains full control of the zone and can publish valid ApertoID records declaring its own agents under the reused name; a verifier has no in-protocol way to distinguish the new owner from the original. The "prev" key-rotation continuity proof (Section 11.2) does NOT mitigate this: it is OPTIONAL, it only helps a verifier that has cached the previous key, and the takeover path is simply to publish a fresh key with no "prev" tag at all -- a fully conforming record that carries no continuity claim and triggers no discontinuity signal. (The reference implementation does not currently verify "prev" at all.) This threat is therefore documented as a residual risk. Relying parties for whom name reuse is a Ferro Expires 11 February 2027 [Page 23] Internet-Draft ApertoID August 2026 material concern SHOULD combine ApertoID with external signals such as domain-age or registration-change monitoring, which are outside the scope of this document. Hostile but legitimately declared agent: ApertoID answers the question "is this agent genuinely declared and, with [APERTOID-SIG], genuinely in possession of the declared key by the claimed domain?" It does NOT answer "should this agent be permitted to perform this particular action?" A domain's own declared agent that behaves maliciously, or is subverted after declaration, will still authenticate successfully, because authentication attests attribution, not good behavior. Per-action authorization -- deciding what a correctly-identified agent is allowed to do -- is explicitly out of scope for ApertoID and belongs to a policy or authorization layer above it. ApertoID provides the verified identity on which such a layer can base its decisions; it does not itself carry or evaluate permissions. 15. Privacy Considerations ApertoID records are published in DNS and are therefore publicly queryable. Domain owners should be aware that publishing ApertoID records reveals: the existence and endpoint URLs of AI agents (which may reveal internal infrastructure); the type classification ("type=ai") indicating the domain uses AI agents; and agent selectors that may reveal organizational structure. Domain owners who wish to limit exposure SHOULD use generic endpoint URLs and non-descriptive selectors. Verifiers querying ApertoID records may reveal interest in specific domains to DNS operators. Standard DNS privacy mechanisms (DNS over TLS [RFC7858], DNS over HTTPS [RFC8484]) mitigate this concern. 16. IANA Considerations 16.1. Underscore-Scoped Domain Name Registration This document requests registration of the following entry in the "Underscored and Globally Scoped DNS Node Names" registry per [RFC8552]: +=========+============+=================+ | RR Type | _NODE NAME | Reference | +=========+============+=================+ | TXT | _apertoid | [this document] | +---------+------------+-----------------+ Table 1 Ferro Expires 11 February 2027 [Page 24] Internet-Draft ApertoID August 2026 16.2. ApertoID Agent Type Registry This document requests IANA to create the "ApertoID Agent Type" registry with the following initial values. New values are registered via the "Specification Required" policy per [RFC8126]. +========+==================================+=================+ | Value | Description | Reference | +========+==================================+=================+ | ai | Autonomous AI agent | [this document] | +--------+----------------------------------+-----------------+ | human | Human-operated tool | [this document] | +--------+----------------------------------+-----------------+ | hybrid | AI-assisted with human oversight | [this document] | +--------+----------------------------------+-----------------+ Table 2 16.3. ApertoID Key Type Registry This document requests IANA to create the "ApertoID Key Type" registry with the following initial value. New values are registered via the "Specification Required" policy per [RFC8126]. +=========+===============================+==========+===========+ | Value | Description | Key Size | Reference | +=========+===============================+==========+===========+ | ed25519 | Ed25519 (EdDSA on Curve25519) | 32 bytes | [RFC8032] | +---------+-------------------------------+----------+-----------+ Table 3 17. References 17.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005, . Ferro Expires 11 February 2027 [Page 25] Internet-Draft ApertoID August 2026 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", RFC 8552, March 2019, . 17.2. Informative References Ferro Expires 11 February 2027 [Page 26] Internet-Draft ApertoID August 2026 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, . [RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, February 2024, . [RFC9989] Herr, T. and J. Levine, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 9989, May 2026, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, October 2018, . [I-D.mozleywilliams-dnsop-dnsaid] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, May 2026, . [I-D.klrc-aiagent-auth] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, July 2026, . Ferro Expires 11 February 2027 [Page 27] Internet-Draft ApertoID August 2026 [I-D.ietf-wimse-arch] Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, July 2026, . [I-D.schwenkschuster-wimse-trust-domain-discovery] Schwenkschuster, A. and Y. Rosomakho, "WIMSE Trust Domain Discovery", Work in Progress, Internet-Draft, draft- schwenkschuster-wimse-trust-domain-discovery-00, July 2026, . [I-D.ferro-dnsop-apertodns-protocol] Ferro, A., "ApertoDNS Protocol: A Modern Dynamic DNS Update Protocol", Work in Progress, Internet-Draft, draft- ferro-dnsop-apertodns-protocol-02, January 2026, . [APERTOID-SIG] Ferro, A., "ApertoID-Signature: HTTP Request Signing for AI Agent Identity", Work in Progress, Internet-Draft, draft-ferro-httpbis-apertoid-sig-02, 2026, . Work in progress. Appendix A. Complete Examples A.1. Basic Deployment ; Policy: warn on failures, receive reports _apertoid.example.com. 3600 IN TXT "v=APERTOID1; p=warn; rua=mailto:apertoid@example.com" ; Agent: MCP server with Ed25519 key assistant._apertoid.example.com. 3600 IN TXT "v=APERTOID1; url=https://mcp.example.com/agent; k=ed25519; pk=22A9MAOrna2yu63pTR/MtR7E6ZvNr0VpuFf3iz0ZqCw; type=ai; exp=1761955200" A.2. Third-Party Delegation Ferro Expires 11 February 2027 [Page 28] Internet-Draft ApertoID August 2026 ; Policy: reject unauthorized agents _apertoid.example.com. 3600 IN TXT "v=APERTOID1; p=reject; rua=mailto:sec@example.com" ; Own agent leadhunter._apertoid.example.com. 3600 IN TXT "v=APERTOID1; url=https://agents.example.com/leadhunter; k=ed25519; pk=zud6BDQnS2LuF3Lea1WJdhfo/TssKNIRHXP7N3I3Rwk; type=ai; exp=1761955200" ; Delegated third-party agent crm._apertoid.example.com. 3600 IN TXT "v=APERTOID1; include=client42._apertoid.salesforce.com" A.3. Emergency Revocation and Key Rotation ; Step 1: Immediately revoke compromised agent leadhunter._apertoid.example.com. 300 IN TXT "v=APERTOID1; status=revoked" ; Step 2: Publish new key with rotation proof leadhunter._apertoid.example.com. 3600 IN TXT "v=APERTOID1; url=https://agents.example.com/leadhunter; " "k=ed25519; pk=SDjyggr4hJnmqHN7KakFCGg63jFIwb7tS3jEMcrDIq0; " "prev=sig:ixwPd0LIcPSCoBzCFpBui04VPn2p6Hx3BKbNKEMw6q6MFVzp" "7p6PF97pkhKocsh7R/kZXSlWXNvkrXayHNi7AQ; type=ai; exp=1764547200" Appendix B. Integration with Application-Layer Protocols This appendix is non-normative. ApertoID is designed to be protocol-agnostic at the application layer. MCP Server Cards at "/.well-known/mcp/server-card.json" provide capability discovery; ApertoID complements MCP by providing DNS-based verification that a given MCP server is authorized by the claimed domain. A2A Agent Cards at "/.well-known/agent.json" provide agent discovery; ApertoID provides a DNS-based trust anchor independent of the agent's self-declared card. DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] provides DNS-based agent discovery; ApertoID provides authorization and identity verification. The two are complementary: DNS-AID answers "what agents does this domain have?" while ApertoID answers "is this agent genuinely authorized by this domain?" Appendix C. Changes from -01 This appendix is non-normative and summarizes the changes made in this revision. Ferro Expires 11 February 2027 [Page 29] Internet-Draft ApertoID August 2026 Normative changes (a verifier conforming to -01 may behave differently): * Delegation limit (Section 8). The limit on "include" delegation is stated unambiguously: a verifier follows at most two "include" delegations (the original record plus up to two delegated targets), and a chain requiring a third hop yields "temperror". The limit is now stated only in Section 8; the Section 11.2 algorithm refers to it rather than restating a number. * Revocation across delegation (Sections 8 and 11.2). The "status=revoked" check now applies to every record resolved through an "include" reference, not only the original record; a revoked record anywhere in a delegation chain makes the agent unauthorized and stops the chain. Clarifications (no change in conforming behavior intended): * URL matching (Section 11.4). Trailing-slash normalization is specified exactly: trailing "/" characters are removed from the path of both URLs before the case-sensitive comparison, so "/x", "/x/", and "/x//" compare equal and a root path equals an empty path; interior slashes are unchanged. * Delegation abuse (Section 13.4). The security consideration is aligned with Section 8: it references the delegation limit rather than restating it, attributes the mitigation to the combination of that limit, cycle detection, and per-hop revocation re-checking, and states the correct result values ("temperror" for a limit or cycle violation, "revoked" for a revoked record in the chain). New material: * Applicability (new section). States where ApertoID is and is not the appropriate mechanism: it fits open-web agent identity where parties share no prior trust configuration and the publishing side operates only DNS; it is not the mechanism where an issuance-based system already establishes trust between the parties, where per- action authorization is required, where full message integrity is required, or where DNS is not an acceptable trust anchor. * Threat Model and Non-Goals (new subsection of Section 13). Consolidates the residual threats: a hostile or compromised resolver, registrar compromise and domain takeover, domain expiry and re-registration, and a hostile but legitimately declared agent. It points to the DNSSEC and authorization-versus-identity considerations rather than repeating them. Ferro Expires 11 February 2027 [Page 30] Internet-Draft ApertoID August 2026 Comparison with existing approaches (Section 2): * The description of [I-D.klrc-aiagent-auth] is corrected to describe its actual scope and its relationship to ApertoID. * Entries are added for WIMSE workload identity [I-D.ietf-wimse-arch] and for HTTPS well-known trust discovery [I-D.schwenkschuster-wimse-trust-domain-discovery], each distinguishing it from ApertoID by how trust is established. * The entry comparing ApertoID to the OWASP Agent Name Service is removed, as its claims could not be verified against a citable source. Editorial (no protocol change): * The Introduction now states the problem qualitatively, without figures that cannot be verified from a citable source. * The description of Ed25519 verification cost is stated qualitatively rather than as a specific timing. * Reference entries are corrected against the canonical IETF records (full author lists, current document revisions, and published titles), and entries for DANE (RFC 6698) and HTTP Message Signatures (RFC 9421), previously cited by number only, are added. The companion reference to [APERTOID-SIG] is updated to its -02 revision. Appendix D. Changes from -00 This appendix is non-normative and summarizes the changes made in the -01 revision. * Corrected the Section 5.1 ABNF: the "pk" public key is a raw 32-byte Ed25519 key in unpadded Base64 (exactly 43 characters, not an SPKI wrapping), and "prev" signatures are 64 bytes unpadded (86 characters); the "=" padding character was removed from BASE64CHAR. * Corrected the "label" production: "ldh-label" is now "alnum"-first (a leading digit is permitted), and an "underscore-label" alternative was added so underscore-scoped names such as "_apertoid" include targets are grammatical. * Tightened the whitespace ("*WSP" around ";"), URI-CHAR (added "%"; excluded ";"), and email-address (RFC 5321 dot-atom) productions. Ferro Expires 11 February 2027 [Page 31] Internet-Draft ApertoID August 2026 * Clarified that revocation records ("status=revoked") are exempt from the "url"-or-"include" requirement; that record type is determined by the DNS query name, not by content; that duplicate known tags are a "permerror"; and that "pk" may appear without "k". * Revised three factual claims in the Introduction for accuracy and sourcing (industry statistics and an impersonation example). * Regenerated all example keys and signatures as real, reproducible Ed25519 values; aligned the "ldh-label" and signature-format productions to be byte-identical with [APERTOID-SIG]. Acknowledgements Without Valentina Tognizioli, none of this would exist, not for anything she did, but for who she is. She was where the ideas started, and the reason I didn't stop. Grazie, Tina. The design of ApertoID was informed by the architectural patterns established by SPF, DKIM, and DMARC for email authentication, and by DANE for DNS-based authentication of named entities. The author acknowledges the DNSOP working group participants whose feedback on draft-ferro-dnsop-apertodns-protocol shaped the approach taken in this document. Author's Address Andrea Ferro ApertoID Verona Italy Email: irn@irn3.com URI: https://github.com/ApertoID Ferro Expires 11 February 2027 [Page 32]