]> AIDAXIA Ltd.

United Kingdom office@aidaxia.ai https://aidaxia.ai

Security Individual Submission AI agent identity authoritative resolution pre-interaction verification This document specifies AIN-WRP, a protocol-independent mechanism for authoritative resolution of persistent digital agent identities and for verification of relationship-specific state before a digital agent begins a protected operational interaction with another agent or with a non-agent service or system. An Agent Identity Number (AIN) acts as a stable lookup anchor. The protocol resolves current identity, lifecycle, operator or authority, endpoint, mandate, restriction, provenance, and cryptographic verification information from sources competent to make the corresponding assertions. AIN-WRP separates persistent identity from credentials, proof of control, delegated authority, operational eligibility, policy decision, and execution. For participants operating under independent administrative domains, the protocol performs logically independent resolution, validates source competence and evidence freshness, correlates the resulting assertions for the proposed relationship, and produces a Pre-Interaction Trust State. A signed, time-limited State Proof may convey that state to a gateway or relying party. The gateway applies local policy and controls whether an A2A, MCP, API, messaging, transactional, or proprietary protocol begins. This version defines the protocol model and the initial requirements for future interoperable profiles. It does not require all AIN registration, resolution, assertion issuance, policy evaluation, or operational enforcement to be performed by a single central service, a mandatory Regional Network Operator (RNO), or a particular gateway, identity provider, authorization framework, or execution protocol.

Introduction Digital agents increasingly initiate requests, invoke tools, exchange data, negotiate, and execute transactions across organisational and jurisdictional boundaries. Existing authentication and authorization mechanisms can establish possession of a credential, authenticate a workload or client, or express delegated access. Those properties are necessary but do not, by themselves, establish the current authoritative state of a specific persistent digital-agent identity or of the proposed relationship between an agent and its intended counterparty, including another agent or a non-agent service or system. A frequently raised objection illustrates why this distinction matters in practice: an operator holding a valid API credential may argue that the credential alone identifies who made a request, and that no additional identity layer is required. This objection is correct as far as it goes; credential validity does identify a requester at the transport layer. It becomes visible as insufficient exactly at the points this document addresses: when the same credential is shared or reused by multiple autonomous agents performing different tasks, when a credential is rotated or redelegated across deployments, or when a dispute requires determining which agent, under whose authority, initiated a specific request that crossed an organisational boundary. In such cases the credential establishes that a request was authorized to reach a service; it does not, by itself, establish which persistent agent identity initiated the request, on whose behalf, or whether that specific action remained within the scope the delegating party intended. In particular, a valid credential does not necessarily establish that the represented agent remains operationally eligible; that the presenter controls the currently authorised key; that a claimed operator or mandate remains current; that a presented endpoint is authoritative; that a restriction issued in another administrative domain has been considered; or that the source making a security-relevant assertion is competent to make that assertion. AIN-WRP introduces an authoritative trust-plane operation that occurs before, or at the admission boundary of, the execution-plane protocol. The operation begins with the persistent AIN of each participating digital agent and, where the counterparty is not a digital agent, with an authoritative service, system, account, or endpoint reference appropriate to that interaction. It resolves required assertions from competent sources, preserves provenance and validity metadata, validates proof material where required, and correlates the evidence for the intended interaction. The resulting state is supplied to a gateway or relying party, which remains responsible for local policy and enforcement. An AIN identifies a technical software system or agent record. It does not confer legal personality, citizenship, regulatory approval, or a status equivalent to that of a natural or legal person. Responsibility remains with the applicable provider, deployer, operator, controller, principal, or other accountable entity. AIN-WRP is complementary to OpenID Connect, OAuth, workload identity, verifiable credentials, A2A, MCP, HTTP message signatures, gateway policy systems, and observability systems. Those systems may carry, bind, or consume AIN information and AIN-WRP results; they are not replaced by this specification.

Why This Requires a Neutral, Cross-Organisational Layer Individual platforms and payment rails are independently addressing adjacent parts of this problem. Agent-management platforms bind identity to governance and policy enforcement within one operator's infrastructure. Payment networks are introducing spending limits, allowed-merchant lists, and proof of intent bound to a specific rail. Both are valuable and neither requires this specification. Neither, however, is designed to let two independent administrative domains, using different platforms and different rails, establish who a counterparty's agent is, who operates it, and under what mandate, before an interaction begins. That specific function — a persistent, publicly resolvable identity anchor and a pre-interaction verification step that neither party's platform vendor nor payment provider is positioned to arbitrate — is the reason this document proposes a protocol-independent, vendor-neutral specification rather than a product. A layer intended for use across independent administrative domains should not require either counterparty to accept the other counterparty's platform vendor or payment provider as the sole authority for cross-domain identity and relationship state; it needs the same standing that addressed identifiers and naming protocols have historically required. This does not diminish the value of platform-level identity and governance products, or of rail-level payment controls; AIN-WRP is designed to be resolved and consumed by them, not to replace them (Section 19).

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.

Terminology

Term	Definition
Digital Agent	A software system capable of initiating, receiving, selecting, or executing operations with operational autonomy on behalf of a principal, operator, or defined system objective. Mere automation of a fixed instruction or transport function does not, by itself, make a component a Digital Agent for purposes of this specification.
Counterparty	The agent, service, system, account, or operational endpoint with which an AIN-identified digital agent proposes to interact. A Counterparty is not required to be a Digital Agent or to possess an AIN unless the applicable profile requires it.
AIN	A globally unique, persistent identifier assigned by an authoritative AIN registry to a digital agent or AI system record.
AIN-WRP	The AIN Web Resolution and Pre-Interaction Verification protocol model specified by this document.
Authoritative Source	A source recognised as competent to confirm one or more specified assertions.
Competent Source	An Authoritative Source whose competence covers the particular attribute, state, restriction, relationship, territory, sector, lifecycle function, endpoint, or class of operation being relied upon.
Competence Record	Evidence describing the scope within which a source is authorised or technically competent to issue assertions.
Resolved Assertion	An assertion obtained from a source together with provenance, validity, version, and competence metadata sufficient for the relying party to evaluate it.
Resolver	A service that obtains current AIN-related information and preserves source, validity, provenance, and competence metadata.
Administrative Domain	A domain within which identity, state, authority, or restrictions are administered under a defined policy.
RNO	A Regional Network Operator that may operate or mandate an authoritative regional source. RNO participation is not required in every deployment.
Relying Party	A component that consumes resolved information or a pre-interaction result and applies its own enforcement policy.
Pre-Interaction Trust State	A relationship-specific result created by correlating validated authoritative assertions before the operational protocol begins.
State Proof	A signed, time-limited representation of a Pre-Interaction Trust State, bound as appropriate to participants, endpoint, roles, audience, interaction context, evidence versions, and restrictions.
Operational Protocol	The A2A, MCP, API, messaging, payment, transactional, or proprietary protocol through which the requested action is carried after admission.
Policy Decision	The relying party or gateway decision derived from the verified state and applicable local policy. AIN-WRP does not require a universal policy.
Controlled Operational Session	An operational session created only after successful validation and, where required, atomic consumption of a State Proof, and constrained by the participants, endpoint, audience, channel context, and mandatory restrictions bound to that proof.
Consumption Receipt	A stable record produced by a successful atomic proof-consumption operation that binds the consumed State Proof, controlled session, idempotency key, consuming gateway, and commit result.

