Agent Registry Protocol

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

Software agents can retrieve protected information, invoke tools, modify workflows, initiate transactions, coordinate other agents, and otherwise cause effects on behalf of principals. A relying system evaluating such an action needs more than endpoint discovery. It needs protocol-visible information sufficient to determine which agent is involved, which deployment is executing, who operates or controls it, what delegated authority applies, whether that authority remains effective, and where supporting evidence can be obtained.¶

ARPA provides a registry and resolution protocol for those questions. It does not define a universal trust score, a universal legal theory of agency, a new authentication protocol, or a mandatory credential format. It also does not treat successful registry resolution as an authorization decision. A relying party combines ARPA resolution results with local policy and any external authentication, credential, or assurance mechanisms required for its context.¶

The protocol intentionally preserves several non-implication rules:¶

• discovering an agent does not imply authorization to invoke it;¶

• control of an identifier or cryptographic key does not imply authority to act for a principal;¶

• an advertised capability does not imply permission to exercise that capability;¶

• successful proof verification does not imply that the asserted authority is current or sufficient;¶

• technical federation does not imply governance recognition; and¶

• historical registry state is evidence for evaluation, not by itself a legal determination about a historical act.¶

The wider ARPA project specification [ARPA-SPEC] defines additional governance, assurance, conformance, federation, redress, implementation, and deployment material. This Internet-Draft deliberately narrows that work to interoperable protocol behavior.¶

2. Scope

ARPA defines protocol behavior for:¶

• persistent agent identifiers and deployment identifiers;¶

• registration and update of agent records;¶

• typed relationships between agents, principals, operators, controllers, accountable entities, and other actors;¶

• representation of bounded delegated authority;¶

• capability and assurance references without treating either as authorization;¶

• multidimensional lifecycle and authority status;¶

• current and point-in-time resolution;¶

• registry discovery and query behavior;¶

• event publication sufficient to communicate material status changes;¶

• deterministic processing of stale, conflicting, unavailable, and unsupported state;¶

• error representation;¶

• extension and version negotiation rules; and¶

• evidence references supporting later audit or reliance evaluation.¶

ARPA does not define a universal agent-to-agent messaging protocol, task protocol, reputation system, liability regime, credential format, signature suite, policy language, distributed ledger, or mandatory storage architecture.¶

3. Terminology

Agent: A software entity capable of performing actions with some degree of autonomy.¶

Agent Identifier: A persistent URI identifying a logical agent independently of a particular version or deployment.¶

Deployment: An operational instance of an agent version in a particular execution context.¶

Principal: A person or organization on whose behalf an agent may act.¶

Operator: The entity responsible for running an agent deployment.¶

Controller: An entity with material technical or administrative control over an agent or deployment.¶

Accountable Entity: An entity identified by the registry as accepting a defined accountability role for an agent or class of actions.¶

Relationship: A typed, scoped, time-bounded statement linking two registry subjects.¶

Authority Envelope: A bounded representation of authority delegated from an issuer to a subject, including permitted actions, resources, conditions, prohibitions, delegation depth, and validity interval.¶

Resolver: A client that queries one or more ARPA registries.¶

Relying Party: A system or actor that uses ARPA data as one input to a local trust or authorization decision.¶

Registry: A service that publishes ARPA records and resolution responses.¶

Authoritative Record: A record for which the publishing registry is identified as an authoritative source within the applicable scope.¶

Derived Record: A cached, indexed, projected, or federated representation whose authoritative source is elsewhere.¶

Material State: State whose absence or change can alter an authorization or reliance outcome.¶

4. Protocol Model

5. Identifier Model

6. Record Envelope

Every ARPA record returned by the protocol MUST contain an envelope with at least:¶

{
  "record_type": "agent",
  "record_id": "urn:example:record:1234",
  "subject": "https://registry.example/agents/7f6a",
  "issuer": "https://registry.example",
  "issued_at": "2026-08-18T12:00:00Z",
  "valid_from": "2026-08-18T12:00:00Z",
  "version": "1",
  "source": "https://registry.example/records/1234"
}

A record that expires MUST contain valid_until. A record that supersedes another record SHOULD contain a reference to the superseded record. A derived record MUST identify the authoritative source and SHOULD identify when the derived representation was produced.¶

The record_type value identifies the record semantics. Unknown record types MUST NOT be interpreted as a known type. A resolver MAY retain unknown record types as opaque evidence.¶

