]> QBF Consulting LLP

sankarshan@qbfconsulting.digital

Applications and Real-Time Individual Submission software agents agent registry delegated authority lifecycle resolution authorization 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.

Introduction Software agents can retrieve protected information, invoke tools, modify workflows, initiate transactions, coordinate other agents, and otherwise cause effects on behalf of principals. A relying system evaluating such an action needs more than endpoint discovery. It needs protocol-visible information sufficient to determine which agent is involved, which deployment is executing, who operates or controls it, what delegated authority applies, whether that authority remains effective, and where supporting evidence can be obtained. ARPA provides a registry and resolution protocol for those questions. It does not define a universal trust score, a universal legal theory of agency, a new authentication protocol, or a mandatory credential format. It also does not treat successful registry resolution as an authorization decision. A relying party combines ARPA resolution results with local policy and any external authentication, credential, or assurance mechanisms required for its context. The protocol intentionally preserves several non-implication rules: discovering an agent does not imply authorization to invoke it; control of an identifier or cryptographic key does not imply authority to act for a principal; an advertised capability does not imply permission to exercise that capability; successful proof verification does not imply that the asserted authority is current or sufficient; technical federation does not imply governance recognition; and historical registry state is evidence for evaluation, not by itself a legal determination about a historical act. The wider ARPA project specification defines additional governance, assurance, conformance, federation, redress, implementation, and deployment material. This Internet-Draft deliberately narrows that work to interoperable protocol behavior.

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 when, and only when, they appear in all capitals, as shown here. HTTP terminology follows . JSON follows . Timestamps use the date-time form of .

Scope ARPA defines protocol behavior for: persistent agent identifiers and deployment identifiers; registration and update of agent records; typed relationships between agents, principals, operators, controllers, accountable entities, and other actors; representation of bounded delegated authority; capability and assurance references without treating either as authorization; multidimensional lifecycle and authority status; current and point-in-time resolution; registry discovery and query behavior; event publication sufficient to communicate material status changes; deterministic processing of stale, conflicting, unavailable, and unsupported state; error representation; extension and version negotiation rules; and evidence references supporting later audit or reliance evaluation. 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.

Terminology Agent: A software entity capable of performing actions with some degree of autonomy. Agent Identifier: A persistent URI identifying a logical agent independently of a particular version or deployment. Deployment: An operational instance of an agent version in a particular execution context. Principal: A person or organization on whose behalf an agent may act. Operator: The entity responsible for running an agent deployment. Controller: An entity with material technical or administrative control over an agent or deployment. Accountable Entity: An entity identified by the registry as accepting a defined accountability role for an agent or class of actions. Relationship: A typed, scoped, time-bounded statement linking two registry subjects. Authority Envelope: A bounded representation of authority delegated from an issuer to a subject, including permitted actions, resources, conditions, prohibitions, delegation depth, and validity interval. Resolver: A client that queries one or more ARPA registries. Relying Party: A system or actor that uses ARPA data as one input to a local trust or authorization decision. Registry: A service that publishes ARPA records and resolution responses. Authoritative Record: A record for which the publishing registry is identified as an authoritative source within the applicable scope. Derived Record: A cached, indexed, projected, or federated representation whose authoritative source is elsewhere. Material State: State whose absence or change can alter an authorization or reliance outcome.

Protocol Model

Separation of Resolution, Decision, and Enforcement ARPA separates three functions: Resolution obtains registry state and evidence references. Decision evaluates that state against action context and relying-party policy. 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.

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.

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.

Identifier Model

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

: ]]>

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.

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.

Record Envelope Every ARPA record returned by the protocol MUST contain an envelope with at least:

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.

Agent Resource Model An agent resource SHOULD contain: the Agent Identifier; human-readable labels, if available; current version and deployment references; relationship references; service endpoint references; capability declaration references; authority references; lifecycle status; evidence references; and representation metadata including source and freshness. A capability declaration MUST NOT be interpreted as authorization. An endpoint reference MUST NOT be interpreted as proof that the endpoint is controlled by the principal for whom an action is proposed.

Relationship Model A relationship record MUST contain: a relationship type; a source subject; a target subject; an issuer; scope; effective time; and current status. Where absence of a relationship would change an authorization outcome, the response MUST provide either the relationship or a machine-readable indication that authoritative relationship state could not be established. Registries MUST NOT infer a broader relationship from a narrower one. For example, an operated_by or controlled_by relationship MUST NOT be interpreted as acts_for or delegates_to without separate authority evidence.

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.