Scope and Non-Goals

Scope

• canonical presentation and validation requirements for an AIN;
• authoritative HTTPS resolution and machine-readable (JSON, ) representations;
• lifecycle disclosure and operational-eligibility semantics;
• discovery of verification material and optional proof of control;
• validation of source competence for security-relevant assertions;
• authoritative endpoint resolution;
• pre-interaction correlation across independent administrative domains, including agent-to-agent and profile-defined agent-to-service interactions;
• preservation and composition of mandatory restrictions;
• optional signed State Proofs for gateway or relying-party consumption;
• federated, enterprise, regional, and sovereign deployment models;
• security, privacy, caching, invalidation, error, and extensibility requirements.

Non-Goals

• define legal responsibility, certification, or regulatory approval;
• standardise a universal trust score, risk score, or behavioural reputation methodology;
• observe or control an operator's internal agent orchestration;
• replace OAuth, OpenID Connect, A2A, MCP, workload identity, gateway policy engines, or execution protocols;
• require all AIN registration, resolution, assertion issuance, policy evaluation, or operational enforcement to be performed by a single central service, one commercial registry, or mandatory RNO deployment;
• require all attributes concerning an agent to be held by the same source;
• require the resolver or correlation service to execute the underlying action or transaction;
• dictate the relying party's local authorization policy.

Architectural Model The architecture separates persistent identity, authoritative verification, policy enforcement, and execution. AIN provides the persistent lookup anchor. AIN-WRP resolves and validates relationship-relevant state. The gateway or relying party applies local policy. The operational protocol carries the permitted interaction.

Stage	Input	Output	Primary component
Identify	Initiator AIN; recipient AIN when applicable, otherwise authoritative counterparty reference; interaction context	Correlation request	Gateway or relying party
Resolve	AINs and required assertion types	Current source records	Resolver and competent sources
Validate	Records, signatures, validity, provenance, competence	Validated assertions	Resolver or correlation engine
Correlate	Validated evidence sets and relationship context	Pre-Interaction Trust State	Correlation engine
Prove (optional)	Trust State and evidence bindings	Signed State Proof	Correlation service
Enforce	Trust State or proof plus local policy	ALLOW, RESTRICT, DENY, REVIEW, or local equivalent	Gateway or relying party
Execute	Permitted protocol parameters	Operational session/action	A2A, MCP, API, payment, messaging, or other protocol

Trust Plane and Execution Plane AIN-WRP does not require the trust plane and execution plane to be operated by the same entity. A resolver may be public, private, federated, sectoral, regional, or sovereign. A gateway may consume a State Proof without delegating execution authority to the resolver. Conversely, a gateway that authenticates an agent credential MUST NOT infer that credential validity alone establishes the full Pre-Interaction Trust State.

Agent Identity Number

Canonical Syntax The current AIN profile uses this canonical textual form, expressed in ABNF : The canonical representation MUST use uppercase ASCII letters and ASCII hyphen-minus separators and MUST contain no surrounding whitespace. Implementations MUST treat the AIN as an opaque persistent identifier and MUST NOT infer jurisdiction, capability, lifecycle state, authority, or regulatory status from its components. Examples such as RG-01-CULRWC8ZKE34-4684 and SYS-01-Q3CZWMSJUEL3-BDAC are synthetic. The checksum is a short registry integrity check; it is not a digital signature, public proof of authenticity, uniqueness guarantee, or substitute for authoritative resolution.

Namespace Coordination and Canonical Registration AINs are globally unique within a coordinated AIN namespace. An identifier is valid as an AIN only when it has been allocated or canonically registered through an authority recognised by the namespace-coordination framework; conformance to the syntax and checksum rules of Section 6.1 alone does not establish that a string is a validly issued AIN. The namespace-coordination function MUST prevent reassignment of an issued AIN to a different digital-agent identity and MUST maintain, or enable discovery of, an authoritative canonical record for each validly issued AIN. A regional, sectoral, or institutional registration operator MAY receive, validate, or process AIN registration requests and MAY maintain a local projection of canonical AIN records for its area of operation. Such a local projection MUST remain synchronized with, and MUST NOT independently modify or reassign, the canonical registration. Where no such regional operator exists for a given deployment, registration and canonical resolution MAY be performed directly by the namespace-coordination function. This model is architecturally comparable to coordinated-namespace systems such as GS1, where a global coordinating function allocates namespace and Member Organisations administer registration within it without creating independent, competing identifier spaces. This document defines the architectural requirement for namespace coordination and canonical registration. It does not standardize the institutional, contractual, commercial, or long-term governance arrangements under which namespace-coordination and registration operators are authorised.

Persistence An issuer MUST NOT reassign an AIN to a different agent or system record. Suspension, revocation, retirement, custody transfer, or replacement of a deployment MUST NOT cause the identifier to be reused. A resolver SHOULD retain enough tombstone information to distinguish a known revoked identifier from one that has never been issued.

AIN and Web Identifier The bare AIN is the persistent identity anchor. A Web-Resolvable AIN URI is a transport representation of that anchor and MAY include role, scope, or context qualifiers. Qualifiers MUST NOT create a new underlying identity unless a separate AIN has been issued for that identity.