7. Agent Resource Model

An agent resource SHOULD contain:¶

• the Agent Identifier;¶

• human-readable labels, if available;¶

• current version and deployment references;¶

• relationship references;¶

• service endpoint references;¶

• capability declaration references;¶

• authority references;¶

• lifecycle status;¶

• evidence references; and¶

• representation metadata including source and freshness.¶

A capability declaration MUST NOT be interpreted as authorization. An endpoint reference MUST NOT be interpreted as proof that the endpoint is controlled by the principal for whom an action is proposed.¶

8. Relationship Model

A relationship record MUST contain:¶

• a relationship type;¶

• a source subject;¶

• a target subject;¶

• an issuer;¶

• scope;¶

• effective time; and¶

• current status.¶

Where absence of a relationship would change an authorization outcome, the response MUST provide either the relationship or a machine-readable indication that authoritative relationship state could not be established.¶

Registries MUST NOT infer a broader relationship from a narrower one. For example, an operated-by relationship MUST NOT be interpreted as an authorized-by relationship unless a separate specification explicitly defines such equivalence.¶

9. Authority Envelope

An authority envelope represents bounded authority. It MUST contain:¶

• issuer;¶

• subject;¶

• actions or an equivalent action scope;¶

• valid_from;¶

• status information; and¶

• a stable identifier for the authority statement.¶

When applicable it MUST also contain:¶

• resources or resource classes;¶

• purpose restrictions;¶

• conditions;¶

• prohibitions;¶

• monetary, rate, geographic, or other limits;¶

• valid_until;¶

• delegation depth or prohibition on further delegation;¶

• evidence references; and¶

• the authority statement from which the issuer derives the delegated scope.¶

An authority envelope MUST NOT be interpreted independently of its current status and applicable parent authority. Delegation MUST NOT increase the issuer's effective action, resource, purpose, temporal, geographic, monetary, or delegation scope.¶

10. Lifecycle and Status

ARPA represents lifecycle state as multiple dimensions rather than a single active flag. A response MAY expose dimensions including registration, operational, security, authority, and assurance status.¶

A registry MUST distinguish at least the following effects when they are applicable:¶

• active or current;¶

• suspended;¶

• revoked;¶

• expired;¶

• superseded;¶

• retired; and¶

• indeterminate or unavailable.¶

A resolver MUST NOT map indeterminate, unavailable, conflicting, or stale material authority state to an affirmative authorization outcome.¶

A registry publishing revocation or suspension SHOULD expose an event or other freshness mechanism enabling consumers to discover the change promptly. A publisher MUST NOT describe revocation as fully converged merely because the registry record changed if downstream enforcement acknowledgements are required by the applicable profile.¶

11. HTTP API

ARPA uses HTTP semantics as defined by [RFC9110]. Registries MUST use HTTPS for network deployments that carry non-public data or authority information unless an equivalent authenticated and confidential transport is provided by the deployment environment.¶

This document defines the following logical resources. Deployments MAY choose different path layouts if discoverable metadata maps the logical operations unambiguously.¶

Use of /.well-known/agent-registry requires an IANA registration before Standards Track publication; see IANA Considerations (Section 18).¶

{
  "protocol": "arpa",
  "protocol_version": "1",
  "issuer": "https://registry.example",
  "api_base": "https://registry.example/api",
  "supported_record_types": [
    "agent", "relationship", "authority", "status"
  ],
  "historical_resolution": true,
  "events_endpoint": "https://registry.example/events"
}

12. Error Handling

Protocol errors SHOULD use Problem Details for HTTP APIs [RFC9457] with an ARPA-specific problem type when interoperable handling is unavailable. The type URI SHOULD identify a stable ARPA problem type. The response SHOULD include an ARPA error code suitable for deterministic client behavior.¶

At minimum, interoperable implementations SHOULD distinguish:¶

• invalid request;¶

• unsupported protocol version;¶

• unsupported record type;¶

• unauthenticated request;¶

• unauthorized request;¶

• record not found;¶

• stale material state;¶

• conflicting authoritative state;¶

• unavailable authoritative state;¶

• unverifiable evidence;¶

• revoked or suspended authority; and¶

• historical reconstruction indeterminate.¶

Clients MUST NOT treat an unknown error code or unknown Problem Details extension as success.¶

13. Event Model

ARPA defines an event envelope for material changes. An event MUST contain:¶

