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 29 March 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. 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

[I-D.drake-agent-identity-problem-statement] defines identity0 and the distinction between an entity, its identifier, credentials, keys, and anchors. The AIRS registry architecture ([I-D.drake-agent-identity-registry]) defines the canonical aid identifier, Agent Identity Record, Registrar trust boundary, lifecycle invariants, and credential profile. This document defines only how those records are read and how a Relying Party uses authoritative resolution when verifying a Registrar-backed credential.¶

The companion EPP mapping ([I-D.drake-agent-identity-epp]) is the Registrar-to- Registry write interface. The read path deliberately reuses existing infrastructure: the URN DDDS framework ([RFC3404]) locates AIRS resolution; RDAP query and response semantics are defined by [RFC9082] and [RFC9083], with HTTP usage defined by [RFC7480].¶

2. Resolution Model

For an aid URN, a Relying Party performs these steps:¶

1. validate the URN and bootstrap the authoritative AIRS RDAP service (Section 4);¶
2. perform an exact RDAP lookup and pin the canonical identifier from the response (Section 5); and¶
3. when authenticating a presenter, establish the identity's authoritative currentIssuer from that resolution result before validating the presented credential and its sender constraint (Section 6).¶

Lookup is not authentication. Anyone who knows an identifier can ask for its public record. Authentication additionally requires the credential and sender-constraint checks in Section 6.¶

3. Identifier Forms and the Pin-Canonical Rule

AIRS defines a permanent canonical-form URN, for example urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg, and an OPTIONAL handle-form alias such as urn:aid:global:crusty. An active handle resolves to the same Agent Identity Record. A retired handle never resolves again and is never reassigned; the canonical identifier remains resolvable permanently.¶

A Relying Party resolving a handle-form URN MUST obtain the canonical identifier from the response and MUST use that canonical value for stored references, comparisons, audit records, reputation keys, and credential sub matching. A remembered handle MUST be re-resolved before use because the actor may have retired it or moved to another handle. The handle is an alias, not the durable join key.¶

4. Finding the Authoritative RDAP Service

AIRS uses the URN Resolution DDDS Application of [RFC3404] and the DNS NAPTR database of [RFC3403]. For an aid URN the first DNS key is therefore aid.urn.arpa. Registration of that NAPTR entry follows [RFC3405] and is requested by Section 10.2.¶

The aid.urn.arpa entry delegates to a stable AIRS-controlled DDDS key with an empty Flags, Services, and Regexp field. The delegated key publishes terminal NAPTR records with the U flag and the standard +I2L resolution service. The current interim reference implementation uses resolver.airs.1id.biz as the delegated key in the example below. That 1id.biz name is temporary and is not the intended long-lived URN.ARPA delegation target; production registration will use a stable name controlled by the aid namespace change controller:¶

NOTE: '\' line wrapping per RFC 8792

aid.urn.arpa. IN NAPTR 100 10 "" "" "" resolver.airs.1id.biz.

resolver.airs.1id.biz. IN NAPTR 100 10 "U" "+I2L"   \
"!^urn:aid:(global|test):([-a-z0-9]+)$!https://airs.1id.biz/rdap/aid\
_identity/urn:aid:\\1:\\2!" .

The terminal rule produces the exact HTTPS RDAP lookup URI. The replacement expression is evaluated against the original URN as required by DDDS. The rule is case-sensitive and maps only lowercase AIRS namespace-specific strings. It does not replace validation of the complete identifier grammar: the RDAP service MUST reject a mapped value that is not a valid canonical identifier or Handle under the Registry specification. global is the sole production uniqueness domain; test carries no production AIRS assurance.¶

AIRS resolution depends on the integrity of the DDDS delegation. A production Relying Party MUST obtain a DNSSEC-validated NAPTR chain ([RFC4033]) from aid.urn.arpa through the terminal rule and MUST treat a bogus or insecure chain as an inability to establish authoritative AIRS resolution. The resulting RDAP URI MUST use HTTPS and the RDAP server MUST be authenticated as required by [RFC7481].¶