Relationship to Other Identifiers A digital agent identified by an AIN MAY also possess or use other identifiers, credentials, account identifiers, workload identities, decentralised identifiers, sector-specific identifiers, or protocol-specific identities. AIN-WRP does not require such identifiers to be replaced. Within AIN-WRP, the AIN is the persistent identity anchor to which authoritative state and relationship-relevant assertions are resolved. Other identifiers or credentials MAY be associated with an AIN and MAY be used as supporting evidence where their issuer, binding, validity, scope, and applicable competence can be established. An additional identifier or credential MUST NOT be treated as a substitute for the AIN when an AIN-WRP operation requires authoritative resolution of a digital agent by AIN.

Authoritative Resolution

Resolution Endpoint This version provisionally uses the following HTTPS resource ():

Resolver Response The following example illustrates a proposed protocol representation. It is not asserted to be the response format of every implementation:

Source Competence A signed response is not authoritative merely because its signature is valid. A relying party MUST establish that the issuer is competent for each security-relevant assertion it consumes. Competence MAY be limited by attribute, territory, sector, relationship type, lifecycle function, endpoint class, or class of operation. Where multiple sources contribute to a result, the resolver SHOULD preserve, for each assertion, the source identity, competence scope, version, issuance time, expiry time, retrieval time, and validation status. A resolver MUST NOT silently elevate a source beyond its competence.

Authoritative Endpoint Resolution An endpoint presented by an initiating agent is a hint, not an authoritative routing instruction. Before a security-sensitive operational interaction begins, the recipient endpoint SHOULD be resolved from a source competent to identify that endpoint. A gateway MUST NOT redirect or initiate a protected operation solely on the basis of an initiator-supplied endpoint when authoritative endpoint resolution is required by the applicable profile.

Lifecycle and Operational Eligibility Identity existence, resolvability, lifecycle state, and operational eligibility are distinct concepts. A known identifier SHOULD remain resolvable after suspension or revocation so a relying party can discover its current state. An endpoint used specifically for an operational handshake MAY refuse inactive identifiers.

State	Identity resolution	Operational treatment	Meaning
ACTIVE	Return current record	Eligible subject to policy	Record is active.
SUSPENDED	Return state and limited record	Deny or require review	Temporarily ineligible.
PENDING	Return state and limited record	Deny or defer	Not yet active.
REVOKED	Return tombstone and state	Deny	Permanently revoked; identifier not reusable.
EXPIRED	Return state when known	Deny or require renewal	Validity interval ended.
UNKNOWN	Not found	Deny	No authoritative record found.

A resolver MUST NOT represent UNKNOWN as REVOKED, or REVOKED as UNKNOWN. A client MUST NOT treat successful identity resolution as authorization to perform an operation.

Proof of Control A registry or competent verification service MAY provide challenge-response verification to demonstrate possession of cryptographic material associated with an AIN. The challenge MUST contain an unpredictable nonce, expiry time, target AIN, intended audience, and sufficient context to prevent use for another purpose. The response MUST be bound to the nonce and AIN and MUST be verified against active cryptographic material obtained through authoritative resolution or an authorised key-discovery resource. A nonce MUST be single-use. Expired, previously used, or context-mismatched challenges MUST be rejected. Proof of control establishes possession of a key. It does not, by itself, establish a valid mandate, permission for a proposed action, current endpoint authority, operator binding, source competence, or cross-domain operational eligibility.

Pre-Interaction Verification

Correlation Request Before sending the first protected operational message, a relying party MAY submit a relationship-specific request containing at least the initiator AIN, a recipient AIN when the recipient is an AIN-identified digital agent or an authoritative counterparty reference when it is not, participant roles, interaction type, audience, request identifier, issuance time, and expiry time. It MAY also include endpoint hints, requested capability, jurisdictional or sectoral context, assurance requirements, and a hash of the requested operation. This version defines the semantic content of the correlation request but does not yet standardize its transport endpoint or media type.

Independent Resolution The resolver MUST create logically separate resolution operations for each AIN-identified digital agent participating in the interaction. Where the counterparty is not a digital agent, the applicable profile MUST define how the counterparty service, system, account, or endpoint is authoritatively identified or resolved. Each required assertion MUST be obtained from a source competent for that assertion. A deployment MAY use one registry, regional RNO nodes, national or institutional registries, enterprise registries, federated services, or a combination of those sources. Independent resolution is a logical requirement, not a requirement for separate network connections. In an agent-to-agent interaction, a single service MAY answer for both participants only when it is demonstrably competent for the assertions consumed for both administrative domains. In an agent-to-service interaction, the agent identity and the non-agent counterparty binding remain distinct verification subjects even when one infrastructure component supplies evidence for both.

Validation For each security-relevant assertion, the resolver or correlation engine MUST evaluate source competence, cryptographic validity where applicable, freshness, lifecycle validity, audience or context binding where applicable, and contradiction with other mandatory evidence. Missing, stale, contradictory, or non-authoritative information MUST NOT be silently converted into permission.

Correlation and Restriction Composition The correlation engine associates validated evidence with the proposed relationship. The resulting Pre-Interaction Trust State is relationship-specific and MUST NOT be interpreted as a permanent reputation or universal authorization for either participant. Mandatory prohibitions MUST be preserved. Compatible restrictions MAY be combined. When two competent sources issue conflicting mandatory requirements and no deterministic precedence rule is available, the result MUST NOT be ALLOW.

Result	Meaning	Required gateway behaviour
ALLOW	Required evidence is current and the applicable evaluation permits the relationship.	Gateway may begin the operational protocol, subject to local policy.
RESTRICT	The relationship is eligible only under stated controls.	Gateway MUST apply every mandatory restriction it accepts as a basis for execution.
DENY	A prohibition, invalid lifecycle state, failed proof, or required-evidence failure applies.	Gateway MUST NOT begin the protected operational protocol.
REVIEW	Higher-assurance, additional-source, or human evaluation is required.	Gateway MUST defer the protected operational protocol.

Separation of Verified State and Local Policy AIN-WRP distinguishes verified state from the relying party's local policy. A resolver MAY return validated assertions without issuing an ALLOW, RESTRICT, DENY, or REVIEW result. A correlation service MAY provide a suggested or profile-defined result, but the relying party remains responsible for applying local authorization and regulatory policy. A State Proof MUST identify whether a decision was produced by the correlation service or by the consuming gateway.

