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

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

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

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

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

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

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

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

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

29.1. Protocol-Core Wire Structures

The following tables define the minimum protocol-core JSON contract for revision -04. Fields not listed here MAY be added only under the extension rules of this document. A field marked required MUST be present whenever the corresponding structure is carried on the wire.¶

29.2. Representation Field Mapping

This document uses the IETF wire names valid_from, valid_until, and version. The corresponding ARPA Candidate v0.10.0 machine-contract names are effective_from, effective_until, and schema_version.¶

The mapping is exact and lossless. Implementations MUST NOT interpret an absent alternate field as an unbounded interval, default version, or equivalent value unless an explicitly selected representation profile defines that behavior. If both mapped names are present in a representation, they MUST carry equivalent values; conflicting values make the representation invalid.¶

29.3. Authority Evaluation Result

A protocol-visible authority evaluation result MUST contain a decision, one or more reason_codes, evaluation_time, and the selected policy identifier, version, and applicability state.¶

When the decision is allow_with_conditions, at least one condition MUST be present.¶

When external, derived, historical, or projected evidence materially contributes to the result, the result MUST retain direct or stable references to that evidence and to the source checkpoint, version, or digest needed to reproduce the material evaluation.¶

Where freshness can affect the result, the result MUST carry a freshness bound or stable freshness-policy reference.¶

Only allow and allow_with_conditions are affirmative outcomes. deny, indeterminate, and not_applicable are non-affirmative outcomes and MUST NOT be collapsed into one another.¶

29.4. Status Composition

Lifecycle, security, operational, and authority status are independent dimensions.¶

A material revoked, suspended, quarantined, compromised, retired, or otherwise restrictive state MUST prevent an affirmative result unless the selected profile explicitly defines a narrower safe interpretation.¶

Unknown, stale, conflicting, or unsupported material status MUST remain non-affirmative. An implementation MUST NOT silently collapse a restrictive state to active.¶

29.5. Agent Identifier Syntax and Equality

The Agent Identifier uses the agentreg URI scheme:¶

agentreg = "agentreg:" registry-namespace ":" agent-local-id
registry-namespace = 1*( unreserved / pct-encoded / sub-delims / "@" )
agent-local-id = 1*( unreserved / pct-encoded / sub-delims / "@" / ":" )

The ABNF uses the unreserved, pct-encoded, and sub-delims productions from [RFC3986] and the core ABNF rules of [RFC5234].¶

The scheme name is case-insensitive. The scheme-specific components are case-sensitive unless the assigning registry publishes a stronger normalization rule.¶

Percent-encoded octets MUST NOT be decoded before identifier equality comparison except where an assigning registry's published normalization profile explicitly permits equivalent normalization. Producers SHOULD emit a single canonical spelling and MUST NOT use percent-encoding to disguise the component delimiter.¶

Registries using human-readable Unicode identifiers MUST address normalization and confusable/homograph risk in their identifier-allocation policy.¶

29.6. JSON Proof Inputs

Where an ARPA JSON proof profile signs or hashes a JSON representation and does not define another canonicalization, the JSON Canonicalization Scheme [RFC8785] MUST be used.¶

A parser MUST reject duplicate JSON member names before canonicalization or proof verification.¶

Proof verification establishes integrity or authenticity only for the covered representation. A valid proof MUST NOT substitute for current lifecycle, authority, policy, freshness, or status evaluation.¶

29.7. Freshness and HTTP Caching

A response carrying material authority or status MUST expose enough information to determine freshness through a generated time, validity bound, authoritative source time, source checkpoint/version/digest, or a stable freshness-policy reference.¶

Derived or projected state MUST identify its authoritative source and material observation time or lag.¶

An HTTP cache lifetime MUST NOT exceed the material validity or freshness bound used for authority evaluation. When material freshness cannot be established, the result MUST remain non-affirmative.¶

29.8. Registration Retry Semantics

ARPA does not define a universal application-level idempotency header for registration.¶

A client MUST NOT automatically replay a non-idempotent registration request unless a negotiated deployment profile defines retry-safe idempotency semantics.¶

A profile that supports retry-safe registration MUST define the idempotency key, replay window, duplicate-detection scope, and deterministic response behavior.¶

29.9. Replacement Semantics

PUT /agents/{id} replaces the current representation by creating a new historical version. It MUST NOT erase the prior version.¶

The path identifier and logical subject identity MUST NOT change through PUT.¶

A mutable registry MUST support a representation precondition such as If-Match with an ETag, or an equivalent version/checkpoint precondition, and MUST reject stale concurrent replacement.¶

Omission of a material prohibition, constraint, delegation bound, or restrictive status MUST NOT silently widen authority. Authority widening requires explicit governing authority and evidence.¶

29.10. Event Ordering, Replay, and Gap Handling

An implementation that advertises an ARPA event endpoint MUST provide, for each event, a stable event identifier and a source ordering position or checkpoint sufficient to detect gaps within that source.¶

Consumers MUST process duplicate events idempotently.¶

A consumer that detects a material sequence gap MUST NOT continue to assert affirmative state based only on the incomplete stream. It MUST resynchronize from an authoritative snapshot/checkpoint or produce a non-affirmative result.¶

Event endpoint metadata MUST declare delivery and replay semantics, including whether replay from a checkpoint is supported.¶