• event identifier;¶

• event type;¶

• subject;¶

• issuer;¶

• event time;¶

• affected record or status reference; and¶

• protocol version.¶

Events SHOULD be immutable once published. A correction SHOULD be represented as a new event referencing the superseded event.¶

Event consumers MUST support duplicate delivery. Processing the same event identifier more than once MUST NOT expand authority or cause a transition that could not result from a single processing of that event.¶

A registry MUST define event ordering semantics. If globally monotonic sequence numbers are unavailable, the registry MUST provide enough source-specific ordering information for consumers to detect gaps or ambiguity within the applicable stream.¶

Revocation and suspension events affecting authority SHOULD be delivered through a mechanism whose expected convergence is documented. A consumer MUST NOT claim enforcement convergence until the acknowledgement or observation requirements of the applicable deployment profile have been satisfied.¶

14. Versioning and Extensions

Protocol versions MUST be explicit in registry metadata and SHOULD be explicit in representations that can cross version boundaries.¶

An implementation receiving a major protocol version it does not support MUST fail explicitly rather than interpret it as a supported version.¶

Extensions MUST use collision-resistant names or registered extension identifiers. An extension MUST specify whether it is ignorable. An implementation MUST fail closed when an unknown non-ignorable extension can affect authority, lifecycle, security, privacy, or evidence semantics.¶

New fields are not automatically safe to ignore. Extension specifications MUST state the processing effect of omission and non-recognition.¶

15. Security Considerations

ARPA exposes information that can influence authorization and operational decisions. An attacker who can forge, suppress, replay, reorder, stale, or selectively disclose registry state can cause both unauthorized action and denial of legitimate action.¶

Implementations MUST authenticate authoritative sources for material state. Deployments MUST define how source authenticity and integrity are established. HTTPS server authentication can provide transport-level source authentication but does not by itself establish that the server is authoritative for a particular principal, agent, relationship, or authority scope.¶

Resolvers MUST evaluate freshness for material state. A cryptographically valid but stale authority statement can be unsafe. Caches and federation layers MUST preserve source, issuance time, validity interval, and status information needed to evaluate freshness.¶

Delegation processing MUST prevent scope amplification. Implementations MUST check that every delegated authority is a subset of the issuer's effective authority after applying conditions, prohibitions, validity, resource scope, action scope, and delegation-depth constraints.¶

Registries and resolvers MUST treat conflicting authoritative state as non-affirmative until the applicable conflict-resolution policy establishes a competent source or otherwise resolves the conflict. Implementations MUST NOT select the most permissive source merely because it enables an action.¶

Historical resolution creates evidence-retention risks. A registry that supports historical queries MUST protect retained records against unauthorized alteration and MUST expose reconstruction limitations rather than fabricate completeness.¶

Events can be replayed, reordered, duplicated, or suppressed. Consumers MUST implement duplicate-safe processing and MUST detect ordering gaps where the source provides sequence information. Material revocation or suspension SHOULD have an out-of-band recovery or resynchronization path when event delivery cannot be trusted.¶

The protocol does not define credential proof formats or cryptographic suites. Deployments using signed credentials, signed HTTP messages, or proof-bearing records MUST select algorithms and key-management practices appropriate to their threat model. A valid signature MUST NOT be treated as proof of current delegated authority without evaluating the signed semantics and lifecycle state.¶

Registry discovery can create enumeration and relationship-disclosure risks. Deployments SHOULD minimize unauthenticated discovery, separate public from restricted metadata, and avoid exposing principal-agent relationships or authority details beyond what the caller is permitted to learn.¶

Implementations MUST apply ordinary HTTP security controls including request size limits, parsing limits, rate limiting, authorization checks, logging controls, and protection against server-side request forgery when dereferencing evidence or federation references.¶

16. Privacy Considerations

Agent registries can expose relationships among people, organizations, agents, deployments, operators, controllers, and delegated authorities. These relationships can reveal organizational structure, sensitive workflows, personal associations, operational capabilities, or transaction intent even when the underlying payloads are not disclosed.¶

Registries SHOULD minimize collected and published relationship data. A record SHOULD contain only the information required for the relying context. Deployments SHOULD prefer opaque or pairwise identifiers when global correlation is unnecessary.¶

Discovery and search interfaces SHOULD be treated as distinct privacy surfaces. A registry MAY permit resolution of a known identifier while denying bulk enumeration or broad search. Authorization for discovery MUST NOT be inferred from authorization for resolution.¶