Pre-Interaction State Proof This version confines the normative treatment of the State Proof to the semantic bindings implied by its definition in Section 3 and by the Prove stage of the architectural model in Section 5. Serialization (JOSE vs. COSE), canonicalization, and format-level encoding of the State Proof are deferred to a future conformance profile, pending community feedback and evaluation of deployment security profiles. The design considerations explored during drafting of this version are retained non-normatively in Appendix C.1, as input to that future work; they do not constitute a stable interface.

State Proof Consumption and Controlled Session Establishment Atomic State Proof consumption, controlled-session establishment, idempotent retry handling, and consumption-receipt creation are significant security-relevant capabilities that this version does not standardize at the transport or persistence level (see Appendix A, “State Proof consumption”). The semantic requirements explored during drafting are retained non-normatively in Appendix C.2 as input to a future conformance profile.

Federated, Regional, Enterprise, and Sovereign Resolution This version confirms, at the level of the architectural model in Section 5, that AIN-WRP does not require a single global registry and that competent sources MAY be operated by independent organisations, sectors, regions, or sovereign infrastructures. The signed routing, discovery, and competence-delegation formats needed to standardize federated, RNO-mediated, and private or air-gapped resolution are deferred to a future revision. The design considerations explored during drafting of this version are retained non-normatively in Appendix C.3 and Appendix C.4, as input to that future work.

Caching, Invalidation, and Re-Evaluation Resolvers MAY cache signed results. Cache lifetime MUST NOT exceed the shortest applicable validity interval or policy limit. Negative caching SHOULD use a shorter lifetime than positive identity caching. Security-sensitive clients SHOULD revalidate when an AIN state, key, mandate, endpoint, competence record, restriction, or relevant configuration changes. A cached ACTIVE state MUST NOT be used after receipt of an authoritative invalidation event. Deployments unable to receive invalidations MUST use conservative expiration intervals appropriate to the operation's risk. Long-lived operational sessions SHOULD define re-evaluation triggers. A higher-assurance profile MAY require re-evaluation when lifecycle state, mandate, endpoint, key material, source competence, mandatory restriction, or supply-chain status changes. Re-evaluation does not require AIN-WRP to carry the application data plane.

Error Model HTTP APIs SHOULD use Problem Details for HTTP APIs . Machine-readable error codes MUST distinguish identifier-format failure, unknown identity, lifecycle ineligibility, proof failure, replay, source failure, competence failure, endpoint-resolution failure, evidence conflict, and policy denial.

Code	Typical HTTP status	Meaning
invalid_ain	400	Identifier is malformed or non-canonical.
ain_not_found	404	No authoritative record exists.
ain_suspended	403 or 200 (identity-only)	Known identity is temporarily ineligible.
ain_revoked	410 or 200 (tombstone)	Known identity is permanently revoked.
challenge_expired	410	Challenge validity interval ended.
replay_detected	409	Nonce, assertion, or proof was consumed.
source_unavailable	503	Required competent source is unavailable.
source_not_competent	422	Source is valid but lacks competence for the required assertion.
endpoint_unresolved	424	Required authoritative endpoint could not be established.
evidence_conflict	409	Competent evidence is contradictory and cannot be safely composed.
policy_denied	403	Applicable policy does not permit the relationship.
proof_expired	410	State Proof expired before successful consumption.
proof_revoked	403 or 410	State Proof was revoked before consumption.
proof_already_consumed	409	Proof was consumed and retry context is not equivalent.
idempotency_conflict	409	Idempotency key was previously used with different security-relevant parameters.
proof_context_mismatch	403	Participant, audience, endpoint, operation, or channel binding does not match.
session_commit_failed	503	Atomic operation did not commit and no session was established.

Alternative statuses for identity-only and operational endpoints are intentional. A future revision is expected to define separate conformance profiles with exact mappings. A profile MAY expose the more specific proof-consumption error codes above. Where it does not, replay_detected is the generic code for reuse of consumed proof material. For profiles exposing the specific codes, an idempotent retry using the same key and equivalent security-relevant context returns the original successful result; reuse of the same idempotency key with different security-relevant context is idempotency_conflict; reuse of a consumed proof with a different idempotency key is proof_already_consumed or the generic replay_detected; and a participant, audience, endpoint, operation, or channel mismatch detected before successful consumption is proof_context_mismatch. Illustrative Problem Details response (the URI is synthetic; normative problem types are deferred to a later profile):

Security Considerations

• An AIN is public and MUST NOT be treated as a bearer credential.
• All authoritative resolution traffic MUST use TLS with server authentication and certificate validation appropriate to the resolver authority. Mutual TLS MAY be required by a higher-assurance profile.
• Security-relevant responses SHOULD be signed or obtained through a mutually authenticated channel.
• Relying parties MUST validate source competence in addition to signature validity.
• Agent-supplied endpoint hints MUST NOT override authoritative endpoint resolution where that resolution is required.
• Challenge nonces and proof identifiers MUST be unpredictable, time-limited, audience-bound where applicable, and protected against replay.
• Key rotation and revocation MUST be represented without reassigning the AIN.
• Resolvers MUST apply controls against enumeration, amplification, recursive-resolution abuse, and resource exhaustion.
• A trust score, badge, QR code, cached response, syntactically valid checksum, or valid credential MUST NOT replace current authoritative verification when such verification is required.
• Implementations SHOULD record identifiers, source versions, competence records, policy versions, results, and evidence necessary to reconstruct a decision.

Implementations MUST also address: substitution of the initiator, recipient, action, resource, or endpoint; mix-up between concurrent correlation requests; replay to another gateway, audience, endpoint, or channel; compromised or no-longer-competent sources; operationally stale but cryptographically valid assertions; key and algorithm confusion; downgrade between protocol profiles; DNS rebinding and unauthorised redirects; server-side request forgery; persistent-identifier correlation; and denial-of-service through federated resolution. Proof consumption and session creation MUST NOT be implemented as independent non-atomic operations when the applicable profile requires single-use proofs. Otherwise, concurrent requests can consume the same proof and create multiple sessions, or a proof can be marked consumed without a corresponding session. Implementations MUST distinguish a pre-commit failure from a response-delivery failure occurring after commit. A retry following an uncertain outcome MUST use the same idempotency key.

