Agent Registration and Discovery Protocol (ARDP)

Abstract

This document specifies the Agent Registration and Discovery Protocol (ARDP), a lightweight protocol for registering, discovering, and reaching autonomous software agents in distributed and federated environments. ARDP provides stable agent identities, dynamic endpoint resolution, capability advertisement (including protocol selection among MCP, A2A, HTTP, and gRPC), minimal presence signaling, and a security-first discovery control plane. ARDP is transport-agnostic and complementary to existing agent interaction protocols.¶

1. Introduction

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

2. Design Goals

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

3. Non-Goals

ARDP is intentionally narrow in scope. The following are explicitly out of scope for this specification:¶

1. Agent-to-agent interaction, session management, task execution, and tool invocation protocols. These are addressed by interaction protocols such as MCP and A2A.¶

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

3. Runtime authorization token formats and enforcement proxies. ARDP provides discovery-time authorization scopes; runtime enforcement is delegated to interaction layers.¶

4. Post-execution evidence, audit trails, compliance logging formats, and non-repudiation mechanisms.¶

5. Billing, accounting, reputation, benchmarking, and other business frameworks.¶

6. Naming and bootstrap mechanisms beyond locating an ARDP authority. DNS-based discovery, well-known URIs, or other bootstrap mechanisms may be used alongside ARDP.¶

7. Centralization requirements. ARDP supports domain-scoped authorities and explicit federation without mandating a single global registry.¶

4. Terminology

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

5. Architecture Overview

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

6. Layering and Composition

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

7. Agent Identity

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

aid              = "agent:" local-id "@" authority
local-id         = 1*( ALPHA / DIGIT / "_" / "-" / "." / "/" )
authority        = dns-name / internal-name / opaque-authority
dns-name         = 1*( ALPHA / DIGIT / "-" / "." )  ; see IDNA2008 notes
internal-name    = 1*( ALPHA / DIGIT / "-" / "." )
opaque-authority = "tenant-" 1*( ALPHA / DIGIT / "-" )

8. Registration Model

{
  "version": "1.0",
  "registrar_id": "ardp.example.com",
  "min_ttl": 30,
  "max_ttl": 3600,
  "default_ttl": 300,
  "supported_protocols": ["MCP", "A2A", "HTTP", "gRPC"],
  "supported_auth_methods": ["jws-proof-of-control"],
  "jws_required": true,
  "nonce_endpoint": "/.well-known/ardp/nonce",
  "supported_schema_versions": ["v0"],
  "compliance_mode": "standard"
}

9. Discovery and Resolution

10. Capabilities

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

11. Presence and Health

Presence is limited to: online, offline, degraded.¶

12. Security Considerations

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

{
  "nonce": "abc123...",
  "expires_in": 300
}

13. Federation

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

14. Relationship to Existing Protocols

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

15. Wire Format Sketch (Non-Normative)

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

16. IANA Considerations

17. Capability Schema v0

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

18. Open Issues

• Capability schema evolution¶

• Privacy-preserving discovery¶

• Federation bootstrapping¶

• Consider adopting RFC 8785 (JSON Canonicalization Scheme) for deterministic JSON serialization in a future revision¶

19. References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5234]

Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key (JWK)", RFC 7517, 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, 2019, <https://www.rfc-editor.org/rfc/rfc8615>.