Individual Submission S. Mukhopadhyay Internet-Draft QBF Consulting LLP Intended status: Standards Track 28 September 2026 Expires: 1 April 2027 Agent Registry Protocol draft-sankarshan-agent-registry-protocol-03 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 1 April 2027. Mukhopadhyay Expires 1 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 . . . . . . . . . . . . . . . . . . 7 5. Identifier Model . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Agent Identifiers . . . . . . . . . . . . . . . . . . . . 8 5.2. Deployment Identifiers . . . . . . . . . . . . . . . . . 9 6. Record Envelope . . . . . . . . . . . . . . . . . . . . . . . 9 7. Agent Resource Model . . . . . . . . . . . . . . . . . . . . 9 8. Relationship Model . . . . . . . . . . . . . . . . . . . . . 10 9. Authority Envelope . . . . . . . . . . . . . . . . . . . . . 11 10. Lifecycle and Status . . . . . . . . . . . . . . . . . . . . 11 11. HTTP API . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Registry Metadata . . . . . . . . . . . . . . . . . . . 13 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 1 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 30.1. Normative References . . . . . . . . . . . . . . . . . . 40 30.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Mukhopadhyay Expires 1 April 2027 [Page 3] Internet-Draft ARPA September 2026 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Software agents can retrieve protected information, invoke tools, modify workflows, initiate transactions, coordinate other agents, and otherwise cause effects on behalf of principals. A relying system evaluating such an action needs more than endpoint discovery. It needs protocol-visible information sufficient to determine which agent is involved, which deployment is executing, who operates or controls it, what delegated authority applies, whether that authority remains effective, and where supporting evidence can be obtained. ARPA provides a registry and resolution protocol for those questions. It does not define a universal trust score, a universal legal theory of agency, a new authentication protocol, or a mandatory credential format. It also does not treat successful registry resolution as an authorization decision. A relying party combines ARPA resolution results with local policy and any external authentication, credential, or assurance mechanisms required for its context. The protocol intentionally preserves several non-implication rules: * discovering an agent does not imply authorization to invoke it; * control of an identifier or cryptographic key does not imply authority to act for a principal; * an advertised capability does not imply permission to exercise that capability; * successful proof verification does not imply that the asserted authority is current or sufficient; * technical federation does not imply governance recognition; and * historical registry state is evidence for evaluation, not by itself a legal determination about a historical act. The wider ARPA project specification [ARPA-SPEC] defines additional governance, assurance, conformance, federation, redress, implementation, and deployment material. This Internet-Draft deliberately narrows that work to interoperable protocol behavior. Mukhopadhyay Expires 1 April 2027 [Page 4] Internet-Draft ARPA September 2026 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; * 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. Mukhopadhyay Expires 1 April 2027 [Page 5] Internet-Draft ARPA September 2026 ARPA does not define a universal agent-to-agent messaging protocol, task protocol, reputation system, liability regime, credential format, signature suite, policy language, distributed ledger, or mandatory storage architecture. 3. Terminology *Agent:* A software entity capable of performing actions with some degree of autonomy. *Agent Identifier:* A persistent URI identifying a logical agent independently of a particular version or deployment. *Deployment:* An operational instance of an agent version in a particular execution context. *Principal:* A person or organization on whose behalf an agent may act. *Operator:* The entity responsible for running an agent deployment. *Controller:* An entity with material technical or administrative control over an agent or deployment. *Accountable Entity:* An entity identified by the registry as accepting a defined accountability role for an agent or class of actions. *Relationship:* A typed, scoped, time-bounded statement linking two registry subjects. *Authority Envelope:* A bounded representation of authority delegated from an issuer to a subject, including permitted actions, resources, conditions, prohibitions, delegation depth, and validity interval. *Resolver:* A client that queries one or more ARPA registries. *Relying Party:* A system or actor that uses ARPA data as one input to a local trust or authorization decision. *Registry:* A service that publishes ARPA records and resolution responses. *Authoritative Record:* A record for which the publishing registry is identified as an authoritative source within the applicable scope. *Derived Record:* A cached, indexed, projected, or federated representation whose authoritative source is elsewhere. Mukhopadhyay Expires 1 April 2027 [Page 6] Internet-Draft ARPA September 2026 *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; * 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; Mukhopadhyay Expires 1 April 2027 [Page 7] Internet-Draft ARPA September 2026 * 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:: 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. Mukhopadhyay Expires 1 April 2027 [Page 8] Internet-Draft ARPA September 2026 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" } 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; Mukhopadhyay Expires 1 April 2027 [Page 9] Internet-Draft ARPA September 2026 * service endpoint references; * capability declaration references; * authority references; * lifecycle status; * evidence references; and * representation metadata including source and freshness. A capability declaration MUST NOT be interpreted as authorization. An endpoint reference MUST NOT be interpreted as proof that the endpoint is controlled by the principal for whom an action is proposed. 8. Relationship Model A relationship record MUST contain: * a relationship type; * a source subject; * a target subject; * an issuer; * scope; * effective time; and * current status. Where absence of a relationship would change an authorization outcome, the response MUST provide either the relationship or a machine-readable indication that authoritative relationship state could not be established. Registries MUST NOT infer a broader relationship from a narrower one. For example, an operated_by or controlled_by relationship MUST NOT be interpreted as acts_for or delegates_to without separate authority evidence. Mukhopadhyay Expires 1 April 2027 [Page 10] Internet-Draft ARPA September 2026 9. Authority Envelope An authority envelope represents bounded authority. It MUST contain: * issuer; * subject; * actions or an equivalent action scope; * valid_from; * status information; and * a stable identifier for the authority statement. When applicable it MUST also contain: * resources or resource classes; * purpose restrictions; * conditions; * prohibitions; * monetary, rate, geographic, or other limits; * valid_until; * delegation depth or prohibition on further delegation; * evidence references; and * the authority statement from which the issuer derives the delegated scope. An authority envelope MUST NOT be interpreted independently of its current status and applicable parent authority. Delegation MUST NOT increase the issuer's effective action, resource, purpose, temporal, geographic, monetary, or delegation scope. 10. Lifecycle and Status ARPA represents lifecycle state as multiple dimensions rather than a single active flag. A response MAY expose dimensions including registration, operational, security, authority, and assurance status. Mukhopadhyay Expires 1 April 2027 [Page 11] Internet-Draft ARPA September 2026 A registry MUST distinguish at least the following effects when they are applicable: * active or current; * suspended; * revoked; * expired; * superseded; * retired; and * indeterminate or unavailable. A resolver MUST NOT map indeterminate, unavailable, conflicting, or stale material authority state to an affirmative authorization outcome. A registry publishing revocation or suspension SHOULD expose an event or other freshness mechanism enabling consumers to discover the change promptly. A publisher MUST NOT describe revocation as fully converged merely because the registry record changed if downstream enforcement acknowledgements are required by the applicable profile. 11. HTTP API ARPA uses HTTP semantics as defined by [RFC9110]. Registries MUST use HTTPS for network deployments that carry non-public data or authority information unless an equivalent authenticated and confidential transport is provided by the deployment environment. This document defines the following logical resources. Deployments MAY choose different path layouts if discoverable metadata maps the logical operations unambiguously. Mukhopadhyay Expires 1 April 2027 [Page 12] Internet-Draft ARPA September 2026 +===================+========================+====================+ | 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). 11.1. Registry Metadata A registry metadata response SHOULD contain: Mukhopadhyay Expires 1 April 2027 [Page 13] Internet-Draft ARPA September 2026 { "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. 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. Mukhopadhyay Expires 1 April 2027 [Page 14] Internet-Draft ARPA September 2026 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 1 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 1 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 1 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 1 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 1 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 1 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::. 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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 1 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. 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. 30. References 30.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, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [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, . Mukhopadhyay Expires 1 April 2027 [Page 40] Internet-Draft ARPA September 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . 30.2. Informative References [ARPA-SPEC] Mukhopadhyay, S., "Agent Registry Protocol and Architecture (ARPA) Candidate Specification", 23 September 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . Mukhopadhyay Expires 1 April 2027 [Page 41] Internet-Draft ARPA September 2026 [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, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [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, . [TOIP-TSP] "ToIP Trust Spanning Protocol Specification", 2026, . [TRQP-V2] O'Donnell, D., Kesselman, A., and D. Reed, "ToIP Trust Registry Query Protocol (TRQP) v2.0", 2026, . [WIMSE-ARCH] Salowey, J., "Workload Identity in a Multi System Environment (WIMSE) Architecture", 6 July 2026, . [WIMSE-CROSS-ORG] Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", 31 August 2026, . 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. Mukhopadhyay Expires 1 April 2027 [Page 42] Internet-Draft ARPA September 2026 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. * 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. Mukhopadhyay Expires 1 April 2027 [Page 43] Internet-Draft ARPA September 2026 * 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. Author's Address Sankarshan Mukhopadhyay QBF Consulting LLP Email: sankarshan@qbfconsulting.digital Mukhopadhyay Expires 1 April 2027 [Page 44]