Agent Registration and Discovery Protocol (ARDP)

Autonomous and semi-autonomous software agents introduce challenges in discoverability, reachability, and interoperability. Agents may be ephemeral, mobile across execution environments, and implemented by heterogeneous vendors. ARDP addresses stable addressing of agents whose runtime location changes, authorized discovery by identity and declared capabilities, capability-driven selection among interaction protocols (e.g., MCP, A2A, HTTP, gRPC), and minimal, privacy-aware presence signaling.

Stable Identity; Dynamic Reachability; Minimalism (control plane only); Security by Default; Federation-Friendly; Extensibility.

ARDP is intentionally narrow in scope. The following are explicitly out of scope for this specification: Agent-to-agent interaction, session management, task execution, and tool invocation protocols. These are addressed by interaction protocols such as MCP and A2A. Identity governance frameworks, IAM policy languages, and organizational trust models. ARDP accepts identity attestations as inputs but does not define how they are issued or governed. Runtime authorization token formats and enforcement proxies. ARDP provides discovery-time authorization scopes; runtime enforcement is delegated to interaction layers. Post-execution evidence, audit trails, compliance logging formats, and non-repudiation mechanisms. Billing, accounting, reputation, benchmarking, and other business frameworks. Naming and bootstrap mechanisms beyond locating an ARDP authority. DNS-based discovery, well-known URIs, or other bootstrap mechanisms may be used alongside ARDP. Centralization requirements. ARDP supports domain-scoped authorities and explicit federation without mandating a single global registry.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174. Agent: Autonomous software entity capable of initiating and receiving interactions. Agent Identifier (AID): Stable, namespaced identifier of the form agent:<local-id>@<authority>. Registrar: Service that accepts agent registrations and maintains bindings. Resolver: Service that resolves an AID to active endpoints. Endpoint: Network location and protocol tuple through which an agent can be reached. Capability: Declarative description of supported protocols and interaction modes.

ARDP defines a logical control plane composed of registrars and resolvers. Agents register their presence and capabilities with a registrar. Authorized clients query resolvers to obtain endpoint and capability information.

ARDP operates as a control-plane protocol for registration and discovery. It is designed to compose with other layers of the agent ecosystem: Transport Security: ARDP endpoints are typically secured using TLS, mTLS, or QUIC. Transport security is orthogonal to ARDP semantics. Identity Governance and Attestation: ARDP uses identity attestations as inputs for proof-of-control during registration and for authorization decisions. The issuance, revocation, and governance of these attestations are handled by external identity frameworks. Bootstrap Mechanisms: Clients may use DNS-based discovery, well-known URIs, or other mechanisms to locate ARDP registrars and resolvers. ARDP does not prescribe a specific bootstrap method. Interaction Protocols: Once an agent's endpoint and capabilities are discovered via ARDP, clients select an appropriate interaction protocol (MCP, A2A, HTTP, gRPC) based on the advertised capabilities. ARDP does not define interaction semantics. ARDP does not specify runtime enforcement mechanisms, session semantics, or evidence/audit systems. These concerns are delegated to the appropriate layers.

Each agent SHALL have a unique AID. The authority component denotes the administrative authority responsible for the identity. Agents MUST prove control of an AID during registration using cryptographic credentials bound to that identity.

An ARDP Agent Identifier (AID) MUST follow this grammar (ABNF per RFC 5234):

Note: When internationalized domain names are used, implementers should follow the IDNA2008 RFC series.

The canonical AID string is: The literal prefix agent: in lowercase. The authority normalized to lowercase (including IDNA2008 normalization where applicable); internal-name is lowercased as-is. local-id is case-sensitive and MUST be preserved as sent. AIDs MUST be compared using the canonical form.

A REGISTER request includes: AID; one or more endpoints; capability document (versioned); TTL; and cryptographic proof. Registrations are soft-state and MUST be refreshed before expiration. Refresh is performed by sending a new REGISTER request with the same (aid, binding_id) pair.

An agent MAY explicitly remove its registration.

Registration is idempotent on (aid, binding_id). If a client sends the same (aid, binding_id), the server MUST treat it as a refresh. If a client sends the same aid with a different binding_id, the server MUST return a conflict error unless the client has registry:override scope.

The server MUST be authoritative for expires_at and SHOULD return it in responses. Clients SHOULD refresh at <= 0.5 * ttl with random jitter. The server MUST define and enforce TTL bounds and advertise them in a metadata resource (recommended: /.well-known/ardp/meta).

This section defines a metadata resource for deployments using HTTPS bindings. Path: GET /.well-known/ardp/meta The response advertises server capabilities, TTL bounds, supported protocols, and proof-of-control requirements:

