1id.com

Australia cnd@1id.com https://1id.com

Applications and Real-Time agent identity RDAP resolution verification URN DNS The Agent Identity Registry System (AIRS) () assigns a permanent canonical aid URN to the identity0 of an autonomous entity and maintains an authoritative record associated with that identifier. This document defines the read side of AIRS: how a Relying Party finds the authoritative resolution service, retrieves the public record, resolves a handle to the canonical identifier, and verifies a Registrar-issued credential presented for that identity. Discovery uses the DNS-based URN Dynamic Delegation Discovery System (DDDS) and lookup uses the Registration Data Access Protocol (RDAP). Credential verification reuses the OAuth 2.0 JWT access-token and sender-constraint profiles defined by the AIRS registry architecture; this document defines no new credential format and no generic direct device-proof protocol.

Introduction defines identity0 and the distinction between an entity, its identifier, credentials, keys, and anchors. The AIRS registry architecture () 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 () is the Registrar-to- Registry write interface. The read path deliberately reuses existing infrastructure: the URN DDDS framework () locates AIRS resolution; RDAP query and response semantics are defined by and , with HTTP usage defined by .

Scope and Non-Goals This document specifies: bootstrap for the AIRS resolution service; one exact-match RDAP lookup; the public Agent Identity response; handle-to-canonical resolution; and the detailed Relying Party algorithm for establishing the current authorized Registrar issuer and verifying its sender-constrained AIRS credential. Provisioning, identity0 semantics, trust-tier semantics, anchor enrollment, Registrar accreditation, and governance are defined by the companion documents and are not restated here. This revision also defines no generic protocol by which an arbitrary Relying Party directly proves control against Registry-held operational proof keys. A future specification may define such a protocol.

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 when, and only when, they appear in all capitals, as shown here. Long lines in some examples are wrapped using the single-backslash strategy of . AIRS terms including "canonical identifier", "handle", "Agent Identity Record", "Registrar", "Registry Operator", and "trust tier" are used as defined in . This document uses currentIssuer for the unique OAuth 2.0 issuer identifier URI that authoritative AIRS Registrar metadata currently maps from an identity's sponsoring Registrar code.

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

1. validate the URN and bootstrap the authoritative AIRS RDAP service ();
2. perform an exact RDAP lookup and pin the canonical identifier from the response (); 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 ().

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 .

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.

Finding the Authoritative RDAP Service AIRS uses the URN Resolution DDDS Application of and the DNS NAPTR database of . For an aid URN the first DNS key is therefore aid.urn.arpa. Registration of that NAPTR entry follows and is requested by . 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 () 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 . 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.

RDAP Query and Response

Exact Lookup Path This specification defines RDAP extension identifier aid. Following the extension namespacing rules of , the lookup path is aid_identity, not a bare aid path. The next path segment is the complete aid URN, percent-encoded if required by URI path-segment syntax: 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 A response using this extension MUST include aid in rdapConformance. This document defines exact lookup only. It defines no partial-match, wildcard, bulk, or search query for Agent Identity objects.

Agent Identity Object A successful lookup returns an object whose objectClassName is aid_agentIdentity. The standard RDAP handle member carries the canonical aid URN. AIRS-specific data is contained in the namespaced aid_data object; child names need no additional prefix because they are scoped by that namespaced object.

canonical

REQUIRED. The permanent canonical-form aid URN. It MUST equal the top-level RDAP handle.

displayHandle

OPTIONAL. The currently active handle-form URN, if disclosed.

lifecycleState

REQUIRED. operational or decommissioned, using the lifecycle semantics defined by the registry architecture.

maxActiveTrustTier

OPTIONAL. The strongest currently active, assurance-qualified binding tier. Absence means that no active binding is currently qualified to support an AIRS tier assertion. This is a record summary; the tier used for a particular authentication comes from the verified credential, not from this field.

currentIssuer

OPTIONAL. The unique current AIRS OAuth 2.0 issuer identifier URI derived by the Registry from the identity's current registrar_code and authoritative Registrar metadata. It MUST be absent when the identity has no current authorized Registrar.

hardwareLocked

OPTIONAL Boolean reporting the irreversible single-binding lock state defined by the registry architecture.

Operational records SHOULD also use the registered RDAP active status; decommissioned records SHOULD use the registered inactive status. This specification does not register AIRS-specific RDAP status values. Anchor fingerprints, operational proof public keys, raw attestation evidence, and operator contact data MUST NOT appear in this public profile.

Handle and Historical Resolution An exact lookup of an active handle-form URN returns the same object as the canonical-form URN and therefore supplies the canonical value required by . A Handle that is not active returns RDAP error 404. A disabled but non-retired Handle remains reserved to the same canonical identity and may be reactivated only under the Registry/EPP Handle policy; a retired Handle is terminal and is never reassigned. A never-assigned Handle likewise returns 404. The error response MUST NOT distinguish whether a Handle is disabled, retired, or has never been assigned. A canonical identifier MUST continue to resolve after voluntary decommissioning and while no current Registrar is authorized. In the no-Registrar state the response remains otherwise valid but omits currentIssuer. De-accreditation or failure of a Registrar therefore cannot erase the durable record or silently substitute another issuer.

Redaction and Minimal Public Responses The Registry architecture permits an identity to reduce public discovery to a minimal response. The canonical identifier and lifecycle state remain available because they are required to resolve the durable record. currentIssuer, when one is authorized, remains available because it is required for the verification algorithm in . displayHandle, maxActiveTrustTier, event data, and other optional public members MAY be withheld by policy. When a server signals that a defined RDAP field has been withheld or altered, it MUST use the redacted extension of , including the redacted rdapConformance value and member required there. RFC 9537 also permits a server to omit a redaction signal when revealing the existence of the withheld field would itself create a privacy problem.

Example 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"} ] }

Verifying a Registrar-Backed AIRS Credential The AIRS registry architecture defines Registrar-issued OAuth 2.0 JWT access tokens conforming to 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 and ;
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 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 , 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 . 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.

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.

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

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 . The general privacy considerations of also apply.

IANA Considerations The aid URN namespace itself is requested by . This document requests the following resolution-related registrations.

RDAP Extensions Registry IANA is requested to register:

Extension identifier

aid

Registry operator

Any

Published specification

This document

Contact

IESG, iesg@ietf.org

Intended usage

Exact RDAP lookup of AIRS Agent Identity records using the aid_identity path, aid_agentIdentity object class, and aid_data response member.

URN.ARPA NAPTR Registration In conjunction with registration of the aid URN NID, IANA is requested to add the following record to the URN.ARPA zone under the procedures of :

Key

aid

Authority

The change controller of the aid URN namespace registration.

Record

TBD: a stable DNS name under the control of the aid namespace change controller. The interim resolver.airs.1id.biz name used in examples is not the intended long-lived URN.ARPA delegation target.

The delegated replacement domain carries the shorter-lived AIRS terminal rules defined in . This keeps Registry Operator succession out of the long-lived URN.ARPA record; a future change of namespace authority can update the delegation using the RFC 3405 procedure.

Normative References Informative References

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.