AIDAXIA Ltd.

United Kingdomelena.c.tanase@gmail.comhttps://aidaxia.ai

Individual Submission agent identityauthoritative resolutionsource competencepre-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 interaction with another registered agent or with a non-agent service or system. Each digital agent participating in AIN-WRP identity resolution is identified by its own persistent Agent Identity Number (AIN). The AIN is the stable anchor used to resolve lifecycle, operator, authority, restriction, endpoint, provenance and cryptographic evidence from sources competent for the corresponding assertions. Where the counterparty is a non-agent target, a target reference identifies the intended resource or service without being treated as an alternative digital-agent identity. AIN-WRP correlates the required evidence for the proposed interaction and can produce a Pre-Interaction Trust State or an optional State Proof. Verification does not itself execute the operation or replace receiving-domain enforcement.The specification distinguishes persistent agent identity from credentials, proof of control, delegated authority, operational eligibility, local admission decisions and execution. AIN-WRP applies at or before the admission boundary of A2A, MCP, API, transactional, messaging and other operational protocols. An identity or target reference alone does not establish the authority, validity or eligibility of the proposed interaction.

IntroductionDigital agents increasingly initiate requests, invoke tools, exchange data and perform transactions across organisational boundaries. Authentication of a client, workload or token does not, by itself, establish the persistent identity, current status or authority of the particular digital agent acting. AIN-WRP therefore starts with the AIN of the initiating agent and, for agent-to-agent interactions, the AIN of the other participating agent. For agent-to-service interactions, the non-agent service or resource is identified as the target of the proposed operation rather than as a digital agent.The trust-plane procedure resolves current agent identity information, evaluates the competence and freshness of relevant sources, and correlates evidence against the proposed interaction. A destination identifier is a reference to the intended target, not automatically an authoritative identity assertion or permission. The gateway or receiving system applies the admission policy and enforces the outcome.An AIN identifies a technical software system. 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, and observability systems. Those systems may carry or consume AIN data; they are not replaced by this specification.

Requirements LanguageThe 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.
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 technically or delegatively competent to confirm a specified identity, attribute, state, relationship, restriction, territory, or endpoint.
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.
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 it participates as a distinct digital agent or the applicable profile requires it.
Target Reference	A reference identifying a non-agent service, system, resource, account, endpoint, or device that is the intended target of a proposed interaction. A Target Reference is not an agent identity.
Resolver	A service that obtains current AIN information and preserves its source, validity, and authority metadata.
Resolved Assertion	An assertion obtained from a source together with provenance, validity, version, and competence metadata sufficient for the relying party to evaluate it.
Administrative Domain	A domain within which identity, state, authority, or restrictions are administered under a defined policy.
RNO	A Regional Network Operator that may administer registration and authoritative records, or operate or mandate an authoritative source, within a delegated scope. 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 authoritative information before the operational protocol begins.
State Proof	A signed, time-limited representation of a Pre-Interaction Trust State, optionally bound to participants, endpoints, roles, audience, and context.
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

ScopeThis document addresses:

• 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 keys 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, error, and extensibility requirements.

Non-GoalsThis document does not:

• define legal responsibility 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, 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 the resolver or correlation service to execute the underlying action or transaction;
• require all attributes concerning an agent to be held by the same source;
• dictate the relying party's local authorization policy.

Implementation Boundaries and Conformance StatusThis revision distinguishes a core authoritative-resolution function from optional pre-interaction correlation functions. Core resolution covers persistent identifier lookup, lifecycle representation, provenance, competence evaluation and error reporting. Pre-interaction correlation adds interaction-specific evidence evaluation and may use optional State Proof mechanisms. These are architectural groupings, not separately registered conformance profiles. Until their wire formats, mandatory fields, error mappings and security processing rules are specified, an implementation MUST NOT claim interoperable conformance to an undefined State Proof, atomic-consumption or federation profile.

Agent Identity Across Interaction TypesWithin an AIN-WRP verification operation, every digital agent participating as a distinct agent identity is identified by its own validly issued AIN, irrespective of deployment environment, communication channel, operational role, or integration within another software system or physical device. An endpoint, account identifier, device identifier, workload credential, or service reference is not substituted for a participating digital agent's AIN within AIN-WRP.Where two or more digital agents participate in the verified interaction, each MUST be identified through its own AIN and independently resolved under the applicable verification requirements. A digital agent MUST NOT be represented as a non-agent service, endpoint, or device to bypass that requirement.Where an AIN-identified agent interacts with a counterparty that is not itself a participating digital agent, the request MUST remain anchored to the participating agent's AIN and MUST identify the intended target by a Target Reference. A Target Reference does not, by itself, establish identity, endpoint authority, control, or permission. The authoritative evidence required for the proposed interaction MUST be evaluated in accordance with the applicable verification profile. This specification does not require a separate AIN for a resource or device that is not itself a participating digital agent.Example (informative): an AIN-identified procurement agent invokes a government tender API. The agent's AIN remains its persistent identity anchor; the API URL and procurement resource identifier specify the intended target, not a substitute agent identity. Applicable authority and endpoint-binding evidence are evaluated separately. If another digital agent participates behind or through that service as a distinct party to the interaction, that agent is identified by its own AIN.

Architectural ModelThe architecture separates the trust plane from the execution plane, while maintaining distinct responsibilities for persistent identity, authoritative verification, policy enforcement, and execution.The AIN provides the globally unique and persistent identity anchor for each participating agent. AIN-WRP resolves and validates authoritative identity, registration, lifecycle, and relationship-relevant evidence, including the standing and competence of the relevant RNO and other authoritative sources, as applicable.The trust plane supports the verification of both the initiating agent and the receiving agent, including their respective AINs, registration contexts, operator bindings, and relevant authority evidence. The two agents MAY belong to different administrative domains and MAY be served by different RNOs.The gateway or relying party evaluates the resulting evidence against its local admission and authorization policies. A successful identity or relationship verification does not, by itself, authorize an interaction.The execution plane carries the operational interaction through the applicable protocol, such as A2A or MCP, subject to the enforcement decisions of the gateway or relying party. AIN-WRP does not replace the operational protocol or assume responsibility for its execution.

