Network Working Group C. Drake Internet-Draft 1id.com Intended status: Experimental 17 July 2026 Expires: 18 January 2027 Resolution and Verification of Agent Identities using DNS and RDAP draft-drake-agent-identity-resolution-00 Abstract The Agent Identity Registry System ([I-D.drake-agent-identity-registry]) issues persistent, hardware- anchored identifiers ("aid" URNs) for autonomous entities such as AI agents and robots. This document defines how a relying party, given an "aid" URN, finds the authoritative registry for it, retrieves its public identity record, and verifies that a party presenting the identifier actually controls it. The profile deliberately reuses deployed infrastructure -- the Domain Name System (DNS) for locating the authoritative service and the Registration Data Access Protocol (RDAP, [RFC9083]) for the query and response -- rather than defining a new resolution system or identifier scheme. It replaces the bespoke lookup interface sketched in the parent specification, in the same way that the Extensible Provisioning Protocol mapping ([I-D.drake-agent-identity-epp]) replaces that specification's bespoke provisioning interface. 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 18 January 2027. Drake Expires 18 January 2027 [Page 1] Internet-Draft Agent Identity Resolution July 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to Other Documents . . . . . . . . . . . . . 3 1.3. Conventions and Terminology . . . . . . . . . . . . . . . 3 2. Resolution Model . . . . . . . . . . . . . . . . . . . . . . 4 3. Identifier Forms and the Pin-Canonical Rule . . . . . . . . . 4 4. Finding the Authoritative Server . . . . . . . . . . . . . . 4 5. RDAP Query and Response . . . . . . . . . . . . . . . . . . . 5 5.1. Lookup Path . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. The Agent Identity Object Class . . . . . . . . . . . . . 5 5.3. Handle Resolution . . . . . . . . . . . . . . . . . . . . 6 5.4. Redaction and Minimal Responses . . . . . . . . . . . . . 6 5.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Verifying Control of an Identity . . . . . . . . . . . . . . 7 6.1. Registry-Issued Assertions . . . . . . . . . . . . . . . 7 6.2. Direct Device Proof of Possession . . . . . . . . . . . . 8 7. Caching and Freshness . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 12. Informative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Provisioning an identity (writing it into a registry) and resolving one (reading and verifying it) are separate problems. The companion EPP mapping ([I-D.drake-agent-identity-epp]) covers the write side, between a Registrar and a Registry Operator. This document covers the read side, between any relying party and the registry: given an "aid" URN ([I-D.drake-agent-identity-registry]), how to (1) find the authoritative server, (2) retrieve the public record, and (3) verify Drake Expires 18 January 2027 [Page 2] Internet-Draft Agent Identity Resolution July 2026 control. A cautionary precedent shaped this design. Earlier abstract identifier systems that introduced a new identifier scheme and a new resolution protocol failed to gain adoption, in part because reviewers concluded the new machinery provided little that established Web and naming infrastructure did not. This profile therefore adds no new scheme and no new resolution protocol: "aid" is a URN [RFC8141], discovery uses DNS, and lookup uses RDAP. Registry operators that already run RDAP for domains can serve agent identities with the same software. 1.1. Scope and Non-Goals In scope: locating the authoritative RDAP service for a namespace; the RDAP lookup path and JSON members for the Agent Identity object class; resolving a handle-form URN to its canonical form; and how a relying party verifies that a presenter controls an identity. Out of scope: provisioning (see [I-D.drake-agent-identity-epp]); identity semantics, trust tiers, hardware attestation, and governance (see [I-D.drake-agent-identity-registry]); and the definition of new credential or token formats. This document defines no new URI scheme and no new wire protocol. 1.2. Relationship to Other Documents This document formalizes, and is intended to replace, the "Registry Discovery Service" sketched in [I-D.drake-agent-identity-registry]; a future revision of that document is expected to reference this profile instead of describing a bespoke lookup endpoint. Verification of control (Section 6) relies on the OpenID Connect token issuance already defined by the registry architecture. 1.3. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms "canonical identifier", "handle", "namespace", "Registry Operator", and "Governance Authority" are used as defined in [I-D.drake-agent-identity-registry]. "Relying party" is any entity that consumes an "aid" URN in order to make a decision. Drake Expires 18 January 2027 [Page 3] Internet-Draft Agent Identity Resolution July 2026 2. Resolution Model Resolving an "aid" URN has three steps: 1. Bootstrap: map the URN's namespace to the base URL of an authoritative RDAP service (Section 4). 2. Query: perform an RDAP lookup for the URN and receive an Agent Identity object (Section 5). 3. Verify: for a party claiming to be the identity, check a registry-issued assertion of control (Section 6). Steps 1 and 2 return only public metadata and require no credentials. Step 3 is performed only when a relying party needs to confirm that a specific counterparty controls the identity, as opposed to merely learning facts about it. 3. Identifier Forms and the Pin-Canonical Rule An identity may be referenced by its permanent canonical-form URN (for example urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg) or by its reassignable-in-principle handle-form URN (for example urn:aid:global:crusty). Both resolve to the same Agent Identity object. A relying party MUST treat the canonical-form URN as the stable identity and the handle as a display convenience. When a relying party resolves a handle-form URN, it MUST read the canonical-form URN from the response (Section 5) and use that value for any stored reference, comparison, audit record, or reputation lookup. A relying party MUST NOT treat two handle-form URNs, or a remembered handle, as denoting the same identity across time without re-resolving to the canonical form. This rule prevents a party from being misled if a handle is retired and (subject to registry policy) later re- presented. 4. Finding the Authoritative Server The Governance Authority publishes an authoritative-server bootstrap file using the JSON structure of [RFC9224]. Each entry maps a namespace label to one or more RDAP base URLs: Drake Expires 18 January 2027 [Page 4] Internet-Draft Agent Identity Resolution July 2026 { "version": "1.0", "publication": "2026-07-01T00:00:00Z", "services": [ [ ["global"], ["https://rdap.aid.example/", "https://rdap-2.aid.example/"] ] ] } The bootstrap file MUST be served over TLS and MUST be published through at least two independent discovery mechanisms: a well-known HTTPS location published by the Governance Authority, and the DNS zone aid.arpa used by the registry architecture. Each namespace entry SHOULD list at least two RDAP base URLs operated on independent infrastructure. A relying party MUST be able to complete resolution when any single discovery mechanism or any single listed base URL is unavailable; no single infrastructure failure -- including a DNS failure -- may make the registry unreachable ([I-D.drake-agent-identity-registry], Survivability Guarantees). A relying party selects the entry whose namespace label exactly matches the namespace segment of the URN. 5. RDAP Query and Response 5.1. Lookup Path This profile defines one lookup path segment, aid, appended to an RDAP base URL and transported per [RFC7480] using the query format of [RFC9082]. The path parameter is the percent-encoded "aid" URN: GET /aid/urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg HTTP/1.1 Host: rdap.aid.example Accept: application/rdap+json A server that implements this profile MUST include the extension identifier aid in the rdapConformance array of its responses, as required for RDAP extensions by [RFC9083]. 5.2. The Agent Identity Object Class A successful lookup returns an RDAP object with objectClassName set to aid and, subject to the redaction policy of Section 5.4, the following members: objectClassName The string aid. handle The canonical-form URN. (This reuses the RDAP handle member Drake Expires 18 January 2027 [Page 5] Internet-Draft Agent Identity Resolution July 2026 as the object's stable identifier and is unrelated to an "aid" display handle.) aidCanonical The canonical-form URN, stated explicitly to satisfy the pin-canonical rule of Section 3. aidHandle The current display handle-form URN, if any. status RDAP status values; this profile adds decommissioned and hardware locked to the RDAP status vocabulary for the states defined by the registry architecture. aidTrustTier One of sovereign, portable, enclave, virtual, declared. events At minimum a registration event; RDAP event semantics apply. aidIssuer The OpenID Connect issuer URL whose tokens assert control of this identity, and from which its jwks_uri is discoverable (Section 6). links At minimum a self link. Hardware fingerprints, device public keys, and operator contact data are private and MUST NOT appear in a public response (Section 9). 5.3. Handle Resolution A lookup of a handle-form URN returns the same object as a lookup of the corresponding canonical-form URN, with aidCanonical present. A relying party completes resolution by adopting the aidCanonical value per Section 3. If the handle is not currently assigned, the server returns RDAP error 404. 5.4. Redaction and Minimal Responses Servers MUST support redaction consistent with [RFC9083]. If the identity has opted out of public discovery, the server MUST return only objectClassName, aidCanonical, status, and aidIssuer, omitting the handle, tier, registrar, and event data. 5.5. Example Response body (media type application/rdap+json): Drake Expires 18 January 2027 [Page 6] Internet-Draft Agent Identity Resolution July 2026 { "rdapConformance": ["rdap_level_0", "aid"], "objectClassName": "aid", "handle": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg", "aidCanonical": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg", "aidHandle": "urn:aid:global:crusty", "status": ["active"], "aidTrustTier": "sovereign", "aidIssuer": "https://issuer.aid.example", "events": [ { "eventAction": "registration", "eventDate": "2026-03-23T10:30:00Z" } ], "links": [ { "rel": "self", "type": "application/rdap+json", "href": "https://rdap.aid.example/aid/urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg" } ] } 6. Verifying Control of an Identity Resolution establishes facts about an identity. It does not, by itself, establish that the party a relying party is talking to controls that identity. Confusing the two -- and more generally confusing identity, authentication, and attributes -- is a common error cataloged in [I-D.drake-agent-identity-problem-statement]; this section keeps them separate. 6.1. Registry-Issued Assertions Two verification paths are first-class, by design: an assertion issued through the registry architecture's OpenID Connect machinery (this section, the common case), and direct proof of possession by the enrolled hardware (Section 6.2). The existence of the second path is a survivability property of the architecture, not an optimization: control of an identity remains provable even when the sponsoring Registrar is unavailable, hostile, or defunct. For the assertion path, the presenting agent supplies a token whose subject (sub) is the canonical-form URN. The relying party: 1. reads aidIssuer from the resolved record; 2. obtains the issuer's signing keys from its jwks_uri via OpenID Connect discovery; Drake Expires 18 January 2027 [Page 7] Internet-Draft Agent Identity Resolution July 2026 3. verifies the token signature, issuer, audience, and expiry; and 4. confirms that sub equals the aidCanonical value obtained during resolution. Because the relying party learns the issuer from the authoritative record and verifies the issuer's signature, the identity's own device public keys need not be exposed publicly, which preserves the privacy properties of Section 9. 6.2. Direct Device Proof of Possession A relying party that requires hardware-level assurance beyond a registry-issued token -- or that cannot or will not rely on the sponsoring Registrar -- MAY request a direct proof of possession from an enrolled device. Such a proof uses the hardware-signed construction defined for transfer authorization in [I-D.drake-agent-identity-epp], rebound to the relying party as audience and to a fresh relying-party nonce. Because device public keys are not published (Section 9), the proof is checked through a verification endpoint operated by the Registry Operator -- a role the registry can always perform, since it holds the device bindings authoritatively and independently of any Registrar. The wire definition of that endpoint is future work; the construction it verifies is normative today in the EPP mapping. 7. Caching and Freshness RDAP responses are HTTP responses and are cacheable under ordinary HTTP semantics. Status is the most time-sensitive member -- an identity may be decommissioned or locked at any time -- so servers SHOULD set a short freshness lifetime for records whose status a relying party would act upon, and relying parties making consequential decisions SHOULD revalidate status rather than rely on a cached value. The canonical identifier, being permanent, may be cached indefinitely. 8. Security Considerations All queries and bootstrap retrievals MUST use TLS; the security considerations of [RFC7481] apply to the RDAP exchange. A relying party that cannot authenticate the bootstrap file or the RDAP server's certificate MUST NOT rely on the results, because a substituted server could assert arbitrary status or issuer values. Resolution is not authentication. Retrieving a record proves only what the authoritative registry publishes about an identity; it does not prove that a counterparty controls the identity. Only the Drake Expires 18 January 2027 [Page 8] Internet-Draft Agent Identity Resolution July 2026 verification of a registry-issued assertion, or a direct proof of possession (Section 6), establishes control. A relying party that acts on resolution alone can be deceived by any party that merely knows a URN, since URNs are not secret. The pin-canonical rule (Section 3) is a security control, not a convenience. A relying party that stores or compares handle-form URNs can be misled if a handle is retired and later re-presented; storing the canonical form removes this class of confusion. The lookup interface is an oracle: anyone may ask whether a given URN exists and what its public status is. Servers MUST rate-limit queries, MUST NOT offer bulk or wildcard queries, and rely on randomized canonical identifiers ([I-D.drake-agent-identity-registry]) so that identifiers cannot be enumerated. 9. Privacy Considerations The read side is where the identities of autonomous entities become observable, so it is the natural place for privacy controls. Public responses MUST exclude hardware fingerprints, device public keys, and operator contact data; exposing device public keys would, in particular, allow the same physical device to be correlated across namespaces. This is the main reason verification is founded on registry-issued assertions (Section 6.1) rather than on publishing device keys. Identities may opt out of public discovery, in which case servers return only the minimal response of Section 5.4. The general privacy considerations of [RFC6973] and the registry architecture apply. Operators should note that the self link and issuer URL can themselves reveal which registry sponsors an identity; deployments with stronger unlinkability requirements may wish to constrain these. 10. IANA Considerations No new URI scheme, URN namespace, or well-known URI is registered by this document. The "aid" URN namespace is registered by [I-D.drake-agent-identity-registry]. 10.1. RDAP Extensions Registry IANA is requested to register the following in the "RDAP Extensions" registry: Extension identifier aid Drake Expires 18 January 2027 [Page 9] Internet-Draft Agent Identity Resolution July 2026 Registry operator Any Published specification This document Contact IESG, iesg@ietf.org Intended usage Lookup of Agent Identity objects (the aid path segment and associated JSON members) as defined herein. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, . [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . [RFC9224] Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, . Drake Expires 18 January 2027 [Page 10] Internet-Draft Agent Identity Resolution July 2026 12. Informative References [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [I-D.drake-agent-identity-registry] Drake, C., "Agent Identity Registry System: A Federated Architecture for Hardware-Anchored Identity of Autonomous Entities", Work in Progress, Internet-Draft, draft-drake- agent-identity-registry-04, July 2026, . [I-D.drake-agent-identity-epp] Drake, C., "Extensible Provisioning Protocol (EPP) Mapping for Agent Identity Objects", Work in Progress, Internet- Draft, draft-drake-agent-identity-epp-00, July 2026, . [I-D.drake-agent-identity-problem-statement] Drake, C., "Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology", Work in Progress, Internet-Draft, draft-drake-agent-identity- problem-statement-00, July 2026, . Appendix A. Acknowledgments This profile follows the design of the domain-name RDAP service and reuses its infrastructure so that agent identity resolution requires no new resolution protocol. Author's Address Christopher Drake 1id.com Australia Email: cnd@1id.com URI: https://1id.com Drake Expires 18 January 2027 [Page 11]