Agent Registry Protocol
draft-sankarshan-agent-registry-protocol-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sankarshan Mukhopadhyay | ||
| Last updated | 2026-09-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
ARPA source, implementation, conformance evidence, and issue tracking
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sankarshan-agent-registry-protocol-04
Individual Submission S. Mukhopadhyay
Internet-Draft QBF Consulting LLP
Intended status: Standards Track 29 September 2026
Expires: 2 April 2027
Agent Registry Protocol
draft-sankarshan-agent-registry-protocol-04
Abstract
Software agents increasingly act on behalf of people and
organizations across administrative and security boundaries.
Existing discovery mechanisms can identify an endpoint or advertise a
capability, but they do not by themselves provide a common way to
resolve who operates an agent, the bounded authority under which it
acts, whether that authority is current, or what evidence supports a
reliance decision.
This document defines the Agent Registry Protocol (ARPA), an HTTP and
JSON protocol for publishing and resolving information about software
agents, their operational deployments, typed relationships, bounded
delegated authority, lifecycle status, and associated evidence. ARPA
separates identification, authentication, authorization, assurance,
and lifecycle state. Registration, successful authentication,
capability advertisement, or proof verification does not by itself
establish authority to perform an action.
The protocol is designed to support deterministic fail-safe behavior
when material authority information is revoked, suspended, expired,
stale, conflicting, unavailable, or unverifiable.
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 2 April 2027.
Mukhopadhyay Expires 2 April 2027 [Page 1]
Internet-Draft ARPA September 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Requirements Language . . . . . . . . . . 5
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Separation of Resolution, Decision, and Enforcement . . . 7
4.2. Protocol Roles . . . . . . . . . . . . . . . . . . . . . 7
4.3. Authority Invariants . . . . . . . . . . . . . . . . . . 8
5. Identifier Model . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Agent Identifiers . . . . . . . . . . . . . . . . . . . . 8
5.2. Deployment Identifiers . . . . . . . . . . . . . . . . . 9
6. Record Envelope . . . . . . . . . . . . . . . . . . . . . . . 9
7. Agent Resource Model . . . . . . . . . . . . . . . . . . . . 10
8. Relationship Model . . . . . . . . . . . . . . . . . . . . . 10
9. Authority Envelope . . . . . . . . . . . . . . . . . . . . . 11
10. Lifecycle and Status . . . . . . . . . . . . . . . . . . . . 12
11. HTTP API . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Registry Metadata . . . . . . . . . . . . . . . . . . . 14
11.2. Registration . . . . . . . . . . . . . . . . . . . . . . 14
11.3. Current Resolution . . . . . . . . . . . . . . . . . . . 14
11.4. Historical Resolution . . . . . . . . . . . . . . . . . 15
11.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . 15
11.6. Authority Resolution . . . . . . . . . . . . . . . . . . 15
11.7. Conditional Requests and Caching . . . . . . . . . . . . 16
12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 16
13. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
14. Versioning and Extensions . . . . . . . . . . . . . . . . . . 17
15. Security Considerations . . . . . . . . . . . . . . . . . . . 18
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
17. Operational Considerations . . . . . . . . . . . . . . . . . 20
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
18.1. agentreg URI Scheme . . . . . . . . . . . . . . . . . . 21
Mukhopadhyay Expires 2 April 2027 [Page 2]
Internet-Draft ARPA September 2026
18.2. /.well-known/agent-registry . . . . . . . . . . . . . . 21
18.3. application/agent-registry+json Media Type . . . . . . . 22
19. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 23
20. References to the Wider ARPA Project . . . . . . . . . . . . 24
21. Adversarial Authority Processing . . . . . . . . . . . . . . 24
21.1. Delegation Scope Intersection . . . . . . . . . . . . . 24
21.2. Time Boundaries . . . . . . . . . . . . . . . . . . . . 25
21.3. Non-Applicability . . . . . . . . . . . . . . . . . . . 25
21.4. Recognition Conflicts . . . . . . . . . . . . . . . . . 26
21.5. Revocation and Enforcement Convergence . . . . . . . . . 26
21.6. Reproducible Decisions . . . . . . . . . . . . . . . . . 26
21.7. Proof Input Semantics . . . . . . . . . . . . . . . . . 26
21.8. Relationship to Existing IETF Mechanisms . . . . . . . . 27
22. Protocol Precision for Revision 01 . . . . . . . . . . . . . 27
22.1. Historical Resolution Semantics . . . . . . . . . . . . 27
22.2. HTTP Problem Details . . . . . . . . . . . . . . . . . . 28
22.3. Critical Extension Processing . . . . . . . . . . . . . 28
23. Action-Specific Authority Evaluation . . . . . . . . . . . . 29
23.1. Action Context . . . . . . . . . . . . . . . . . . . . . 29
23.2. Current Authority and Constraint Preservation . . . . . 29
23.3. Approval Binding . . . . . . . . . . . . . . . . . . . . 30
23.4. Collective Principals . . . . . . . . . . . . . . . . . 30
23.5. Execution Binding and Reproducibility . . . . . . . . . 30
24. Relationship to Adjacent IETF Work . . . . . . . . . . . . . 31
25. Wire-Contract Precision for Revision 03 . . . . . . . . . . . 32
25.1. Authority Evaluation Outcomes . . . . . . . . . . . . . 32
25.2. Parent Authority Linkage . . . . . . . . . . . . . . . . 32
25.3. Temporal Boundaries and Clock Profile . . . . . . . . . 33
25.4. Collective-Principal Snapshot Binding . . . . . . . . . 33
25.5. ARPA Problem Details . . . . . . . . . . . . . . . . . . 34
25.5.1. Core Error Codes . . . . . . . . . . . . . . . . . . 34
25.6. Media Type . . . . . . . . . . . . . . . . . . . . . . . 36
25.7. Extension Namespaces . . . . . . . . . . . . . . . . . . 36
25.8. Core Relationship and Event Vocabularies . . . . . . . . 36
26. Federated Trust Resolution and ToIP Composition . . . . . . . 37
26.1. External Authoritative Evidence . . . . . . . . . . . . 37
26.2. ToIP Trust Registry Query Protocol . . . . . . . . . . . 38
26.3. ToIP Trust Spanning Protocol . . . . . . . . . . . . . . 38
26.4. Action Vocabulary and TRQL . . . . . . . . . . . . . . . 39
27. Conformance Evidence and Specification Precedence . . . . . . 39
28. Additional Composability Notes . . . . . . . . . . . . . . . 39
29. Protocol Interoperability and Security Hardening for Revision
04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
29.1. Protocol-Core Wire Structures . . . . . . . . . . . . . 40
29.1.1. Common Record Envelope . . . . . . . . . . . . . . . 40
29.1.2. Agent Resource . . . . . . . . . . . . . . . . . . . 41
29.1.3. Relationship Record . . . . . . . . . . . . . . . . 42
29.1.4. Authority Envelope . . . . . . . . . . . . . . . . . 42
Mukhopadhyay Expires 2 April 2027 [Page 3]
Internet-Draft ARPA September 2026
29.1.5. Event . . . . . . . . . . . . . . . . . . . . . . . 44
29.1.6. Registry Metadata . . . . . . . . . . . . . . . . . 44
29.1.7. Authority Evaluation Result Wire Object . . . . . . 45
29.2. Representation Field Mapping . . . . . . . . . . . . . . 46
29.3. Authority Evaluation Result . . . . . . . . . . . . . . 47
29.4. Status Composition . . . . . . . . . . . . . . . . . . . 47
29.5. Agent Identifier Syntax and Equality . . . . . . . . . . 47
29.6. JSON Proof Inputs . . . . . . . . . . . . . . . . . . . 48
29.7. Freshness and HTTP Caching . . . . . . . . . . . . . . . 48
29.8. Registration Retry Semantics . . . . . . . . . . . . . . 48
29.9. Replacement Semantics . . . . . . . . . . . . . . . . . 49
29.10. Event Ordering, Replay, and Gap Handling . . . . . . . . 49
29.11. Write Authorization . . . . . . . . . . . . . . . . . . 49
29.12. Critical Extensions . . . . . . . . . . . . . . . . . . 50
29.13. Dereference Security . . . . . . . . . . . . . . . . . . 50
29.14. Discovery and Search . . . . . . . . . . . . . . . . . . 50
29.15. HTTP Operation Surface . . . . . . . . . . . . . . . . . 51
29.16. Conformance Matrix . . . . . . . . . . . . . . . . . . . 51
30. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
31. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
31.1. Normative References . . . . . . . . . . . . . . . . . . 51
31.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 54
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56
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.
Mukhopadhyay Expires 2 April 2027 [Page 4]
Internet-Draft ARPA September 2026
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.
1.1. Conventions and Requirements Language
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.
HTTP terminology follows [RFC9110]. JSON follows [RFC8259].
Timestamps use the date-time form of [RFC3339].
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;
Mukhopadhyay Expires 2 April 2027 [Page 5]
Internet-Draft ARPA September 2026
* 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.
Mukhopadhyay Expires 2 April 2027 [Page 6]
Internet-Draft ARPA September 2026
*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
4.1. Separation of Resolution, Decision, and Enforcement
ARPA separates three functions:
1. *Resolution* obtains registry state and evidence references.
2. *Decision* evaluates that state against action context and
relying-party policy.
3. *Enforcement* permits, restricts, or denies an actual action.
A registry response MUST NOT claim that a relying party is required
to authorize an action unless the registry is itself the applicable
policy decision authority for that action and this role is explicitly
represented. A resolver MUST NOT infer authorization solely from
successful resolution.
4.2. Protocol Roles
An implementation can act as one or more of:
* registry publisher;
Mukhopadhyay Expires 2 April 2027 [Page 7]
Internet-Draft ARPA September 2026
* resolver or registry consumer;
* authority evaluator;
* event publisher;
* event consumer or enforcement point; or
* federation participant.
An implementation claiming conformance to one role MUST NOT imply
conformance to another role.
4.3. Authority Invariants
An authority evaluator conforming to this document:
* MUST verify that a delegation issuer possessed the effective
authority being delegated;
* MUST NOT allow delegation to expand the issuer's effective scope;
* MUST apply explicit validity intervals, conditions, prohibitions,
resource limits, action limits, and delegation-depth limits;
* MUST treat revoked, suspended, expired, stale, conflicting,
unavailable, or unverifiable material authority as non-
affirmative;
* MUST NOT infer transitive recognition unless a transitive
relationship is explicitly declared and permitted by policy; and
* MUST retain enough input and result information to explain an
affirmative or negative authority evaluation.
5. Identifier Model
5.1. Agent Identifiers
An Agent Identifier MUST use the agentreg URI scheme defined by this
document and MUST conform to [RFC3986]. The syntax is:
agentreg:<registry-namespace>:<agent-local-id>
Mukhopadhyay Expires 2 April 2027 [Page 8]
Internet-Draft ARPA September 2026
The registry-namespace identifies the registry namespace in which the
local identifier is assigned. The agent-local-id identifies the
logical agent within that namespace. Implementations MUST NOT emit a
different URI scheme as the ARPA Agent Identifier merely because the
agent also has an identifier in another identity or discovery system.
External identifiers MAY be represented as aliases or mapped
identifiers, but they MUST remain distinguishable from the ARPA Agent
Identifier. A resolver receiving an unsupported identifier scheme
MUST NOT silently reinterpret it as an ARPA Agent Identifier; an
explicit mapping mechanism MAY be used when the resulting agentreg
identifier and mapping provenance are preserved.
An Agent Identifier MUST identify the logical agent rather than a
single software build, process, network endpoint, or ephemeral
runtime session.
Registries MUST NOT silently reassign an Agent Identifier to a
different logical agent. If an identifier becomes unusable, the
registry SHOULD publish a terminal status or supersession
relationship rather than reuse it.
5.2. Deployment Identifiers
A deployment MUST have an identifier unique within the scope of the
authoritative registry. A deployment identifier SHOULD be globally
unique when deployments are expected to move between registries or
administrative domains.
A deployment record MUST identify the logical Agent Identifier and
SHOULD identify the agent version from which the deployment was
created.
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"
}
Mukhopadhyay Expires 2 April 2027 [Page 9]
Internet-Draft ARPA September 2026
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;
Mukhopadhyay Expires 2 April 2027 [Page 10]
Internet-Draft ARPA September 2026
* 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 or controlled_by relationship MUST NOT be
interpreted as acts_for or delegates_to without separate authority
evidence.
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;
Mukhopadhyay Expires 2 April 2027 [Page 11]
Internet-Draft ARPA September 2026
* 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.
Mukhopadhyay Expires 2 April 2027 [Page 12]
Internet-Draft ARPA September 2026
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.
+===================+========================+====================+
| Operation | Example target | Purpose |
+===================+========================+====================+
| Registry metadata | GET /.well-known/ | Discover protocol |
| | agent-registry | metadata |
+-------------------+------------------------+--------------------+
| List/discover | GET /agents | Query discoverable |
| agents | | agents |
+-------------------+------------------------+--------------------+
| Resolve agent | GET /agents/{id} | Resolve current |
| | | agent state |
+-------------------+------------------------+--------------------+
| Historical | GET | Resolve effective- |
| resolution | /agents/{id}?at={time} | time state |
+-------------------+------------------------+--------------------+
| Resolve authority | GET | Resolve authority |
| | /agents/{id}/authority | statements |
+-------------------+------------------------+--------------------+
| Resolve status | GET | Resolve lifecycle/ |
| | /agents/{id}/status | status state |
+-------------------+------------------------+--------------------+
| Register agent | POST /agents | Create an agent |
| | | registration |
+-------------------+------------------------+--------------------+
| Update | PUT /agents/{id} | Replace an owned |
| registration | | registration |
+-------------------+------------------------+--------------------+
Table 1
Use of /.well-known/agent-registry requires an IANA registration
before Standards Track publication; see IANA Considerations
(Section 18).
Mukhopadhyay Expires 2 April 2027 [Page 13]
Internet-Draft ARPA September 2026
11.1. Registry Metadata
A registry metadata response SHOULD contain:
{
"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"
}
The metadata endpoint MUST NOT imply that every advertised optional
feature is authorized for every caller. Access control remains
operation-specific.
11.2. Registration
A client creating a registration sends POST to the registration
collection with a JSON representation of the requested agent record.
The registry MUST authenticate and authorize the registration request
according to local policy. ARPA does not define that authentication
mechanism.
On successful creation, the registry SHOULD return 201 Created and a
Location header identifying the new agent resource. A retry-safe
deployment SHOULD support an application-level idempotency mechanism
and MUST document its semantics.
A registry MUST reject a request that would reassign an existing
persistent Agent Identifier to a different logical agent.
11.3. Current Resolution
A successful current-state resolution returns 200 OK with the current
representation and sufficient freshness/provenance metadata for the
client to distinguish authoritative from derived state.
A response MUST identify when material state is derived or cached.
Derived material authority state MUST include the authoritative
source and freshness information.
Mukhopadhyay Expires 2 April 2027 [Page 14]
Internet-Draft ARPA September 2026
404 Not Found means that the queried registry has no resolvable
resource for the supplied identifier. It MUST NOT be interpreted as
evidence that the agent does not exist in any other registry.
11.4. Historical Resolution
Historical resolution uses an at query parameter containing an
[RFC3339] timestamp. The response MUST distinguish:
* the requested effective time;
* the time at which the resolution was performed;
* records selected as effective at the requested time;
* later material events known at evaluation time; and
* reconstruction completeness or limitations.
A historical response MUST NOT silently apply current status to the
requested historical time or silently ignore later events that
materially affect interpretation.
If the registry cannot reconstruct material historical state with
sufficient confidence, it MUST return an indeterminate reconstruction
status and MUST NOT present the result as an authoritative
affirmative determination.
11.5. Discovery
Discovery endpoints are informational. Search or list results MUST
NOT imply authorization, endorsement, assurance, or permission to
invoke an agent.
A registry SHOULD minimize information disclosed through
unauthenticated discovery. Sensitive relationships, principal
linkage, delegated authority details, or operational metadata SHOULD
require authorization when disclosure creates material privacy or
security risk.
11.6. Authority Resolution
Authority resolution returns one or more authority envelopes and
their status. If the registry knows that required parent authority,
status, or evidence is missing, stale, conflicting, or unavailable,
the response MUST expose that condition rather than omit it in a way
that could be interpreted as affirmative authority.
Mukhopadhyay Expires 2 April 2027 [Page 15]
Internet-Draft ARPA September 2026
11.7. Conditional Requests and Caching
Registries SHOULD provide validators such as ETag where stable
representation validators are available. Resolvers SHOULD use
conditional requests to reduce load while retaining freshness.
Responses containing authority or security status MUST define cache
behavior appropriate to the revocation and freshness requirements of
the deployment. Shared caches MUST NOT store confidential responses
unless explicitly permitted by applicable HTTP caching rules
[RFC9111] and response directives.
A stale cached response MUST NOT be used to produce an affirmative
authority result when the applicable freshness policy requires newer
authoritative state.
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
Mukhopadhyay Expires 2 April 2027 [Page 16]
Internet-Draft ARPA September 2026
* 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.
Mukhopadhyay Expires 2 April 2027 [Page 17]
Internet-Draft ARPA September 2026
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.
Mukhopadhyay Expires 2 April 2027 [Page 18]
Internet-Draft ARPA September 2026
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.
Mukhopadhyay Expires 2 April 2027 [Page 19]
Internet-Draft ARPA September 2026
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.
Mukhopadhyay Expires 2 April 2027 [Page 20]
Internet-Draft ARPA September 2026
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
18.1. agentreg URI Scheme
This document requests permanent registration of the agentreg URI
scheme in the URI Schemes registry in accordance with [RFC7595].
Scheme name: agentreg
Status: Permanent
Applications/protocols that use this scheme: Agent Registry Protocol
(ARPA).
Contact: the author of this document.
Change controller: IETF.
References: this document, Identifier Model and Security
Considerations.
The scheme-specific syntax is agentreg:<registry-namespace>:<agent-
local-id>. The scheme identifies an ARPA Agent Identifier; it does
not by itself confer authority, recognition, assurance, or
permission. Security considerations are described in the Security
Considerations section of this document.
18.2. /.well-known/agent-registry
This document requests registration of the agent-registry well-known
URI suffix in the Well-Known URIs registry in accordance with
[RFC8615].
URI suffix: agent-registry
Change controller: IETF.
Specification document: this document, Registry Metadata.
Related information: the resource identifies ARPA registry metadata
and discovery information. A representation SHOULD use a media type
appropriate to the selected representation format; JSON deployments
Mukhopadhyay Expires 2 April 2027 [Page 21]
Internet-Draft ARPA September 2026
SHOULD use application/agent-registry+json; application/json MAY be
accepted only as a semantics-identical compatibility fallback.
Access control remains operation-specific, and discovery of this
resource does not imply authority, recognition, assurance,
endorsement, or permission to invoke any discovered agent.
No IANA registry for project-specific relationship types, extension
namespaces, reason codes, or conformance profiles is requested by
this revision.
18.3. application/agent-registry+json Media Type
This document requests registration of the media type application/
agent-registry+json in accordance with [RFC6838].
Type name: application
Subtype name: agent-registry+json
Required parameters: none
Optional parameters: none
Encoding considerations: binary; JSON representations use UTF-8 as
required by [RFC8259].
Security considerations: see the Security Considerations and Privacy
Considerations sections of this document. ARPA representations can
expose authority, relationship, lifecycle, endpoint, and evidence
information and therefore can be security- and privacy-sensitive.
Interoperability considerations: protocol/profile versioning is
carried in ARPA metadata and representations, not inferred from a
media-type version parameter. application/json may be supported only
as a semantics-identical compatibility fallback.
Published specification: this document.
Applications that use this media type: Agent Registry Protocol
implementations.
Fragment identifier considerations: none defined by this document.
Additional information: none.
Person and email address to contact for further information: the
author of this document.
Mukhopadhyay Expires 2 April 2027 [Page 22]
Internet-Draft ARPA September 2026
Intended usage: COMMON
Restrictions on usage: none.
Author: the author of this document.
Change controller: IETF.
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;
Mukhopadhyay Expires 2 April 2027 [Page 23]
Internet-Draft ARPA September 2026
* 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.
21.1. Delegation Scope Intersection
The effective authority of a downstream delegation MUST be the
semantic intersection of the issuer's effective authority and the
downstream delegation's declared scope.
For every constrained dimension, the evaluator MUST establish that
the downstream constraint denotes a semantic subset of the effective
upstream constraint. Relevant dimensions include actions, resources,
purposes, jurisdictions, time, quantitative limits, approvals,
prohibitions, assurance requirements, deployment constraints, and
delegation depth.
Omission of an upstream constraint MUST NOT remove or wildcard that
constraint. An omitted constrained dimension inherits the effective
upstream constraint unchanged.
Mukhopadhyay Expires 2 April 2027 [Page 24]
Internet-Draft ARPA September 2026
If two scope expressions use different vocabularies, taxonomies,
jurisdiction models, resource grammars, or policy languages and no
governed subset relation can be established, the evaluator MUST
return a non-affirmative result. It MUST NOT infer narrowing from
syntactic similarity.
A downstream delegation MUST NOT remove a mandatory upstream
prohibition merely by omitting it.
21.2. Time Boundaries
Unless a deployment profile defines a stricter rule, validity
intervals are half-open: an authority is temporally applicable when
valid_from <= evaluation_time < valid_until. If valid_until is
absent, no upper time bound is asserted by that field, but
revocation, suspension, supersession, or another material status
boundary still applies.
An action evaluated exactly at valid_until is outside the validity
interval.
A consequential deployment MUST define permitted clock skew and
timestamp precision. Future-dated or clock-ambiguous material status
outside the permitted skew MUST NOT yield an affirmative authority
result.
Where contradictory material events have the same wall-clock
timestamp, an authoritative sequence, checkpoint, or equivalent
ordering mechanism MUST resolve their order. If the contradiction
remains unordered, the affected state MUST be non-affirmative.
21.3. Non-Applicability
not_applicable is not an authority-failure result. It MAY be
returned only when the requested operation is outside the declared
authority-evaluation domain of the selected policy or profile.
Missing delegation, expired or revoked authority, unavailable or
unsupported evidence, an unrecognized issuer, incomparable scope,
stale material state, conflicting material state, or inability to
determine authority MUST NOT be represented as not_applicable.
Mukhopadhyay Expires 2 April 2027 [Page 25]
Internet-Draft ARPA September 2026
21.4. Recognition Conflicts
A published governance rule MAY establish which source is competent
for a particular record type and scope. Where two or more
simultaneously competent authoritative sources conflict and no
applicable rule deterministically resolves the conflict, the
evaluator MUST return a non-affirmative result. It MUST NOT select
the most permissive source or retain an earlier affirmative result
merely because it is cached.
21.5. Revocation and Enforcement Convergence
An effective authoritative revocation immediately makes the revoked
authority non-affirmative for new authority evaluations. Pending or
failed enforcement acknowledgement MUST NOT restore or extend that
authority.
Revocation convergence is a separate evidence property describing
whether applicable enforcement surfaces have acknowledged
application. A propagation deadline is an operational bound and MUST
NOT be treated as evidence of convergence.
21.6. Reproducible Decisions
For a consequential decision, reproducibility requires the request
and material context, evaluation time, policy identifier and version,
selected authoritative records or digests, material source
checkpoints or sequence positions, freshness inputs, and recognition
or issuer-competence state.
Where material state is drawn from multiple independently ordered
sources, a decision receipt SHOULD identify the source checkpoint set
sufficient to reconstruct the evaluated snapshot. If a coherent
material snapshot cannot be established, the decision MUST be non-
affirmative.
21.7. Proof Input Semantics
A proof mechanism used for a normative ARPA record MUST define the
proof input transformation, excluded or transformed proof fields,
deterministic encoding, algorithm or suite identifier, verification-
method interpretation, key-status evaluation time, and any domain-
separation or replay-binding semantics required by the mechanism.
Canonicalization alone does not define the logical object covered by
a proof. Successful proof verification MUST NOT be interpreted as
current authority, issuer competence, governance recognition, or
acceptable reliance.
Mukhopadhyay Expires 2 April 2027 [Page 26]
Internet-Draft ARPA September 2026
21.8. Relationship to Existing IETF Mechanisms
ARPA is designed to compose with existing IETF mechanisms rather than
redefine them. OAuth 2.0 [RFC6749] and OAuth Authorization Server
Metadata [RFC8414] can provide authorization and discovery inputs,
but possession of an OAuth token or discovery of an authorization
server does not by itself establish the registry-visible delegated-
authority state defined by ARPA. The /.well-known/agent-registry
discovery convention follows the Well-Known URI model in [RFC8615]
and requires the registration discussed in the IANA Considerations
section before Standards Track publication. Deployments that use
HTTP Message Signatures [RFC9421] can protect message authenticity
and integrity, but successful signature verification MUST NOT be
treated as proof that the signer has current delegated authority for
the requested action.
22. Protocol Precision for Revision 01
This section carries protocol-core precision requirements derived
from ARPA Candidate Protocol Precision Amendment ARPA-CAND-PP-01,
against the ARPA v0.9.0 Candidate normative baseline. It does not
import project-only governance, conformance profiles, A2A
integration, TRQP projection, or redress workflows.
22.1. Historical Resolution Semantics
Historical resolution is a reconstruction operation rather than a
simple timestamp filter over current state.
A successful historical-resolution result MUST identify, directly or
by stable reference:
* the requested effective time;
* the resolution or evaluation time;
* the material records selected as effective at the requested time;
* source and version or checkpoint provenance for selected material
records;
* later material events known at evaluation time that affect
interpretation; and
* reconstruction quality or limitations.
Mukhopadhyay Expires 2 April 2027 [Page 27]
Internet-Draft ARPA September 2026
A registry MUST NOT silently substitute current state for requested-
time state. It MUST NOT silently omit a later material event when
that event changes safe interpretation of the historical result.
If material historical evidence is unavailable, conflicting, fails
integrity validation, or cannot be reconstructed to the degree
required by applicable policy, the result MUST remain non-affirmative
and MUST expose the applicable reconstruction condition.
The HTTP path layout for the logical historical-resolution operation
is discoverable rather than normative. A deployment MAY use an at
parameter, a dedicated historical-resolution resource, or another
unambiguous operation mapping, provided that the semantic result
above is preserved.
22.2. HTTP Problem Details
An ARPA HTTP API MUST represent protocol-significant errors using
Problem Details [RFC9457] unless a governing transport profile
defines another interoperable error representation.
A protocol-significant Problem Details response MUST provide a stable
problem type, the applicable HTTP status, and a stable ARPA code.
Human-readable title and detail text is informative and MUST NOT be
the sole machine contract for client behavior.
A client that does not recognize an ARPA error code or Problem
Details extension MUST NOT interpret the response as success.
Unknown error semantics affecting authority, integrity, lifecycle, or
historical reconstruction remain non-affirmative.
Problem extensions MAY include reason codes, correlation identifiers,
and retry metadata. Such fields MUST NOT expose confidential
evidence, hidden authority relationships, internal exception details,
or other security-sensitive implementation state beyond the caller's
authorization.
22.3. Critical Extension Processing
An extension that can change interpretation of core identity,
authority, lifecycle, evidence, proof, recognition, or decision
semantics MUST declare whether it is critical to processing.
A critical extension MUST identify a namespace and version sufficient
for a receiver to determine whether it supports the required
semantics.
Mukhopadhyay Expires 2 April 2027 [Page 28]
Internet-Draft ARPA September 2026
If a receiver does not understand or support a critical extension
material to the requested operation, it MUST return a non-affirmative
result or protocol error. It MUST NOT ignore the extension and
continue as though it were absent.
Unknown non-critical extensions MAY be ignored or retained as opaque
data only when doing so cannot change core interpretation, broaden
authority, suppress a prohibition, hide a lifecycle restriction, or
convert unknown or indeterminate state into success.
An extension MUST NOT redefine a core ARPA field in place. A
semantic change to a core field requires an applicable protocol-
version change.
23. Action-Specific Authority Evaluation
ARPA resolution can expose authority state, but consequential systems
often need to decide whether that state supports one particular
action at one particular time. This section defines the protocol-
visible invariants for such an evaluation. It does not define a
universal policy language or require that the registry make the final
authorization decision.
23.1. Action Context
An authority evaluation that can affect whether a material action is
accepted MUST be bound to an explicit action context. The context
MUST identify the action or action class, the target resource,
evaluation time, and every material constraint needed to interpret
the authority envelope.
Where an approval, signature, receipt, or downstream execution could
otherwise be replayed or substituted across actions, the context MUST
also contain a canonical action digest or equivalent stable binding.
Successful authentication, registration, discovery, capability
advertisement, signature verification, or registry resolution MUST
NOT by itself be treated as authority for that action.
23.2. Current Authority and Constraint Preservation
An affirmative authority evaluation MUST require current effective
authority at evaluation time.
Expired, suspended, revoked, stale, conflicting, unavailable,
unverifiable, or otherwise indeterminate material authority state
MUST NOT produce an affirmative result.
Mukhopadhyay Expires 2 April 2027 [Page 29]
Internet-Draft ARPA September 2026
The evaluator MUST preserve all applicable action, resource, purpose,
counterparty, jurisdiction, value, rate, temporal, prohibition, and
delegation-depth constraints. Evaluation MUST NOT enlarge an
authority envelope.
23.3. Approval Binding
When additional approval is required, every approval counted by the
evaluator MUST be bound to the exact action being evaluated or to a
canonical digest that unambiguously identifies that action.
An approval for a different action, resource, amount, counterparty,
material parameter, or action digest MUST NOT satisfy the
requirement. Expired, revoked, unverifiable, or materially
incomplete approval evidence MUST NOT be counted.
When required approval evidence is missing or its current state
cannot be established, the outcome MUST remain non-affirmative.
23.4. Collective Principals
Some principals exercise authority collectively through a threshold,
quorum, role, or other governed exercise rule. ARPA does not require
a particular collective-identifier format or threshold cryptosystem,
but an evaluator processing collective-principal authority MUST
establish the current controller or membership set, the current
exercise rule, and the contributions counted toward satisfaction of
that rule.
Membership in a collective MUST NOT be interpreted as independent
possession of the collective authority.
A controller MUST NOT be counted more than once toward a threshold
unless the governing rule explicitly defines multiple independently
exercisable roles and the evidence establishes those roles.
Stale membership or a superseded exercise rule MUST NOT authorize a
new material action. Missing material membership or rule evidence
MUST remain indeterminate.
23.5. Execution Binding and Reproducibility
A downstream system MUST NOT accept or execute a materially different
action context from the one evaluated without a new authority
evaluation or a policy-proven equivalence.
Mukhopadhyay Expires 2 April 2027 [Page 30]
Internet-Draft ARPA September 2026
An implementation producing an authority evaluation SHOULD retain
enough decision input metadata to reproduce material results, subject
to privacy and retention constraints. This normally includes
evaluation time, authoritative source or checkpoint, selected
authority/lifecycle records, the action context or action digest,
material constraints, approval or collective-rule evidence, and the
result.
24. Relationship to Adjacent IETF Work
ARPA is intended to compose with existing identity, authorization,
attestation, and transparency mechanisms rather than replace them.
The WIMSE architecture [WIMSE-ARCH] defines workload identity and
describes delegation and impersonation as security-context concerns
that can be bound to workload identity. ARPA can consume workload
identity as evidence about the executing workload while separately
resolving agent/principal relationships, bounded authority, lifecycle
state, and historical authority context. A WIMSE-authenticated
workload is therefore not automatically authorized under ARPA.
OAuth 2.0 Token Exchange [RFC8693] provides a mechanism for
exchanging security tokens and representing delegation or
impersonation in token-processing systems. ARPA does not replace
that grant or token mechanism. An OAuth token can be an input to
authorization, while ARPA supplies registry-visible authority
provenance, scope, lifecycle, relationship, and reconstruction
evidence that a relying party can evaluate alongside the token.
Current WIMSE discussion of cross-organizational agent delegation
[WIMSE-CROSS-ORG] identifies recursive attenuation, principal
binding, independently administered domains, and verifiable
delegation chains as open requirements. ARPA's contribution is
complementary: it defines registry-visible bounded authority and
fail-safe resolution semantics, including current/historical state
and action-specific evaluation. It does not require that delegated
authority be encoded in a particular credential or token format.
Remote attestation under the RATS architecture [RFC9334] can provide
evidence about an execution environment and appraisal results. Such
evidence MAY be referenced by ARPA as assurance input, but successful
attestation MUST NOT be interpreted as proof that a principal
delegated authority for a particular action.
Mukhopadhyay Expires 2 April 2027 [Page 31]
Internet-Draft ARPA September 2026
SCITT [RFC9943] provides transparency architecture for signed
statements and verifiable receipts. ARPA MAY reference transparency
evidence or receipts to strengthen provenance and later audit, but
inclusion in a transparency service MUST NOT confer agent authority,
governance recognition, or permission to act.
These boundaries preserve a central ARPA rule: identity,
authentication, evidence integrity, transparency, capability, and
delegated authority are related but distinct protocol properties.
25. Wire-Contract Precision for Revision 03
This section promotes protocol-core wire-contract semantics from ARPA
Candidate v0.10.0 and Candidate Wire-Contract Coherence Amendment PP-
03. The project schemas and vectors are implementation evidence; the
normative requirements for this Internet-Draft are the requirements
stated here.
25.1. Authority Evaluation Outcomes
An authority evaluation outcome MUST be one of allow,
allow_with_conditions, deny, indeterminate, or not_applicable.
not_applicable is a normal authority-evaluation outcome. It is not a
lifecycle state and it is not an HTTP or protocol error. It MAY be
returned only when the selected policy or profile does not govern the
requested operation. A not_applicable result MUST include at least
one stable reason code identifying the non-applicability basis.
Missing authority, missing delegation, expired, revoked or suspended
authority, stale or conflicting material state, an unknown critical
extension, unavailable or unsupported material evidence, incomparable
scope, an unrecognized issuer, or inability to determine authority
MUST NOT produce not_applicable. Those conditions produce deny,
indeterminate, or a protocol error according to the failure layer.
Protocol errors represent malformed requests, unsupported
protocol/profile/version negotiation, invalid wire representations,
unavailable protocol services, or equivalent failures. They MUST NOT
be used as a substitute for a valid policy outcome.
25.2. Parent Authority Linkage
A delegated authority envelope MUST identify the parent authority
statement from which its delegated scope derives using derives_from
or an exactly equivalent field defined by a negotiated representation
profile.
Mukhopadhyay Expires 2 April 2027 [Page 32]
Internet-Draft ARPA September 2026
A root authority grant MAY omit derives_from. A delegated envelope
MUST NOT omit the parent link when the omission prevents a resolver
from evaluating monotonic delegation or current parent status.
Implementations MUST NOT infer parent authority solely from issuer
identity, record ordering, network location, or an unauthenticated
relationship.
25.3. Temporal Boundaries and Clock Profile
Authority validity is half-open:
valid_from <= evaluation_time < valid_until
An evaluation exactly at valid_from is inside the interval. An
evaluation exactly at valid_until is outside it.
Where timestamp precision or clock skew can materially affect an
authority decision, the selected deployment or profile MUST expose,
directly or by stable policy reference, the timestamp precision,
maximum permitted clock skew, and treatment of future-dated material
observations.
This document does not define a universal skew tolerance. Clock-
ambiguous material authority state MUST remain non-affirmative until
the applicable policy resolves the ambiguity.
25.4. Collective-Principal Snapshot Binding
A threshold, quorum, role, or other collective-principal evaluation
MUST bind the decision to one stated membership/controller and
exercise-rule snapshot, identified by a stable checkpoint, version,
or digest.
Each approval counted toward the collective rule MUST be valid under
that same snapshot unless the governing rule explicitly permits
cross-snapshot composition and the evidence proves the permitted
transition.
Approvals collected across membership removal and re-addition,
material role change, exercise-rule change, or stale membership MUST
NOT be combined by default.
Decision evidence MUST retain the snapshot/checkpoint used for the
membership and exercise-rule evaluation.
Mukhopadhyay Expires 2 April 2027 [Page 33]
Internet-Draft ARPA September 2026
25.5. ARPA Problem Details
Protocol-significant HTTP errors MUST use Problem Details [RFC9457]
unless a negotiated transport profile defines another interoperable
error representation.
An ARPA Problem Details object MUST contain type, title, status, and
code. The code value MUST be a stable machine-readable ARPA error
code. The type URI SHOULD be stable, and dereferenceable
documentation SHOULD describe its semantics.
Human-readable title or detail fields MUST NOT be the sole machine
contract. A client that encounters an unknown material error code or
extension MUST NOT interpret the response as success.
25.5.1. Core Error Codes
For the protocol failures named by this document, implementations
MUST use the following stable code values when the corresponding
condition applies:
Mukhopadhyay Expires 2 April 2027 [Page 34]
Internet-Draft ARPA September 2026
+==============================+===============================+
| Condition | Code |
+==============================+===============================+
| invalid request | ARPA-INVALID-REQUEST |
+------------------------------+-------------------------------+
| unsupported protocol version | ARPA-UNSUPPORTED-VERSION |
+------------------------------+-------------------------------+
| unsupported record/profile | ARPA-UNSUPPORTED-PROFILE |
| semantics | |
+------------------------------+-------------------------------+
| record/identifier not found | ARPA-IDENTIFIER-NOT-FOUND |
+------------------------------+-------------------------------+
| record not authorized for | ARPA-RECORD-NOT-AUTHORIZED |
| caller | |
+------------------------------+-------------------------------+
| invalid schema/wire | ARPA-SCHEMA-INVALID |
| representation | |
+------------------------------+-------------------------------+
| unverifiable proof/evidence | ARPA-PROOF-INVALID |
+------------------------------+-------------------------------+
| issuer not authorized for | ARPA-ISSUER-NOT-AUTHORIZED |
| asserted scope | |
+------------------------------+-------------------------------+
| stale material status | ARPA-STATUS-STALE |
+------------------------------+-------------------------------+
| expired authority | ARPA-AUTHORITY-EXPIRED |
+------------------------------+-------------------------------+
| revoked authority | ARPA-AUTHORITY-REVOKED |
+------------------------------+-------------------------------+
| indeterminate authority | ARPA-AUTHORITY-INDETERMINATE |
+------------------------------+-------------------------------+
| delegated scope exceeds | ARPA-DELEGATION-EXCEEDS-SCOPE |
| parent scope | |
+------------------------------+-------------------------------+
| conflicting material status | ARPA-CONFLICTING-STATUS |
+------------------------------+-------------------------------+
| temporarily unavailable | ARPA-TEMPORARILY-UNAVAILABLE |
| protocol service | |
+------------------------------+-------------------------------+
Table 2
A profile MAY define additional codes. Additional codes MUST be
collision-resistant within their defining namespace and MUST NOT
redefine the semantics of a core code.
Mukhopadhyay Expires 2 April 2027 [Page 35]
Internet-Draft ARPA September 2026
25.6. Media Type
The media type for ARPA JSON representations is application/agent-
registry+json.
HTTP servers implementing this representation MUST emit Content-Type:
application/agent-registry+json for ARPA-specific JSON
representations unless an explicit compatibility mode has negotiated
application/json.
A deployment MAY support application/json as a compatibility fallback
only when the represented ARPA semantics are identical. A server
MUST NOT change normative interpretation solely because the generic
fallback is used.
Protocol and profile version negotiation remain explicit in the
representation or registry metadata. This revision does not define a
media-type version parameter.
25.7. Extension Namespaces
Extensions MUST use collision-resistant identifiers. URI- or URN-
based namespace identifiers SHOULD use an authority controlled by the
extension owner. An extension MUST identify its owner/authority,
version, criticality, and processing semantics.
An implementation MUST NOT treat an unrecognized namespace as a known
extension merely because its local name resembles a known field.
25.8. Core Relationship and Event Vocabularies
For protocol-core relationships represented by this document, the
following values have stable meanings:
* operated_by identifies an operator relationship;
* controlled_by identifies a control relationship;
* accountable_to identifies an accountability relationship;
* acts_for identifies an explicitly asserted principal/agency
relationship;
* delegates_to identifies an explicit delegation relationship; and
* recognized_by identifies a recognition relationship.
Mukhopadhyay Expires 2 April 2027 [Page 36]
Internet-Draft ARPA September 2026
An operated_by or controlled_by relationship MUST NOT be interpreted
as acts_for or delegates_to without separate authority evidence.
For material lifecycle and authority changes, implementations
supporting the corresponding event MUST use stable event-type values
including agent.updated, agent.suspended, agent.revoked,
delegation.issued, delegation.suspended, delegation.revoked,
recognition.added, recognition.changed, recognition.withdrawn, and
status.restored.
An extension MAY define additional relationship or event values using
the extension namespace rules above. Unknown values MUST NOT be
reinterpreted as known core values.
26. Federated Trust Resolution and ToIP Composition
ARPA can consume authoritative evidence from trust infrastructures
outside an ARPA registry. Such composition does not transfer
decision semantics from the external protocol into ARPA.
26.1. External Authoritative Evidence
When an external trust query materially contributes to an ARPA
authority result, the evaluator MUST retain, directly or by stable
reference:
* the external protocol and protocol version;
* source registry or endpoint identity;
* governing authority/trust-domain context when supplied;
* the query inputs material to the result;
* requested/effective time and evaluation time when applicable;
* the returned authorization/recognition result;
* freshness, validity, or expiry information;
* integrity/authentication evidence available to the evaluator; and
* enough source/checkpoint information to reproduce the material
evaluation.
An external affirmative result MUST NOT bypass ARPA lifecycle,
delegation, action-binding, conflict, critical-extension, freshness,
or relying-policy rules.
Mukhopadhyay Expires 2 April 2027 [Page 37]
Internet-Draft ARPA September 2026
26.2. ToIP Trust Registry Query Protocol
The Trust Over IP Trust Registry Query Protocol (TRQP) v2.0 [TRQP-V2]
defines read-only Authorization and Recognition queries over trust
registries.
An ARPA implementation MAY use a TRQP Authorization response as
evidence that an authority states that an entity is authorized for an
action/resource context. It MAY use a TRQP Recognition response as
evidence about authority recognition.
A TRQP result MUST be treated as evidence input to ARPA evaluation,
not as an ARPA allow result by substitution. The ARPA evaluator MUST
still determine whether the evidence is current, applicable to the
exact action context, within the relevant delegation/recognition
scope, and compatible with other material authority state.
TRQP v2.0 does not standardize Delegation queries. ARPA delegation
processing therefore MUST NOT depend on a hypothetical TRQP
delegation operation. If a later TRQP revision supplies delegation
evidence, ARPA MAY consume it only when the evidence preserves ARPA
monotonic delegation, parent linkage, lifecycle, temporal, and
provenance requirements.
26.3. ToIP Trust Spanning Protocol
The Trust Over IP Trust Spanning Protocol (TSP) [TOIP-TSP] defines a
spanning-layer mechanism for authenticated and optionally
confidential exchanges between endpoints identified by Verifiable
Identifiers. The current ToIP specification is experimental.
An ARPA deployment MAY carry ARPA messages over TSP or use a TSP
relationship as one source of endpoint/authentication evidence. TSP
support is not required for ARPA conformance.
Establishing a TSP relationship, secure channel, or VID binding MUST
NOT by itself establish delegated authority, governance recognition,
authorization for an action, collective-principal approval, or
current lifecycle validity.
A TSP VID MAY be retained as an external or alternate identifier
under ARPA mapping rules. This revision does not standardize a TSP-
VID-to-agentreg: projection.
Mukhopadhyay Expires 2 April 2027 [Page 38]
Internet-Draft ARPA September 2026
26.4. Action Vocabulary and TRQL
ARPA requires an explicit action/action-class context and stable
action binding where replay or substitution is possible. This
revision does not require the ToIP Trust Registry Query Language
(TRQL) or any universal action vocabulary.
A deployment MAY map a governance-defined or TRQL-defined action
vocabulary into the ARPA action context when the mapping is explicit,
versioned, and does not broaden authority.
27. Conformance Evidence and Specification Precedence
The wider ARPA project maintains JSON Schemas, controlled registries,
conformance vectors, and validators for the Candidate specification.
Candidate v0.10.0 and PP-03 artifacts at repository commit
7200c8512a13615d84c9711ac550da36ae338dd9 are informative
implementation and test evidence for the wire semantics promoted by
this revision.
Those external project artifacts do not override this document for
IETF conformance.
Where this Internet-Draft and the wider ARPA Candidate Specification
conflict on protocol-core behavior defined by this document, this
Internet-Draft is authoritative for conformance to this Internet-
Draft. The Candidate Specification remains authoritative for project
governance, assurance, profiles, redress, implementation guidance,
and other material outside this document's scope.
A conforming implementation SHOULD test both positive and negative
boundary cases for not_applicable, half-open time validity,
collective-principal snapshot binding, parent authority linkage,
unknown material errors/extensions, and externally sourced authority
evidence.
28. Additional Composability Notes
The WIMSE architecture [WIMSE-ARCH] treats AI/ML intermediaries and
delegated workloads as a workload-identity problem that can involve
multi-hop delegation. ARPA supplies registry-visible authority,
lifecycle, and action-bound evidence; it does not replace workload
authentication.
Mukhopadhyay Expires 2 April 2027 [Page 39]
Internet-Draft ARPA September 2026
The cross-organizational delegation problem statement
[WIMSE-CROSS-ORG] describes requirements for authority that crosses
administrative boundaries. ARPA's monotonic delegation and evidence-
resolution semantics address one protocol layer of that problem
without claiming to solve workload authentication or token issuance.
Where a deployment uses SCITT [RFC9943], a SCITT receipt identifier
MAY be carried as an ARPA evidence reference. A SCITT receipt, log
entry, or transparency inclusion MUST NOT by itself confer agent
authority.
29. Protocol Interoperability and Security Hardening for Revision 04
This section promotes protocol-core semantics from ARPA Candidate
v0.10.0 and Candidate Protocol Interoperability Amendment PP-04. The
Candidate amendment and project artifacts are evidence and source
governance; the normative requirements for this Internet-Draft are
stated here.
29.1. Protocol-Core Wire Structures
The following tables define the minimum protocol-core JSON contract
for revision -04. Fields not listed here MAY be added only under the
extension rules of this document. A field marked required MUST be
present whenever the corresponding structure is carried on the wire.
29.1.1. Common Record Envelope
+=============+===========+=============+========================+
| Field | JSON type | Cardinality | Requirement |
+=============+===========+=============+========================+
| id | string | 1 | Stable record |
| | | | identifier. |
+-------------+-----------+-------------+------------------------+
| record_type | string | 1 | Identifies the record |
| | | | kind. |
+-------------+-----------+-------------+------------------------+
| version | string | 1 | Representation/schema |
| | | | version for this IETF |
| | | | profile. |
+-------------+-----------+-------------+------------------------+
| issuer | string | 1 | Identifier of the |
| | | | authority publishing |
| | | | the record. |
+-------------+-----------+-------------+------------------------+
| valid_from | date-time | 1 | Inclusive lower |
| | string | | validity bound. |
+-------------+-----------+-------------+------------------------+
Mukhopadhyay Expires 2 April 2027 [Page 40]
Internet-Draft ARPA September 2026
| valid_until | date-time | 0..1 | Exclusive upper |
| | string | | validity bound when |
| | | | present. |
+-------------+-----------+-------------+------------------------+
| status | object | 0..1 | Multi-dimensional |
| | | | status; when material |
| | | | to authority, absence |
| | | | MUST NOT be |
| | | | interpreted as active. |
+-------------+-----------+-------------+------------------------+
| proof | object | 0..1 | Proof metadata/bytes |
| | | | as defined by the |
| | | | selected proof |
| | | | profile. |
+-------------+-----------+-------------+------------------------+
| extensions | object | 0..1 | Namespaced extensions, |
| | | | including criticality |
| | | | metadata. |
+-------------+-----------+-------------+------------------------+
Table 3
29.1.2. Agent Resource
An Agent Resource MUST contain the common envelope plus:
+===============+============+=============+======================+
| Field | JSON type | Cardinality | Requirement |
+===============+============+=============+======================+
| agent_id | string | 1 | Canonical agentreg: |
| | | | Agent Identifier. |
+---------------+------------+-------------+----------------------+
| display_name | string | 0..1 | Human-readable only; |
| | | | MUST NOT be used for |
| | | | identifier equality. |
+---------------+------------+-------------+----------------------+
| endpoints | array | 0..n | Service endpoints |
| | | | with protocol/ |
| | | | profile metadata. |
+---------------+------------+-------------+----------------------+
| relationships | array of | 0..n | References to typed |
| | references | | relationship |
| | | | records. |
+---------------+------------+-------------+----------------------+
Table 4
Mukhopadhyay Expires 2 April 2027 [Page 41]
Internet-Draft ARPA September 2026
29.1.3. Relationship Record
A Relationship Record MUST contain the common envelope plus:
+===================+========+=============+========================+
| Field | JSON | Cardinality | Requirement |
| | type | | |
+===================+========+=============+========================+
| relationship_type | string | 1 | Registered/core |
| | | | value or collision- |
| | | | resistant extension |
| | | | value. |
+-------------------+--------+-------------+------------------------+
| subject | string | 1 | Entity from which |
| | | | the typed edge |
| | | | originates. |
+-------------------+--------+-------------+------------------------+
| related_entity | string | 1 | Entity to which the |
| | | | typed edge points. |
+-------------------+--------+-------------+------------------------+
| scope | object | 0..1 | Scope limiting the |
| | | | relationship. |
+-------------------+--------+-------------+------------------------+
| authority_source | string | 1 | Stable source |
| | | | establishing the |
| | | | relationship. |
+-------------------+--------+-------------+------------------------+
Table 5
Relationship semantics MUST NOT be inferred from field position
alone. In particular, operated_by and controlled_by MUST NOT be
interpreted as acts_for or delegates_to.
29.1.4. Authority Envelope
An Authority Envelope MUST contain the common envelope plus:
Mukhopadhyay Expires 2 April 2027 [Page 42]
Internet-Draft ARPA September 2026
+====================+==========+=============+=====================+
| Field | JSON | Cardinality | Requirement |
| | type | | |
+====================+==========+=============+=====================+
| principal | string | 1 | Principal whose |
| | | | authority is |
| | | | being |
| | | | represented. |
+--------------------+----------+-------------+---------------------+
| delegate | string | 1 | Agent/entity |
| | | | receiving bounded |
| | | | authority. |
+--------------------+----------+-------------+---------------------+
| actions | array | 1..n | Permitted action/ |
| | | | action-class |
| | | | identifiers. |
+--------------------+----------+-------------+---------------------+
| resources | array | 0..n | Resource scope |
| | | | when applicable. |
+--------------------+----------+-------------+---------------------+
| constraints | object | 0..1 | Limits, |
| | | | conditions, and |
| | | | prohibitions. |
+--------------------+----------+-------------+---------------------+
| derives_from | string | 0..1 | Parent authority |
| | | | reference; |
| | | | REQUIRED for |
| | | | delegated |
| | | | authority and MAY |
| | | | be absent for a |
| | | | root grant. |
+--------------------+----------+-------------+---------------------+
| further_delegation | boolean/ | 0..1 | Whether and under |
| | object | | what limits |
| | | | further |
| | | | delegation is |
| | | | permitted. |
+--------------------+----------+-------------+---------------------+
Table 6
A delegated Authority Envelope without the required derives_from
linkage is invalid when parent state is needed to establish monotonic
delegation.
Mukhopadhyay Expires 2 April 2027 [Page 43]
Internet-Draft ARPA September 2026
29.1.5. Event
An Event MUST contain:
+============+===========+=============+==========================+
| Field | JSON type | Cardinality | Requirement |
+============+===========+=============+==========================+
| event_id | string | 1 | Stable event identifier. |
+------------+-----------+-------------+--------------------------+
| event_type | string | 1 | Core or namespaced event |
| | | | type. |
+------------+-----------+-------------+--------------------------+
| source | string | 1 | Registry/event-source |
| | | | identifier. |
+------------+-----------+-------------+--------------------------+
| sequence | integer | 1 | Source ordering |
| | or string | | position/checkpoint. |
+------------+-----------+-------------+--------------------------+
| event_time | date-time | 1 | Time asserted by the |
| | string | | event source. |
+------------+-----------+-------------+--------------------------+
| subject | string | 1 | Affected record/entity. |
+------------+-----------+-------------+--------------------------+
| data | object | 0..1 | Event-specific content. |
+------------+-----------+-------------+--------------------------+
Table 7
29.1.6. Registry Metadata
The /.well-known/agent-registry representation MUST contain:
Mukhopadhyay Expires 2 April 2027 [Page 44]
Internet-Draft ARPA September 2026
+====================+===========+=============+=================+
| Field | JSON type | Cardinality | Requirement |
+====================+===========+=============+=================+
| registry_id | string | 1 | Stable registry |
| | | | identity. |
+--------------------+-----------+-------------+-----------------+
| protocol_version | string | 1 | ARPA protocol |
| | | | version/profile |
| | | | identifier. |
+--------------------+-----------+-------------+-----------------+
| base_endpoint | URI | 1 | Base endpoint |
| | string | | for the |
| | | | selected |
| | | | protocol |
| | | | surface. |
+--------------------+-----------+-------------+-----------------+
| supported_profiles | array | 1..n | Supported |
| | | | representation/ |
| | | | conformance |
| | | | profiles. |
+--------------------+-----------+-------------+-----------------+
| events_endpoint | URI | 0..1 | Present only |
| | string | | when the event |
| | | | contract is |
| | | | supported. |
+--------------------+-----------+-------------+-----------------+
| write_policy | URI/ | 0..1 | Stable policy |
| | string | | reference for |
| | | | mutation |
| | | | authorization |
| | | | when writes are |
| | | | supported. |
+--------------------+-----------+-------------+-----------------+
| clock_profile | object/ | 0..1 | Required when |
| | reference | | clock/skew |
| | | | assumptions can |
| | | | affect material |
| | | | decisions. |
+--------------------+-----------+-------------+-----------------+
Table 8
29.1.7. Authority Evaluation Result Wire Object
An Authority Evaluation Result MUST contain:
Mukhopadhyay Expires 2 April 2027 [Page 45]
Internet-Draft ARPA September 2026
+=================+==========+===========+=========================+
|Field |JSON type |Cardinality| Requirement |
+=================+==========+===========+=========================+
|decision |string |1 | One of allow, |
| | | | allow_with_conditions, |
| | | | deny, indeterminate, or |
| | | | not_applicable. |
+-----------------+----------+-----------+-------------------------+
|reason_codes |array of |1..n | Stable machine-readable |
| |strings | | reasons. |
+-----------------+----------+-----------+-------------------------+
|evaluation_time |date-time |1 | Time at which the |
| |string | | result was evaluated. |
+-----------------+----------+-----------+-------------------------+
|policy |object |1 | MUST identify policy |
| | | | id, version, and |
| | | | applicability. |
+-----------------+----------+-----------+-------------------------+
|conditions |array |0..n | REQUIRED and non-empty |
| | | | for |
| | | | allow_with_conditions. |
+-----------------+----------+-----------+-------------------------+
|evidence |array of |0..n | Material evidence/ |
| |references| | authority references. |
+-----------------+----------+-----------+-------------------------+
|source_checkpoint|string |0..1 | REQUIRED when |
| | | | derived/historical/ |
| | | | projected state |
| | | | materially contributed. |
+-----------------+----------+-----------+-------------------------+
|freshness |object/ |0..1 | REQUIRED when freshness |
| |reference | | can affect the result. |
+-----------------+----------+-----------+-------------------------+
Table 9
29.2. Representation Field Mapping
This document uses the IETF wire names valid_from, valid_until, and
version. The corresponding ARPA Candidate v0.10.0 machine-contract
names are effective_from, effective_until, and schema_version.
The mapping is exact and lossless. Implementations MUST NOT
interpret an absent alternate field as an unbounded interval, default
version, or equivalent value unless an explicitly selected
representation profile defines that behavior. If both mapped names
are present in a representation, they MUST carry equivalent values;
conflicting values make the representation invalid.
Mukhopadhyay Expires 2 April 2027 [Page 46]
Internet-Draft ARPA September 2026
29.3. Authority Evaluation Result
A protocol-visible authority evaluation result MUST contain a
decision, one or more reason_codes, evaluation_time, and the selected
policy identifier, version, and applicability state.
When the decision is allow_with_conditions, at least one condition
MUST be present.
When external, derived, historical, or projected evidence materially
contributes to the result, the result MUST retain direct or stable
references to that evidence and to the source checkpoint, version, or
digest needed to reproduce the material evaluation.
Where freshness can affect the result, the result MUST carry a
freshness bound or stable freshness-policy reference.
Only allow and allow_with_conditions are affirmative outcomes. deny,
indeterminate, and not_applicable are non-affirmative outcomes and
MUST NOT be collapsed into one another.
29.4. Status Composition
Lifecycle, security, operational, and authority status are
independent dimensions.
A material revoked, suspended, quarantined, compromised, retired, or
otherwise restrictive state MUST prevent an affirmative result unless
the selected profile explicitly defines a narrower safe
interpretation.
Unknown, stale, conflicting, or unsupported material status MUST
remain non-affirmative. An implementation MUST NOT silently collapse
a restrictive state to active.
29.5. Agent Identifier Syntax and Equality
The Agent Identifier uses the agentreg URI scheme:
agentreg = "agentreg:" registry-namespace ":" agent-local-id
registry-namespace = 1*( unreserved / pct-encoded / sub-delims / "@" )
agent-local-id = 1*( unreserved / pct-encoded / sub-delims / "@" / ":" )
The ABNF uses the unreserved, pct-encoded, and sub-delims productions
from [RFC3986] and the core ABNF rules of [RFC5234].
Mukhopadhyay Expires 2 April 2027 [Page 47]
Internet-Draft ARPA September 2026
The scheme name is case-insensitive. The scheme-specific components
are case-sensitive unless the assigning registry publishes a stronger
normalization rule.
Percent-encoded octets MUST NOT be decoded before identifier equality
comparison except where an assigning registry's published
normalization profile explicitly permits equivalent normalization.
Producers SHOULD emit a single canonical spelling and MUST NOT use
percent-encoding to disguise the component delimiter.
Registries using human-readable Unicode identifiers MUST address
normalization and confusable/homograph risk in their identifier-
allocation policy.
29.6. JSON Proof Inputs
Where an ARPA JSON proof profile signs or hashes a JSON
representation and does not define another canonicalization, the JSON
Canonicalization Scheme [RFC8785] MUST be used.
A parser MUST reject duplicate JSON member names before
canonicalization or proof verification.
Proof verification establishes integrity or authenticity only for the
covered representation. A valid proof MUST NOT substitute for
current lifecycle, authority, policy, freshness, or status
evaluation.
29.7. Freshness and HTTP Caching
A response carrying material authority or status MUST expose enough
information to determine freshness through a generated time, validity
bound, authoritative source time, source checkpoint/version/digest,
or a stable freshness-policy reference.
Derived or projected state MUST identify its authoritative source and
material observation time or lag.
An HTTP cache lifetime MUST NOT exceed the material validity or
freshness bound used for authority evaluation. When material
freshness cannot be established, the result MUST remain non-
affirmative.
29.8. Registration Retry Semantics
ARPA does not define a universal application-level idempotency header
for registration.
Mukhopadhyay Expires 2 April 2027 [Page 48]
Internet-Draft ARPA September 2026
A client MUST NOT automatically replay a non-idempotent registration
request unless a negotiated deployment profile defines retry-safe
idempotency semantics.
A profile that supports retry-safe registration MUST define the
idempotency key, replay window, duplicate-detection scope, and
deterministic response behavior.
29.9. Replacement Semantics
PUT /agents/{id} replaces the current representation by creating a
new historical version. It MUST NOT erase the prior version.
The path identifier and logical subject identity MUST NOT change
through PUT.
A mutable registry MUST support a representation precondition such as
If-Match with an ETag, or an equivalent version/checkpoint
precondition, and MUST reject stale concurrent replacement.
Omission of a material prohibition, constraint, delegation bound, or
restrictive status MUST NOT silently widen authority. Authority
widening requires explicit governing authority and evidence.
29.10. Event Ordering, Replay, and Gap Handling
An implementation that advertises an ARPA event endpoint MUST
provide, for each event, a stable event identifier and a source
ordering position or checkpoint sufficient to detect gaps within that
source.
Consumers MUST process duplicate events idempotently.
A consumer that detects a material sequence gap MUST NOT continue to
assert affirmative state based only on the incomplete stream. It
MUST resynchronize from an authoritative snapshot/checkpoint or
produce a non-affirmative result.
Event endpoint metadata MUST declare delivery and replay semantics,
including whether replay from a checkpoint is supported.
29.11. Write Authorization
Protocol writes are default-deny.
A registry MUST expose or stably reference the policy controlling
which authenticated principals may create, replace, or append
relationship, authority, and status records.
Mukhopadhyay Expires 2 April 2027 [Page 49]
Internet-Draft ARPA September 2026
Operator or controller status alone MUST NOT imply permission to
mutate unrelated accountability, delegation, recognition, or
authority records.
Unauthorized mutation MUST use ARPA Problem Details and the stable
code ARPA-RECORD-NOT-AUTHORIZED.
29.12. Critical Extensions
critical is the normative term for an extension whose non-recognition
can affect authority, lifecycle, security, privacy, or evidence
semantics.
An unknown critical extension MUST fail closed. Legacy ignorable or
non-ignorable wording is equivalent only where explicitly mapped to
the critical property; it is not a second extension model.
29.13. Dereference Security
When dereferencing evidence, federation, source, or other external
references, implementations MUST enforce SSRF protections.
Only profile-authorized URI schemes may be dereferenced. The
resolved destination and every redirect target MUST be validated
against deployment origin/network policy.
Unless explicitly trusted by profile, implementations MUST reject
loopback, link-local, multicast, and private/internal destinations
after resolution and MUST mitigate DNS rebinding.
Implementations MUST enforce request/response size and time limits.
Ambient credentials, cookies, and authorization headers MUST NOT be
forwarded across origins unless explicitly authorized.
A dereference failure or blocked dereference MUST NOT produce an
affirmative authority result.
29.14. Discovery and Search
/.well-known/agent-registry is registry capability and metadata
discovery.
GET /agents is search or listing within a registry already selected
by the caller.
Permission to discover registry metadata MUST NOT imply permission to
enumerate agents.
Mukhopadhyay Expires 2 April 2027 [Page 50]
Internet-Draft ARPA September 2026
29.15. HTTP Operation Surface
The interoperable HTTP core consists of registry metadata discovery,
agent resolution/search, registration/replacement when supported, and
any event endpoint explicitly advertised under the event contract
above.
Relationship, authority, history/lineage, and record-specific
operations MAY be exposed by a profile. An implementation MUST NOT
advertise an operation as interoperable ARPA core unless its request,
response, authorization, error, and version semantics are defined by
this document or the selected profile.
29.16. Conformance Matrix
For revision -04, every promoted normative requirement MUST map to an
applicable implementation role and at least one positive and one
hostile or negative fixture in the version-pinned ARPA conformance
corpus.
A conformance claim MUST identify the role or roles claimed.
Features that are not implemented MUST NOT be implied by conformance
to another role.
30. 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.
31. References
31.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
Mukhopadhyay Expires 2 April 2027 [Page 51]
Internet-Draft ARPA September 2026
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/rfc/rfc7595>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/rfc/rfc9457>.
31.2. Informative References
Mukhopadhyay Expires 2 April 2027 [Page 52]
Internet-Draft ARPA September 2026
[ARPA-SPEC]
Mukhopadhyay, S., "Agent Registry Protocol and
Architecture (ARPA) Candidate Specification", 23 September
2026, <https://qbfconsulting.digital/agent-registry-
protocol/spec/agent-registry-protocol-v0.10.0.html>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/rfc/rfc8414>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[TOIP-TSP] "ToIP Trust Spanning Protocol Specification", 2026,
<https://trustoverip.github.io/tswg-tsp-specification/>.
[TRQP-V2] O'Donnell, D., Kesselman, A., and D. Reed, "ToIP Trust
Registry Query Protocol (TRQP) v2.0", 2026,
<https://github.com/trustoverip/tswg-trust-registry-
protocol/tree/main/specification/v2-approved>.
[WIMSE-ARCH]
Salowey, J., "Workload Identity in a Multi System
Environment (WIMSE) Architecture", 6 July 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-
arch/08/>.
Mukhopadhyay Expires 2 April 2027 [Page 53]
Internet-Draft ARPA September 2026
[WIMSE-CROSS-ORG]
Reece, M., "Cross-Organizational Delegation for Workload
and Agent Identity: Problem Statement and Requirements",
31 August 2026, <https://datatracker.ietf.org/doc/draft-
reece-wimse-cross-org-delegation/02/>.
Appendix A. Change Log
This section is to be removed by the RFC Editor before publication.
A.1. -00
* Initial individual submission extracted from the ARPA Candidate
Specification and implementation corpus.
* Defines HTTP/JSON registry metadata, agent/deployment resources,
relationships, authority envelopes, lifecycle/status handling,
current and historical resolution, discovery, events, errors,
versioning, security, privacy, operations, and conformance.
A.2. -01
* Aligns the ARPA Agent Identifier with the agentreg: scheme already
used by the Candidate Specification and machine-readable API
contract.
* Adds adversarial authority-processing requirements for monotonic
delegation, temporal boundaries, conflict handling, revocation
effectiveness, decision reproducibility, and proof-input
semantics.
* Defines deterministic historical-resolution reconstruction, RFC
9457 Problem Details behavior, and fail-safe critical-extension
processing.
* Requests IANA registration of the agentreg URI scheme and the
agent-registry well-known URI suffix.
* Preserves project governance, A2A, TRQP, assurance-profile, and
redress semantics outside the IETF protocol core.
A.3. -02
* Defines action-specific authority evaluation with explicit action
context, current-authority checks, constraint preservation, and
exact-action approval binding.
Mukhopadhyay Expires 2 April 2027 [Page 54]
Internet-Draft ARPA September 2026
* Defines mechanism-neutral collective-principal exercise semantics,
including current membership/rule evidence and distinct-controller
threshold counting.
* Strengthens composability guidance and informative references for
WIMSE workload identity/delegation, OAuth 2.0 Token Exchange, RATS
attestation, and SCITT transparency.
* Preserves the separation between registry-visible authority
evidence and the relying party's final authorization or execution
decision.
A.4. -03
* Defines interoperable authority-evaluation outcome semantics,
including a machine-stable not_applicable boundary distinct from
protocol errors, deny, and indeterminate.
* Adds explicit parent-authority linkage, lower-bound time
semantics, discoverable clock-profile assumptions, and collective-
principal snapshot binding.
* Registers application/agent-registry+json and tightens RFC 9457
Problem Details and extension-namespace processing.
* Defines how external authoritative trust evidence contributes to
ARPA evaluation and specifies normative composition boundaries
with ToIP TRQP v2.0.
* Describes ToIP TSP as an optional spanning substrate without
making TSP a conformance dependency and preserves the rule that
authenticated channels/identifiers do not confer authority.
* Pins WIMSE references to the revisions reviewed for this draft and
clarifies optional SCITT evidence-reference composition.
* Makes IETF-draft precedence explicit for IETF protocol conformance
while retaining Candidate v0.10.0 as the project baseline for
wider governance/profile material.
A.5. -04
* Defines explicit Candidate-to-IETF wire-field mappings and rejects
conflicting aliases.
* Makes the Authority Evaluation Result, affirmative/non-affirmative
grouping, multi-dimensional status composition, and freshness
contract explicit.
Mukhopadhyay Expires 2 April 2027 [Page 55]
Internet-Draft ARPA September 2026
* Defines agentreg ABNF/equality/normalization and RFC 8785 default
canonicalization for JSON proof inputs.
* Hardens registration retry, PUT replacement, event ordering/gap
recovery, write authorization, and critical-extension semantics.
* Adds concrete SSRF/dereference safeguards and separates registry
metadata discovery from agent search.
* Requires role-scoped positive and hostile conformance evidence for
promoted -04 requirements.
Author's Address
Sankarshan Mukhopadhyay
QBF Consulting LLP
Email: sankarshan@qbfconsulting.digital
Mukhopadhyay Expires 2 April 2027 [Page 56]