29.11. Write Authorization

Protocol writes are default-deny.¶

A registry MUST expose or stably reference the policy controlling which authenticated principals may create, replace, or append relationship, authority, and status records.¶

Operator or controller status alone MUST NOT imply permission to mutate unrelated accountability, delegation, recognition, or authority records.¶

Unauthorized mutation MUST use ARPA Problem Details and the stable code ARPA-RECORD-NOT-AUTHORIZED.¶

29.12. Critical Extensions

critical is the normative term for an extension whose non-recognition can affect authority, lifecycle, security, privacy, or evidence semantics.¶

An unknown critical extension MUST fail closed. Legacy ignorable or non-ignorable wording is equivalent only where explicitly mapped to the critical property; it is not a second extension model.¶

29.13. Dereference Security

When dereferencing evidence, federation, source, or other external references, implementations MUST enforce SSRF protections.¶

Only profile-authorized URI schemes may be dereferenced. The resolved destination and every redirect target MUST be validated against deployment origin/network policy.¶

Unless explicitly trusted by profile, implementations MUST reject loopback, link-local, multicast, and private/internal destinations after resolution and MUST mitigate DNS rebinding.¶

Implementations MUST enforce request/response size and time limits. Ambient credentials, cookies, and authorization headers MUST NOT be forwarded across origins unless explicitly authorized.¶

A dereference failure or blocked dereference MUST NOT produce an affirmative authority result.¶

29.14. Discovery and Search

/.well-known/agent-registry is registry capability and metadata discovery.¶

GET /agents is search or listing within a registry already selected by the caller.¶

Permission to discover registry metadata MUST NOT imply permission to enumerate agents.¶

29.15. HTTP Operation Surface

The interoperable HTTP core consists of registry metadata discovery, agent resolution/search, registration/replacement when supported, and any event endpoint explicitly advertised under the event contract above.¶

Relationship, authority, history/lineage, and record-specific operations MAY be exposed by a profile. An implementation MUST NOT advertise an operation as interoperable ARPA core unless its request, response, authorization, error, and version semantics are defined by this document or the selected profile.¶

29.16. Conformance Matrix

For revision -04, every promoted normative requirement MUST map to an applicable implementation role and at least one positive and one hostile or negative fixture in the version-pinned ARPA conformance corpus.¶

A conformance claim MUST identify the role or roles claimed. Features that are not implemented MUST NOT be implied by conformance to another role.¶

31.1. Normative References

[RFC2119]

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

[RFC3339]

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

[RFC3986]

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

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7595]

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

[RFC8174]

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

[RFC8259]

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

[RFC8615]

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

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9110]

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

[RFC9111]

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

[RFC9457]

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

31.2. Informative References

[ARPA-SPEC]

Mukhopadhyay, S., "Agent Registry Protocol and Architecture (ARPA) Candidate Specification", 23 September 2026, <https://qbfconsulting.digital/agent-registry-protocol/spec/agent-registry-protocol-v0.10.0.html>.

[RFC6749]

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

[RFC8414]

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

[RFC8693]

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

[RFC9334]

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

[RFC9421]

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

[RFC9943]

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

[TOIP-TSP]

"ToIP Trust Spanning Protocol Specification", 2026, <https://trustoverip.github.io/tswg-tsp-specification/>.

[TRQP-V2]

O'Donnell, D., Kesselman, A., and D. Reed, "ToIP Trust Registry Query Protocol (TRQP) v2.0", 2026, <https://github.com/trustoverip/tswg-trust-registry-protocol/tree/main/specification/v2-approved>.

[WIMSE-ARCH]

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

[WIMSE-CROSS-ORG]

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

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

A.4. -03

• Defines interoperable authority-evaluation outcome semantics, including a machine-stable not_applicable boundary distinct from protocol errors, deny, and indeterminate.¶

• Adds explicit parent-authority linkage, lower-bound time semantics, discoverable clock-profile assumptions, and collective-principal snapshot binding.¶

• Registers application/agent-registry+json and tightens RFC 9457 Problem Details and extension-namespace processing.¶

• Defines how external authoritative trust evidence contributes to ARPA evaluation and specifies normative composition boundaries with ToIP TRQP v2.0.¶

• Describes ToIP TSP as an optional spanning substrate without making TSP a conformance dependency and preserves the rule that authenticated channels/identifiers do not confer authority.¶

• Pins WIMSE references to the revisions reviewed for this draft and clarifies optional SCITT evidence-reference composition.¶

• Makes IETF-draft precedence explicit for IETF protocol conformance while retaining Candidate v0.10.0 as the project baseline for wider governance/profile material.¶

A.5. -04

• Defines explicit Candidate-to-IETF wire-field mappings and rejects conflicting aliases.¶

• Makes the Authority Evaluation Result, affirmative/non-affirmative grouping, multi-dimensional status composition, and freshness contract explicit.¶

• Defines agentreg ABNF/equality/normalization and RFC 8785 default canonicalization for JSON proof inputs.¶

• Hardens registration retry, PUT replacement, event ordering/gap recovery, write authorization, and critical-extension semantics.¶

• Adds concrete SSRF/dereference safeguards and separates registry metadata discovery from agent search.¶

• Requires role-scoped positive and hostile conformance evidence for promoted -04 requirements.¶