Lifecycle and Status ARPA represents lifecycle state as multiple dimensions rather than a single active flag. A response MAY expose dimensions including registration, operational, security, authority, and assurance status. A registry MUST distinguish at least the following effects when they are applicable: active or current; suspended; revoked; expired; superseded; retired; and indeterminate or unavailable. A resolver MUST NOT map indeterminate, unavailable, conflicting, or stale material authority state to an affirmative authorization outcome. A registry publishing revocation or suspension SHOULD expose an event or other freshness mechanism enabling consumers to discover the change promptly. A publisher MUST NOT describe revocation as fully converged merely because the registry record changed if downstream enforcement acknowledgements are required by the applicable profile.

HTTP API ARPA uses HTTP semantics as defined by . Registries MUST use HTTPS for network deployments that carry non-public data or authority information unless an equivalent authenticated and confidential transport is provided by the deployment environment. This document defines the following logical resources. Deployments MAY choose different path layouts if discoverable metadata maps the logical operations unambiguously. Operation Example target Purpose Registry metadata GET /.well-known/agent-registry Discover protocol metadata List/discover agents GET /agents Query discoverable agents Resolve agent GET /agents/{id} Resolve current agent state Historical resolution GET /agents/{id}?at={time} Resolve effective-time state Resolve authority GET /agents/{id}/authority Resolve authority statements Resolve status GET /agents/{id}/status Resolve lifecycle/status state Register agent POST /agents Create an agent registration Update registration PUT /agents/{id} Replace an owned registration Use of /.well-known/agent-registry requires an IANA registration before Standards Track publication; see IANA Considerations.

Registry Metadata A registry metadata response SHOULD contain:

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

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.

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.

Historical Resolution Historical resolution uses an at query parameter containing an 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.

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.

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.

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

Error Handling Protocol errors SHOULD use Problem Details for HTTP APIs 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 historical reconstruction indeterminate. Clients MUST NOT treat an unknown error code or unknown Problem Details extension as success.

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.

Versioning and Extensions Protocol versions MUST be explicit in registry metadata and SHOULD be explicit in representations that can cross version boundaries. 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.

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

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

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

IANA Considerations

agentreg URI Scheme This document requests permanent registration of the agentreg URI scheme in the URI Schemes registry in accordance with . 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.

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

application/agent-registry+json Media Type This document requests registration of the media type application/agent-registry+json in accordance with . 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 . 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.

Conformance An implementation claiming conformance to this document MUST identify the protocol version and role or roles for which conformance is claimed. A conforming registry implementation MUST: expose protocol metadata; preserve persistent identifier semantics; distinguish authoritative from derived state; expose lifecycle and authority status without mapping indeterminate state to affirmative authority; implement current resolution; use the defined error behavior or a documented compatible mapping; preserve extension/version fail-closed rules; and satisfy the security and privacy requirements applicable to the implemented features. A conforming resolver implementation MUST: distinguish resolution from authorization; evaluate material freshness; fail non-affirmatively on stale, conflicting, unavailable, or unverifiable material authority; 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Relationship to Existing IETF Mechanisms ARPA is designed to compose with existing IETF mechanisms rather than redefine them. OAuth 2.0 and OAuth Authorization Server Metadata 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 and requires the registration discussed in the IANA Considerations section before Standards Track publication. Deployments that use HTTP Message Signatures 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.

Protocol Precision for Revision 01 This section carries protocol-core precision requirements derived from ARPA Candidate Protocol Precision Amendment ARPA-CAND-PP-01, against the ARPA v0.9.0 Candidate normative baseline. It does not import project-only governance, conformance profiles, A2A integration, TRQP projection, or redress workflows.

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.

HTTP Problem Details An ARPA HTTP API MUST represent protocol-significant errors using Problem Details 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.

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.

Action-Specific Authority Evaluation ARPA resolution can expose authority state, but consequential systems often need to decide whether that state supports one particular action at one particular time. This section defines the protocol-visible invariants for such an evaluation. It does not define a universal policy language or require that the registry make the final authorization decision.

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.

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.

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.

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.

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.

Relationship to Adjacent IETF Work ARPA is intended to compose with existing identity, authorization, attestation, and transparency mechanisms rather than replace them. The WIMSE architecture defines workload identity and describes delegation and impersonation as security-context concerns that can be bound to workload identity. ARPA can consume workload identity as evidence about the executing workload while separately resolving agent/principal relationships, bounded authority, lifecycle state, and historical authority context. A WIMSE-authenticated workload is therefore not automatically authorized under ARPA. OAuth 2.0 Token Exchange provides a mechanism for exchanging security tokens and representing delegation or impersonation in token-processing systems. ARPA does not replace that grant or token mechanism. An OAuth token can be an input to authorization, while ARPA supplies registry-visible authority provenance, scope, lifecycle, relationship, and reconstruction evidence that a relying party can evaluate alongside the token. Current WIMSE discussion of cross-organizational agent delegation identifies recursive attenuation, principal binding, independently administered domains, and verifiable delegation chains as open requirements. ARPA's contribution is complementary: it defines registry-visible bounded authority and fail-safe resolution semantics, including current/historical state and action-specific evaluation. It does not require that delegated authority be encoded in a particular credential or token format. Remote attestation under the RATS architecture can provide evidence about an execution environment and appraisal results. Such evidence MAY be referenced by ARPA as assurance input, but successful attestation MUST NOT be interpreted as proof that a principal delegated authority for a particular action. SCITT provides transparency architecture for signed statements and verifiable receipts. ARPA MAY reference transparency evidence or receipts to strengthen provenance and later audit, but inclusion in a transparency service MUST NOT confer agent authority, governance recognition, or permission to act. These boundaries preserve a central ARPA rule: identity, authentication, evidence integrity, transparency, capability, and delegated authority are related but distinct protocol properties.