Stage	Input	Output	Component
Identify	Initiator AIN; recipient AIN or Target Reference; interaction context	Correlation request	Gateway or relying party
Resolve	AINs and required assertion types	Current records	Resolver and authoritative sources
Validate	Records, signatures, validity, competence	Validated evidence	Resolver or correlation engine
Correlate	Validated evidence sets and context	Pre-Interaction Trust State	Correlation engine
Prove (optional)	Trust State and evidence bindings	Signed State Proof	Correlation service
Enforce	State, restrictions, optional proof, local policy	Local admission decision	Gateway or relying party
Execute	Permitted protocol parameters	Operational session	A2A, MCP, API, or other protocol

A permission issued in one administrative domain MUST NOT automatically override a mandatory prohibition issued by another source competent for the relevant restriction. A central identity confirmation MUST NOT override a valid local restriction outside the central source's competence.

Architectural Separation and Processing StagesAIN-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.The identify, resolve, validate, correlate, optionally prove, enforce, and execute stages are logically distinct:

• Identification starts from each participating digital agent's AIN and, for a non-agent target, a separate Target Reference.
• Resolution establishes the relevant agent records and obtains the required counterparty evidence. It does not elevate a caller-provided URL to an authoritative endpoint.
• Validation evaluates the authenticity, integrity, provenance, temporal validity, and applicable issuer competence of the resolved evidence.
• Correlation evaluates the relationship-relevant evidence in the context of the intended interaction. A computed trust state does not, by itself, constitute an authorization decision.
• State Proof issuance, where supported, is separate from correlation, because a computed trust state need not be signed, issued, or consumed as a State Proof.
• The receiving gateway or relying party retains responsibility for its local admission and enforcement decisions. Correlation results, advisory outcomes, and State Proofs MUST NOT replace those decisions.
• Execution remains within the execution plane and is performed through the applicable operational protocol, subject to the receiving domain's enforcement controls.

Agent Identity Number

Canonical SyntaxThe following ABNF defines the canonical textual syntax for the AIN v1 identifier profile:For this profile, the canonical representation uses uppercase ASCII letters and ASCII hyphen-minus separators without surrounding whitespace.Resolvers MUST treat AINs as opaque persistent identifiers and MUST NOT infer jurisdiction, capability, lifecycle state, operator identity, RNO competence, or authority from their textual components.A receiving implementation MUST use the authoritative identifier profile applicable to the AIN being resolved. The syntax defined above specifies the current AIN v1 profile and MUST NOT be assumed to define the syntax of unrelated identifier schemes.Synthetic examples conforming to the AIN v1 textual profile include RG-01-CULRWC8ZKE34-4684 and SYS-01-Q3CZWMSJUEL3-BDAC.The checksum is a short, issuer-specific registry integrity check. It is not a digital signature, proof of issuance, uniqueness guarantee, proof of control, or substitute for authoritative resolution. This specification does not define a portable public checksum verification method.Identifier processing distinguishes:

• (a) textual well-formedness;
• (b) issuer recognition;
• (c) any issuer-specific integrity check;
• (d) authoritative registry record existence;
• (e) current lifecycle status; and
• (f) control and authority evidence.

Success at any earlier stage MUST NOT be interpreted as success at a later stage. Registry issuance MUST enforce non-reassignment and uniqueness independently of the identifier checksum.An AIN remains persistent across changes in the RNO responsible for administering its record. A change of RNO MUST NOT, by itself, cause the AIN to be modified or reassigned.

Namespace Coordination and Canonical RegistrationAINs 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.

PersistenceAn 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 IdentifierThe 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 IdentifiersWithin AIN-WRP, the AIN is the persistent identity anchor for every participating digital agent. Agent identification, authoritative identity resolution, lifecycle verification, and agent identity correlation within AIN-WRP use the AIN; other identifiers are not accepted as substitutes for establishing a participating digital agent's identity within an AIN-WRP verification flow.The AIN's identity function remains independent of changes in registration administration, RNO, operator relationships, cryptographic credentials, delegated authority, operational roles, or lifecycle status. Such changes MUST NOT, by themselves, modify or reassign the AIN.A digital agent MAY possess or use other identifiers, credentials, account identifiers, workload identities, decentralised identifiers, sector-specific identifiers, or protocol-specific identities in external systems, environments, or operational protocols. AIN-WRP does not require those identifiers to be replaced or discontinued, and does not govern their use outside its scope.External credentials and authoritative evidence MAY be evaluated for their respective purposes, including authentication and verification of operator relationships, delegated authority, or other interaction-relevant assertions. Such evidence MUST be associated with the participating agent's AIN. The existence or validity of an external identifier or credential does not, by itself, establish an agent's lifecycle status, authority, or eligibility for a proposed interaction.A distinct digital agent MUST be assigned a distinct AIN. Role, scope, context, or transport qualifiers MUST NOT create a separate agent identity without the issuance of a separate AIN.

Authoritative Resolution

Resolution EndpointThis version provisionally uses the following HTTPS resource :The "ain" well-known URI suffix is provisional and has not been registered with IANA. Its appearance in this draft is not evidence of an assigned IANA registration. This document requests no IANA action at this time; registration under will be requested in a later revision once the resolution mechanism is stable (see Section 17).

Resolver ResponseThe following example illustrates a proposed protocol representation. It is not asserted to be the response format of every implementation:The example is informative, deliberately does not assert operational eligibility, and is not a deployed wire-format claim. A reference to an RNO mandate, an operator binding, or a JWKS endpoint is not proof that the issuer was competent or that the agent controls its key. The validator evaluates those properties independently at decision time. Registration types such as AGENT are defined by the applicable registration profile and are not a universal normative enumeration.