Historical records increase correlation and retention risk. Deployments MUST define retention periods, access controls, correction procedures, and deletion or tombstoning behavior consistent with their legal and governance obligations. A historical-resolution feature MUST NOT be interpreted as requiring indefinite retention of personal data.¶

Evidence references can leak sensitive information through URLs, identifiers, query strings, or dereference patterns. Implementations SHOULD avoid embedding confidential data in evidence URLs and SHOULD authorize evidence retrieval independently from registry resolution.¶

Logs SHOULD avoid storing unnecessary authority contents, credentials, personal identifiers, or evidence payloads. Where audit requirements require retention, access SHOULD be restricted and retention SHOULD be bounded.¶

Federated registries can amplify privacy risk because data disclosed for one context can be indexed or correlated in another. Federation agreements SHOULD define permitted propagation, purpose restrictions, retention, correction, and withdrawal behavior.¶

ARPA does not define a legal basis for processing personal data. Implementers are responsible for identifying and satisfying applicable privacy and data-protection requirements.¶

17. Operational Considerations

Deployments SHOULD publish operational metadata sufficient for resolvers to understand supported protocol versions, record types, historical-resolution support, event mechanisms, and relevant freshness expectations.¶

A registry SHOULD define service-level expectations for material status propagation. Where authority revocation or suspension affects downstream enforcement, the deployment SHOULD define the expected path from authoritative change to consumer observation and enforcement acknowledgement.¶

Resolvers SHOULD retain enough decision input metadata to reproduce material authority evaluations, subject to privacy and retention constraints. At minimum this normally includes evaluation time, authoritative source, source checkpoint or version, selected records, freshness assessment, and result.¶

Registries SHOULD provide backup, restoration, and compromise-recovery procedures. Recovery MUST NOT silently restore superseded or revoked authority as current. A restored registry SHOULD establish a trusted checkpoint before serving affirmative authority results.¶

18. IANA Considerations

This document requests no IANA actions in -00.¶

A future revision may request registration of /.well-known/agent-registry in the Well-Known URIs registry and may define or request registries for protocol media types, relation types, or error identifiers if interoperability experience shows that centralized registration is warranted.¶

Until such registrations are approved, implementations MUST treat names used by this draft as experimental/project-scoped and MUST NOT represent them as IANA-assigned values.¶

19. Conformance

An implementation claiming conformance to this document MUST identify the protocol version and role or roles for which conformance is claimed.¶

A conforming registry implementation MUST:¶

• expose protocol metadata;¶

• preserve persistent identifier semantics;¶

• distinguish authoritative from derived state;¶

• expose lifecycle and authority status without mapping indeterminate state to affirmative authority;¶

• implement current resolution;¶

• use the defined error behavior or a documented compatible mapping;¶

• preserve extension/version fail-closed rules; and¶

• satisfy the security and privacy requirements applicable to the implemented features.¶

A conforming resolver implementation MUST:¶

• distinguish resolution from authorization;¶

• evaluate material freshness;¶

• fail non-affirmatively on stale, conflicting, unavailable, or unverifiable material authority;¶

• prevent delegation scope amplification when it evaluates authority;¶

• preserve unknown non-ignorable extension behavior; and¶

• retain sufficient decision metadata for reproducibility where it produces authority evaluations.¶

Historical-resolution conformance additionally requires the implementation to distinguish requested-time state, evaluation-time knowledge, later material events, and reconstruction quality.¶

Event conformance additionally requires duplicate-safe processing and documented ordering/gap behavior.¶

20. References to the Wider ARPA Project

The repository-maintained Candidate Specification contains governance, assurance, conformance, federation, implementation, redress, test-vector, and deployment material intentionally omitted from this protocol-focused Internet-Draft. The two documents are related but have separate version lines and publication states.¶

21. Adversarial Authority Processing

This section hardens authority-processing boundaries that can otherwise admit divergent or permissive interpretations. It does not broaden authority. A resolver or authority evaluator MUST treat ambiguity in a material authority boundary as non-affirmative.¶

22. Acknowledgements

The author thanks contributors and reviewers of the wider Agent Registry Protocol project whose implementation, interoperability, governance, security, privacy, and adversarial-hardening work informed this protocol extraction.¶

23. References

Appendix A. Change Log

This section is to be removed by the RFC Editor before publication.¶

Author's Address