When jws_required is true, the nonce_endpoint field indicates where clients acquire nonces for proof-of-control.

RESOLVE maps an AID to active endpoints and capabilities. Access MUST be authorized via the registry:resolve scope.

QUERY allows authorized discovery by capability or namespace. Results SHOULD be minimized to prevent metadata leakage. Access MUST be authorized via the registry:query scope.

By default, QUERY returns only aid and status. Clients MAY request full details via a detail=full parameter. If redaction applies, the server MUST omit restricted fields and include "redacted": true in the response.

Capability documents MAY include supported protocols (MCP, A2A, HTTP, gRPC), transport bindings, authentication mechanisms, modalities, rate or cost hints, and protocol-specific metadata. Capabilities are declarative and do not imply authorization.

Capabilities MUST include protocol-specific bindings when a protocol is declared.

Presence is limited to: online, offline, degraded.

Threats include identity spoofing, registration poisoning, unauthorized discovery, replay and downgrade attacks, and registrar compromise. Mitigations include cryptographic identity proof, signed registrations, strict authorization, rate limiting, and audit logging.

Proof-of-control is REQUIRED for REGISTER and refresh operations. RESOLVE and QUERY do not use proof-of-control; they are authorized via scopes (see Authorization Scopes below).

Clients MUST present a JWS-signed proof when registering or refreshing. The signed payload consists of: The registration body, serialized as deterministic JSON A server-provided nonce An issued_at timestamp in RFC 3339 format

The registration body MUST be serialized using deterministic JSON with the following rules: Object keys are sorted lexicographically (Unicode code point order) No insignificant whitespace between tokens Array element order is preserved Strings are encoded as UTF-8 Numbers use minimal representation without trailing zeros

Clients acquire nonces via: GET /.well-known/ardp/nonce The response is a JSON object:

Nonces are single-use or have a narrow replay window. The recommended TTL is 300 seconds. The nonce endpoint is advertised in the /meta response when JWS proof-of-control is required.

Servers MUST verify the JWS using a JWKS key set (RFC 7517) or a configured trust store. Servers MUST enforce replay windows and clock skew tolerances.

Implementations MUST support ES256 (ECDSA using P-256 and SHA-256). Implementations MAY additionally support: RS256, RS384, RS512, PS256, PS384, PS512, ES384, ES512. EdDSA is not currently supported.

Proof-of-control is used for REGISTER and refresh operations. Authorization scopes apply to all operations and are the primary access control mechanism for RESOLVE and QUERY. Operations require the following scopes: registry:register - required for REGISTER registry:refresh - required for refresh (re-REGISTER with same binding_id) registry:resolve - required for RESOLVE registry:query - required for QUERY registry:deregister - required for DEREGISTER registry:override - allows registering with a different binding_id for an existing AID

Registrars MAY federate across domains via explicit trust relationships and policy agreements.

Federation is allowed only between explicit trust anchors. Responses from remote registrars MUST include provenance fields: origin_authority, origin_registrar_id, origin_signature. Caches MUST honor remote TTL and mark records as federated.

ARDP complements, and does not replace, agent interaction protocols such as MCP and A2A.

JSON over HTTPS is shown as an example binding. Alternative encodings (e.g., CBOR, gRPC) are possible.

This section describes a minimal HTTPS binding for ARDP operations. All endpoints are under the /.well-known/ardp/ path prefix. GET /.well-known/ardp/meta - Returns server metadata including TTL bounds, supported protocols, and proof-of-control requirements. GET /.well-known/ardp/nonce - Returns a JSON object with nonce and expires_in fields for use in proof-of-control. POST /.well-known/ardp/register - Registers or refreshes an agent. Refresh is performed by re-registering with the same (aid, binding_id). POST /.well-known/ardp/deregister - Removes an agent registration. GET /.well-known/ardp/resolve?aid={aid} - Resolves an AID to endpoints and capabilities. GET /.well-known/ardp/query - Queries for agents by capability or namespace. Supports parameters: protocol, schema, limit, offset, detail. Default returns minimal data; use detail=full to request complete records.

Servers MUST return errors with: code (stable error code), message (human-readable), and correlation_id (for tracing). Required codes: invalid_aid, unauthorized, forbidden, conflict, not_found, expired.

IANA is requested to register the following URI suffix per RFC 8615 in the "Well-Known URIs" registry: URI suffix: ardp Change controller: IETF Specification document(s): This document

The agent: prefix is used as an internal identifier namespace and is not registered as a URI scheme in this version.

A minimal JSON schema for capability documents is provided as a companion artifact in the GitHub mirror.

Capability schema evolution Privacy-preserving discovery Federation bootstrapping Consider adopting RFC 8785 (JSON Canonicalization Scheme) for deterministic JSON serialization in a future revision