RNO Mandates and Assertion RelianceThe namespace-coordination function maintains the AIN namespace and guarantees uniqueness and non-reassignment (Section 6.2). An RNO is a delegated registration and administration actor, not an independent namespace or a default authority for every claim. An RNO mandate MUST be validated for its issuer, status, scope, registration class, territory or sector where applicable, effective interval, and permitted operations before an RNO-issued or RNO-administered assertion is relied upon.The resolver determines the competent regional source for an AIN on the basis of the applicable jurisdictional or organisational routing. Where no valid RNO mapping exists, or the mapped RNO cannot be established as competent, the resolver MAY use an authorised alternative resolution path, such as the namespace-coordination function, where the applicable profile and local policy permit it. Otherwise, the affected evidence MUST be reported as unresolved rather than established. A fallback source MUST itself be competent for each assertion it supplies, and a fallback path MUST NOT be used to bypass, override or omit a restriction issued by a source competent for that restriction. The evaluation record identifies whether evidence was obtained from a regional source or through a fallback path. A change in resolution source is treated as a material change that triggers re-evaluation of the affected evidence (Section 12).

Operator Binding and Independent EvidenceA declarant statement that an agent belongs to an operator, RNO validation of that statement, and independent external evidence are separate objects with separately attributable provenance. A validator MUST NOT equate a registration or signed operator-binding assertion with independently established legal authority. The source competence for operator binding MUST be evaluated for that specific assertion; a valid RNO mandate for registration does not automatically authorize legal representation or delegated transaction powers.

Registration Class and Interaction RolesA registration class describes the type of registered entity under the applicable registration profile and MUST NOT be inferred from the AIN prefix alone. Initiator and recipient are roles of a particular interaction, not permanent properties of an agent identity. Claimed capabilities and operational eligibility MUST NOT be treated as globally valid authorization for a particular request.

Source CompetenceA 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.An assertion source may be the namespace-coordination function, an RNO, or another authority competent for the particular assertion. An RNO's authority MUST NOT be inferred solely from its designation as an RNO, possession of a signing key, or ability to serve a resolver response. Where competence is delegated, verification MUST establish the applicable mandate, scope, validity and restrictions for the assertion and relevant evaluation time.Authority to issue or administer an AIN does not, by itself, establish competence to attest every attribute associated with that AIN. A resolver that republishes an assertion MUST NOT represent its own signature as evidence that the original source was competent.The agent operator, original issuing authority, current registration administrator, and resolver or response signer are distinct roles. A transfer of AIN administrative custody MUST NOT, by itself, be interpreted as a change in the agent's operator, ownership, or authority to manage cryptographic keys.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. An assertion's competenceRecord reference or validity timestamps MUST NOT alone be treated as successful verification of the source's standing or of the assertion's current applicability. A resolver MUST NOT silently elevate a source beyond its competence.

Operational Identity, Operator and Instance AttributionAn AIN identifies a registered persistent digital agent or AI system. The AIN remains the authoritative identity anchor for that agent or system across its applicable deployments and execution instances. An AIN MUST NOT be interpreted as a unique identifier assigned separately to every ephemeral execution process.The original software developer, the entity deploying the software, the operator exercising operational control, and the delegating authority are distinct roles. These roles MUST NOT be inferred to belong to the same entity solely from a software name, repository, credential, deployment reference, or agent-provided statement.Where an agent instance participates in an AIN-WRP verification flow, its association with the relevant AIN MUST be established through the applicable authoritative verification mechanisms. Instance identifiers, workload identities, deployment references, or cryptographic credentials MAY be used as supporting evidence of that association.Where instance-level attribution is required, the verifier MUST validate evidence binding the presenting instance to the relevant AIN and deployment or operator context. Such evidence MUST identify its competent source, applicable scope, and validity interval.Successful workload authentication does not, by itself, establish persistent-agent identity continuity, operator authority, delegated authority, or eligibility for the proposed interaction.

Competent Sources and Issuer StandingSource discovery MUST be distinguished from establishing the source's competence for a particular assertion. A cryptographically valid assertion from a known source does not establish that the source is competent for the assertion's scope or that its mandate remains valid at the evaluation time. Competence assessment SHOULD consider issuer identity, mandate scope, validity interval, restrictions, source status, and relevant changes. An entity competent to administer registration MUST NOT automatically be considered competent to grant operational authority or regulatory approval.If a mandatory competence or issuer-standing check cannot be completed, the result MUST remain distinguishable from a confirmed invalid or revoked authority. The relying party determines whether the available evidence satisfies its local policy. Issuer standing as a verifier-side evaluation input is discussed in .A verifier may discover candidate sources through registry records, authority directories or configured trust anchors. Discovery MUST NOT itself establish competence. Where competence evidence is missing or cannot be refreshed, the evaluation MUST distinguish an unresolved condition from a known revoked or out-of-scope mandate.

Delegator Authority and Non-Self-Authenticating ClaimsA mandate, credential or registration record that names a principal, delegator or agent does not by itself establish that the delegator possessed authority to grant the requested permissions. Where such authority is mandatory under the receiving domain's policy, the verifier MUST evaluate evidence from a source competent to attest the delegator's powers, limits, applicable scope and validity at the evaluation time. A permission claimed by a root mandate MUST NOT exceed the authority established by its required supporting evidence. When the delegator and principal are the same, the verifier MUST NOT infer independently established authority from that equality alone. Applicable profiles or local policy MAY specify circumstances in which a self-assertion is accepted for a particular interaction; such acceptance MUST NOT be represented as independently verified authority unless supported by evidence from a competent source.If a mandate references multiple required authority assertions, the verifier MUST evaluate each required reference independently. A missing required assertion, an expired one, and a presented assertion that is valid but insufficient in scope MUST remain distinguishable in the evaluation record. A signature-valid but expired authority assertion MUST NOT establish current authority merely because the mandate remains unexpired. A missing required assertion MUST NOT be silently omitted, and the presence of one valid assertion MUST NOT imply that all referenced assertions have been assessed. This document leaves exact wire-level error-code precedence to a future profile.AIN-WRP does not define a mandate format. Mandate validation by a relying party in another administrative domain is addressed in , and the association between a principal and an accepted delegation root is discussed in . This section states the requirements that AIN-WRP places on such evidence when it is consumed.

