Individual Submission S. Mukhopadhyay Internet-Draft QBF Consulting LLP Intended status: Standards Track 17 September 2026 Expires: 21 March 2027 Agent Registry Protocol draft-sankarshan-agent-registry-protocol-00 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 21 March 2027. Mukhopadhyay Expires 21 March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Requirements Language . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Separation of Resolution, Decision, and Enforcement . . . 6 4.2. Protocol Roles . . . . . . . . . . . . . . . . . . . . . 6 4.3. Authority Invariants . . . . . . . . . . . . . . . . . . 7 5. Identifier Model . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Agent Identifiers . . . . . . . . . . . . . . . . . . . . 7 5.2. Deployment Identifiers . . . . . . . . . . . . . . . . . 8 6. Record Envelope . . . . . . . . . . . . . . . . . . . . . . . 8 7. Agent Resource Model . . . . . . . . . . . . . . . . . . . . 8 8. Relationship Model . . . . . . . . . . . . . . . . . . . . . 9 9. Authority Envelope . . . . . . . . . . . . . . . . . . . . . 10 10. Lifecycle and Status . . . . . . . . . . . . . . . . . . . . 10 11. HTTP API . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Registry Metadata . . . . . . . . . . . . . . . . . . . 12 11.2. Registration . . . . . . . . . . . . . . . . . . . . . . 13 11.3. Current Resolution . . . . . . . . . . . . . . . . . . . 13 11.4. Historical Resolution . . . . . . . . . . . . . . . . . 14 11.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . 14 11.6. Authority Resolution . . . . . . . . . . . . . . . . . . 14 11.7. Conditional Requests and Caching . . . . . . . . . . . . 15 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15 13. Event Model . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Versioning and Extensions . . . . . . . . . . . . . . . . . . 16 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 17. Operational Considerations . . . . . . . . . . . . . . . . . 19 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 19. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 20 Mukhopadhyay Expires 21 March 2027 [Page 2] Internet-Draft ARPA September 2026 20. References to the Wider ARPA Project . . . . . . . . . . . . 21 21. Adversarial Authority Processing . . . . . . . . . . . . . . 21 21.1. Delegation Scope Intersection . . . . . . . . . . . . . 21 21.2. Time Boundaries . . . . . . . . . . . . . . . . . . . . 22 21.3. Non-Applicability . . . . . . . . . . . . . . . . . . . 22 21.4. Recognition Conflicts . . . . . . . . . . . . . . . . . 23 21.5. Revocation and Enforcement Convergence . . . . . . . . . 23 21.6. Reproducible Decisions . . . . . . . . . . . . . . . . . 23 21.7. Proof Input Semantics . . . . . . . . . . . . . . . . . 23 21.8. Relationship to Existing IETF Mechanisms . . . . . . . . 24 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 23.1. Normative References . . . . . . . . . . . . . . . . . . 24 23.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 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; Mukhopadhyay Expires 21 March 2027 [Page 3] Internet-Draft ARPA September 2026 * 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; * 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; Mukhopadhyay Expires 21 March 2027 [Page 4] Internet-Draft ARPA September 2026 * deterministic processing of stale, conflicting, unavailable, and unsupported state; * error representation; * extension and version negotiation rules; and * evidence references supporting later audit or reliance evaluation. ARPA does not define a universal agent-to-agent messaging protocol, task protocol, reputation system, liability regime, credential format, signature suite, policy language, distributed ledger, or mandatory storage architecture. 3. Terminology *Agent:* A software entity capable of performing actions with some degree of autonomy. *Agent Identifier:* A persistent URI identifying a logical agent independently of a particular version or deployment. *Deployment:* An operational instance of an agent version in a particular execution context. *Principal:* A person or organization on whose behalf an agent may act. *Operator:* The entity responsible for running an agent deployment. *Controller:* An entity with material technical or administrative control over an agent or deployment. *Accountable Entity:* An entity identified by the registry as accepting a defined accountability role for an agent or class of actions. *Relationship:* A typed, scoped, time-bounded statement linking two registry subjects. *Authority Envelope:* A bounded representation of authority delegated from an issuer to a subject, including permitted actions, resources, conditions, prohibitions, delegation depth, and validity interval. *Resolver:* A client that queries one or more ARPA registries. *Relying Party:* A system or actor that uses ARPA data as one input to a local trust or authorization decision. Mukhopadhyay Expires 21 March 2027 [Page 5] Internet-Draft ARPA September 2026 *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; * resolver or registry consumer; * authority evaluator; * event publisher; * event consumer or enforcement point; or * federation participant. Mukhopadhyay Expires 21 March 2027 [Page 6] Internet-Draft ARPA September 2026 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 be a URI conforming to [RFC3986]. Its scheme and dereference behavior are deployment choices unless another specification defines them. ARPA does not define a new URI scheme in this document. 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 21 March 2027 [Page 7] 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 21 March 2027 [Page 8] 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 relationship MUST NOT be interpreted as an authorized-by relationship unless a separate specification explicitly defines such equivalence. Mukhopadhyay Expires 21 March 2027 [Page 9] 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 21 March 2027 [Page 10] 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 21 March 2027 [Page 11] 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 21 March 2027 [Page 12] 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 21 March 2027 [Page 13] 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 21 March 2027 [Page 14] 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 21 March 2027 [Page 15] 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 21 March 2027 [Page 16] 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 21 March 2027 [Page 17] 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 21 March 2027 [Page 18] 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 21 March 2027 [Page 19] 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 This document requests no IANA actions in -00. A future revision may request registration of /.well-known/agent- registry in the Well-Known URIs registry and may define or request registries for protocol media types, relation types, or error identifiers if interoperability experience shows that centralized registration is warranted. Until such registrations are approved, implementations MUST treat names used by this draft as experimental/project-scoped and MUST NOT represent them as IANA-assigned values. 19. Conformance An implementation claiming conformance to this document MUST identify the protocol version and role or roles for which conformance is claimed. A conforming registry implementation MUST: * expose protocol metadata; * preserve persistent identifier semantics; * distinguish authoritative from derived state; * expose lifecycle and authority status without mapping indeterminate state to affirmative authority; * implement current resolution; * use the defined error behavior or a documented compatible mapping; * preserve extension/version fail-closed rules; and * satisfy the security and privacy requirements applicable to the implemented features. A conforming resolver implementation MUST: Mukhopadhyay Expires 21 March 2027 [Page 20] Internet-Draft ARPA September 2026 * distinguish resolution from authorization; * evaluate material freshness; * fail non-affirmatively on stale, conflicting, unavailable, or unverifiable material authority; * prevent delegation scope amplification when it evaluates authority; * preserve unknown non-ignorable extension behavior; and * retain sufficient decision metadata for reproducibility where it produces authority evaluations. Historical-resolution conformance additionally requires the implementation to distinguish requested-time state, evaluation-time knowledge, later material events, and reconstruction quality. Event conformance additionally requires duplicate-safe processing and documented ordering/gap behavior. 20. References to the Wider ARPA Project The repository-maintained Candidate Specification contains governance, assurance, conformance, federation, implementation, redress, test-vector, and deployment material intentionally omitted from this protocol-focused Internet-Draft. The two documents are related but have separate version lines and publication states. 21. Adversarial Authority Processing This section hardens authority-processing boundaries that can otherwise admit divergent or permissive interpretations. It does not broaden authority. A resolver or authority evaluator MUST treat ambiguity in a material authority boundary as non-affirmative. 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. Mukhopadhyay Expires 21 March 2027 [Page 21] Internet-Draft ARPA September 2026 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. 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. Mukhopadhyay Expires 21 March 2027 [Page 22] Internet-Draft ARPA September 2026 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. 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. Mukhopadhyay Expires 21 March 2027 [Page 23] Internet-Draft ARPA September 2026 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. 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. Acknowledgements The author thanks contributors and reviewers of the wider Agent Registry Protocol project whose implementation, interoperability, governance, security, privacy, and adversarial-hardening work informed this protocol extraction. 23. References 23.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, . Mukhopadhyay Expires 21 March 2027 [Page 24] 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, . [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, . 23.2. Informative References [ARPA-SPEC] Mukhopadhyay, S., "Agent Registry Protocol and Architecture (ARPA) Candidate Specification", 16 July 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, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . Mukhopadhyay Expires 21 March 2027 [Page 25] Internet-Draft ARPA September 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. Author's Address Sankarshan Mukhopadhyay QBF Consulting LLP Email: sankarshan@qbfconsulting.digital Mukhopadhyay Expires 21 March 2027 [Page 26]