| Internet-Draft | Agent Identifier RDAP | May 2026 |
| Yu | Expires 21 November 2026 | [Page] |
AI agents may need stable identifiers that are independent from their current network locations. In agent deployments, an Agent identifier may be associated with IPv6 locators, IPv6 prefixes, Agent Gateways, public key references, policy references, lifecycle state, and revocation status. Applications, gateways, controllers, and operators need a trusted way to query this registration data.¶
This document defines an RDAP profile for querying Agent identifier registration data. The profile reuses the Registration Data Access Protocol (RDAP) query model and JSON response format, and defines an RDAP object class and extension members for Agent identifiers, IPv6 locator bindings, Agent Gateway bindings, and related operational metadata.¶
This document does not define a new agent discovery protocol, a new agent interaction protocol, or a new authentication mechanism. It defines a registration data access profile that can be used by agent deployments and by other agent-related systems that need trusted Agent identifier metadata.¶
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 21 November 2026.¶
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.¶
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.¶
AI agents are increasingly expected to interact across platforms, organizations, clouds, edge environments, and administrative domains. A stable Agent identifier can help identify an agent independently from the agent's current network location. However, a relying party may still need to know which entity is responsible for the Agent identifier, whether the identifier is active, which IPv6 locators or Agent Gateways are authorized to represent the agent, and whether a binding has expired or been revoked.¶
The companion IPv6 networking considerations draft discusses what networking information may be needed after agent discovery, including Agent-ID to IPv6 locator or Agent Gateway binding. This document explores one possible way to provide stable registration data for Agent identifiers using RDAP.¶
RDAP provides a RESTful query model and JSON responses for registration data [RFC7480] [RFC9082] [RFC9083]. Reusing RDAP allows agent deployments to use an existing registration data access model rather than defining a new query protocol.¶
This document specifies:¶
This document does not specify:¶
RDAP responses that use the extensions defined in this document MUST include the extension identifier "agent_identifier_rdap" in the "rdapConformance" array.¶
{
"rdapConformance": [
"rdap_level_0",
"agent_identifier_rdap"
]
}
¶
The extension identifier is used provisionally in this version. Future versions may request IANA registration if this approach receives community interest.¶
This profile defines the following RDAP query path for exact Agent identifier lookup:¶
/agent/{agentIdentifier}
¶
The "agentIdentifier" path component is the Agent identifier being queried. The value MUST be percent-encoded when required by URI syntax.¶
Servers MAY also support search paths in a future version. This document defines only exact lookup.¶
An Agent RDAP Object is an RDAP response object that describes an Agent identifier and related registration data. It reuses common RDAP members such as "objectClassName", "handle", "entities", "events", "links", "notices", and "remarks" as defined by RDAP.¶
The "objectClassName" member for an Agent RDAP Object MUST be "agent".¶
The following agent-specific members are defined:¶
An IPv6 Locator Object describes an IPv6 address or prefix through which an agent instance, service, or gateway can be reached.¶
The following members are defined:¶
An Agent Gateway Object describes a gateway that is authorized to represent one or more Agent identifiers.¶
The following members are defined:¶
The following example shows an Agent RDAP Object for an agent that is reachable through an Agent Gateway.¶
{
"rdapConformance": [
"rdap_level_0",
"agent_identifier_rdap"
],
"objectClassName": "agent",
"handle": "AGENT-EXAMPLE-0001",
"agentIdentifier": "agent:warehouse.example.cn:agv-001",
"agentStatus": "active",
"responsibleEntity": "CNIC-EXAMPLE-ENTITY",
"agentDomains": [
"warehouse.example.cn"
],
"ipv6Locators": [
{
"locator": "2001:db8:100:20::1",
"locatorType": "gateway",
"priority": 100,
"weight": 100,
"region": "warehouse-site-a",
"validFrom": "2026-05-20T00:00:00Z",
"validUntil": "2026-11-20T00:00:00Z",
"status": "active"
}
],
"agentGateways": [
{
"gatewayIdentifier": "warehouse-gateway-001",
"gatewayLocator": "2001:db8:100:20::1",
"representedAgents": [
"agent:warehouse.example.cn:agv-001"
],
"authorizationRef": "https://example.net/agent/authz/warehouse-gw-001",
"policyRefs": [
"policy:warehouse-dispatch"
],
"status": "active"
}
],
"certificateRefs": [
"https://example.net/agent/certs/agv-001"
],
"policyRefs": [
"policy:warehouse-dispatch"
],
"revocationStatus": {
"status": "notRevoked",
"revocationCheck": "https://example.net/agent/status/agv-001"
},
"events": [
{
"eventAction": "registration",
"eventDate": "2026-05-20T00:00:00Z"
},
{
"eventAction": "last changed",
"eventDate": "2026-05-20T00:00:00Z"
}
],
"links": [
{
"value": "https://rdap.example.net/agent/agent%3Awarehouse.example.cn%3Aagv-001",
"rel": "self",
"href": "https://rdap.example.net/agent/agent%3Awarehouse.example.cn%3Aagv-001",
"type": "application/rdap+json"
}
]
}
¶
An agent networking implementation can use this RDAP profile to verify Agent-ID binding data before selecting an IPv6 locator, Agent Gateway, or network policy. For example, an Agent Gateway can query the Agent RDAP Object to determine whether it is authorized to represent a target Agent-ID. A controller can query the same object to select a locator or policy for a given communication, such as an SRv6 policy in a controlled domain.¶
This RDAP profile is not a real-time reachability protocol. It provides registration data. Implementations that require live reachability, health, or load information should combine this profile with other mechanisms such as Agent registries, service discovery systems, controllers, telemetry, or application-layer health checks. Online/offline state, live load, health, capability ranking, and endpoint selection are out of scope for this profile.¶
Servers implementing this profile MUST follow RDAP transport and response requirements. RDAP error responses, including status codes, notices, and remarks, are used as defined by RDAP.¶
If the requested Agent identifier does not exist, the server SHOULD return an RDAP not-found response. If the Agent identifier exists but the client is not authorized to view the requested data, the server SHOULD return an appropriate authorization error or a redacted response according to local policy.¶
A server MAY return different field sets to different clients based on authentication, authorization, local policy, and privacy requirements. Clients MUST NOT assume that absence of a field means absence of the corresponding registration data.¶
Agent identifier registration data can be useful to audit and accountability systems. For example, an audit record may contain an Agent identifier and later need to determine the responsible entity, lifecycle state, revocation state, authorized Agent Gateway, or associated IPv6 locator for that identifier.¶
This profile can provide stable registration data that audit systems may reference. It does not define audit records, distributed audit log formats, audit context propagation, attestation evidence, transparency logs, or non-repudiation mechanisms.¶
Agent registration data can influence routing, gateway selection, access control, and policy enforcement. Servers providing Agent RDAP Objects MUST authenticate update operations and MUST ensure that an Agent identifier cannot be bound to an unauthorized IPv6 locator or Agent Gateway.¶
RDAP clients MUST use HTTPS as specified by RDAP over HTTP. Clients MUST validate the server identity according to the applicable TLS validation rules.¶
Agent Gateway authorization data is security-sensitive. A gateway MUST NOT be treated as authorized to represent an Agent identifier solely because it appears in an unauthenticated or stale response. Implementations SHOULD check validity periods, revocation status, and policy references before relying on gateway binding information.¶
Replay and stale-data attacks are possible if old registration data is accepted after a binding has changed or been revoked. Servers SHOULD include update events and validity intervals. Clients SHOULD apply local freshness policies and re-query when cached data is stale.¶
This profile does not define how Agent identifiers are created, delegated, or cryptographically controlled. Deployments MUST define the authority model used to issue and manage Agent identifiers.¶
Agent RDAP Objects may reveal information about organizations, internal deployments, gateways, network locations, operational regions, policy names, and relationships between domains. Servers SHOULD minimize disclosed data and apply access control where appropriate.¶
Some Agent identifiers may be pseudonymous or scoped to a domain. Servers SHOULD avoid exposing unnecessary personally identifiable information, user data, prompts, task descriptions, or sensitive application payload information in Agent RDAP Objects.¶
Public RDAP responses and authenticated RDAP responses may have different disclosure levels. Deployments SHOULD define which fields are public and which require authorization.¶
This initial version does not request any IANA action.¶
Future versions may request registration of an RDAP extension identifier if this approach receives community interest.¶