Authoritative Endpoint ResolutionAn endpoint supplied by an initiating digital agent MUST be treated as a claimed destination or routing hint and MUST NOT, by itself, be accepted as an authoritative endpoint.Where an AIN-WRP pre-interaction verification involves a network endpoint, the verifier MUST establish and validate the authoritative binding between the intended counterparty and the endpoint used for the proposed interaction. This binding MUST be established using evidence from a source competent for the relevant assertion.The verifier MUST ensure that the resolved endpoint corresponds to the intended counterparty and is applicable to the requested interaction, including its relevant scope, audience, and restrictions.Endpoint substitution, audience mismatch, or unauthorized redirection MUST NOT be accepted as a successfully verified endpoint binding. A valid AIN, successful identity resolution, or verified mandate MUST NOT, by itself, establish the authority of an unverified or modified network destination.Endpoint-binding evidence SHOULD preserve its authoritative source, applicable scope, issuance and expiration times, and relevant revocation or change information.Where a verified endpoint binding becomes invalid, is revoked, or no longer corresponds to the intended interaction, the affected pre-interaction verification MUST NOT be reported as successful.

Lifecycle and Operational EligibilityIdentity 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 handshake	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 authorisation to perform an operation.

Operational Composition and Material ChangesAn agent or agentic system identified by an AIN MAY reference a versioned Composition Manifest describing security-relevant software components, models, orchestrators, tools, connectors, deployments, and configuration. The manifest MUST be associated with the relevant AIN and MUST NOT constitute an alternative agent identifier.A Composition Manifest represents declared composition information and MUST NOT, by itself, be treated as independent proof of the agent's actual runtime composition. Where required for a proposed interaction, runtime or supply-chain assertions MUST be corroborated by evidence from competent sources.A material change affecting identity continuity, operator binding, delegated authority, privileged tool access, endpoint binding, or operational eligibility MUST trigger re-evaluation of the affected mandatory evidence before a subsequent protected interaction can be authoritatively admitted. Routine software or dependency updates do not necessarily require the issuance of a new AIN, provided that the registered agent's identity continuity is preserved (see Appendix B.5).This document does not define a universal manifest serialization, fingerprint algorithm, or runtime attestation format.

Lifecycle States, Restrictions and Input OutcomesAIN lifecycle states MUST be distinguished from operational restrictions, verification outcomes, and input-validation errors. Operational restrictions MAY be applied to an agent independently of its registered lifecycle state; such restrictions MUST NOT be represented as lifecycle states unless explicitly defined as such by an applicable profile.A missing AIN, a malformed identifier, an unknown identifier, and a known revoked identifier MUST remain distinguishable in verification results. A verifier MUST NOT represent an input-validation failure as an authoritative lifecycle determination.This document does not standardize implementation-specific restriction labels, input-error codes, or HTTP status mappings. Such mappings MAY be defined by applicable protocol profiles.

Agent Proof of ControlA 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.

Optional Agent Proof of Control ProfileAn implementation MAY support an Agent Proof of Control profile. An implementation claiming conformance to this profile MUST require a cryptographic proof generated using private key material available to the presenting agent or authorized agent instance. The verifier MUST validate the proof using public key material authoritatively bound to the relevant AIN. Such a binding MUST identify the key, permitted verification purpose, validity interval, and relevant rotation or revocation state. The authoritative binding MUST be obtained from a source competent for the assertion; discovery or signature validity alone is insufficient.For this optional profile, the proof MUST bind the target AIN, an unpredictable challenge nonce, intended verifier or audience, verification purpose, and expiration condition. The verifier MUST reject invalid, expired, previously consumed, context-mismatched, or ineligible-key proofs. No more than one verification attempt can succeed for the same nonce and challenge context. Implementations SHOULD apply rate limits and anti-abuse controls.A successful proof demonstrates that the presenting party could use the corresponding private key for this challenge. It does not establish the human or organizational operator, the security of the workload, delegated authority, or admission of an operational interaction. Where instance-level attribution is required, the verifier MUST separately establish an authoritative binding among the relevant key, workload instance, and persistent AIN. A registry-signed assertion issued without a cryptographic proof produced by the presenting agent or authorized instance MUST NOT be represented as Agent Proof of Control.This document does not define a mandatory serialization, algorithm suite, public key publication format, or interoperable proof-of-control wire profile. These are deferred to a future profile. The requirements in this section apply only when an implementation claims the optional Agent Proof of Control capability; they do not apply to core resolution-only implementations.

Pre-Interaction Correlation

Correlation RequestBefore sending the first protected operational message, a relying party MAY submit a relationship-specific correlation request.Such a request MUST identify the initiating digital agent by its persistent AIN. If the counterparty is another participating digital agent, the request MUST contain the counterparty's own AIN; each AIN is resolved independently. If the intended target is a non-agent service, resource, account, or endpoint, the request MUST identify it with a Target Reference defined or accepted by the applicable interaction profile. A Target Reference MUST NOT be interpreted as another agent AIN or as sufficient verification evidence.The request MUST also identify participant roles, interaction type, audience, request identifier, issuance time, and expiry time. A correlation request MAY additionally include endpoint hints, requested capability, jurisdictional or sectoral context, assurance requirements, resource or operation binding, and a cryptographic hash of the requested operation. The applicable interaction profile MAY require specific additional elements.This specification defines the semantic content of the correlation request but does not standardize a transport endpoint or media type for its submission. The precise wire fields remain profile-dependent. The following JSON object illustrates a correlation request between two independently identified digital agents:An endpoint, account, or Target Reference supplied by the initiator is a claimed target or hint until the required evidence has been obtained from sources competent for the relevant assertion. The verifier MUST distinguish identifying the intended destination from proving the destination's identity, control, endpoint binding, or authority. An operational action MUST NOT be redirected solely on the basis of an unverified initiator-supplied endpoint. The presence of a non-agent Target Reference does not relax checks required by the receiving domain.The requestId is an opaque, collision-resistant identifier within the applicable profile. Implementations SHOULD generate requestId values using a cryptographically secure random generator with sufficient entropy to make accidental collision negligible over the deployment's expected volume (for example, at least 122 bits, as provided by a version 4 UUID). The UUID format shown in examples is illustrative only.