Privacy Considerations A persistent agent identifier enables correlation across services. Public responses MUST minimise personal data and SHOULD expose only information necessary for verification. Operator details SHOULD use organisational identifiers or resolvable references rather than personal contact information unless disclosure is necessary and lawful. Resolvers SHOULD support tiered projections for public, authenticated, and authorised callers. Incident evidence, private mandates, internal supply-chain details, sensitive policy constraints, and security telemetry MUST NOT be included in public responses by default. Cross-domain correlation SHOULD disclose only the assertions necessary for the proposed relationship. A State Proof SHOULD prefer hashes, references, or bounded claims over unnecessary replication of source records when the relying party can validate them without receiving the underlying sensitive data.

Deployment Examples (Non-Normative)

Gateway Admission An API or MCP gateway receives a request from an agent identified within AIN-WRP by its AIN. The agent MAY also present or use other identifiers, credentials, or authentication mechanisms. Before admitting the protected protocol, the gateway or associated AIN-WRP service resolves the initiating AIN, validates its current lifecycle state and applicable proof material, and, where required, verifies the relationship between the AIN and any additional identity or credential presented by the agent. Where the recipient is an AIN-identified digital agent, it resolves the recipient AIN and authoritative endpoint from competent sources. Where the recipient is a non-agent service or system, it instead establishes the authoritative counterparty and endpoint binding required by the applicable profile. It then evaluates applicable restrictions and consumes a State Proof or equivalent verified state. The gateway then applies its own OAuth, OIDC, OPA, ACL, or other authorization policy. Such mechanisms are complementary to AIN-WRP and do not replace the AIN as the persistent identity anchor within AIN-WRP.

Cross-Organisation Agent Interaction Agent A, identified by AIN-A, is administered by Organisation A, and Agent B, identified by AIN-B, is administered by Organisation B. Either agent MAY also use other identifiers, credentials, or authentication mechanisms within its administrative domain. For purposes of AIN-WRP, AIN-A and AIN-B remain the persistent identity anchors to which the relevant authoritative assertions are resolved and correlated. Each administrative domain may maintain different competent sources for identity, operator binding, mandate, endpoint information, lifecycle state, and restrictions. AIN-WRP resolves the evidence associated with AIN-A and AIN-B independently, validates the competence of the contributing sources, and correlates the resulting assertions for the proposed interaction. A restriction validly issued by a competent source in Organisation B's domain is not overridden merely because Organisation A permits the action.

Agent-to-Service Interaction An AIN-identified digital agent may interact with a conventional API, web service, merchant system, database service, or other non-agent counterparty. The non-agent counterparty is not required by this specification to obtain an AIN solely because an agent interacts with it. Before the protected operation begins, AIN-WRP resolves and validates the agent's persistent identity and applicable authoritative assertions and, where required by the applicable profile, establishes the authoritative identity or endpoint binding of the counterparty. The resulting Pre-Interaction Trust State is therefore relationship-specific without converting every automated service into a Digital Agent. In this scenario, the non-agent counterparty is not itself identified by an AIN. Rather, it acts as a relying party that consumes AIN-based assurance about the initiating agent. What the counterparty gains beyond validation of an API credential is independent, cross-organisational verification of the persistent agent identity, its current operator binding, and applicable mandate assertions — verification that does not depend on the agent's own platform self-asserting these facts, and that reflects a restriction issued by a source outside the counterparty's own trust boundary before the interaction is admitted.

Regulated Financial Interaction A financial institution may require a payment or treasury agent participating in an AIN-WRP protected interaction to have a resolvable AIN in an operationally eligible state, together with current proof of control where required, an authoritative mandate from the account-holding organisation, an authoritative recipient AIN and endpoint where the recipient is an AIN-identified agent, or an authoritative counterparty and endpoint binding where it is not, and no applicable mandatory restriction before the payment protocol begins. The agent MAY also use banking, payment-network, enterprise, workload, OAuth, or other identifiers and credentials required by the institution or the underlying transaction protocol. Such identifiers and credentials MAY be validated or correlated with the agent's AIN as supporting evidence, but they do not replace the AIN as the persistent identity anchor within AIN-WRP. The financial institution remains responsible for payment authorization, regulatory controls, transaction screening, and execution. AIN-WRP provides authoritative identity resolution and pre-interaction verification; it does not execute or approve the payment itself.

Sovereign or Private Domain A government, bank, critical-infrastructure operator, or other high-assurance environment may operate an authorised private or sovereign AIN source and keep sensitive attributes within its administrative perimeter. Agents within that domain MAY also use local, sector-specific, governmental, workload, or other identity schemes. Such identifiers MAY be associated with an AIN and used as supporting evidence without replacing the AIN as the persistent identity anchor for AIN-WRP interactions. Cross-domain verification may expose only the AIN and the minimum signed, time-limited result or selected authoritative assertions required through an authorised boundary. The same AIN identity semantics can therefore support public, enterprise, federated, private, and sovereign deployments without requiring central storage or disclosure of all underlying identity data.

IANA Considerations This document requests no IANA action at this time. The ain well-known URI suffix used in the resolution endpoint (Section 7.1) is provisional. Registration of this suffix under the Well-Known URIs registry established by will be requested in a later revision, once the resolution mechanism and its security properties are sufficiently stable. The registration request will specify: the URI suffix (ain); the change controller (IETF or the authors pending WG adoption); the applicable specification (this document); and security considerations as required by . If a dedicated media type or registries for lifecycle states, error codes, proof profiles, competence types, or issuer prefixes are required, their registration policies and initial values will be specified in a later revision or a companion profile document.

Implementation Status (Non-Normative) This section distinguishes implemented primitives from proposed protocol elements. It may be removed before publication as an RFC. Deployment status can differ from development status, and this draft does not claim production parity for any implementation.

Capability	Current classification
Public verification and machine-readable resolution	Implemented in a development workspace
Web-resolvable AIN and JSON-LD	Implemented in a development workspace
Lifecycle enforcement and JWKS discovery	Implemented in a development workspace
Single-agent challenge-response, signed assertions, replay state	Implemented in a development workspace
Public incident intake and scoped case handling	Implemented in a development workspace
Uniform lifecycle semantics across public endpoints	Partially implemented
Independent dual-domain resolution and competence validation	Proposed
RNO-to-RNO signed resolution protocol	Proposed
Bilateral State Proof and restriction composition	Proposed
Atomic proof consumption, controlled-session creation, idempotent retry, and receipt	Not implemented end to end
Continuous gateway re-evaluation	Proposed

