Authoritative Resolution and Pre-Interaction Verification of Persistent Digital Agent Identities

4.1. Scope

This document addresses:¶

• canonical presentation and validation requirements for an AIN;¶

• authoritative HTTPS resolution and machine-readable JSON representations [RFC8259];¶

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

4.2. Non-Goals

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

4.3. Implementation Boundaries and Conformance Status

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

4.4. Agent Identity Across Interaction Types

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

5.1. Architectural Separation and Processing Stages

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

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

6.2. Namespace Coordination and Canonical Registration

AINs are globally unique within a coordinated AIN namespace. An identifier is valid as an AIN only when it has been allocated or canonically registered through an authority recognised by the namespace-coordination framework; conformance to the syntax and checksum rules of Section 6.1 alone does not establish that a string is a validly issued AIN.¶

The namespace-coordination function MUST prevent reassignment of an issued AIN to a different digital-agent identity and MUST maintain, or enable discovery of, an authoritative canonical record for each validly issued AIN.¶

A regional, sectoral, or institutional registration operator MAY receive, validate, or process AIN registration requests and MAY maintain a local projection of canonical AIN records for its area of operation. Such a local projection MUST remain synchronized with, and MUST NOT independently modify or reassign, the canonical registration. Where no such regional operator exists for a given deployment, registration and canonical resolution MAY be performed directly by the namespace-coordination function.¶

This model is architecturally comparable to coordinated-namespace systems such as GS1, where a global coordinating function allocates namespace and member organisations administer registration within it without creating independent, competing identifier spaces.¶

This document defines the architectural requirement for namespace coordination and canonical registration. It does not standardize the institutional, contractual, commercial, or long-term governance arrangements under which namespace-coordination and registration operators are authorised.¶

6.3. Persistence

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

6.4. AIN and Web Identifier

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

7.1. Resolution Endpoint

This version provisionally uses the following HTTPS resource [RFC9110]:¶

GET /.well-known/ain/{ain}
Accept: application/ld+json, application/json

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 [RFC8615] will be requested in a later revision once the resolution mechanism is stable (see Section 17).¶

7.2. Resolver Response

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

{
  "@type": "DigitalAgentIdentity",
  "ain": "RG-01-CULRWC8ZKE34-4684",
  "status": "ACTIVE",
  "identity": {
    "name": "Synthetic Procurement Agent",
    "agentType": "AGENT"
  },
  "assertions": {
    "operatorBinding": {
      "value": "https://example.org/operators/123",
      "source": "https://rno.example",
      "competenceRecord":
        "https://registry.example/mandates/rno-a/operator-binding",
      "issuedAt": "2026-09-16T08:00:00Z",
      "expiresAt": "2026-09-16T10:00:00Z"
    }
  },
  "verification": {
    "jwks": "https://registry.example/.well-known/jwks.json"
  },
  "issuedAt": "2026-09-01T09:00:00Z",
  "updatedAt": "2026-09-16T08:30:00Z"
}

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

7.4. Operational Identity, Operator and Instance Attribution

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

7.5. Competent Sources and Issuer Standing

Source 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 [VERIFIER-EVAL].¶

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

7.6. Delegator Authority and Non-Self-Authenticating Claims

A 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 [AGENT-MANDATE], and the association between a principal and an accepted delegation root is discussed in [APS]. This section states the requirements that AIN-WRP places on such evidence when it is consumed.¶

7.7. Authoritative Endpoint Resolution

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

8.1. Operational Composition and Material Changes

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

8.2. Lifecycle States, Restrictions and Input Outcomes

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

9.1. Optional Agent Proof of Control Profile

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

10.1. Correlation Request

Before 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:¶

{
  "requestId": "72e36e04-a3a5-4ec8-9d54-cab760ade791",
  "participants": {
    "initiator": {
      "ain": "RG-01-CULRWC8ZKE34-4684",
      "role": "buyer"
    },
    "recipient": {
      "ain": "SYS-01-Q3CZWMSJUEL3-BDAC",
      "role": "supplier"
    }
  },
  "interactionType": "procurement.offer",
  "audience": "https://gateway.example",
  "issuedAt": "2026-09-15T10:00:00Z",
  "expiresAt": "2026-09-15T10:02:00Z"
}

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