Bilateral Agent Verification and RNO DiversityFor an agent-to-agent interaction, the initiator A and recipient B each possess their own persistent AIN. Each identity is independently resolved with its own lifecycle, operator binding, original issuer, current RNO administrator, source competence, instance-control evidence where required, and delegation chain where applicable. The two RNOs may be different, and neither RNO is automatically competent for the other participant. A single interaction identifier binds the two participant evaluations to the intended action, endpoint, audience, scope and decision time. Verification may occur concurrently; bilateral verification does not prescribe a network call order.

Mutual Verification and Decision SeparationWhen the interaction profile requires mutual assurance, each side MUST have sufficient independently attributable evidence for the counterparty before disclosing protected information or executing a sensitive operation. The verifier MUST distinguish evidence validation outcomes (for example VALID, INVALID or INDETERMINATE) from the relying party's local admission decision. The correlation results in Section 10.4 are advisory or profile-defined inputs to that decision (Section 10.5); they do not replace it. A relying party choosing to proceed following an INDETERMINATE validation MUST NOT relabel unknown authority as established. A generic eligibility flag MUST NOT substitute for interaction-specific eligibility and policy evaluation.

Independent ResolutionThe 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, 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.For a bilateral pre-interaction verification, the verifier MUST establish a separately attributable verification result for each participant. Each result MUST cover the participant's authoritative identity or applicable counterparty binding, relevant lifecycle state where applicable, assertion-source competence, and any authentication or proof-of-control requirements applicable to that participant's role and interaction context.The participants MAY be administered by the same authority or by different authorities, including different RNOs. Each participant's verification result MUST preserve the relevant authoritative provenance of the evidence used. The original issuing authority, current administering authority, and competent assertion sources MUST remain distinguishable where relevant to the verification. Successful verification of one participant MUST NOT substitute for verification of the other. Independent verification does not require direct communication between RNOs or identical verification mechanisms for both participants.

ValidationFor 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.Where a mandatory validation condition cannot be established, the verifier MUST NOT report that condition as successfully validated. The evaluation record MUST distinguish unavailable or indeterminate evidence from evidence establishing that an assertion is invalid, revoked, expired, or outside its permitted scope.

Correlation and Restriction CompositionThe 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	Expected 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.

For bilateral verification, the correlation engine MUST evaluate the separately attributable participant-verification results together with the proposed interaction context. An affirmative interaction result MUST be bound to both participant identities or applicable non-agent Target References, their roles, interaction type, intended audience, request identifier, relevant endpoint bindings, restrictions, and validity period. Successful identity verification of both participants MUST NOT, by itself, establish eligibility or authorization for the requested interaction.Where mandatory participant evidence cannot be established, the correlation engine MUST NOT produce an affirmative result. The evaluation record MUST distinguish missing or indeterminate evidence from known invalid, revoked, or out-of-scope authority. The meaning of a non-affirmative verification result MUST remain distinct from any subsequent local enforcement action.

Separation of Verified State and Local PolicyAIN-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.Verification of identity, authority, or evidence is not, by itself, an authorization grant. A receiving-domain gateway MAY deny an interaction even where all requested evidence checks succeed. Conversely, a local decision to proceed despite unresolved mandatory checks MUST NOT be reported as successful authority verification. Local policy and configured trust anchors MUST NOT be represented as conferring competence upon a source that lacks the required authority.

Pre-Interaction State ProofThis 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 or COSE), canonicalization, and format-level encoding of the State Proof are deferred to a future conformance profile. Candidate semantic bindings are retained non-normatively in Appendix B.1 and are not a stable interface.Where an implementation issues a Pre-Interaction State Proof under an applicable profile, the proof MUST be bound to the interaction properties required by that profile. Such properties may include the initiator AIN; recipient AIN or verified non-agent Target Reference; participant roles; request identifier; audience; verified endpoint or resource; operation; restrictions; applicable evidence, state and policy versions; and expiry. A proof MUST NOT be accepted for a different context where that context is a mandatory binding. A valid State Proof does not, by itself, override the receiving gateway's local policy.

State Proof Consumption and Controlled Session EstablishmentAtomic State Proof consumption, controlled-session establishment, idempotent retry handling, and consumption-receipt creation are security-relevant capabilities that this version does not standardize at the transport or persistence level. Their semantic design, retained non-normatively in Appendix B.2, remains subject to a future conformance profile with its own interoperability and security review.A deployment MUST NOT claim that nonce-based Agent Proof of Control, a single-agent registry assertion, or a signed correlation result establishes interoperable State Proof consumption or controlled-session establishment. Where a future profile requires single-use State Proofs, it must specify atomic consumption, concurrency handling, permitted idempotent retries, and the binding of any resulting session and receipt to the consumed proof.

