Agent Registry Protocol

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

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

• 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.1. Agent Identifiers

An Agent Identifier MUST use the agentreg URI scheme defined by this document and MUST conform to [RFC3986]. The syntax is:¶

agentreg:<registry-namespace>:<agent-local-id>

The registry-namespace identifies the registry namespace in which the local identifier is assigned. The agent-local-id identifies the logical agent within that namespace. Implementations MUST NOT emit a different URI scheme as the ARPA Agent Identifier merely because the agent also has an identifier in another identity or discovery system.¶

External identifiers MAY be represented as aliases or mapped identifiers, but they MUST remain distinguishable from the ARPA Agent Identifier. A resolver receiving an unsupported identifier scheme MUST NOT silently reinterpret it as an ARPA Agent Identifier; an explicit mapping mechanism MAY be used when the resulting agentreg identifier and mapping provenance are preserved.¶

An Agent Identifier MUST identify the logical agent rather than a single software build, process, network endpoint, or ephemeral runtime session.¶

Registries MUST NOT silently reassign an Agent Identifier to a different logical agent. If an identifier becomes unusable, the registry SHOULD publish a terminal status or supersession relationship rather than reuse it.¶

5.2. Deployment Identifiers

A deployment MUST have an identifier unique within the scope of the authoritative registry. A deployment identifier SHOULD be globally unique when deployments are expected to move between registries or administrative domains.¶

A deployment record MUST identify the logical Agent Identifier and SHOULD identify the agent version from which the deployment was created.¶

11.1. Registry Metadata

A registry metadata response SHOULD contain:¶

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

The metadata endpoint MUST NOT imply that every advertised optional feature is authorized for every caller. Access control remains operation-specific.¶

11.2. Registration

A client creating a registration sends POST to the registration collection with a JSON representation of the requested agent record.¶

The registry MUST authenticate and authorize the registration request according to local policy. ARPA does not define that authentication mechanism.¶

On successful creation, the registry SHOULD return 201 Created and a Location header identifying the new agent resource. A retry-safe deployment SHOULD support an application-level idempotency mechanism and MUST document its semantics.¶

A registry MUST reject a request that would reassign an existing persistent Agent Identifier to a different logical agent.¶

11.3. Current Resolution

A successful current-state resolution returns 200 OK with the current representation and sufficient freshness/provenance metadata for the client to distinguish authoritative from derived state.¶

A response MUST identify when material state is derived or cached. Derived material authority state MUST include the authoritative source and freshness information.¶

404 Not Found means that the queried registry has no resolvable resource for the supplied identifier. It MUST NOT be interpreted as evidence that the agent does not exist in any other registry.¶

11.4. Historical Resolution

Historical resolution uses an at query parameter containing an [RFC3339] timestamp. The response MUST distinguish:¶

• the requested effective time;¶

• the time at which the resolution was performed;¶

• records selected as effective at the requested time;¶

• later material events known at evaluation time; and¶

• reconstruction completeness or limitations.¶

A historical response MUST NOT silently apply current status to the requested historical time or silently ignore later events that materially affect interpretation.¶

If the registry cannot reconstruct material historical state with sufficient confidence, it MUST return an indeterminate reconstruction status and MUST NOT present the result as an authoritative affirmative determination.¶

11.5. Discovery

Discovery endpoints are informational. Search or list results MUST NOT imply authorization, endorsement, assurance, or permission to invoke an agent.¶

A registry SHOULD minimize information disclosed through unauthenticated discovery. Sensitive relationships, principal linkage, delegated authority details, or operational metadata SHOULD require authorization when disclosure creates material privacy or security risk.¶

11.6. Authority Resolution

Authority resolution returns one or more authority envelopes and their status. If the registry knows that required parent authority, status, or evidence is missing, stale, conflicting, or unavailable, the response MUST expose that condition rather than omit it in a way that could be interpreted as affirmative authority.¶

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

18.1. agentreg URI Scheme

This document requests permanent registration of the agentreg URI scheme in the URI Schemes registry in accordance with [RFC7595].¶

Scheme name: agentreg¶

Status: Permanent¶

Applications/protocols that use this scheme: Agent Registry Protocol (ARPA).¶

Contact: the author of this document.¶

Change controller: IETF.¶

References: this document, Identifier Model and Security Considerations.¶

The scheme-specific syntax is agentreg:<registry-namespace>:<agent-local-id>. The scheme identifies an ARPA Agent Identifier; it does not by itself confer authority, recognition, assurance, or permission. Security considerations are described in the Security Considerations section of this document.¶

18.2. /.well-known/agent-registry

This document requests registration of the agent-registry well-known URI suffix in the Well-Known URIs registry in accordance with [RFC8615].¶

URI suffix: agent-registry¶

Change controller: IETF.¶

Specification document: this document, Registry Metadata.¶

Related information: the resource identifies ARPA registry metadata and discovery information. A representation SHOULD use a media type appropriate to the selected representation format; JSON deployments SHOULD use application/json unless a future specification registers a more specific media type. 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.¶

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

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

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

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

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

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

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

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

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

26.1. Normative References

[RFC2119]

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

[RFC3339]

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

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC7595]

Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/rfc/rfc7595>.

[RFC8174]

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

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8615]

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

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

26.2. Informative References

[ARPA-SPEC]

Mukhopadhyay, S., "Agent Registry Protocol and Architecture (ARPA) Candidate Specification", 16 July 2026, <https://qbf-consulting.github.io/agent-registry-protocol/spec/agent-registry-protocol-v0.9.0.html>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[WIMSE-ARCH]

Salowey, J., "Workload Identity in a Multi System Environment (WIMSE) Architecture", 6 July 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

[WIMSE-CROSS-ORG]

Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", 31 August 2026, <https://datatracker.ietf.org/doc/draft-reece-wimse-cross-org-delegation/>.

A.1. -00

• Initial individual submission extracted from the ARPA Candidate Specification and implementation corpus.¶

• Defines HTTP/JSON registry metadata, agent/deployment resources, relationships, authority envelopes, lifecycle/status handling, current and historical resolution, discovery, events, errors, versioning, security, privacy, operations, and conformance.¶

A.2. -01

• Aligns the ARPA Agent Identifier with the agentreg: scheme already used by the Candidate Specification and machine-readable API contract.¶

• Adds adversarial authority-processing requirements for monotonic delegation, temporal boundaries, conflict handling, revocation effectiveness, decision reproducibility, and proof-input semantics.¶

• Defines deterministic historical-resolution reconstruction, RFC 9457 Problem Details behavior, and fail-safe critical-extension processing.¶

• Requests IANA registration of the agentreg URI scheme and the agent-registry well-known URI suffix.¶

• Preserves project governance, A2A, TRQP, assurance-profile, and redress semantics outside the IETF protocol core.¶

A.3. -02

• Defines action-specific authority evaluation with explicit action context, current-authority checks, constraint preservation, and exact-action approval binding.¶

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