Resolution and Verification of Agent Identities using DNS and RDAP

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

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

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

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

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

GET /aid/urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg HTTP/1.1
Host: rdap.aid.example
Accept: application/rdap+json

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

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

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