Receiving-Domain Evaluation of Foreign Transaction ContextValidation of a transaction token issued by a foreign transaction-token service, such as a Transaction Token , MUST NOT be treated as sufficient evidence of admission to a resource controlled by the receiving domain. Token signature validity, structural validity, expiration and issuer trust are distinct from the receiving domain's determination that the actor has current authority for the requested action and resource. A token MAY carry historical transaction or delegation context; the receiving verifier MUST evaluate any additional conditions required by its own admission policy. A fresh token does not establish that all represented authority or delegation conditions remain current. This document neither defines a transaction-token trust framework nor replaces OAuth or WIMSE token processing.Where the receiving domain requires current authoritative evidence of the actor's identity, delegated authority, issuer standing, or other admission conditions, the verifier MUST establish that evidence independently of the foreign token's cryptographic validity. If mandatory evidence cannot be resolved or validated, the verifier MUST NOT produce an affirmative admission result. An unresolved mandatory condition MUST remain distinguishable from evidence establishing that the claimed authority is invalid, revoked, or outside its permitted scope.

Unresolved Verification and Dependency SemanticsAn evaluation result MUST distinguish, when known, invalid or revoked authority, unavailable competent sources, stale evidence, conflicting evidence, an evaluation skipped due to a failed prerequisite, and evidence insufficient for the requested interaction. An unresolved mandatory condition MUST NOT be reported as successfully verified. Local policy MAY deny, defer or request additional evidence; the protocol does not equate an unresolved evaluation with a finding that an issuer was revoked. Audit information SHOULD preserve the reason for non-admission even when several evaluation outcomes lead to the same enforcement action. Where local policy requires authority evidence, a valid foreign credential and an unexpired delegation token MUST NOT turn an unresolved root-authority check into a positive authority result.The same distinction between an established negative result and a result that could not be established is discussed for agent protocol decisions in , and for the association between a principal and an accepted authority root in .

Decision-Time Evidence and Retrospective ReconstructionA pre-interaction evaluation occurs at an explicit evaluation time T. Implementations SHOULD preserve, in a protected evaluation record or evidence receipt, the initiating AIN, any counterparty agent AIN or non-agent Target Reference, verified endpoint or resource bindings, relevant instance evidence, operation, source and competence scope, assertion identifiers or integrity-protected recoverable references, issuance and expiration times, retrieval time, relevant revocation or status evidence as known at T, freshness thresholds, the trust-anchor set and policy version applied, verification outcomes and any local admission action. This evidence is necessary to distinguish an actually evaluated requirement from one skipped or left unresolved.A later reviewer MUST NOT treat a current resolver response as proof of what a verifier observed at T. A cryptographic digest or reference is useful only if the referenced evidence, its provenance and the time semantics can be recovered under the applicable retention policy. Retrospective reconstruction establishes the evidentiary basis for the recorded decision; it does not retroactively make an unresolved mandatory condition valid, and an audit receipt alone does not prove that a decision was substantively correct. A receiving-domain decision to proceed despite an indeterminate result MUST remain explicitly distinguishable from successful authority verification.Where a decision receipt or later interaction receipt is produced, the implementation SHOULD provide a verifiable linkage among the original request, the decision-time evidence record, the evaluation result, any issued State Proof, and the receipt. Such linkage MAY use integrity-protected identifiers and cryptographic commitments, provided that the relevant evidence remains recoverable and the verifier can establish which assertions were evaluated at T. The receipt MUST NOT imply that a mandatory authority condition was established when it was missing, stale, invalid, or not evaluated at T.This section defines evidence-preservation semantics, not a mandatory receipt serialization, durable-storage implementation or deployed audit capability. Related requirements for independently determinable agent actions are discussed in .

Correlation with Non-Agent CounterpartiesFor an agent-to-service interaction, the initiator MUST be identified by its persistent AIN. The destination is designated using a Target Reference for the non-agent service, resource, account or endpoint; this reference does not become an alternative agent identity. The correlation evaluator MUST distinguish the initiator's persistent agent-identity assertions from the target's own identity, endpoint and resource-related evidence. It MUST evaluate the latter from competent sources when required and preserve the binding to the actual target and operation. A State Proof issued for such an interaction MUST prevent substitution of the verified destination or protected resource where that binding is required by the applicable profile. If the destination is itself a participating digital agent, its own AIN MUST be used instead of the Target Reference path.

Federated, Regional, Enterprise, and Sovereign ResolutionThis version confirms, at the level of the architectural model in Section 5, that AIN-WRP does not require a single global resolution service 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. Design considerations are retained non-normatively in Appendix B.3 and Appendix B.4.The absence of a single mandatory resolution service does not create competing AIN namespaces: globally coordinated AIN issuance and non-reassignment remain governed by Section 6.2.

Competent Sources and Federated ResolutionAn RNO is one possible operator of a competent regional source. A resolver MUST NOT assume that every jurisdiction has an RNO. Direct resolution by the namespace-coordination function, and resolution by other competent national, institutional, enterprise, or sovereign sources, remain permitted. An RNO MAY act as an authoritative source within its established competence. An enterprise MAY be competent for an internal operator binding, while a public authority MAY be competent for a legal or regulatory restriction. A namespace-coordination function may preserve global AIN uniqueness without being competent for every attribute.Independently issued assertions MUST preserve their attribution, relevant status, scope, and competence boundaries. A regional assertion SHOULD identify the issuing node, applicable competence scope, validity interval, and relevant signature, protocol version, and freshness information.Central confirmation of an AIN or RNO mandate MUST NOT override a restriction validly issued by another source within that source's competence. An RNO MUST NOT modify canonical identity information outside its applicable mandate.

Sovereign, Private, and Restricted ResolutionSovereign, enterprise, and private deployments MAY restrict public disclosure of security-sensitive information while providing authorised verifiers with the evidence necessary for the applicable verification operation. Such deployments MUST preserve the distinction between identity resolution, source competence, assertion validity, and receiving-domain admission. A source outage, unavailable federation route, or inability to obtain mandatory competent evidence MUST NOT be interpreted as positive authority.

Administrative RolesThe original AIN issuing authority, current administrative authority, agent operator, and competent assertion sources are distinct roles. A change of administrative authority MUST preserve the persistent AIN and its issuance provenance and MUST NOT, by itself, establish a change in operator, ownership, delegated authority, or control of cryptographic keys. This document does not standardize an RNO succession procedure, a signed RNO-to-RNO exchange format, a federation-routing protocol, or an institutional governance arrangement.