Relationship to Other Work

OpenID Connect Agent Identity Profiles OpenID Connect agent-identity profiles can carry agent-specific claims in ID Tokens. AIN-WRP addresses a different but complementary layer: persistent authoritative resolution and relationship-specific verification that is not limited to one identity provider or one token session. An AIN MAY be carried as an OpenID Connect claim, and an OpenID Connect token MAY be evidence consumed during AIN-WRP validation.

OAuth, WIMSE, and Agent Authentication/Authorization OAuth-family mechanisms, workload-identity systems, and emerging AI-agent authentication and authorization profiles provide credentials, delegation, scopes, token exchange, channel binding, and resource authorization. AIN-WRP does not redefine those mechanisms. It addresses the authoritative resolution of persistent agent identity and other relationship-relevant assertions, including the competence and provenance of the sources from which those assertions are obtained.

External Identity, Delegation, and Capability Artefacts External identity, delegation, and capability systems may provide cryptographically verifiable artefacts concerning a digital agent, its delegated authority, mandate, or prior actions. Such artefacts MAY be used as supporting evidence during AIN-WRP verification where their issuer, validity, provenance, scope, and applicable competence can be established. Possession or presentation of such an artefact does not, by itself, establish the current authoritative state or cross-domain eligibility of a digital agent. Where required by the applicable profile, AIN-WRP independently resolves and evaluates the relevant persistent identity, lifecycle state, source competence, mandate or authority, endpoint information, and applicable restrictions before producing a Pre-Interaction Trust State. AIN-WRP therefore does not require delegated authority, permissions, or operational eligibility to be encoded in the persistent AIN identity itself. These properties are treated as distinct, potentially dynamic assertions that may originate from different competent sources.

A2A, MCP, APIs, and Gateways A2A , MCP , APIs, messaging systems, payment networks, and proprietary protocols carry operational messages. Gateways and policy engines control admission and execution. AIN-WRP is intended to run before, or at the admission boundary of, those protocols and to provide verified identity and relationship state that such systems may consume.

Observability and Audit Observability systems explain execution behaviour and system events after or during operation. AIN-WRP establishes persistent actor identity and pre-interaction state. The two functions are complementary; an implementation MAY attach AIN and State Proof identifiers to traces, logs, or receipts for later correlation.

Relationship to Contemporaneous Work Several other efforts published or updated during the development of this document address closely related problems. This section positions AIN-WRP relative to them and is expected to be revised as those efforts mature. Other recent Internet-Drafts start from a premise similar to Section 1 of this document: that possession of a valid credential is insufficient to establish which agent is acting, under whose authority, and within what constraints. carries agent-specific claims within OpenID Connect ID Tokens; applies the WIMSE architecture and the OAuth 2.0 family of specifications to agent authentication and authorization; and binds a cryptographic agent passport to a separately signed principal binding and to delegation chains that narrow monotonically, producing signed action receipts. AIN-WRP shares this premise but differs in its principal contribution: an authoritative, cross-administrative-domain resolution and correlation step, performed by sources independently competent for the identity, lifecycle, and relationship in question, prior to admission at the execution-plane protocol. Where such efforts define credential formats that bind identity, delegation, and authorization constraints together, AIN-WRP treats persistent identity resolution as a distinct trust-plane operation that such credentials, and other delegation or authorization artefacts, MAY be validated against, rather than as a data format for carrying them. Commercial and open-source implementations addressing adjacent problems, including agent identity and governance platforms and agent-guardrail tooling, provide credential lifecycle management, scoped authorization, and runtime policy enforcement within a single operator's infrastructure or a single integration surface. AIN-WRP does not compete with these functions; a deployment MAY use such a platform as a competent source, or as the gateway that consumes a Pre-Interaction Trust State. AIN-WRP's distinguishing scope is authoritative resolution and pre-interaction verification across independent administrative domains that do not share a common operator, registry, or platform. Where a future revision of this document, or a companion profile, can express identical semantics using a contemporaneous specification's data format, convergence is preferred to parallel formats. This section will be updated as those specifications reach further maturity.

Relationship to Other Identifier and Credential Systems An AIN is not intended to replace URIs, DIDs, SPIFFE IDs, certificates, OAuth tokens, workload credentials, or other identifier and authentication mechanisms. Those mechanisms address different, and often complementary, requirements. An AIN is a persistent lookup anchor within a coordinated namespace. It enables a relying party to request current identity-related and relationship-specific assertions while preserving the distinction between the identifier, the current controller or operator, the presented credential, the resolved endpoint, delegated authority, lifecycle state, and operational eligibility. A URI can identify or locate a resource, and an AIN can be represented through a Web-resolvable URI. However, an operational endpoint URI is not necessarily a persistent digital-agent identity; endpoints can change, expire, or be reassigned without requiring the underlying registered identity to change. A DID can provide a resolvable identifier and cryptographic verification material under an applicable DID method. A SPIFFE ID can identify a workload within a SPIFFE trust domain and can be used with a workload credential. Such identifiers and credentials MAY be associated with an AIN or used as evidence during AIN-WRP validation. Control of a URI, DID, SPIFFE ID, certificate, key, or token does not, by itself, establish every assertion required for a pre-interaction decision. In particular, it does not necessarily establish the current lifecycle state, operator binding, mandate, authoritative endpoint, source competence, applicable restrictions, or cross-domain operational eligibility of the identified agent. Conversely, possession or resolution of an AIN does not authenticate the presenter and does not authorise an operation; authentication, proof of control, mandate validation, local authorization, and execution remain separate protocol functions. AIN-WRP therefore permits existing identifier and credential systems to be carried as resolved attributes, verification methods, or evidence. Its distinct function is to use a persistent lookup anchor to resolve and correlate current assertions from sources competent for those assertions across potentially independent administrative domains. The distinction is not that an AIN uses characters that other identifiers cannot express; the distinction is the persistence, non-reassignment, resolution, provenance, competence, lifecycle, and cross-domain correlation contract defined around the identifier.

Normative References Informative References Model Context Protocol Project Work in Progress A2A Protocol Project Work in Progress