10.2. Independent Resolution

The resolver MUST create logically separate resolution operations for each AIN-identified digital agent participating in the interaction. Where the counterparty is not a digital agent, the applicable profile MUST define how the counterparty service, system, account, or endpoint is authoritatively identified or resolved. Each required assertion MUST be obtained from a source competent for that assertion. A deployment MAY use one registry, 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.¶

10.3. Validation

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

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

10.4. Correlation and Restriction Composition

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

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

10.5. Separation of Verified State and Local Policy

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

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

10.6. Pre-Interaction State Proof

This version confines the normative treatment of the State Proof to the semantic bindings implied by its definition in Section 3 and by the Prove stage of the architectural model in Section 5. Serialization (JOSE 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.¶

10.7. State Proof Consumption and Controlled Session Establishment

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

10.8. Receiving-Domain Evaluation of Foreign Transaction Context

Validation of a transaction token issued by a foreign transaction-token service, such as a Transaction Token [TXN-TOKENS], 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.¶

10.9. Unresolved Verification and Dependency Semantics

An 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 [EVAL-STATE], and for the association between a principal and an accepted authority root in [APS].¶

10.10. Decision-Time Evidence and Retrospective Reconstruction

A 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 [DETERMINABILITY].¶

10.11. Correlation with Non-Agent Counterparties

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

11.1. Competent Sources and Federated Resolution

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

11.2. Sovereign, Private, and Restricted Resolution

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

11.3. Administrative Roles

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

14.1. Open-Source Agent Instance Attribution and Composition Drift

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

14.2. Cross-Domain Token Validation Is Not Admission

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

14.3. Decision-Time Authority Evidence Threats

Implementations 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 [AGENT-MANDATE] and in [DELEGATION-VECTORS]. Preserving evidence for audit requires access control, data minimization, integrity protection and retention limits appropriate to sensitive delegations and personal data.¶

16.1. Gateway Admission

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

16.2. Cross-Organisation Agent Interaction

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

16.3. Agent-to-Service Interaction

An AIN-identified digital agent may interact with a conventional API, web service, merchant system, database service, or other non-agent counterparty. The non-agent counterparty is not required by this specification to obtain an AIN solely because an agent interacts with it. Before the protected operation begins, AIN-WRP resolves and validates the agent's persistent identity and applicable authoritative assertions and, where required by the applicable profile, establishes the authoritative identity or endpoint binding of the counterparty. The resulting Pre-Interaction Trust State is therefore relationship-specific without converting every automated service into a Digital Agent.¶

In this scenario, the non-agent counterparty 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.¶

16.4. Regulated Financial Interaction

A financial institution may require a payment or treasury agent participating in an AIN-WRP protected interaction to have a resolvable AIN in an operationally eligible state, together with current proof of control where required, an authoritative mandate from the account-holding organisation, an authoritative recipient AIN and endpoint where the recipient is an AIN-identified agent or an authoritative counterparty and endpoint binding where it is not, and no applicable mandatory restriction before the payment protocol begins. The agent MAY also use banking, payment-network, enterprise, workload, OAuth, or other identifiers and credentials required by the institution or the underlying transaction protocol; such identifiers and credentials MAY be validated or correlated with the agent's AIN as supporting evidence. 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.¶

16.5. Sovereign or Private Domain

A government, bank, critical-infrastructure operator, or other high-assurance environment may operate an authorised private or sovereign AIN source and keep sensitive attributes within its administrative perimeter. Agents within that domain MAY also use local, sector-specific, governmental, workload, or other identity schemes, 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.¶

19.1. OpenID Connect Agent Identity Profiles

OpenID Connect agent-identity profiles can carry agent-specific claims in ID Tokens [SHARIF-OIDC]. 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.¶

19.2. OAuth, WIMSE, and Agent Authentication and Authorization

OAuth-family mechanisms, workload-identity systems, and AI-agent authentication and authorization work such as [AIMS] 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.¶

19.3. External Identity, Delegation, and Capability Artefacts

External identity, delegation, and capability systems may provide cryptographically verifiable artefacts concerning a digital agent, its delegated authority, mandate, or prior actions. Such artefacts MAY be used as supporting evidence during AIN-WRP verification where their issuer, validity, provenance, scope, and applicable competence can be established.¶

Possession or presentation of such an artefact does not, by itself, establish the current authoritative state or cross-domain eligibility of a digital agent. Where required by the applicable profile, AIN-WRP independently resolves and evaluates the relevant persistent identity, lifecycle state, source competence, mandate or authority, endpoint information, and applicable restrictions before producing a Pre-Interaction Trust State.¶

AIN-WRP therefore does not require delegated authority, permissions, or operational eligibility to be encoded in the persistent AIN identity itself. These properties are treated as distinct, potentially dynamic assertions that may originate from different competent sources.¶

19.4. A2A, MCP, APIs, and Gateways

A2A [A2A], MCP [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.¶

19.5. Observability and Audit

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

19.6. Relationship to Contemporaneous Work

Several other efforts published or updated during the development of this document address closely related problems. This section positions AIN-WRP relative to them and is expected to be revised as those efforts mature.¶

Other recent Internet-Drafts start from a premise similar to Section 1 of this document: that possession of a valid credential is insufficient to establish which agent is acting, under whose authority, and within what constraints. [SHARIF-OIDC] carries agent-specific claims within OpenID Connect ID Tokens; [AIMS] applies the WIMSE architecture and the OAuth 2.0 family of specifications to agent identity, authentication and authorization; and [APS] 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.¶

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

[VERIFIER-EVAL] 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. [APS] 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.¶

19.7. Relationship to Other Identifier and Credential Systems

An AIN is not intended to replace URIs, DIDs, SPIFFE IDs, certificates, OAuth tokens, workload credentials, or other identifier and authentication mechanisms. Those mechanisms address different, and often complementary, requirements. 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.¶

19.8. Complementary Authority and Decision-Time Evidence Work

Contemporaneous agent-mandate and delegation-chain work, including [AGENT-MANDATE] and [APS], provides possible external evidence of delegator standing, delegation limits and authority assertion validation. Work on preserving evaluation state [EVAL-STATE] and on independently determinable agent actions [DETERMINABILITY] 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.¶

B.1. Pre-Interaction State Proof

A correlation service may issue a signed, time-limited State Proof. It should bind the initiator AIN and, where applicable, the recipient AIN; otherwise it should bind an authoritative reference to the non-agent counterparty. It should also bind participant roles, intended audience, resolved recipient endpoint, interaction type, evidence or state versions, policy version where applicable, decision provenance, restrictions, issuance time, expiry time, and a unique proof identifier. Higher-assurance profiles may also bind challenge hashes, operation hashes, channel information, or bilateral configuration fingerprints.¶

A State Proof must not be described as implemented merely because a deployment supports a single-agent signed assertion. Bilateral proof issuance, atomic consumption, controlled-session creation, and receipts are distinct protocol capabilities. This appendix describes candidate semantic bindings for a future State Proof profile; it does not select a JOSE ([RFC7515], [RFC7517], [RFC8037]) 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.¶

B.2. State Proof Consumption and Controlled Session Establishment

A higher-assurance AIN-WRP profile may require a State Proof to be consumed before a protected operational session is established. In such a profile, proof consumption, controlled-session creation, and receipt creation form one atomic security operation.¶

A State Proof subject to single-use consumption must have an authoritatively determinable lifecycle state equivalent to one of the following: ISSUED, CONSUMED, EXPIRED, or REVOKED. ISSUED means the proof is valid and unconsumed; CONSUMED means it has been successfully bound to one controlled session and must not create another; EXPIRED means its validity interval ended before successful consumption; REVOKED means it was invalidated by a competent source or issuing service before successful consumption. The expression "equivalent to" permits implementations to use different internal state names while preserving these protocol semantics.¶

Before consuming a proof, the gateway or proof-consumption service must verify, as required by the applicable profile: the proof signature and signing-key status; issuer identity and competence; proof identifier and lifecycle state; issuance and expiry times; initiator AIN binding and, where applicable, recipient AIN binding or authoritative non-agent counterparty binding; intended audience; resolved recipient endpoint; interaction type and operation or parameter hash when present; channel or session-establishment binding when required; evidence-state and policy versions; mandatory restrictions; and the idempotency key associated with the session-establishment attempt. The idempotency key is associated with the proof-consumption and session-establishment request; it is not necessarily part of the preceding correlation request.¶

The gateway must not permit protected operational traffic solely because the proof is cryptographically valid. The protected channel must remain closed until the atomic consumption operation has successfully committed.¶

The atomic operation must, as one indivisible transaction: (1) conditionally change the proof state from ISSUED to CONSUMED; (2) create the controlled operational session; (3) bind the session to the proof, participants, audience, endpoint, applicable restrictions, and channel context; (4) create a consumption receipt; and (5) record the resulting proof and session state. The transaction must succeed or fail as a unit. If any step fails before commit, all effects must be rolled back, the proof must remain in its preceding state, and no successful session or consumption receipt may be returned.¶

A successful commit must produce a stable session identifier and stable consumption receipt. The receipt should bind at least the State Proof identifier, controlled-session identifier, idempotency key, consuming gateway or relying party, initiator AIN and, where applicable, recipient AIN or authoritative non-agent counterparty reference, proof-consumption result, and commit time. It may additionally contain or reference applied restrictions, endpoint binding, channel binding, evidence versions, and policy version. It must not disclose source evidence or personal data that the relying party is not authorised to receive.¶

If a client retries after a successful commit using the same proof identifier, the same idempotency key, and equivalent security-relevant parameters, the service should treat the request as an idempotent retry and should return the same session identifier and receipt. It must not create a second session. If a proof is already CONSUMED and a subsequent request uses a different idempotency key, gateway audience, participants, endpoint, channel binding, or other non-equivalent security-relevant parameters, the service must reject the request as replay or context substitution and must not create another session.¶

A response-delivery failure occurring after commit must not restore the proof to ISSUED. A retry following an uncertain outcome should use the same idempotency key. The service must use committed transaction state to return the previously created session and receipt.¶

Implementations must ensure that concurrent attempts to consume the same proof cannot both succeed. The authoritative replay state must be shared by all gateway or proof-consumption instances that can accept the proof. An in-memory cache local to one process is not sufficient as the authoritative replay record.¶

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

B.3. Federated, Regional, Enterprise, and Sovereign Resolution

AIN-WRP does not require all identity or trust information to be stored in a single global registry. Competent sources may be operated by independent organisations, enterprises, sectors, regional operators, national authorities, or sovereign infrastructures, provided that their competence can be established for the assertions consumed.¶

An RNO is one possible operator of a domain-authoritative source. A resolver must not assume every jurisdiction has an RNO. Direct central resolution and other authorised sources remain valid when they hold the required competence.¶

A regional, institutional, or sovereign assertion should include issuing-source identity, signature or authenticated-channel evidence, validity interval, protocol version, freshness marker, and competence scope. A central registry may confirm the canonical AIN or the mandate of another source. Central confirmation must not override a restriction validly issued within another source's competence, and a delegated source must not modify canonical identity information outside its mandate.¶

B.4. Private and Air-Gapped Deployments

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

B.5. Identity Continuity

Persistence of an AIN does not mean that every technical or administrative attribute of the identified digital agent remains unchanged. Models, prompts, credentials, keys, endpoints, tools, capabilities, operators, and deployment infrastructure are potentially mutable attributes.¶

Changes to mutable attributes do not necessarily create a new digital-agent identity. The applicable registration profile must define the identity invariants and continuity conditions under which an existing AIN may be retained, and the conditions under which a new AIN is required.¶

A registration profile must consider both individual and cumulative changes. A sequence of changes that would require a new AIN if performed as one replacement must not avoid that requirement merely because the changes were introduced incrementally.¶

An existing AIN must not be retained solely to preserve reputation, audit history, permissions, assurance results, or other favourable state when the identity invariants defined by the applicable registration profile no longer hold.¶

When a material change does not break identity continuity, the change must be recorded with sufficient provenance and effective-time information. Retention of the AIN does not imply continuity of every assertion concerning the agent. Credentials, mandates, capabilities, assurance results, risk classifications, endpoint bindings, State Proofs, permissions, and operational eligibility must be independently re-evaluated when affected by the change.¶

When a material change breaks identity continuity, a new AIN must be issued. The preceding AIN must not be reassigned or erased. Where appropriate, the authoritative records should express a typed relationship between the preceding and succeeding AINs. Such a relationship is provenance information and must not, by itself, imply the transfer of credentials, mandates, permissions, restrictions, reputation, assurance results, or operational eligibility.¶

B.6. Operator Transfer

An operator binding is a time-bounded authoritative relationship between a digital-agent identity and an entity responsible for operating that agent. A change of operator does not necessarily create a new digital-agent identity.¶

An existing AIN may be retained following an operator transfer only when the applicable registration profile permits the transfer and the identity-continuity conditions defined by that profile remain satisfied. A registration profile may require issuance of a new AIN for specified classes of transfer, including transfers that materially change the identity, purpose, accountability, administrative domain, or operational characteristics of the agent.¶

An operator transfer must be recorded as an authoritative, time-ordered event. A registry must not represent a transfer merely by overwriting the previous operator binding. The authoritative record must preserve sufficient information to determine the preceding and succeeding operator bindings, the effective time of the transfer, the source competent to authorise or record the transfer, the transfer status, and the provenance of the transition.¶

The registry must ensure that there is an unambiguous current operator binding at any effective time, unless the applicable profile explicitly permits concurrent or joint operators and defines their respective roles and authority.¶

Retention of an AIN following an operator transfer does not imply automatic transfer of credentials, cryptographic keys, mandates, permissions, endpoint authority, assurance results, State Proofs, reputation, restrictions, or operational eligibility. Each affected assertion must be retained, revoked, replaced, or revalidated according to its own issuer, competence scope, validity conditions, and the applicable registration profile. After the transfer becomes effective, the preceding operator must not be treated as the current operator and must not retain authority to modify the agent's authoritative record unless a competent source has explicitly granted continuing authority.¶

Historical events associated with an AIN must remain attributable to the operator binding and agent state effective when those events occurred. A change of operator must not retroactively attribute the preceding operator's actions to the succeeding operator, and retention of the AIN must not cause operator-specific reputation or assurance to transfer automatically to the succeeding operator.¶

B.7. Mandate and Delegated Authority

An AIN identifies the digital agent that is the subject of a mandate. The AIN does not create the mandate and does not establish that the agent is authorised to perform a particular operation.¶

A mandate is an assertion issued on behalf of a principal under an applicable administrative, organisational, legal, contractual, or technical trust framework. The source competent to issue or confirm a mandate depends on that framework and may be, for example, an authorised person, an organisational authority, an identity or access-management system, a procurement or enterprise system, a delegation service, or another authorised technical component.¶

AIN-WRP does not create authority, mandate, or competence. It resolves and validates assertions of authority issued under an applicable trust framework and determines whether the issuing source is competent for the asserted mandate, subject, scope, and administrative domain.¶

Cryptographic validity alone does not establish mandate validity. A relying party must also establish that the issuer was competent to issue the mandate for the identified principal, agent, scope, and administrative domain at the relevant time. A resolver or correlation service that transports, validates, or includes a mandate assertion in a Pre-Interaction Trust State does not become the issuer of that mandate and must not represent itself as the source of the underlying authority unless it independently holds the required competence.¶

Where a mandate depends on delegated authority, each security-relevant delegation in the chain must be valid, current, within the delegator's authority, and no broader than the authority held by the delegator. The applicable trust framework must define whether further delegation is permitted and any maximum delegation depth; absence of such permission must not be interpreted as permission to re-delegate.¶

An AIN registry may publish or resolve competence records, but operation of an AIN registry does not, by itself, make that registry competent to create mandates on behalf of every principal or administrative domain.¶

A change of operator binding does not transfer mandates automatically. A mandate issued under the authority of a preceding operator remains usable after transfer only when its issuer, terms, applicable trust framework, and current competent sources explicitly permit such continuity.¶

A self-asserted mandate must not be treated as authoritative unless the applicable trust framework explicitly recognises the agent as competent to issue that mandate and the relying party accepts that framework.¶