Internet Engineering Task Force B. Nemethi, Ed. Internet-Draft Open Agent Registry, Inc. Intended status: Informational 1 June 2026 Expires: 3 December 2026 Agent Identity and Discovery (AID) draft-nemethi-aid-agent-identity-discovery-latest Abstract Agent Identity and Discovery (AID) is a minimal, DNS-first discovery protocol for locating agent and tool endpoints. Given a domain name, an AID client queries a DNS TXT record at the well-known base name _agent. and learns the endpoint URI, protocol token, authentication hint, and optional endpoint-proof key for that domain. AID v2 is the current wire format defined by this document. It uses `v=aid2`, keeps _agent. as the canonical discovery name, and updates endpoint proof so that the DNS key is an Ed25519 JSON Web Key (JWK) `x` value and the HTTP signature `keyid` is derived as an RFC 7638 JWK thumbprint. Legacy `aid1` records remain a compatibility format for clients that need to read older deployments. AID is intentionally a first-contact discovery layer. After discovery, protocol-specific mechanisms such as MCP, A2A, OpenAPI, OAuth, auth.md, or other application layers handle communication, capability negotiation, authentication, authorization, and policy. 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 3 December 2026. 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 2. Conventions and Terminology 2.1. Requirements Language 2.2. Terms 3. AID Record Format 3.1. Syntax and Parsing 3.2. Defined Keys 3.3. Examples 4. Client Discovery Procedure 4.1. Discovery Algorithm 4.2. Standard Client Error Codes 4.3. Exact-Host Semantics and Delegation 4.4. Protocol-Specific Names 5. Security Considerations 5.1. What PKA Proves 5.2. Threat Model 5.3. Enterprise Policy Modes 6. DNS and Caching 7. Rotation Stance 7.1. No Multi-Key RRset in Core 7.2. Future Rotation Profile 8. Registries and Governance 9. IANA Considerations 10. Normative References 11. Informative References Appendix A. Authentication Scheme Registry Appendix B. Protocol Registry Appendix C. Client Error Constants Appendix D. PKA Handshake D.1. Key Decoding D.2. Derived Key Identifier D.3. Request and Response Shape D.4. Covered Components D.5. URI, Authority, and Redirects D.6. Verifier Summary Appendix E. .well-known Fallback Appendix F. Composition Notes F.1. Web Bot Auth F.2. auth.md and OAuth F.3. SPIFFE and WIMSE F.4. Pkarr Appendix G. Migration from AID v1.2 G.1. Provider Migration G.2. Client Migration Appendix H. Changes from -00 Author's Address 1. Introduction Applications that need to locate and connect to an agent often rely on out-of-band configuration, centralized directories, or protocol- specific discovery mechanisms. AID defines a DNS-based bootstrap point that answers one question: given a domain, where is the agent and which protocol should a client speak? AID resolves a domain to the current agent endpoint, protocol hint, and optional endpoint-proof key. After AID discovery, the selected endpoint's protocol, authorization, registration, identity, and policy layers take over. AID uses a TXT record at the well-known DNS name _agent.. The record is small, versioned, and protocol-agnostic. It tells a client where the agent is located, which protocol token applies, what authentication hint to expect, and whether endpoint proof is available. * Zero configuration: a user supplies a domain and the client performs discovery. * DNS-first deployment: the protocol uses standard DNS publication. * Protocol-agnostic bootstrap: AID identifies the next protocol, rather than replacing it. * Endpoint proof: when `k` is present, the endpoint proves possession of the matching Ed25519 private key. * Scope honesty: AID does not issue credentials, grant authorization, prove human approval, define workload federation, or publish DID-like metadata. This document specifies the wire format and client behavior for AID v2. AID v2 keeps the stable `_agent` label and TXT payload model while changing the PKA key encoding and endpoint proof profile. The label governance question is independent of the v2 key-format cleanup; see Section 9. 2. Conventions and Terminology 2.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.2. Terms AID Client Software that performs AID discovery for a domain. Provider The entity that controls a domain and publishes the AID TXT record. _agent subdomain The DNS name `_agent.` where the canonical AID TXT record is published. A-label The Punycode representation of an Internationalized Domain Name as described in [RFC5890]. PKA Public Key for Agent: an optional Ed25519 endpoint-proof key in the AID record. JWK `x` The unpadded base64url public-key member of an Ed25519 OKP JWK. JWK thumbprint An RFC 7638 hash of a canonical JWK representation. AID v2 uses this value as the HTTP Message Signature `keyid`. Trust source The source from which the selected AID record was obtained: `dns` or `well-known-tls`. 3. AID Record Format A provider MUST advertise its agent service by publishing a DNS TXT record at the canonical base name `_agent.`. For AID v2, providers MUST use DNS TXT records for discovery. TXT records remain the baseline because they are widely deployable across DNS providers and registrar control panels. Future AID versions may adopt other record types, but v2 uses the stable `_agent` label and TXT payload defined here. 3.1. Syntax and Parsing The record MUST be a single semicolon-delimited string of `key=value` pairs. Clients SHOULD trim leading and trailing whitespace from keys and values. Clients MUST ignore unknown keys unless the key has a known legacy meaning that this specification explicitly rejects for `aid2`. If a DNS server splits the TXT record into multiple 255-octet character strings, the client MUST concatenate them in order before parsing. Providers SHOULD keep the total payload below 255 octets when practical. Clients MUST recognize single-letter lowercase aliases. A record MUST NOT include both a full key and its alias. Key comparisons are case-insensitive. Providers SHOULD emit the short-key form for compact DNS deployment. 3.2. Defined Keys +=======+=====+===========+==============+===============================================+ |Key |Alias|Requirement|Description |Example | +=======+=====+===========+==============+===============================================+ |version|v |Required |Specification |`v=aid2` | | | | |version. For | | | | | |v2 this MUST | | | | | |be `aid2`. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |uri |u |Required |Absolute |`u=https://api.example.com/mcp` | | | | |`https://` URL| | | | | |for a remote | | | | | |agent, | | | | | |`wss://` for | | | | | |WebSocket, or | | | | | |a local | | | | | |locator. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |proto |p |Required |Protocol token|`p=mcp` | | | | |from | | | | | |Appendix B. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |auth |a |Recommended|Authentication|`a=oauth2_code` | | | | |hint token | | | | | |from | | | | | |Appendix A. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |desc |s |Optional |Short human- |`s=Primary AI Gateway` | | | | |readable | | | | | |display text. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |docs |d |Optional |Absolute |`d=https://docs.example.com/agent` | | | | |`https://` URL| | | | | |to human- | | | | | |readable | | | | | |documentation.| | +-------+-----+-----------+--------------+-----------------------------------------------+ |dep |e |Optional |ISO 8601 UTC |`e=2027-01-01T00:00:00Z` | | | | |deprecation | | | | | |timestamp. | | +-------+-----+-----------+--------------+-----------------------------------------------+ |pka |k |Optional |Unpadded |`k=JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs`| | | | |base64url | | | | | |Ed25519 public| | | | | |key. The | | | | | |value is | | | | | |exactly the | | | | | |RFC 8037 JWK | | | | | |`x` member. | | +-------+-----+-----------+--------------+-----------------------------------------------+ Table 1: AID v2 TXT Keys AID v2 records MUST NOT use `kid` or `i` for endpoint proof. A `v=aid2` record containing `kid` or `i` is invalid. The expected key identifier is derived from `k` as described in Appendix D. 3.3. Examples _agent.example.com. 300 IN TXT "v=aid2;u=https://api.example.com/mcp;p=mcp;a=pat;s=Example AI Tools" Figure 1: Remote MCP Agent _agent.example.com. 300 IN TXT "v=aid2;p=mcp;u=https://api.example.com/mcp;k=JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs;a=oauth2_code;s=Secure AI Gateway" Figure 2: Remote MCP with PKA _agent.example.com. 300 IN TXT "v=aid2;p=websocket;u=wss://agent.example.com/session;a=oauth2_code;s=Streaming Agent" Figure 3: WebSocket Agent _agent.grafana.com. 300 IN TXT "v=aid2;u=docker:grafana/mcp:latest;p=local;a=pat;s=Run Grafana agent locally" Figure 4: Local Agent via Docker _agent.example.com. 300 IN TXT "v=aid1;p=mcp;u=https://api.example.com/mcp;k=;i=g1" _agent.example.com. 300 IN TXT "v=aid2;p=mcp;u=https://api.example.com/mcp;k=" Figure 5: Legacy Compatibility During Migration Clients that support both versions partition records by version before ambiguity checks. A same-key migration from legacy `aid1` to current `aid2` is not a key rotation when the decoded Ed25519 public key bytes are the same. 4. Client Discovery Procedure 4.1. Discovery Algorithm When an AID client is given a domain, it MUST perform the following steps: 1. Normalize the domain. If the domain contains non-ASCII labels, convert them to A-label form as described in [RFC5890]. 2. Query TXT records for the canonical base name `_agent.`. Clients MUST NOT walk up to parent domains. 3. Parse returned TXT answers as semicolon-delimited `key=value` records. Key comparisons are case-insensitive. 4. Validate records using versioned rules. For `aid2`, require `v`, `u`, and `p`; reject a record containing both a full key and alias; reject `kid` or `i`; and reject malformed `k` values. 5. Partition valid records by AID major version. 6. Select the highest supported valid version allowed by local policy. Clients that support `aid2` SHOULD prefer `aid2` over `aid1`. 7. Within the selected version, if exactly one valid record exists, use it. If more than one valid record exists, fail with ambiguity. Clients MUST NOT choose among multiple valid same- version records by DNS answer order. 8. Process optional metadata. If `docs` is present, the client MAY display it. If `dep` is in the future, the client SHOULD warn. If `dep` is in the past, the client SHOULD fail gracefully. 9. If `k` is present, perform PKA endpoint proof using Appendix D. 10. Return the discovered endpoint, protocol, metadata, PKA state, and trust source. Malformed answers do not matter when there is exactly one valid record in the selected version. Returning clients that previously selected `aid2` SHOULD treat an `aid1`-only result as a version downgrade. If no DNS record is found or DNS lookup fails, the client MAY attempt the `.well-known` fallback on the same exact host as described in Appendix E. If both DNS and fallback fail, discovery fails. 4.2. Standard Client Error Codes +======+=======================+====================================+ | Code | Name | Meaning | +======+=======================+====================================+ | 1000 | ERR_NO_RECORD | No AID DNS record was | | | | found. | +------+-----------------------+------------------------------------+ | 1001 | ERR_INVALID_TXT | A record was malformed, | | | | invalid, or ambiguous. | +------+-----------------------+------------------------------------+ | 1002 | ERR_UNSUPPORTED_PROTO | The protocol token is | | | | unsupported. | +------+-----------------------+------------------------------------+ | 1003 | ERR_SECURITY | Discovery failed due to | | | | a security policy or | | | | failed endpoint proof. | +------+-----------------------+------------------------------------+ | 1004 | ERR_DNS_LOOKUP_FAILED | The DNS lookup failed | | | | for a network-related | | | | reason. | +------+-----------------------+------------------------------------+ | 1005 | ERR_FALLBACK_FAILED | The `.well-known` | | | | fallback failed or | | | | returned invalid data. | +------+-----------------------+------------------------------------+ Table 2: Client Error Codes 4.3. Exact-Host Semantics and Delegation Discovery is exact-host by default. If the application asks for `app.team.example.com`, the base query is `_agent.app.team.example.com`. Clients MUST NOT implicitly retry parent hosts such as `_agent.team.example.com` or `_agent.example.com`. If an operator wants child hosts to inherit a shared record, that inheritance MUST be expressed in DNS for the exact queried name. A common pattern is a CNAME from the child host's `_agent` label to a shared `_agent` record. _agent.app.team.example.com. 300 IN CNAME _agent.shared.team.example.com. _agent.shared.team.example.com. 300 IN TXT "v=aid2;p=mcp;u=https://gateway.team.example.com/mcp;k=" Figure 6: Exact-Host and Delegated Example 4.4. Protocol-Specific Names The canonical v2 location is the base record `_agent.`. Providers MAY additionally publish protocol-specific names such as `_agent._mcp.` or `_agent._a2a.` for legacy clients, diagnostics, or explicitly configured base-failure probing. When an application explicitly requests a protocol, v2 clients still query the canonical base name `_agent.` first and filter that record for the requested protocol. Protocol- prefixed `_agent._.` probing is legacy, diagnostic, or base-failure-only behavior where supported and explicitly configured. Clients MUST NOT perform a compatibility lookup at `_agent..`. Protocol-specific names, when used, always use the underscore form `_agent._.`. 5. Security Considerations AID publishes public discovery metadata. The TXT record MUST NOT contain secrets. The protocol depends on DNS integrity, TLS for remote endpoints, and explicit client safeguards for local execution. * Providers SHOULD sign AID records with DNSSEC when available. Clients SHOULD perform DNSSEC validation when DNSSEC-signed answers are available. * Remote agent URIs MUST use `https://`, except `proto=websocket` which MUST use `wss://`. Clients MUST perform standard TLS certificate and hostname validation as described in [RFC9525]. * When the selected `aid2` record contains `k`, clients MUST verify endpoint proof using the PKA profile in Appendix D. * Clients that support `proto=local` MUST implement the safeguards described below. * Clients MUST NOT follow redirects during PKA verification or `.well-known` fallback. For normal protocol use after discovery, clients MUST NOT automatically follow cross-origin redirects from the discovered endpoint without policy approval or user confirmation. Clients that support `proto=local` MUST implement the following safeguards: 1. Explicit consent: before first execution, the client MUST display the full resolved command and require explicit confirmation. 2. Integrity check: the client MUST compute and cache a cryptographic fingerprint of the `uri` and `proto` values. If these values change on a later lookup, the client MUST re-trigger the full consent process. 3. No shell interpretation: arguments derived from the `uri` MUST be passed atomically to the underlying OS execution call to prevent command injection. 4. No nested discovery: the client MUST reject a local execution `uri` that could be interpreted as a command that initiates another AID discovery request. 5. Sandboxing: clients SHOULD run local agents in a sandboxed environment with minimum necessary permissions. 5.1. What PKA Proves PKA proves exactly this: the endpoint reached at the discovered URI controls the Ed25519 private key corresponding to the public key currently published in the domain's selected AID record. PKA does not prove that a user authorized a specific action, that an OAuth token is valid, that a workload identity belongs to a trust domain, that an internal policy engine approved a request, or that a key change is cryptographically continuous with a previous key. 5.2. Threat Model AID addresses DNS spoofing and cache poisoning with optional DNSSEC validation, endpoint impersonation with PKA endpoint proof using Ed25519 HTTP Message Signatures, downgrade detection with remembered state, command injection risks for local execution, and cross-origin redirect abuse for remote endpoints. Returning clients can detect PKA removal, key replacement, and `aid2` to `aid1` version downgrade when they retain previous security state. If the key changes, the key changed; AID v2 core does not define DNS- level cryptographic continuity across key changes. Compromised authoritative DNS servers, active attackers after TLS validation fails, authorization, delegation, user consent, reputation, workload federation, and managed cryptographic rotation in the core DNS record are outside the direct scope of AID v2. 5.3. Enterprise Policy Modes Clients that expose enterprise controls SHOULD provide simple policy knobs. * PKA policy: `if-present | require` * DNSSEC policy: `off | prefer | require` * Well-known policy: `auto | disable` * Downgrade policy: `off | warn | fail` Policy semantics are as follows: * `pka=require`: discovery fails if the selected record has no `k`. * `dnssec=require`: discovery fails when DNSSEC validation is unavailable or unsuccessful for the selected DNS answer. * `well-known=disable`: clients do not use `/.well-known/agent` fallback. * `downgrade=warn|fail`: applies to PKA removal, key replacement, and `aid2` to `aid1` downgrade when previous state exists. If discovery succeeds only through `.well-known`, that result cannot satisfy a policy that requires DNSSEC validation. 6. DNS and Caching Providers SHOULD publish `_agent` TXT records with a TTL between 300 and 900 seconds. Clients MUST respect the received TTL and MUST NOT cache DNS records longer than that. PKA responses are separate from DNS records. A nonce-bound PKA response MUST include `Cache-Control: no-store`. Clients SHOULD also send `Cache-Control: no-store` on PKA requests. 7. Rotation Stance AID v2 core does not define DNS-level cryptographic key rotation. The core record says that DNS currently publishes this endpoint and this key, the endpoint can prove possession of the corresponding private key, and verifiers can derive stable key identity from `k`. _agent.acme.com. 300 IN TXT "v=aid2;p=mcp;u=https://agent.acme.com/mcp;k=" Figure 7: Current Endpoint and Key This does not mean that the new key is authorized by the old key, that multiple keys are active through DNS, that DNS provides validity windows, or that AID core provides request provenance or delegated signing infrastructure. If the key changes, the key changed. Clients with previous state decide whether to warn, fail, or accept according to local policy. 7.1. No Multi-Key RRset in Core AID v2 core rejects the following shape as a core discovery result: _agent.acme.com. 300 IN TXT "v=aid2;p=mcp;u=https://agent.acme.com/mcp;k=" _agent.acme.com. 300 IN TXT "v=aid2;p=mcp;u=https://agent.acme.com/mcp;k=" Figure 8: Rejected Multi-Key Core Shape This changes the model from one selected endpoint record with an optional proof key into one endpoint descriptor with an active key set where the HTTP response `keyid` selects a key. That larger model requires rules for normalized non-key field equivalence, duplicate handling, partial DNS propagation, key-set pinning, downgrade policy, SDK return types, and conformance fixtures. It also does not solve lost-key or compromised-key recovery. 7.2. Future Rotation Profile If AID later needs managed rotation for pinned clients or provenance profiles, it should be a separate HTTP key-directory profile, likely using JWKS or Web Bot Auth style overlap. { "keys": [ { "kty": "OKP", "crv": "Ed25519", "kid": "", "x": "", "use": "sig", "nbf": 1712793600, "exp": 1715385600 } ] } Figure 9: Possible Future Key Directory Shape If such a directory chains to DNS `k`, that chaining is the defining property of an AID-anchored key directory. If it does not chain to DNS `k`, it is a normal external key directory outside AID core. 8. Registries and Governance The auth and protocol registries remain compatible with AID v1.2 unless changed through the normal extension process. 9. IANA Considerations This revision does not request new IANA actions. AID v2 keeps `_agent.` as the discovery label. The earlier RFC 8552 `_agent` registration request was rejected on procedural grounds in April 2026. That label-governance question is decoupled from the v2 PKA cleanup. A later working group or BoF process may revisit the label. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, September 2015, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC9421] Fielding, R., "HTTP Message Signatures", RFC 9421, November 2023, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, November 2023, . 11. Informative References [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, . [RFC6335] Cotton, M., "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", RFC 6335, August 2011, . [RFC8552] Sullivan, A., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", RFC 8552, March 2019, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . [RFC9460] Schwartz, B., "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, November 2023, . Appendix A. Authentication Scheme Registry All authentication tokens are case-sensitive and use lowercase ASCII. * none * pat * apikey * basic * oauth2_device * oauth2_code * mtls * custom The `auth` value is an advisory hint. It does not define registration payloads, credential formats, authorization-server semantics, or trust policy. Appendix B. Protocol Registry All protocol tokens are case-sensitive and use lowercase ASCII. +===========+=========================+=========================+ | Token | Meaning | Allowed `uri` scheme(s) | +===========+=========================+=========================+ | mcp | Model Context Protocol | https:// | +-----------+-------------------------+-------------------------+ | a2a | Agent-to-Agent Protocol | https:// | +-----------+-------------------------+-------------------------+ | openapi | OpenAPI specification | https:// | | | document | | +-----------+-------------------------+-------------------------+ | grpc | gRPC over HTTP/2 or | https:// | | | HTTP/3 | | +-----------+-------------------------+-------------------------+ | graphql | GraphQL over HTTP | https:// | +-----------+-------------------------+-------------------------+ | websocket | WebSocket transport | wss:// | +-----------+-------------------------+-------------------------+ | local | The agent runs locally | docker:, npx:, pip: | | | on the client machine | | +-----------+-------------------------+-------------------------+ | zeroconf | mDNS or DNS-SD service | zeroconf: | | | discovery | | +-----------+-------------------------+-------------------------+ | ucp | Universal Commerce | https:// | | | Protocol | | +-----------+-------------------------+-------------------------+ Table 3: Protocol Tokens Appendix C. Client Error Constants For cross-language SDK consistency, clients SHOULD use the following numeric constants. +=======================+=======+ | Constant | Value | +=======================+=======+ | ERR_NO_RECORD | 1000 | +-----------------------+-------+ | ERR_INVALID_TXT | 1001 | +-----------------------+-------+ | ERR_UNSUPPORTED_PROTO | 1002 | +-----------------------+-------+ | ERR_SECURITY | 1003 | +-----------------------+-------+ | ERR_DNS_LOOKUP_FAILED | 1004 | +-----------------------+-------+ | ERR_FALLBACK_FAILED | 1005 | +-----------------------+-------+ Table 4: Error Constant Values Appendix D. PKA Handshake When `k` is present, clients MUST verify endpoint proof using HTTP Message Signatures with Ed25519 as specified in [RFC9421]. D.1. Key Decoding For v2, `k` MUST be unpadded base64url. Decoding MUST produce exactly 32 octets. Legacy `z...` multibase keys MUST NOT be accepted in `v=aid2`. The corresponding JWK is: { "kty": "OKP", "crv": "Ed25519", "x": "" } Figure 10: Ed25519 JWK Shape D.2. Derived Key Identifier The expected HTTP Message Signature `keyid` is the RFC 7638 JWK thumbprint using SHA-256 over this exact UTF-8 JSON serialization, with no extra spaces: {"crv":"Ed25519","kty":"OKP","x":""} Figure 11: JWK Thumbprint Input The SHA-256 digest is encoded as unpadded base64url. Implementations MUST NOT hash the raw public key bytes directly for `keyid`. D.3. Request and Response Shape The validated RFC 9421 Structured Fields shape is: Accept-Signature: aid-pka=("@method";req "@target-uri";req "@authority";req "@status");created;expires;keyid="";alg="ed25519";nonce="";tag="aid-pka-v2" Signature-Input: aid-pka=("@method";req "@target-uri";req "@authority";req "@status");created=;expires=;keyid="";alg="ed25519";nonce="";tag="aid-pka-v2" Signature: aid-pka=:: Cache-Control: no-store Figure 12: PKA HTTP Fields The signature MUST NOT cover HTTP `Date`. The client challenge MUST contain at least 32 bytes of entropy and SHOULD be transported as unpadded base64url in the RFC 9421 `nonce` signature parameter. The verifier MUST compare the received `nonce` exactly to the challenge it sent. Servers are not required to store nonce state in v2 core because the verifier supplies the one-shot nonce and the signed response is not cacheable. `created` and `expires` are mandatory. `expires` MUST be greater than `created`. `expires - created` MUST NOT exceed 300 seconds and SHOULD be 60 seconds or less. Verifiers MAY allow a small clock-skew tolerance when evaluating `created` and `expires`. Signers MUST emit `alg="ed25519"` lowercase. Verifiers MUST compare the semantic algorithm value case-insensitively and MUST reconstruct `@signature-params` from the received Structured Field value. D.4. Covered Components The v2 PKA response signature covers: * `"@method";req` * `"@target-uri";req` * `"@authority";req` * `"@status"` `@method`, `@target-uri`, and `@authority` are request-derived components and therefore use `;req`. `@status` is response-derived and does not use `;req`. `@status` signs the status actually returned. PKA does not require status `200`. A signed `401` can still prove endpoint authenticity before an OAuth or auth.md handoff continues. D.5. URI, Authority, and Redirects Clients MUST NOT follow redirects during PKA verification. The request context is the discovered endpoint URI after fragment removal. Query strings are preserved. `@authority` uses the externally visible request authority: lowercase hostname, omitted default port, and retained non-default port. Servers behind reverse proxies must sign the externally visible request context, not internal hop-local scheme, host, or port values. D.6. Verifier Summary A verifier accepts a v2 PKA response only when: 1. the selected AID record contains valid v2 `k`; 2. the response contains a valid `Signature-Input` and `Signature`; 3. the covered components and `tag="aid-pka-v2"` match this profile; 4. `keyid` equals the RFC 7638 thumbprint derived from DNS `k`; 5. `alg` has semantic value `ed25519`; 6. `nonce` exactly equals the verifier-generated challenge; 7. `created` and `expires` pass freshness checks; 8. the response includes `Cache-Control: no-store`; 9. Ed25519 verification succeeds over the reconstructed RFC 9421 signature base. Appendix E. .well-known Fallback AID remains DNS-first. The `.well-known` fallback is a convenience for environments where DNS TXT record creation is restricted. * Path: `GET https:///.well-known/agent` * Format: JSON mirroring v2 record keys. * Trust source: `well-known-tls`. * Security: relies on TLS certificate validation. PKA may still apply, but it proves consistency with TLS-hosted metadata, not DNS-published external trust. DNS-discovered records have `trustSource=dns`. Fallback-discovered records have `trustSource=well-known-tls`. If a policy requires DNSSEC-backed trust, `.well-known` cannot satisfy it. The `.well-known` URI convention itself is described in [RFC8615]. Appendix F. Composition Notes This section is non-normative. F.1. Web Bot Auth AID v2 follows Web Bot Auth where the layers match: Ed25519, RFC 9421 HTTP Message Signatures, RFC 7638 JWK thumbprints, `created`, `expires`, `nonce`, and `tag`. AID does not become Web Bot Auth. Web Bot Auth signs automated client requests to origins. AID PKA proves endpoint control for a DNS-discovered agent endpoint. Operators may reuse key material across AID and Web Bot Auth if their threat model allows it, but AID does not recommend reuse. Reuse shares blast radius between endpoint proof and request-signing. F.2. auth.md and OAuth AID can support auth.md without adding auth.md-specific fields to core: 1. AID resolves a domain to `u` and `p`. 2. If `k` is present, PKA verifies the endpoint. 3. The client follows the endpoint, protocol, OAuth, or auth.md layer where present. AID does not specify ID-JAG `aud`, provider trust lists, registration payloads, scopes, credential types, revocation, or auth.md metadata registries. F.3. SPIFFE and WIMSE AID may be used by future SPIFFE or WIMSE profiles as a public first- contact anchor. AID v2 core does not define SPIFFE trust-domain mapping, SPIFFE bundle federation, WIMSE hop re-binding, OAuth client registration, or workload authorization. F.4. Pkarr AID v2 remains compatible with the Pkarr-inspired idea of compact Ed25519 key material, but it does not adopt Pkarr's identity model. Pkarr makes the public key the address and signs DNS packets under that key. AID remains DNS-authority-rooted: the DNS owner publishes the current endpoint and current endpoint-proof key inside a TXT payload. Reviewer-facing language should say "DNS-current endpoint/key" and should not imply Pkarr-style self-certifying names, key-addressed identity, or cryptographic continuity across key changes. Appendix G. Migration from AID v1.2 G.1. Provider Migration 1. Inventory current `aid1` records. 2. For PKA records, decode the v1 multibase/base58btc `k` to the 32-byte Ed25519 public key. 3. Encode those bytes as unpadded base64url. This is the v2 `k`. 4. Publish `v=aid2` with the same endpoint, protocol, and v2 `k`, without `i`. 5. Keep `aid1` during the compatibility window. 6. Remove `aid1` after old-client support is no longer needed. G.2. Client Migration 1. Support both `aid1` and `aid2` parsing. 2. Partition records by version before ambiguity checks. 3. Prefer `aid2` when both versions are valid and policy allows it. 4. Keep legacy PKA only for selected `aid1` records. 5. Store previous security state using derived JWK thumbprints so same-key `aid1` to `aid2` migration does not look like key replacement. Appendix H. Changes from -00 This revision changes the draft from the AID v1.2 `aid1` wire format to the AID v2 `aid2` wire format. * Changed the current record version from `aid1` to `aid2`. * Changed PKA key encoding from legacy multibase/base58btc to unpadded base64url Ed25519 JWK `x`. * Removed `kid` and `i` from v2 records; v2 derives HTTP signature `keyid` as an RFC 7638 JWK thumbprint. * Replaced the old PKA handshake with an RFC 9421 response-signature profile using `Accept-Signature`, `nonce`, mandatory `created` and `expires`, `tag="aid-pka-v2"`, and `Cache-Control: no-store`. * Removed the AID-specific `AID-Challenge` header and removed HTTP `Date` from the PKA signature base. * Specified version partitioning for side-by-side `aid1` and `aid2` migration. * Clarified `.well-known` fallback trust as `well-known-tls`, not DNS-rooted trust. * Clarified that AID is a first-contact endpoint-and-key anchor and that authorization, workload identity, registration, and policy compose above AID core. * Deferred `_agent` IANA label governance from the v2 key-format cleanup. Author's Address Balazs Nemethi (editor) Open Agent Registry, Inc. Email: balazs@agentcommunity.org URI: https://agentcommunity.org