ApertoID: DNS-Based Agent Identity Declaration Protocol

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.¶

5.1. ABNF Definition

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

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 11), 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 6.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.¶

6.1. Record Location

The ApertoID Policy Record is a DNS TXT record published at:¶

_apertoid.<domain>

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 5.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.<domain>", and an Agent Declaration Record is a record at "<selector>._apertoid.<domain>". 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 5.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 5.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").¶

6.2. Example

_apertoid.example.com. 3600 IN TXT
  "v=APERTOID1; p=reject; rua=mailto:apertoid@example.com"

6.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.¶

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.¶

7.1. Record Location

Each authorized agent is declared in a separate DNS TXT record at:¶

<selector>._apertoid.<domain>

The <selector> 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.¶

7.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.¶

7.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 be an HTTPS URI. Required in every Agent Declaration Record except a revocation record (see "status" below and Section 8); 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 11.4.¶

k (RECOMMENDED)

Key type. MUST be "ed25519" for this specification. Additional key types MAY be registered via the ApertoID Key Type Registry (Section 15.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 12.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 10), 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 15.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).¶

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 8.¶

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 10.¶

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 10.2.¶

7.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.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 (approximately 50 microseconds), 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 15.3).¶

9.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.¶

10.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.¶

10.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.¶

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).¶

11.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.<claimed_domain>", 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].¶

11.2. Verification Algorithm

VERIFY_APERTOID(claimed_domain, selector, agent_url, agent_pubkey):

  1. Query TXT record at "_apertoid.<claimed_domain>"
  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 "<selector>._apertoid.<claimed_domain>"
  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 (max depth 2, max 10 total lookups)
       If delegation fails: Return result="temperror"
       Continue verification with 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"

11.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.¶

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).¶

11.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; trailing slashes are normalized; query strings and fragments are ignored; port numbers, if present, MUST match (default HTTPS port 443 is assumed when absent).¶

12.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.¶

12.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.¶

12.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.¶

13.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].¶

13.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.¶

13.3. Key Compromise

If an agent's Ed25519 private key is compromised, the domain owner MUST immediately publish a revocation record (Section 10.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.¶

13.4. Delegation Abuse

Attackers may attempt to abuse the delegation mechanism to create excessively long resolution chains or circular references. The limits defined in Section 8 (maximum depth of 2, maximum 10 lookups) mitigate this risk. Verifiers MUST enforce these limits and treat violations as permanent errors.¶

13.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.¶

13.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.¶

15.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]:¶

15.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].¶

15.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].¶

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

; 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"