Open Design Decisions The State Proof serialization, federated/RNO routing, and State Proof consumption rows below correspond to material carried forward, non-normatively, in Appendix C.

Decision	Version-00 position	Required before later revision
Canonical JSON-LD context	Provisional/example namespace only	Publish a stable context or select a neutral namespace.
Lifecycle HTTP mapping	Identity and operational endpoints distinguished	Define conformance profiles and exact status mapping.
AIN checksum	Opaque registry integrity field	Decide whether syntax belongs in the core standard or an issuer profile.
Competence records	Semantic requirements defined	Specify interoperable signed competence-record representation and validation rules.
Federated/RNO routing	Architectural model	Define signed routing, discovery, and competence formats.
State Proof serialization	Semantic binding requirements defined; JOSE vs COSE open	Select serialization profile guided by community feedback and deployment security profile; evaluate both options before standardizing.
Invalidation/re-evaluation	Normative semantics, transport open	Define event/webhook or polling profiles and freshness requirements.
IANA registrations	Well-known URI suffix registration intended before publication	Complete ain well-known URI registration per ; determine media type and extensibility registry needs.
Document split	Single version-00 draft	Evaluate separate core-resolution and pre-interaction documents after community review.
State Proof consumption	Atomic security semantics defined; transport and serialization open	Define endpoint, JOSE/COSE profile, receipt schema, channel binding, and conformance tests.

Deferred Protocol Elements (Non-Normative, Target -01) This appendix is non-normative. It preserves, for continuity and for use in preparing the next revision, protocol elements that were drafted in earlier working versions of this document but whose normative status this version defers, as recorded in Appendix A. Nothing in this appendix creates a requirement on an implementation of draft-tanase-ain-authoritative-resolution-00.

Pre-Interaction State Proof A correlation service may issue a signed, time-limited State Proof. It should bind the initiator AIN and, where applicable, the recipient AIN; otherwise it should bind an authoritative reference to the non-agent counterparty. It should also bind participant roles, intended audience, resolved recipient endpoint, interaction type, evidence or state versions, policy version where applicable, decision provenance, restrictions, issuance time, expiry time, and a unique proof identifier. Higher-assurance profiles may also bind challenge hashes, operation hashes, channel information, or bilateral configuration fingerprints. A State Proof must not be described as implemented merely because a deployment supports a single-agent signed assertion. Bilateral proof issuance, atomic consumption, controlled-session creation, and receipts are distinct protocol capabilities. This appendix describes candidate semantic bindings for a future State Proof profile; it does not select a JOSE or COSE serialization and does not itself constitute a normative requirement of this version.

State Proof Consumption and Controlled Session Establishment A higher-assurance AIN-WRP profile may require a State Proof to be consumed before a protected operational session is established. In such a profile, proof consumption, controlled-session creation, and receipt creation form one atomic security operation. A State Proof subject to single-use consumption must have an authoritatively determinable lifecycle state equivalent to one of the following: ISSUED, CONSUMED, EXPIRED, or REVOKED. ISSUED means the proof is valid and unconsumed; CONSUMED means it has been successfully bound to one controlled session and must not create another; EXPIRED means its validity interval ended before successful consumption; REVOKED means it was invalidated by a competent source or issuing service before successful consumption. The expression 'equivalent to' permits implementations to use different internal state names while preserving these protocol semantics. Before consuming a proof, the gateway or proof-consumption service must verify, as required by the applicable profile: the proof signature and signing-key status; issuer identity and competence; proof identifier and lifecycle state; issuance and expiry times; initiator AIN binding and, where applicable, recipient AIN binding or authoritative non-agent counterparty binding; intended audience; resolved recipient endpoint; interaction type and operation or parameter hash when present; channel or session-establishment binding when required; evidence-state and policy versions; mandatory restrictions; and the idempotency key associated with the session-establishment attempt. The idempotency key is associated with the proof-consumption and session-establishment request. It is not necessarily part of the preceding correlation request. The gateway must not permit protected operational traffic solely because the proof is cryptographically valid. The protected channel must remain closed until the atomic consumption operation has successfully committed. The atomic operation must, as one indivisible transaction: (1) conditionally change the proof state from ISSUED to CONSUMED; (2) create the controlled operational session; (3) bind the session to the proof, participants, audience, endpoint, applicable restrictions, and channel context; (4) create a consumption receipt; and (5) record the resulting proof and session state. The transaction must succeed or fail as a unit. If any step fails before commit, all effects must be rolled back, the proof must remain in its preceding state, and no successful session or consumption receipt may be returned. A successful commit must produce a stable session identifier and stable consumption receipt. The receipt should bind at least the State Proof identifier, controlled-session identifier, idempotency key, consuming gateway or relying party, initiator AIN and, where applicable, recipient AIN or authoritative non-agent counterparty reference, proof-consumption result, and commit time. It may additionally contain or reference applied restrictions, endpoint binding, channel binding, evidence versions, and policy version. It must not disclose source evidence or personal data that the relying party is not authorised to receive. If a client retries after a successful commit using the same proof identifier, the same idempotency key, and equivalent security-relevant parameters, the service should treat the request as an idempotent retry and should return the same session identifier and receipt. It must not create a second session. If a proof is already CONSUMED and a subsequent request uses a different idempotency key, gateway audience, participants, endpoint, channel binding, or other non-equivalent security-relevant parameters, the service must reject the request as replay or context substitution and must not create another session. A response-delivery failure occurring after commit must not restore the proof to ISSUED. A retry following an uncertain outcome should use the same idempotency key. The service must use committed transaction state to return the previously created session and receipt. Implementations must ensure that concurrent attempts to consume the same proof cannot both succeed. The authoritative replay state must be shared by all gateway or proof-consumption instances that can accept the proof. An in-memory cache local to one process is not sufficient as the authoritative replay record. This version defines the security and transaction semantics of proof consumption. It does not standardize the transport endpoint, persistence technology, transaction API, receipt serialization, or JOSE or COSE proof profile. Those elements are to be defined by a future AIN-WRP conformance profile.

Existing proof state	Idempotency/context	Result
ISSUED	Valid	Atomically create session and receipt; mark CONSUMED
ISSUED	Transaction fails before commit	Roll back; proof remains ISSUED
CONSUMED	Same idempotency key and equivalent context	Return the same session and receipt
CONSUMED	Different key or context	REPLAY_DETECTED; no new session
EXPIRED	Any	Reject; no session
REVOKED	Any	Reject; no session

