Individual Submission E. Tănase Internet-Draft AIDAXIA Ltd. Intended status: Standards Track 18 September 2026 Expires: 22 March 2027 Authoritative Resolution and Pre-Interaction Verification of Persistent Digital Agent Identities draft-tanase-ain-authoritative-resolution-00 Abstract This document specifies AIN-WRP, a protocol-independent mechanism for authoritative resolution of persistent digital agent identities and for verification of relationship-specific state before a digital agent begins a protected operational interaction with another agent or with a non-agent service or system. An Agent Identity Number (AIN) acts as a stable lookup anchor. The protocol resolves current identity, lifecycle, operator or authority, endpoint, mandate, restriction, provenance, and cryptographic verification information from sources competent to make the corresponding assertions. AIN-WRP separates persistent identity from credentials, proof of control, delegated authority, operational eligibility, policy decision, and execution. For participants operating under independent administrative domains, the protocol performs logically independent resolution, validates source competence and evidence freshness, correlates the resulting assertions for the proposed relationship, and produces a Pre-Interaction Trust State. A signed, time-limited State Proof may convey that state to a gateway or relying party. The gateway applies local policy and controls whether an A2A, MCP, API, messaging, transactional, or proprietary protocol begins. This version defines the protocol model and the initial requirements for future interoperable profiles. It does not require all AIN registration, resolution, assertion issuance, policy evaluation, or operational enforcement to be performed by a single central service, a mandatory Regional Network Operator (RNO), or a particular gateway, identity provider, authorization framework, or execution protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Tanase Expires 22 March 2027 [Page 1] Internet-Draft AIN Authoritative Resolution September 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Why This Requires a Neutral, Cross-Organisational Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 8 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Architectural Model . . . . . . . . . . . . . . . . . . . . . 9 5.1. Trust Plane and Execution Plane . . . . . . . . . . . . . 11 6. Agent Identity Number . . . . . . . . . . . . . . . . . . . . 11 6.1. Canonical Syntax . . . . . . . . . . . . . . . . . . . . 11 6.2. Namespace Coordination and Canonical Registration . . . . 12 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. AIN and Web Identifier . . . . . . . . . . . . . . . . . 13 6.5. Relationship to Other Identifiers . . . . . . . . . . . . 13 7. Authoritative Resolution . . . . . . . . . . . . . . . . . . 13 7.1. Resolution Endpoint . . . . . . . . . . . . . . . . . . . 13 7.2. Resolver Response . . . . . . . . . . . . . . . . . . . . 14 7.3. Source Competence . . . . . . . . . . . . . . . . . . . . 14 Tanase Expires 22 March 2027 [Page 2] Internet-Draft AIN Authoritative Resolution September 2026 7.4. Authoritative Endpoint Resolution . . . . . . . . . . . . 15 8. Lifecycle and Operational Eligibility . . . . . . . . . . . . 15 9. Proof of Control . . . . . . . . . . . . . . . . . . . . . . 16 10. Pre-Interaction Verification . . . . . . . . . . . . . . . . 16 10.1. Correlation Request . . . . . . . . . . . . . . . . . . 16 10.2. Independent Resolution . . . . . . . . . . . . . . . . . 17 10.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 17 10.4. Correlation and Restriction Composition . . . . . . . . 18 10.5. Separation of Verified State and Local Policy . . . . . 18 10.6. Pre-Interaction State Proof . . . . . . . . . . . . . . 19 10.7. State Proof Consumption and Controlled Session Establishment . . . . . . . . . . . . . . . . . . . . . 19 11. Federated, Regional, Enterprise, and Sovereign Resolution . . 19 12. Caching, Invalidation, and Re-Evaluation . . . . . . . . . . 19 13. Error Model . . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 16. Deployment Examples (Non-Normative) . . . . . . . . . . . . . 24 16.1. Gateway Admission . . . . . . . . . . . . . . . . . . . 24 16.2. Cross-Organisation Agent Interaction . . . . . . . . . . 24 16.3. Agent-to-Service Interaction . . . . . . . . . . . . . . 25 16.4. Regulated Financial Interaction . . . . . . . . . . . . 25 16.5. Sovereign or Private Domain . . . . . . . . . . . . . . 26 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 18. Implementation Status (Non-Normative) . . . . . . . . . . . . 26 19. Relationship to Other Work . . . . . . . . . . . . . . . . . 27 19.1. OpenID Connect Agent Identity Profiles . . . . . . . . . 28 19.2. OAuth, WIMSE, and Agent Authentication/Authorization . . 28 19.3. External Identity, Delegation, and Capability Artefacts . . . . . . . . . . . . . . . . . . . . . . . 28 19.4. A2A, MCP, APIs, and Gateways . . . . . . . . . . . . . . 29 19.5. Observability and Audit . . . . . . . . . . . . . . . . 29 19.6. Relationship to Contemporaneous Work . . . . . . . . . . 29 19.7. Relationship to Other Identifier and Credential Systems . . . . . . . . . . . . . . . . . . . . . . . . 30 20. Normative References . . . . . . . . . . . . . . . . . . . . 31 21. Informative References . . . . . . . . . . . . . . . . . . . 32 Appendix A. Open Design Decisions . . . . . . . . . . . . . . . 33 Appendix B. Deferred Protocol Elements (Non-Normative, Target -01) . . . . . . . . . . . . . . . . . . . . . . . . . . 34 B.1. Pre-Interaction State Proof . . . . . . . . . . . . . . . 34 B.2. State Proof Consumption and Controlled Session Establishment . . . . . . . . . . . . . . . . . . . . . . 35 B.3. Federated, Regional, Enterprise, and Sovereign Resolution . . . . . . . . . . . . . . . . . . . . . . . 37 B.4. Private and Air-Gapped Deployments . . . . . . . . . . . 38 B.5. Identity Continuity . . . . . . . . . . . . . . . . . . . 38 B.6. Operator Transfer . . . . . . . . . . . . . . . . . . . . 39 Tanase Expires 22 March 2027 [Page 3] Internet-Draft AIN Authoritative Resolution September 2026 B.7. Mandate and Delegated Authority . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction Digital agents increasingly initiate requests, invoke tools, exchange data, negotiate, and execute transactions across organisational and jurisdictional boundaries. Existing authentication and authorization mechanisms can establish possession of a credential, authenticate a workload or client, or express delegated access. Those properties are necessary but do not, by themselves, establish the current authoritative state of a specific persistent digital-agent identity or of the proposed relationship between an agent and its intended counterparty, including another agent or a non-agent service or system. A frequently raised objection illustrates why this distinction matters in practice: an operator holding a valid API credential may argue that the credential alone identifies who made a request, and that no additional identity layer is required. This objection is correct as far as it goes; credential validity does identify a requester at the transport layer. It becomes visible as insufficient exactly at the points this document addresses: when the same credential is shared or reused by multiple autonomous agents performing different tasks, when a credential is rotated or redelegated across deployments, or when a dispute requires determining which agent, under whose authority, initiated a specific request that crossed an organisational boundary. In such cases the credential establishes that a request was authorized to reach a service; it does not, by itself, establish which persistent agent identity initiated the request, on whose behalf, or whether that specific action remained within the scope the delegating party intended. In particular, a valid credential does not necessarily establish that the represented agent remains operationally eligible; that the presenter controls the currently authorised key; that a claimed operator or mandate remains current; that a presented endpoint is authoritative; that a restriction issued in another administrative domain has been considered; or that the source making a security- relevant assertion is competent to make that assertion. AIN-WRP introduces an authoritative trust-plane operation that occurs before, or at the admission boundary of, the execution-plane protocol. The operation begins with the persistent AIN of each participating digital agent and, where the counterparty is not a digital agent, with an authoritative service, system, account, or endpoint reference appropriate to that interaction. It resolves Tanase Expires 22 March 2027 [Page 4] Internet-Draft AIN Authoritative Resolution September 2026 required assertions from competent sources, preserves provenance and validity metadata, validates proof material where required, and correlates the evidence for the intended interaction. The resulting state is supplied to a gateway or relying party, which remains responsible for local policy and enforcement. An AIN identifies a technical software system or agent record. It does not confer legal personality, citizenship, regulatory approval, or a status equivalent to that of a natural or legal person. Responsibility remains with the applicable provider, deployer, operator, controller, principal, or other accountable entity. AIN-WRP is complementary to OpenID Connect, OAuth, workload identity, verifiable credentials, A2A, MCP, HTTP message signatures, gateway policy systems, and observability systems. Those systems may carry, bind, or consume AIN information and AIN-WRP results; they are not replaced by this specification. 1.1. Why This Requires a Neutral, Cross-Organisational Layer Individual platforms and payment rails are independently addressing adjacent parts of this problem. Agent-management platforms bind identity to governance and policy enforcement within one operator's infrastructure. Payment networks are introducing spending limits, allowed-merchant lists, and proof of intent bound to a specific rail. Both are valuable and neither requires this specification. Neither, however, is designed to let two independent administrative domains, using different platforms and different rails, establish who a counterparty's agent is, who operates it, and under what mandate, before an interaction begins. That specific function — a persistent, publicly resolvable identity anchor and a pre-interaction verification step that neither party's platform vendor nor payment provider is positioned to arbitrate — is the reason this document proposes a protocol-independent, vendor- neutral specification rather than a product. A layer intended for use across independent administrative domains should not require either counterparty to accept the other counterparty's platform vendor or payment provider as the sole authority for cross-domain identity and relationship state; it needs the same standing that addressed identifiers and naming protocols have historically required. This does not diminish the value of platform-level identity and governance products, or of rail-level payment controls; AIN-WRP is designed to be resolved and consumed by them, not to replace them (Section 19). Tanase Expires 22 March 2027 [Page 5] Internet-Draft AIN Authoritative Resolution September 2026 2. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology +=================+==============================================+ | Term | Definition | +=================+==============================================+ | Digital Agent | A software system capable of initiating, | | | receiving, selecting, or executing | | | operations with operational autonomy on | | | behalf of a principal, operator, or defined | | | system objective. Mere automation of a | | | fixed instruction or transport function does | | | not, by itself, make a component a Digital | | | Agent for purposes of this specification. | +-----------------+----------------------------------------------+ | Counterparty | The agent, service, system, account, or | | | operational endpoint with which an AIN- | | | identified digital agent proposes to | | | interact. A Counterparty is not required to | | | be a Digital Agent or to possess an AIN | | | unless the applicable profile requires it. | +-----------------+----------------------------------------------+ | AIN | A globally unique, persistent identifier | | | assigned by an authoritative AIN registry to | | | a digital agent or AI system record. | +-----------------+----------------------------------------------+ | AIN-WRP | The AIN Web Resolution and Pre-Interaction | | | Verification protocol model specified by | | | this document. | +-----------------+----------------------------------------------+ | Authoritative | A source recognised as competent to confirm | | Source | one or more specified assertions. | +-----------------+----------------------------------------------+ | Competent | An Authoritative Source whose competence | | Source | covers the particular attribute, state, | | | restriction, relationship, territory, | | | sector, lifecycle function, endpoint, or | | | class of operation being relied upon. | +-----------------+----------------------------------------------+ | Competence | Evidence describing the scope within which a | | Record | source is authorised or technically | Tanase Expires 22 March 2027 [Page 6] Internet-Draft AIN Authoritative Resolution September 2026 | | competent to issue assertions. | +-----------------+----------------------------------------------+ | Resolved | An assertion obtained from a source together | | Assertion | with provenance, validity, version, and | | | competence metadata sufficient for the | | | relying party to evaluate it. | +-----------------+----------------------------------------------+ | Resolver | A service that obtains current AIN-related | | | information and preserves source, validity, | | | provenance, and competence metadata. | +-----------------+----------------------------------------------+ | Administrative | A domain within which identity, state, | | Domain | authority, or restrictions are administered | | | under a defined policy. | +-----------------+----------------------------------------------+ | RNO | A Regional Network Operator that may operate | | | or mandate an authoritative regional source. | | | RNO participation is not required in every | | | deployment. | +-----------------+----------------------------------------------+ | Relying Party | A component that consumes resolved | | | information or a pre-interaction result and | | | applies its own enforcement policy. | +-----------------+----------------------------------------------+ | Pre-Interaction | A relationship-specific result created by | | Trust State | correlating validated authoritative | | | assertions before the operational protocol | | | begins. | +-----------------+----------------------------------------------+ | State Proof | A signed, time-limited representation of a | | | Pre-Interaction Trust State, bound as | | | appropriate to participants, endpoint, | | | roles, audience, interaction context, | | | evidence versions, and restrictions. | +-----------------+----------------------------------------------+ | Operational | The A2A, MCP, API, messaging, payment, | | Protocol | 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 | An operational session created only after | | Operational | successful validation and, where required, | | Session | atomic consumption of a State Proof, and | Tanase Expires 22 March 2027 [Page 7] Internet-Draft AIN Authoritative Resolution September 2026 | | constrained by the participants, endpoint, | | | audience, channel context, and mandatory | | | restrictions bound to that proof. | +-----------------+----------------------------------------------+ | Consumption | A stable record produced by a successful | | Receipt | atomic proof-consumption operation that | | | binds the consumed State Proof, controlled | | | session, idempotency key, consuming gateway, | | | and commit result. | +-----------------+----------------------------------------------+ Table 1 4. Scope and Non-Goals 4.1. Scope * canonical presentation and validation requirements for an AIN; * authoritative HTTPS resolution and machine-readable (JSON, [RFC8259]) representations; * lifecycle disclosure and operational-eligibility semantics; * discovery of verification material and optional proof of control; * validation of source competence for security-relevant assertions; * authoritative endpoint resolution; * pre-interaction correlation across independent administrative domains, including agent-to-agent and profile-defined agent-to- service interactions; * preservation and composition of mandatory restrictions; * optional signed State Proofs for gateway or relying-party consumption; * federated, enterprise, regional, and sovereign deployment models; * security, privacy, caching, invalidation, error, and extensibility requirements. 4.2. Non-Goals * define legal responsibility, certification, or regulatory approval; Tanase Expires 22 March 2027 [Page 8] Internet-Draft AIN Authoritative Resolution September 2026 * standardise a universal trust score, risk score, or behavioural reputation methodology; * observe or control an operator's internal agent orchestration; * replace OAuth, OpenID Connect, A2A, MCP, workload identity, gateway policy engines, or execution protocols; * require all AIN registration, resolution, assertion issuance, policy evaluation, or operational enforcement to be performed by a single central service, one commercial registry, or mandatory RNO deployment; * require all attributes concerning an agent to be held by the same source; * require the resolver or correlation service to execute the underlying action or transaction; * dictate the relying party's local authorization policy. 5. Architectural Model The architecture separates persistent identity, authoritative verification, policy enforcement, and execution. AIN provides the persistent lookup anchor. AIN-WRP resolves and validates relationship-relevant state. The gateway or relying party applies local policy. The operational protocol carries the permitted interaction. Tanase Expires 22 March 2027 [Page 9] Internet-Draft AIN Authoritative Resolution September 2026 +============+=====================+=================+=============+ | Stage | Input | Output | Primary | | | | | component | +============+=====================+=================+=============+ | Identify | Initiator AIN; | Correlation | Gateway or | | | recipient AIN when | request | relying | | | applicable, | | party | | | otherwise | | | | | authoritative | | | | | counterparty | | | | | reference; | | | | | interaction context | | | +------------+---------------------+-----------------+-------------+ | Resolve | AINs and required | Current source | Resolver | | | assertion types | records | and | | | | | competent | | | | | sources | +------------+---------------------+-----------------+-------------+ | Validate | Records, | Validated | Resolver or | | | signatures, | assertions | correlation | | | validity, | | engine | | | provenance, | | | | | competence | | | +------------+---------------------+-----------------+-------------+ | Correlate | Validated evidence | Pre-Interaction | Correlation | | | sets and | Trust State | engine | | | relationship | | | | | context | | | +------------+---------------------+-----------------+-------------+ | Prove | Trust State and | Signed State | Correlation | | (optional) | evidence bindings | Proof | service | +------------+---------------------+-----------------+-------------+ | Enforce | Trust State or | ALLOW, | Gateway or | | | proof plus local | RESTRICT, DENY, | relying | | | policy | REVIEW, or | party | | | | local | | | | | equivalent | | +------------+---------------------+-----------------+-------------+ | Execute | Permitted protocol | Operational | A2A, MCP, | | | parameters | session/action | API, | | | | | payment, | | | | | messaging, | | | | | or other | | | | | protocol | +------------+---------------------+-----------------+-------------+ Table 2 Tanase Expires 22 March 2027 [Page 10] Internet-Draft AIN Authoritative Resolution September 2026 | 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. 5.1. Trust Plane and Execution Plane AIN-WRP does not require the trust plane and execution plane to be operated by the same entity. A resolver may be public, private, federated, sectoral, regional, or sovereign. A gateway may consume a State Proof without delegating execution authority to the resolver. Conversely, a gateway that authenticates an agent credential MUST NOT infer that credential validity alone establishes the full Pre- Interaction Trust State. 6. Agent Identity Number 6.1. Canonical Syntax The current AIN profile uses this canonical textual form, expressed in ABNF [RFC5234]: AIN = issuer "-" version "-" payload "-" checksum issuer = 2*4UPPER version = 2DIGIT payload = 12ALPHANUM checksum = 4UPPERHEX UPPER = %x41-5A ALPHANUM = UPPER / DIGIT UPPERHEX = DIGIT / %x41-46 The canonical representation MUST use uppercase ASCII letters and ASCII hyphen-minus separators and MUST contain no surrounding whitespace. Implementations MUST treat the AIN as an opaque persistent identifier and MUST NOT infer jurisdiction, capability, lifecycle state, authority, or regulatory status from its components. Examples such as RG-01-CULRWC8ZKE34-4684 and SYS-01-Q3CZWMSJUEL3-BDAC are synthetic. The checksum is a short registry integrity check; it is not a digital signature, public proof of authenticity, uniqueness guarantee, or substitute for authoritative resolution. Tanase Expires 22 March 2027 [Page 11] Internet-Draft AIN Authoritative Resolution September 2026 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. Tanase Expires 22 March 2027 [Page 12] Internet-Draft AIN Authoritative Resolution September 2026 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. 6.5. Relationship to Other Identifiers A digital agent identified by an AIN MAY also possess or use other identifiers, credentials, account identifiers, workload identities, decentralised identifiers, sector-specific identifiers, or protocol- specific identities. AIN-WRP does not require such identifiers to be replaced. Within AIN-WRP, the AIN is the persistent identity anchor to which authoritative state and relationship-relevant assertions are resolved. Other identifiers or credentials MAY be associated with an AIN and MAY be used as supporting evidence where their issuer, binding, validity, scope, and applicable competence can be established. An additional identifier or credential MUST NOT be treated as a substitute for the AIN when an AIN-WRP operation requires authoritative resolution of a digital agent by AIN. 7. Authoritative Resolution 7.1. Resolution Endpoint This version provisionally uses the following HTTPS resource ([RFC9110]): GET /.well-known/ain/{ain} Accept: application/ld+json, application/json | NOTE: 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. Tanase Expires 22 March 2027 [Page 13] Internet-Draft AIN Authoritative Resolution September 2026 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", "operationallyEligible": true, "identity": { "name": "Synthetic Procurement Agent", "agentType": "AGENT" }, "assertions": { "operatorBinding": { "value": "https://example.org/operators/123", "source": "https://registry.example", "competenceRecord": "https://registry.example/competence/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" } 7.3. Source Competence A signed response is not authoritative merely because its signature is valid. A relying party MUST establish that the issuer is competent for each security-relevant assertion it consumes. Competence MAY be limited by attribute, territory, sector, relationship type, lifecycle function, endpoint class, or class of operation. Where multiple sources contribute to a result, the resolver SHOULD preserve, for each assertion, the source identity, competence scope, version, issuance time, expiry time, retrieval time, and validation status. A resolver MUST NOT silently elevate a source beyond its competence. Tanase Expires 22 March 2027 [Page 14] Internet-Draft AIN Authoritative Resolution September 2026 7.4. Authoritative Endpoint Resolution An endpoint presented by an initiating agent is a hint, not an authoritative routing instruction. Before a security-sensitive operational interaction begins, the recipient endpoint SHOULD be resolved from a source competent to identify that endpoint. A gateway MUST NOT redirect or initiate a protected operation solely on the basis of an initiator-supplied endpoint when authoritative endpoint resolution is required by the applicable profile. 8. Lifecycle and Operational Eligibility Identity existence, resolvability, lifecycle state, and operational eligibility are distinct concepts. A known identifier SHOULD remain resolvable after suspension or revocation so a relying party can discover its current state. An endpoint used specifically for an operational handshake MAY refuse inactive identifiers. +===========+================+=============+=====================+ | State | Identity | Operational | Meaning | | | resolution | treatment | | +===========+================+=============+=====================+ | ACTIVE | Return current | Eligible | Record is active. | | | record | subject to | | | | | policy | | +-----------+----------------+-------------+---------------------+ | SUSPENDED | Return state | Deny or | Temporarily | | | and limited | require | ineligible. | | | record | review | | +-----------+----------------+-------------+---------------------+ | PENDING | Return state | Deny or | Not yet active. | | | and limited | defer | | | | record | | | +-----------+----------------+-------------+---------------------+ | REVOKED | Return | Deny | Permanently | | | tombstone and | | revoked; identifier | | | state | | not reusable. | +-----------+----------------+-------------+---------------------+ | EXPIRED | Return state | Deny or | Validity interval | | | when known | require | ended. | | | | renewal | | +-----------+----------------+-------------+---------------------+ | UNKNOWN | Not found | Deny | No authoritative | | | | | record found. | +-----------+----------------+-------------+---------------------+ Table 3 Tanase Expires 22 March 2027 [Page 15] Internet-Draft AIN Authoritative Resolution September 2026 A resolver MUST NOT represent UNKNOWN as REVOKED, or REVOKED as UNKNOWN. A client MUST NOT treat successful identity resolution as authorization to perform an operation. 9. Proof of Control A registry or competent verification service MAY provide challenge- response verification to demonstrate possession of cryptographic material associated with an AIN. The challenge MUST contain an unpredictable nonce, expiry time, target AIN, intended audience, and sufficient context to prevent use for another purpose. The response MUST be bound to the nonce and AIN and MUST be verified against active cryptographic material obtained through authoritative resolution or an authorised key-discovery resource. A nonce MUST be single-use. Expired, previously used, or context-mismatched challenges MUST be rejected. Proof of control establishes possession of a key. It does not, by itself, establish a valid mandate, permission for a proposed action, current endpoint authority, operator binding, source competence, or cross-domain operational eligibility. 10. Pre-Interaction Verification 10.1. Correlation Request Before sending the first protected operational message, a relying party MAY submit a relationship-specific request containing at least the initiator AIN, a recipient AIN when the recipient is an AIN- identified digital agent or an authoritative counterparty reference when it is not, participant roles, interaction type, audience, request identifier, issuance time, and expiry time. It MAY also include endpoint hints, requested capability, jurisdictional or sectoral context, assurance requirements, and a hash of the requested operation. This version defines the semantic content of the correlation request but does not yet standardize its transport endpoint or media type. | NOTE: The requestId is an opaque, collision-resistant | identifier within the applicable profile. | | Implementations SHOULD generate requestId values using a | cryptographically random generator with | Tanase Expires 22 March 2027 [Page 16] Internet-Draft AIN Authoritative Resolution September 2026 | 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 and does not itself guarantee | a specific entropy value. { "requestId": "018f47a2-8b9c-7def-8123-456789abcdef", "initiatorAin": "RG-01-CULRWC8ZKE34-4684", "recipientAin": "SYS-01-Q3CZWMSJUEL3-BDAC", "interactionType": "procurement.offer", "audience": "https://gateway.example", "issuedAt": "2026-09-16T10:00:00Z", "expiresAt": "2026-09-16T10:02:00Z" } 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, regional RNO nodes, national or institutional registries, enterprise registries, federated services, or a combination of those sources. Independent resolution is a logical requirement, not a requirement for separate network connections. In an agent-to-agent interaction, a single service MAY answer for both participants only when it is demonstrably competent for the assertions consumed for both administrative domains. In an agent-to-service interaction, the agent identity and the non-agent counterparty binding remain distinct verification subjects even when one infrastructure component supplies evidence for both. 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. Tanase Expires 22 March 2027 [Page 17] Internet-Draft AIN Authoritative Resolution September 2026 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. +==========+===========================+==========================+ | Result | Meaning | Required gateway | | | | behaviour | +==========+===========================+==========================+ | ALLOW | Required evidence is | Gateway may begin the | | | current and the | operational protocol, | | | applicable evaluation | subject to local policy. | | | permits the relationship. | | +----------+---------------------------+--------------------------+ | RESTRICT | The relationship is | Gateway MUST apply every | | | eligible only under | mandatory restriction it | | | stated controls. | accepts as a basis for | | | | execution. | +----------+---------------------------+--------------------------+ | DENY | A prohibition, invalid | Gateway MUST NOT begin | | | lifecycle state, failed | the protected | | | proof, or required- | operational protocol. | | | evidence failure applies. | | +----------+---------------------------+--------------------------+ | REVIEW | Higher-assurance, | Gateway MUST defer the | | | additional-source, or | protected operational | | | human evaluation is | protocol. | | | required. | | +----------+---------------------------+--------------------------+ Table 4 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. Tanase Expires 22 March 2027 [Page 18] Internet-Draft AIN Authoritative Resolution September 2026 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 vs. COSE), canonicalization, and format-level encoding of the State Proof are deferred to a future conformance profile, pending community feedback and evaluation of deployment security profiles. The design considerations explored during drafting of this version are retained non-normatively in Appendix C.1, as input to that future work; they do not constitute a stable interface. 10.7. State Proof Consumption and Controlled Session Establishment Atomic State Proof consumption, controlled-session establishment, idempotent retry handling, and consumption-receipt creation are significant security-relevant capabilities that this version does not standardize at the transport or persistence level (see Appendix A, “State Proof consumption”). The semantic requirements explored during drafting are retained non-normatively in Appendix C.2 as input to a future conformance profile. 11. Federated, Regional, Enterprise, and Sovereign Resolution This version confirms, at the level of the architectural model in Section 5, that AIN-WRP does not require a single global registry and that competent sources MAY be operated by independent organisations, sectors, regions, or sovereign infrastructures. The signed routing, discovery, and competence-delegation formats needed to standardize federated, RNO-mediated, and private or air-gapped resolution are deferred to a future revision. The design considerations explored during drafting of this version are retained non-normatively in Appendix C.3 and Appendix C.4, as input to that future work. 12. Caching, Invalidation, and Re-Evaluation Resolvers MAY cache signed results. Cache lifetime MUST NOT exceed the shortest applicable validity interval or policy limit. Negative caching SHOULD use a shorter lifetime than positive identity caching. Security-sensitive clients SHOULD revalidate when an AIN state, key, mandate, endpoint, competence record, restriction, or relevant configuration changes. A cached ACTIVE state MUST NOT be used after receipt of an authoritative invalidation event. Deployments unable to receive invalidations MUST use conservative expiration intervals appropriate to the operation's risk. Tanase Expires 22 March 2027 [Page 19] Internet-Draft AIN Authoritative Resolution September 2026 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. 13. Error Model HTTP APIs SHOULD use Problem Details for HTTP APIs [RFC9457]. Machine-readable error codes MUST distinguish identifier-format failure, unknown identity, lifecycle ineligibility, proof failure, replay, source failure, competence failure, endpoint-resolution failure, evidence conflict, and policy denial. +========================+=================+========================+ | Code | Typical HTTP | Meaning | | | status | | +========================+=================+========================+ | invalid_ain | 400 | Identifier is | | | | malformed or non- | | | | canonical. | +------------------------+-----------------+------------------------+ | ain_not_found | 404 | No authoritative | | | | record exists. | +------------------------+-----------------+------------------------+ | ain_suspended | 403 or 200 | Known identity is | | | (identity-only) | temporarily | | | | ineligible. | +------------------------+-----------------+------------------------+ | ain_revoked | 410 or 200 | Known identity is | | | (tombstone) | 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 | Tanase Expires 22 March 2027 [Page 20] Internet-Draft AIN Authoritative Resolution September 2026 | | | authoritative | | | | endpoint could not | | | | be established. | +------------------------+-----------------+------------------------+ | evidence_conflict | 409 | Competent evidence | | | | is contradictory and | | | | cannot be safely | | | | composed. | +------------------------+-----------------+------------------------+ | policy_denied | 403 | Applicable policy | | | | does not permit the | | | | relationship. | +------------------------+-----------------+------------------------+ | proof_expired | 410 | State Proof expired | | | | before successful | | | | consumption. | +------------------------+-----------------+------------------------+ | proof_revoked | 403 or 410 | State Proof was | | | | revoked before | | | | consumption. | +------------------------+-----------------+------------------------+ | proof_already_consumed | 409 | Proof was consumed | | | | and retry context is | | | | not equivalent. | +------------------------+-----------------+------------------------+ | idempotency_conflict | 409 | Idempotency key was | | | | previously used with | | | | different security- | | | | relevant parameters. | +------------------------+-----------------+------------------------+ | proof_context_mismatch | 403 | Participant, | | | | audience, endpoint, | | | | operation, or | | | | channel binding does | | | | not match. | +------------------------+-----------------+------------------------+ | session_commit_failed | 503 | Atomic operation did | | | | not commit and no | | | | session was | | | | established. | +------------------------+-----------------+------------------------+ Table 5 Alternative statuses for identity-only and operational endpoints are intentional. A future revision is expected to define separate conformance profiles with exact mappings. Tanase Expires 22 March 2027 [Page 21] Internet-Draft AIN Authoritative Resolution September 2026 A profile MAY expose the more specific proof-consumption error codes above. Where it does not, replay_detected is the generic code for reuse of consumed proof material. For profiles exposing the specific codes, an idempotent retry using the same key and equivalent security-relevant context returns the original successful result; reuse of the same idempotency key with different security-relevant context is idempotency_conflict; reuse of a consumed proof with a different idempotency key is proof_already_consumed or the generic replay_detected; and a participant, audience, endpoint, operation, or channel mismatch detected before successful consumption is proof_context_mismatch. Illustrative Problem Details response (the URI is synthetic; normative problem types are deferred to a later profile): { "type": "https://registry.example/problems/ain-not-found", "title": "AIN not found", "status": 404, "code": "ain_not_found", "detail": "No authoritative record exists for the supplied AIN." } 14. Security Considerations * An AIN is public and MUST NOT be treated as a bearer credential. * All authoritative resolution traffic MUST use TLS with server authentication and certificate validation appropriate to the resolver authority. Mutual TLS MAY be required by a higher- assurance profile. * Security-relevant responses SHOULD be signed or obtained through a mutually authenticated channel. * Relying parties MUST validate source competence in addition to signature validity. * Agent-supplied endpoint hints MUST NOT override authoritative endpoint resolution where that resolution is required. * Challenge nonces and proof identifiers MUST be unpredictable, time-limited, audience-bound where applicable, and protected against replay. * Key rotation and revocation MUST be represented without reassigning the AIN. Tanase Expires 22 March 2027 [Page 22] Internet-Draft AIN Authoritative Resolution September 2026 * 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. 15. Privacy Considerations A persistent agent identifier enables correlation across services. Public responses MUST minimise personal data and SHOULD expose only information necessary for verification. Operator details SHOULD use organisational identifiers or resolvable references rather than personal contact information unless disclosure is necessary and lawful. Resolvers SHOULD support tiered projections for public, authenticated, and authorised callers. Incident evidence, private mandates, internal supply-chain details, sensitive policy constraints, and security telemetry MUST NOT be included in public responses by default. Tanase Expires 22 March 2027 [Page 23] Internet-Draft AIN Authoritative Resolution September 2026 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. 16. Deployment Examples (Non-Normative) 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 and do not replace the AIN as the persistent identity anchor within 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. Tanase Expires 22 March 2027 [Page 24] Internet-Draft AIN Authoritative Resolution September 2026 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 is not itself identified by an AIN. Rather, it acts as a relying party that consumes AIN- based assurance about the initiating agent. What the counterparty gains beyond validation of an API credential is independent, cross- organisational verification of the persistent agent identity, its current operator binding, and applicable mandate assertions — verification that does not depend on the agent's own platform self- asserting these facts, and that reflects a restriction issued by a source outside the counterparty's own trust boundary before the interaction is admitted. 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, but they do not replace the AIN as the persistent identity anchor within AIN-WRP. The financial institution remains responsible for payment authorization, regulatory controls, transaction screening, and execution. AIN-WRP provides authoritative identity resolution and pre-interaction verification; it does not execute or approve the payment itself. Tanase Expires 22 March 2027 [Page 25] Internet-Draft AIN Authoritative Resolution September 2026 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. Such identifiers MAY be associated with an AIN and used as supporting evidence without replacing the AIN as the persistent identity anchor for AIN-WRP interactions. Cross-domain verification may expose only the AIN and the minimum signed, time-limited result or selected authoritative assertions required through an authorised boundary. The same AIN identity semantics can therefore support public, enterprise, federated, private, and sovereign deployments without requiring central storage or disclosure of all underlying identity data. 17. IANA Considerations This document requests no IANA action at this time. The ain well-known URI suffix used in the resolution endpoint (Section 7.1) is provisional. Registration of this suffix under the Well-Known URIs registry established by [RFC8615] will be requested in a later revision, once the resolution mechanism and its security properties are sufficiently stable. The registration request will specify: the URI suffix (ain); the change controller (IETF or the authors pending WG adoption); the applicable specification (this document); and security considerations as required by [RFC8615]. 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. 18. 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. Tanase Expires 22 March 2027 [Page 26] Internet-Draft AIN Authoritative Resolution September 2026 +====================================+=======================+ | Capability | Current | | | classification | +====================================+=======================+ | Public verification and machine- | Implemented in a | | readable resolution | development workspace | +------------------------------------+-----------------------+ | Web-resolvable AIN and JSON-LD | Implemented in a | | | development workspace | +------------------------------------+-----------------------+ | Lifecycle enforcement and JWKS | Implemented in a | | discovery | development workspace | +------------------------------------+-----------------------+ | Single-agent challenge-response, | Implemented in a | | signed assertions, replay state | development workspace | +------------------------------------+-----------------------+ | Public incident intake and scoped | Implemented in a | | case handling | development workspace | +------------------------------------+-----------------------+ | Uniform lifecycle semantics across | Partially implemented | | public endpoints | | +------------------------------------+-----------------------+ | Independent dual-domain resolution | Proposed | | and competence validation | | +------------------------------------+-----------------------+ | RNO-to-RNO signed resolution | Proposed | | protocol | | +------------------------------------+-----------------------+ | Bilateral State Proof and | Proposed | | restriction composition | | +------------------------------------+-----------------------+ | Atomic proof consumption, | Not implemented end | | controlled-session creation, | to end | | idempotent retry, and receipt | | +------------------------------------+-----------------------+ | Continuous gateway re-evaluation | Proposed | +------------------------------------+-----------------------+ Table 6 19. Relationship to Other Work Tanase Expires 22 March 2027 [Page 27] Internet-Draft AIN Authoritative Resolution September 2026 19.1. OpenID Connect Agent Identity Profiles OpenID Connect agent-identity profiles can carry agent-specific claims in ID Tokens. AIN-WRP addresses a different but complementary layer: persistent authoritative resolution and relationship-specific verification that is not limited to one identity provider or one token session. An AIN MAY be carried as an OpenID Connect claim, and an OpenID Connect token MAY be evidence consumed during AIN-WRP validation. 19.2. OAuth, WIMSE, and Agent Authentication/Authorization OAuth-family mechanisms, workload-identity systems, and emerging AI- agent authentication and authorization profiles provide credentials, delegation, scopes, token exchange, channel binding, and resource authorization. AIN-WRP does not redefine those mechanisms. It addresses the authoritative resolution of persistent agent identity and other relationship-relevant assertions, including the competence and provenance of the sources from which those assertions are obtained. 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. Tanase Expires 22 March 2027 [Page 28] Internet-Draft AIN Authoritative Resolution September 2026 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; [AI-AUTH] applies the WIMSE architecture and the OAuth 2.0 family of specifications to agent authentication and authorization; and [APS] binds a cryptographic agent passport to a separately signed principal binding and to delegation chains that narrow monotonically, producing signed action receipts. AIN-WRP shares this premise but differs in its principal contribution: an authoritative, cross-administrative-domain resolution and correlation step, performed by sources independently competent for the identity, lifecycle, and relationship in question, prior to admission at the execution-plane protocol. Where such efforts define credential formats that bind identity, delegation, and authorization constraints together, AIN-WRP treats persistent identity resolution as a distinct trust-plane operation that such credentials, and other delegation or authorization artefacts, MAY be validated against, rather than as a data format for carrying them. Commercial and open-source implementations addressing adjacent problems, including agent identity and governance platforms and agent-guardrail tooling, provide credential lifecycle management, scoped authorization, and runtime policy enforcement within a single Tanase Expires 22 March 2027 [Page 29] Internet-Draft AIN Authoritative Resolution September 2026 operator's infrastructure or a single integration surface. AIN-WRP does not compete with these functions; a deployment MAY use such a platform as a competent source, or as the gateway that consumes a Pre-Interaction Trust State. AIN-WRP's distinguishing scope is authoritative resolution and pre-interaction verification across independent administrative domains that do not share a common operator, registry, or platform. Where a future revision of this document, or a companion profile, can express identical semantics using a contemporaneous specification's data format, convergence is preferred to parallel formats. This section will be updated as those specifications reach further maturity. 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. An AIN is a persistent lookup anchor within a coordinated namespace. It enables a relying party to request current identity-related and relationship-specific assertions while preserving the distinction between the identifier, the current controller or operator, the presented credential, the resolved endpoint, delegated authority, lifecycle state, and operational eligibility. A URI can identify or locate a resource, and an AIN can be represented through a Web-resolvable URI. However, an operational endpoint URI is not necessarily a persistent digital-agent identity; endpoints can change, expire, or be reassigned without requiring the underlying registered identity to change. A DID can provide a resolvable identifier and cryptographic verification material under an applicable DID method. A SPIFFE ID can identify a workload within a SPIFFE trust domain and can be used with a workload credential. Such identifiers and credentials MAY be associated with an AIN or used as evidence during AIN-WRP validation. Tanase Expires 22 March 2027 [Page 30] Internet-Draft AIN Authoritative Resolution September 2026 Control of a URI, DID, SPIFFE ID, certificate, key, or token does not, by itself, establish every assertion required for a pre- interaction decision. In particular, it does not necessarily establish the current lifecycle state, operator binding, mandate, authoritative endpoint, source competence, applicable restrictions, or cross-domain operational eligibility of the identified agent. Conversely, possession or resolution of an AIN does not authenticate the presenter and does not authorise an operation; authentication, proof of control, mandate validation, local authorization, and execution remain separate protocol functions. AIN-WRP therefore permits existing identifier and credential systems to be carried as resolved attributes, verification methods, or evidence. Its distinct function is to use a persistent lookup anchor to resolve and correlate current assertions from sources competent for those assertions across potentially independent administrative domains. The distinction is not that an AIN uses characters that other identifiers cannot express; the distinction is the persistence, non-reassignment, resolution, provenance, competence, lifecycle, and cross-domain correlation contract defined around the identifier. 20. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . Tanase Expires 22 March 2027 [Page 31] Internet-Draft AIN Authoritative Resolution September 2026 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9457] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, . 21. Informative References [SHARIF-OIDC] Sharif, R., "OpenID Connect Agent Identity Claims for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-sharif-openid-agent-identity-01, August 2026, . [AI-AUTH] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., and N. Steele, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, July 2026, . [APS] Pidlisnyi, T., "Agent Passport System (APS): Verifiable Agent Identity, Faceted Authority, and Signed Action Receipts", Work in Progress, Internet-Draft, draft- pidlisnyi-aps-03, July 2026, . [MCP] Model Context Protocol Project, "Model Context Protocol: Authorization and Protocol Specifications", Work in Progress. Tanase Expires 22 March 2027 [Page 32] Internet-Draft AIN Authoritative Resolution September 2026 [A2A] A2A Protocol Project, "Agent-to-Agent (A2A) Protocol: Interoperability Specification", Work in Progress. Appendix A. Open Design Decisions The State Proof serialization, federated/RNO routing, and State Proof consumption rows below correspond to material carried forward, non- normatively, in Appendix C. +===============+=================+===============================+ | Decision | Version-00 | Required before later | | | position | revision | +===============+=================+===============================+ | Canonical | Provisional/ | Publish a stable context or | | JSON-LD | example | select a neutral namespace. | | context | namespace only | | +---------------+-----------------+-------------------------------+ | Lifecycle | Identity and | Define conformance profiles | | HTTP mapping | operational | and exact status mapping. | | | endpoints | | | | distinguished | | +---------------+-----------------+-------------------------------+ | AIN checksum | Opaque registry | Decide whether syntax belongs | | | integrity field | in the core standard or an | | | | issuer profile. | +---------------+-----------------+-------------------------------+ | Competence | Semantic | Specify interoperable signed | | records | requirements | competence-record | | | defined | representation and validation | | | | rules. | +---------------+-----------------+-------------------------------+ | Federated/RNO | Architectural | Define signed routing, | | routing | model | discovery, and competence | | | | formats. | +---------------+-----------------+-------------------------------+ | State Proof | Semantic | Select serialization profile | | serialization | binding | guided by community feedback | | | requirements | and deployment security | | | defined; JOSE | profile; evaluate both | | | vs COSE open | options before standardizing. | +---------------+-----------------+-------------------------------+ | Invalidation/ | Normative | Define event/webhook or | | re-evaluation | semantics, | polling profiles and | | | transport open | freshness requirements. | +---------------+-----------------+-------------------------------+ | IANA | Well-known URI | Complete ain well-known URI | | registrations | suffix | registration per [RFC8615]; | | | registration | determine media type and | Tanase Expires 22 March 2027 [Page 33] Internet-Draft AIN Authoritative Resolution September 2026 | | intended before | extensibility registry needs. | | | publication | | +---------------+-----------------+-------------------------------+ | Document | Single | Evaluate separate core- | | split | version-00 | resolution and pre- | | | draft | interaction documents after | | | | community review. | +---------------+-----------------+-------------------------------+ | State Proof | Atomic security | Define endpoint, JOSE/COSE | | consumption | semantics | profile, receipt schema, | | | defined; | channel binding, and | | | transport and | conformance tests. | | | serialization | | | | open | | +---------------+-----------------+-------------------------------+ Table 7 Appendix B. Deferred Protocol Elements (Non-Normative, Target -01) This appendix is non-normative. It preserves, for continuity and for use in preparing the next revision, protocol elements that were drafted in earlier working versions of this document but whose normative status this version defers, as recorded in Appendix A. Nothing in this appendix creates a requirement on an implementation of draft-tanase-ain-authoritative-resolution-00. 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 or COSE serialization and does not itself constitute a normative requirement of this version. Tanase Expires 22 March 2027 [Page 34] Internet-Draft AIN Authoritative Resolution September 2026 | NOTE: The choice between JOSE ([RFC7515], [RFC7517], [RFC8037]) | and COSE serialization for State Proofs, and the selection of | | a canonicalization rule set, will be determined by a future | conformance profile. That choice | | 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 to the | | working group or mailing list 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. Tanase Expires 22 March 2027 [Page 35] Internet-Draft AIN Authoritative Resolution September 2026 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. Tanase Expires 22 March 2027 [Page 36] Internet-Draft AIN Authoritative Resolution September 2026 Implementations must ensure that concurrent attempts to consume the same proof cannot both succeed. The authoritative replay state must be shared by all gateway or proof-consumption instances that can accept the proof. An in-memory cache local to one process is not sufficient as the authoritative replay record. This version defines the security and transaction semantics of proof consumption. It does not standardize the transport endpoint, persistence technology, transaction API, receipt serialization, or JOSE or COSE proof profile. Those elements are to be defined by a future AIN-WRP conformance profile. +=============+========================+============================+ | Existing | Idempotency/ | Result | | proof state | context | | +=============+========================+============================+ | ISSUED | Valid | Atomically create session | | | | and receipt; mark CONSUMED | +-------------+------------------------+----------------------------+ | ISSUED | Transaction fails | Roll back; proof remains | | | before commit | ISSUED | +-------------+------------------------+----------------------------+ | CONSUMED | Same idempotency | Return the same session | | | key and equivalent | and receipt | | | context | | +-------------+------------------------+----------------------------+ | CONSUMED | Different key or | REPLAY_DETECTED; no new | | | context | session | +-------------+------------------------+----------------------------+ | EXPIRED | Any | Reject; no session | +-------------+------------------------+----------------------------+ | REVOKED | Any | Reject; no session | +-------------+------------------------+----------------------------+ Table 8 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. Tanase Expires 22 March 2027 [Page 37] Internet-Draft AIN Authoritative Resolution September 2026 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. Tanase Expires 22 March 2027 [Page 38] Internet-Draft AIN Authoritative Resolution September 2026 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 Tanase Expires 22 March 2027 [Page 39] Internet-Draft AIN Authoritative Resolution September 2026 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 Tanase Expires 22 March 2027 [Page 40] Internet-Draft AIN Authoritative Resolution September 2026 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. Author's Address Elena Tănase AIDAXIA Ltd. United Kingdom Email: office@aidaxia.ai URI: https://aidaxia.ai Tanase Expires 22 March 2027 [Page 41]