Wire-Contract Precision for Revision 03 This section promotes protocol-core wire-contract semantics from ARPA Candidate v0.10.0 and Candidate Wire-Contract Coherence Amendment PP-03. The project schemas and vectors are implementation evidence; the normative requirements for this Internet-Draft are the requirements stated here.

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.

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.

Temporal Boundaries and Clock Profile Authority validity is half-open:

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.

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.

ARPA Problem Details Protocol-significant HTTP errors MUST use Problem Details 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.

Core Error Codes For the protocol failures named by this document, implementations MUST use the following stable code values when the corresponding condition applies: Condition Code invalid request ARPA-INVALID-REQUEST unsupported protocol version ARPA-UNSUPPORTED-VERSION unsupported record/profile semantics ARPA-UNSUPPORTED-PROFILE record/identifier not found ARPA-IDENTIFIER-NOT-FOUND record not authorized for caller ARPA-RECORD-NOT-AUTHORIZED invalid schema/wire representation ARPA-SCHEMA-INVALID unverifiable proof/evidence ARPA-PROOF-INVALID issuer not authorized for asserted scope ARPA-ISSUER-NOT-AUTHORIZED stale material status ARPA-STATUS-STALE expired authority ARPA-AUTHORITY-EXPIRED revoked authority ARPA-AUTHORITY-REVOKED indeterminate authority ARPA-AUTHORITY-INDETERMINATE delegated scope exceeds parent scope ARPA-DELEGATION-EXCEEDS-SCOPE conflicting material status ARPA-CONFLICTING-STATUS temporarily unavailable protocol service ARPA-TEMPORARILY-UNAVAILABLE A profile MAY define additional codes. Additional codes MUST be collision-resistant within their defining namespace and MUST NOT redefine the semantics of a core code.

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.

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.

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.

Federated Trust Resolution and ToIP Composition ARPA can consume authoritative evidence from trust infrastructures outside an ARPA registry. Such composition does not transfer decision semantics from the external protocol into ARPA.

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.

ToIP Trust Registry Query Protocol The Trust Over IP Trust Registry Query Protocol (TRQP) v2.0 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.

ToIP Trust Spanning Protocol The Trust Over IP Trust Spanning Protocol (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.

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.

Conformance Evidence and Specification Precedence The wider ARPA project maintains JSON Schemas, controlled registries, conformance vectors, and validators for the Candidate specification. Candidate v0.10.0 and PP-03 artifacts at repository commit 7200c8512a13615d84c9711ac550da36ae338dd9 are informative implementation and test evidence for the wire semantics promoted by this revision. Those external project artifacts do not override this document for IETF conformance. Where this Internet-Draft and the wider ARPA Candidate Specification conflict on protocol-core behavior defined by this document, this Internet-Draft is authoritative for conformance to this Internet-Draft. The Candidate Specification remains authoritative for project governance, assurance, profiles, redress, implementation guidance, and other material outside this document's scope. A conforming implementation SHOULD test both positive and negative boundary cases for not_applicable, half-open time validity, collective-principal snapshot binding, parent authority linkage, unknown material errors/extensions, and externally sourced authority evidence.

Additional Composability Notes The WIMSE architecture treats AI/ML intermediaries and delegated workloads as a workload-identity problem that can involve multi-hop delegation. ARPA supplies registry-visible authority, lifecycle, and action-bound evidence; it does not replace workload authentication. The cross-organizational delegation problem statement describes requirements for authority that crosses administrative boundaries. ARPA's monotonic delegation and evidence-resolution semantics address one protocol layer of that problem without claiming to solve workload authentication or token issuance. Where a deployment uses SCITT , a SCITT receipt identifier MAY be carried as an ARPA evidence reference. A SCITT receipt, log entry, or transparency inclusion MUST NOT by itself confer agent authority.

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.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. QBF Consulting LLP

Change Log This section is to be removed by the RFC Editor before publication.

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

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

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

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