Federated, Regional, Enterprise, and Sovereign Resolution AIN-WRP does not require all identity or trust information to be stored in a single global registry. Competent sources may be operated by independent organisations, enterprises, sectors, regional operators, national authorities, or sovereign infrastructures, provided that their competence can be established for the assertions consumed. An RNO is one possible operator of a domain-authoritative source. A resolver must not assume every jurisdiction has an RNO. Direct central resolution and other authorised sources remain valid when they hold the required competence. A regional, institutional, or sovereign assertion should include issuing-source identity, signature or authenticated-channel evidence, validity interval, protocol version, freshness marker, and competence scope. A central registry may confirm the canonical AIN or the mandate of another source. Central confirmation must not override a restriction validly issued within another source's competence, and a delegated source must not modify canonical identity information outside its mandate.

Private and Air-Gapped Deployments A private deployment may maintain sensitive attributes entirely within an enterprise or sovereign boundary while exposing only the minimum information required for cross-domain verification. Where direct external resolution is prohibited, a deployment may use signed, short-lived assertions or mediated resolution through an authorised boundary service. Such deployment choices must preserve freshness, competence, audience binding, and revocation semantics required by the applicable profile.

Identity Continuity Persistence of an AIN does not mean that every technical or administrative attribute of the identified digital agent remains unchanged. Models, prompts, credentials, keys, endpoints, tools, capabilities, operators, and deployment infrastructure are potentially mutable attributes. Changes to mutable attributes do not necessarily create a new digital-agent identity. The applicable registration profile must define the identity invariants and continuity conditions under which an existing AIN may be retained, and the conditions under which a new AIN is required. A registration profile must consider both individual and cumulative changes. A sequence of changes that would require a new AIN if performed as one replacement must not avoid that requirement merely because the changes were introduced incrementally. An existing AIN must not be retained solely to preserve reputation, audit history, permissions, assurance results, or other favourable state when the identity invariants defined by the applicable registration profile no longer hold. When a material change does not break identity continuity, the change must be recorded with sufficient provenance and effective-time information. Retention of the AIN does not imply continuity of every assertion concerning the agent. Credentials, mandates, capabilities, assurance results, risk classifications, endpoint bindings, State Proofs, permissions, and operational eligibility must be independently re-evaluated when affected by the change. When a material change breaks identity continuity, a new AIN must be issued. The preceding AIN must not be reassigned or erased. Where appropriate, the authoritative records should express a typed relationship between the preceding and succeeding AINs. Such a relationship is provenance information and must not, by itself, imply the transfer of credentials, mandates, permissions, restrictions, reputation, assurance results, or operational eligibility.

Operator Transfer An operator binding is a time-bounded authoritative relationship between a digital-agent identity and an entity responsible for operating that agent. A change of operator does not necessarily create a new digital-agent identity. An existing AIN may be retained following an operator transfer only when the applicable registration profile permits the transfer and the identity-continuity conditions defined by that profile remain satisfied. A registration profile may require issuance of a new AIN for specified classes of transfer, including transfers that materially change the identity, purpose, accountability, administrative domain, or operational characteristics of the agent. An operator transfer must be recorded as an authoritative, time-ordered event. A registry must not represent a transfer merely by overwriting the previous operator binding. The authoritative record must preserve sufficient information to determine the preceding and succeeding operator bindings, the effective time of the transfer, the source competent to authorise or record the transfer, the transfer status, and the provenance of the transition. The registry must ensure that there is an unambiguous current operator binding at any effective time, unless the applicable profile explicitly permits concurrent or joint operators and defines their respective roles and authority. Retention of an AIN following an operator transfer does not imply automatic transfer of credentials, cryptographic keys, mandates, permissions, endpoint authority, assurance results, State Proofs, reputation, restrictions, or operational eligibility. Each affected assertion must be retained, revoked, replaced, or revalidated according to its own issuer, competence scope, validity conditions, and the applicable registration profile. After the transfer becomes effective, the preceding operator must not be treated as the current operator and must not retain authority to modify the agent's authoritative record unless a competent source has explicitly granted continuing authority. Historical events associated with an AIN must remain attributable to the operator binding and agent state effective when those events occurred. A change of operator must not retroactively attribute the preceding operator's actions to the succeeding operator, and retention of the AIN must not cause operator-specific reputation or assurance to transfer automatically to the succeeding operator.

Mandate and Delegated Authority An AIN identifies the digital agent that is the subject of a mandate. The AIN does not create the mandate and does not establish that the agent is authorised to perform a particular operation. A mandate is an assertion issued on behalf of a principal under an applicable administrative, organisational, legal, contractual, or technical trust framework. The source competent to issue or confirm a mandate depends on that framework and may be, for example, an authorised person, an organisational authority, an identity or access-management system, a procurement or enterprise system, a delegation service, or another authorised technical component. AIN-WRP does not create authority, mandate, or competence. It resolves and validates assertions of authority issued under an applicable trust framework and determines whether the issuing source is competent for the asserted mandate, subject, scope, and administrative domain. Cryptographic validity alone does not establish mandate validity. A relying party must also establish that the issuer was competent to issue the mandate for the identified principal, agent, scope, and administrative domain at the relevant time. A resolver or correlation service that transports, validates, or includes a mandate assertion in a Pre-Interaction Trust State does not become the issuer of that mandate and must not represent itself as the source of the underlying authority unless it independently holds the required competence. Where a mandate depends on delegated authority, each security-relevant delegation in the chain must be valid, current, within the delegator's authority, and no broader than the authority held by the delegator. The applicable trust framework must define whether further delegation is permitted and any maximum delegation depth; absence of such permission must not be interpreted as permission to re-delegate. An AIN registry may publish or resolve competence records, but operation of an AIN registry does not, by itself, make that registry competent to create mandates on behalf of every principal or administrative domain. A change of operator binding does not transfer mandates automatically. A mandate issued under the authority of a preceding operator remains usable after transfer only when its issuer, terms, applicable trust framework, and current competent sources explicitly permit such continuity. A self-asserted mandate must not be treated as authoritative unless the applicable trust framework explicitly recognises the agent as competent to issue that mandate and the relying party accepts that framework.