Caching, Invalidation, and Re-EvaluationResolvers 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.An unexpired cache entry MUST NOT override a newer authoritative revocation or competence withdrawal known to the verifier. A source outage MUST NOT be converted into a positive lifecycle or authority assertion. A receiving domain determines whether cached evidence is sufficiently fresh for each mandatory admission condition; different attributes MAY have different freshness limits.Where a material change invalidates evidence mandatory for an ongoing or subsequent protected interaction, the affected evidence MUST be re-evaluated before the interaction can be reported as authoritatively verified. An earlier successful verification or unexpired State Proof MUST NOT be interpreted as establishing the continued validity of evidence known to have been revoked or invalidated.

Error ModelHTTP 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 failure, evidence conflict, and policy denial. Typical HTTP mappings are illustrative and depend on the identity-resolution or operational profile.

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 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 HTTP statuses for identity-only and operational endpoints are intentional; a future profile may define exact mappings. The evaluation conditions stale_evidence, evidence_insufficient, and not_evaluated_due_to_prerequisite MUST remain distinguishable from confirmed revocation or invalidity; these illustrative condition names are not registered interoperable error codes.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 idempotency key and equivalent security-relevant context returns the original successful result.
• Reuse of the same idempotency key with different security-relevant context results in idempotency_conflict.
• Reuse of a consumed proof with a different idempotency key results in proof_already_consumed or the generic replay_detected.
• A participant, audience, endpoint, operation, or channel mismatch detected before successful consumption results in proof_context_mismatch.

These rules apply to profiles that define consumable proof material and idempotent proof-consumption operations. They do not imply that every AIN-WRP resolution response or State Proof is single-use.The following illustrates a 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 issuer competence in addition to signature validity.
• Agent-supplied endpoint hints MUST NOT override authoritative endpoint resolution.
• 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.

Open-Source Agent Instance Attribution and Composition DriftAn adversary can deploy a modified open-source agent while presenting the name or provenance of the original software. Software provenance alone cannot identify the operator, workload instance or authority of a particular deployment. Implementations SHOULD test unauthorized instance substitution, false operator binding, mis-scoped delegation, malicious tool or MCP-server insertion, changed model or orchestrator, stale composition declarations, forged manifests and failure of independent runtime corroboration. A signed manifest can authenticate the declarant without proving the configuration currently executing. AIN-WRP MUST NOT infer authorization from software identity or a manifest alone.

Cross-Domain Token Validation Is Not AdmissionA trusted foreign transaction-token service can issue a structurally valid and unexpired token while the receiving domain cannot establish a mandatory current issuer-standing, delegation or resource-specific condition. Implementations SHOULD preserve this case as unresolved or insufficient evidence, as applicable, rather than reporting a malformed token or a confirmed revocation. Enforcement remains under receiving-domain policy. A valid token MUST NOT override a more recent authoritative revocation when current standing is a mandatory condition.

Decision-Time Authority Evidence ThreatsImplementations SHOULD test authority inflation at a delegation root, self-assertion by an ineligible principal class, missing or expired supporting authority assertions, partial availability of multiple required assertions, and revocation discovered after issuance of an otherwise valid token. Test fixtures SHOULD retain the expected evaluation outcome separately from the receiving domain's enforcement decision. Comparable test cases are being developed for and in . Preserving evidence for audit requires access control, data minimization, integrity protection and retention limits appropriate to sensitive delegations and personal data.

Privacy ConsiderationsA 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 AdmissionAn 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.

Cross-Organisation Agent InteractionAgent 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 InteractionAn 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 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, which does not depend on the agent's own platform self-asserting these facts, and which reflects any restriction issued by a source outside the counterparty's own trust boundary before the interaction is admitted.

Regulated Financial InteractionA 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. 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 DomainA 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, which MAY be associated with an AIN and used as supporting evidence. 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 ConsiderationsThis 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 working group 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	Public endpoint behaviour observed; protocol conformance not established
Web-resolvable AIN and JSON-LD	Public endpoint behaviour observed; formats differ by endpoint
Lifecycle enforcement and JWKS discovery	Public lifecycle and JWKS behaviour observed; mappings are endpoint-dependent
Single-agent challenge-response, signed assertions, replay state	Challenge issuance observed publicly; registry-signed assertions do not establish agent-key proof of control; replay evidence from development only
Public incident intake and scoped case handling	Development controls tested; production intake not exercised
Uniform lifecycle semantics across public endpoints	Partially implemented
Agent-signed Proof of Control (optional profile)	Development implementation reported; production not verified
Independent dual-domain resolution and competence validation	Proposed
RNO-to-RNO signed resolution protocol	Proposed
Bilateral State Proof and restriction composition	Proposed
Atomic State Proof consumption, controlled-session creation, idempotent retry and receipt	Not implemented end to end
Continuous gateway re-evaluation	Proposed

A registry JWKS authenticating registry assertions is not proof that a presenting agent controls its own private key. Production and development observations establish only their respective tested behaviour. This table does not certify interoperable implementation of the proposed optional profiles. The bilateral evidence-record structure described in this revision expresses intended protocol semantics; it is not an assertion of deployed production behaviour or of an already interoperable JSON-LD schema. A future profile must specify serialization, signatures, canonicalization, status retrieval and negative test vectors.

Relationship to Other Work