Until the aid.urn.arpa entry is registered, no DNSSEC-validated chain from it exists. In that interim a deployment MAY configure the delegated key or the RDAP base URI (currently https://airs.1id.biz) directly, as an explicit local trust decision recorded in its configuration. Such a configured bootstrap is experimental and carries only the assurance its operator assigns to it. Once the aid.urn.arpa entry exists, a Relying Party MUST use the DNSSEC-validated chain and MUST NOT fall back to a configured bootstrap when that chain fails validation.¶

5. RDAP Query and Response

NOTE: '\' line wrapping per RFC 8792

GET /rdap/aid_identity/urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg \
HTTP/1.1
Host: airs.1id.biz
Accept: application/rdap+json

NOTE: '\' line wrapping per RFC 8792

{
  "rdapConformance": ["rdap_level_0", "aid"],
  "objectClassName": "aid_agentIdentity",
  "handle": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg",
  "status": ["active"],
  "aid_data": {
    "canonical": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg",
    "displayHandle": "urn:aid:global:crusty",
    "lifecycleState": "operational",
    "maxActiveTrustTier": "sovereign",
    "currentIssuer": "https://registrar.example.com/realms/agents",
    "hardwareLocked": false
  },
  "events": [
    {"eventAction": "registration",
     "eventDate": "2026-03-23T10:30:00Z"}
  ],
  "links": [
    {"rel": "self",
     "type": "application/rdap+json",
     "href": "https://airs.1id.biz/rdap/aid_identity/urn:aid:global:\
id-qkckh-xxtcw-cxbvp-gpskg"}
  ]
}

6. Verifying a Registrar-Backed AIRS Credential

The AIRS registry architecture defines Registrar-issued OAuth 2.0 JWT access tokens conforming to [RFC9068] and requires them to be sender constrained. Resolution owns the ordering that makes the issuer assertion authoritative. In particular, a credential's presented iss value MUST NOT bootstrap its own authority.¶

Given a credential claiming canonical subject A, the Relying Party MUST:¶

1. validate A as a canonical production aid URN and resolve it through Section 4 and Section 5;¶
2. confirm that the response's aid_data.canonical exactly equals A;¶
3. confirm that aid_data.lifecycleState is operational; a decommissioned identity cannot be authenticated;¶
4. obtain aid_data.currentIssuer. If it is absent, reject Registrar-backed AIRS authentication for that identity; a credential from a former Registrar is not currently authoritative;¶
5. require the credential's iss claim to exactly equal that currentIssuer URI;¶
6. retrieve OAuth 2.0 Authorization Server Metadata for that exact issuer as specified by [RFC8414] and require its issuer value to exactly equal currentIssuer before trusting its jwks_uri or other endpoints;¶
7. validate the JWT access token according to [RFC9068], including signature, audience, expiry and other applicable claims, and require sub to exactly equal the resolved canonical identifier;¶
8. verify the credential's sender constraint on the actual protected request using the cnf binding and the mTLS or HTTP Message Signatures proof profile defined by [I-D.drake-agent-identity-registry]. A valid JWT without its corresponding sender proof does not establish AIRS proof-of-control; and¶
9. apply local policy, including whether this Relying Party trusts that otherwise-authorized Registrar and whether the credential's per-interaction aid.trust_tier is sufficient for the intended action.¶

The public maxActiveTrustTier is not substituted for the credential's aid.trust_tier. The former summarizes the strongest currently active assurance-qualified binding; the latter identifies the binding tier actually used for that authentication. Trust-tier semantics and the Registrar's responsibility for validating hardware evidence are defined only in the registry architecture.¶

7. Caching and Freshness

RDAP responses use normal HTTP caching semantics. The canonical identifier is permanent, but lifecycle state, currentIssuer, maxActiveTrustTier, active handle, and hardware-lock state can change. Servers SHOULD therefore give those records short freshness lifetimes suitable for authentication use. A Relying Party making a consequential decision SHOULD revalidate the authoritative record rather than rely on stale cached values, especially before accepting a Registrar-backed credential.¶

Cached OAuth metadata and JWK sets are governed by their own HTTP freshness semantics. A Relying Party MUST still perform the authoritative currentIssuer comparison; possession of a formerly valid issuer key does not preserve issuer authority after the identity becomes unsponsored or transfers to another Registrar.¶

8. Security Considerations

The DDDS bootstrap and RDAP response determine security-critical values, particularly the canonical identifier and current authorized issuer. Production use therefore requires DNSSEC validation of the DDDS chain, HTTPS, and RDAP server authentication as specified in Section 4. A substituted resolution service could otherwise direct a Relying Party to an attacker's issuer.¶

Resolving an identifier is not proof that the counterparty controls it. Conversely, validating a token signature is not sufficient if the issuer learned only from that same token. The ordered algorithm in Section 6 binds three independent facts: authoritative identity state, authority of the current Registrar issuer, and possession of the sender-constrained proof key.¶

Registrar suspension, de-accreditation, or actor-authorized transfer can invalidate issuer authority before an otherwise well-formed credential expires. Consequential Relying Parties SHOULD use fresh resolution. When currentIssuer is absent, no Registrar- backed credential is currently authoritative for that identity.¶

This extension defines exact lookup only. Randomized canonical identifiers make population enumeration impractical, but an exact identifier or handle can still be tested for existence. Operators SHOULD rate-limit abusive lookup patterns. This document defines no wildcard, partial-match, bulk, or search endpoint.¶

9. Privacy Considerations

Public AIRS resolution intentionally excludes anchor fingerprints, operational proof public keys, raw attestation evidence, and operator contact information. Publishing those values is unnecessary for the Registrar-backed verification path and would create avoidable correlation and disclosure risks. The registry architecture defines the separation between identity0 and mutable operator or higher-layer attributes; this profile does not recreate those attributes in RDAP.¶

An active handle, trust-tier summary, event data, and currentIssuer can themselves reveal information about the identified actor or its service relationship. Minimal responses and RFC 9537 redaction are described in Section 5.4. The general privacy considerations of [RFC6973] also apply.¶

10. IANA Considerations

The aid URN namespace itself is requested by [I-D.drake-agent-identity-registry]. This document requests the following resolution-related registrations.¶

Appendix A. Acknowledgments

This profile reuses the URN DDDS and RDAP frameworks so that AIRS resolution adds only the identifier-specific mapping and response semantics needed by the registry architecture.¶

Author's Address