OpenID Connect Agent Identity ProfilesOpenID 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 and AuthorizationOAuth-family mechanisms, workload-identity systems, and AI-agent authentication and authorization work such as 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 ArtefactsExternal 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 GatewaysA2A , 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 AuditObservability 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 WorkSeveral 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 identity, authentication and authorization; and binds an agent passport to a principal binding and to delegation chains that narrow monotonically. 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. specifies a federated registry for durable agent identity, with persistent identifiers, registrars, and resolution of the current lifecycle state and issuer before a credential is relied upon. AIN-WRP and both treat persistent identity and authoritative resolution as distinct from credential validity. AIN-WRP's focus is the bilateral, relationship-specific correlation of evidence about both participants from sources competent for each assertion, and the composition of restrictions across independent administrative domains. defines the evaluation inputs and rules a verifier applies to a delegated authority chain, including issuer standing established from a source pinned by the relying party, and identifies key bootstrapping across boundaries as an open issue. leaves the association between a principal and an accepted authority root to verifier trust policy and reports it as not established when it cannot be made. AIN-WRP's source-competence requirements (Section 7.3, Section 7.5) address the same boundary from the relying-party side: whether the source of an assertion, including the issuer of a mandate, is competent for that principal, scope and domain.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 mature.

Relationship to Other Identifier and Credential SystemsAn 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. Within AIN-WRP, the AIN is the identity anchor for each participating digital agent (Section 6.5).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 as supporting attributes, authentication mechanisms, or evidence relevant to specific assertions.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 authorize an operation; authentication, proof of control, mandate validation, local authorization, and execution remain separate protocol functions.AIN-WRP therefore permits evidence originating from external identifier and credential systems to be evaluated for the specific assertions it supports, subject to verification of provenance, binding, validity, scope, and source competence. The distinct function of AIN-WRP is to use a persistent identity 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.

Complementary Authority and Decision-Time Evidence WorkContemporaneous agent-mandate and delegation-chain work, including and , provides possible external evidence of delegator standing, delegation limits and authority assertion validation. Work on preserving evaluation state and on independently determinable agent actions addresses how decisions and their inputs are recorded. Such evidence MAY be consumed by AIN-WRP when its provenance, issuer competence, scope, freshness and relevant instance or resource bindings are established. Evidence validation remains distinct from the receiving-domain authorization decision. Human-anchored identity architectures are compatible with AIN-WRP but are not mandatory for AIN issuance.

ReferencesNormative ReferencesInformative ReferencesWork in ProgressWork in ProgressWork in ProgressWork in ProgressWork in ProgressWork in ProgressWork in ProgressWork in ProgressWork in ProgressagentcredsModel Context Protocol ProjectA2A Protocol Project

Open Design DecisionsThe State Proof serialization, federated or RNO routing, and State Proof consumption rows below correspond to material carried forward, non-normatively, in Appendix B.

Decision	Position in this revision	Required before a 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, issuer-specific 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 and RNO routing	Architectural model	Define signed routing, discovery, and competence formats.
State Proof serialization	Semantic binding requirements defined; JOSE or COSE open	Select a serialization profile guided by community feedback and deployment security profiles.
Invalidation and re-evaluation	Normative semantics; transport open	Define event, webhook or polling profiles and freshness requirements.
Evaluation outcome vocabulary	Validation outcomes, correlation results and local decisions distinguished	Consolidate into a single registered outcome model.
IANA registrations	Well-known URI suffix registration intended before publication	Complete the registration per ; determine media type and extensibility registry needs.
Document split	Single document	Evaluate separate core-resolution and pre-interaction documents after community review.
State Proof consumption	Atomic security semantics described; transport and serialization open	Define endpoint, JOSE or COSE profile, receipt schema, channel binding, and conformance tests.

Deferred Protocol Elements (Non-Normative)This appendix is non-normative. It preserves, for continuity and for use in preparing later revisions, protocol elements whose normative status this version defers, as recorded in Appendix A. Nothing in this appendix creates a requirement on an implementation of this document.

Pre-Interaction State ProofA 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. That choice, and the selection of a canonicalization rule set, will be guided by community feedback and by the security profile of the primary deployment targets (web, constrained IoT, enterprise, sovereign). Authors of implementation profiles are encouraged to evaluate both options and to report interoperability experience before a profile is standardized.

State Proof Consumption and Controlled Session EstablishmentA 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 appendix describes 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 or 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 ResolutionAIN-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 DeploymentsA 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 ContinuityPersistence 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 TransferAn 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 AuthorityAn 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.

Changes from draft-tanase-ain-authoritative-resolution-00

• Added Section 4.3 on implementation boundaries and conformance status, and Section 4.4 on agent identity across agent-to-agent and agent-to-service interactions; introduced the term Target Reference for non-agent targets.
• Refined RNO terminology: an RNO may administer registration and authoritative records within a delegated scope; RNO participation remains optional.
• Clarified the AIN checksum as an issuer-specific integrity check and added the identifier-processing stages in Section 6.1.
• Added Sections 7.2.1 to 7.2.3 on RNO mandates, optional fallback resolution where no valid RNO mapping exists, without bypassing restrictions from competent sources, operator binding and interaction roles; expanded Section 7.3 on source competence; added Sections 7.4 (instance attribution), 7.5 (competent sources and issuer standing), 7.6 (delegator authority) and 7.7 (authoritative endpoint resolution, formerly Section 7.4).
• Added Section 8.1 (operational composition and material changes) and Section 8.2 (lifecycle states, restrictions and input outcomes).
• Added Section 9.1 describing an optional Agent Proof of Control profile.
• Revised the correlation request to identify each participating agent by its own AIN; added Sections 10.1.1 and 10.1.2 on bilateral verification and decision separation; expanded Sections 10.2 to 10.5.
• Added Sections 10.8 to 10.11 on foreign transaction context, unresolved verification, decision-time evidence and non-agent counterparties.
• Moved deferred normative text out of Sections 10.6, 10.7 and 11 into references to Appendix B; added Sections 11.1 to 11.3.
• Expanded Sections 12 and 13, and added Sections 14.1 to 14.3.
• Updated the implementation status table (Section 18) to separate observed behaviour from development reports.
• Added references to , , , , , and ; updated to -04 and replaced the earlier AI agent authentication reference with ; added Section 19.8.
• Corrected appendix cross-references and moved JOSE references to the informative references.

AcknowledgmentsThe author thanks participants in WIMSE working group discussions whose comments informed this revision.