Independent Submission C. Hood Internet-Draft Nomotic, Inc. Intended status: Informational 30 October 2026 Expires: 3 May 2027 AGTP Binding to the Legal Entity Identifier (LEI and vLEI) draft-hood-agtp-lei-01 Abstract The Legal Entity Identifier (LEI), defined by ISO 17442 and operated under the global governance of the Global Legal Entity Identifier Foundation (GLEIF), is the internationally recognized identifier for legal entities in financial transactions and regulatory reporting. The verifiable LEI (vLEI), built on Key Event Receipt Infrastructure (KERI) and Authentic Chained Data Containers (ACDC), extends the LEI into the digital trust ecosystem with cryptographically verifiable credentials issued through Qualified vLEI Issuers (QVIs). This document specifies how the Agent Transfer Protocol (AGTP) binds to the LEI and vLEI infrastructure. It defines how an LEI is carried as the owner of an agent in its Agent Genesis and Identity Document, how a vLEI Legal Entity credential composes with AGTP-CERT to establish institutional identity at the wire, how a new verification path (vlei-anchored) is added to AGTP-TRUST for KERI-based verification, and how vLEI Role Credentials (OOR, ECR, AUTH) express the human authorization chain that produced an agent. The four layers compose: AGTP provides the agent identity substrate, the LEI provides the institutional identity, the vLEI provides cryptographic verification of that institutional identity, and the vLEI Role Credentials provide the authorization chain from the legal entity through human officers to the agent. This document positions financial institutions, regulated entities, and other LEI holders to deploy agents with verifiable institutional identity from day one. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. Hood Expires 3 May 2027 [Page 1] Internet-Draft AGTP-LEI October 2026 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 3 May 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Owner-ID Binding . . . . . . . . . . . . . . . . . . . . . . 6 3.1. LEI as Owner-ID . . . . . . . . . . . . . . . . . . . . . 6 3.2. Owner-ID Examples . . . . . . . . . . . . . . . . . . . . 6 3.3. Composition with Domain-Anchored Identifiers . . . . . . 7 3.4. The Verification Ladder . . . . . . . . . . . . . . . . . 7 4. Certificate Composition . . . . . . . . . . . . . . . . . . . 9 4.1. vLEI Legal Entity Credential in AGTP-CERT . . . . . . . . 9 4.2. Extension Field Schema . . . . . . . . . . . . . . . . . 9 4.3. Verification Workflow . . . . . . . . . . . . . . . . . . 11 5. Verification Path . . . . . . . . . . . . . . . . . . . . . . 11 5.1. The vlei-anchored Verification Path . . . . . . . . . . . 11 5.2. Verification Procedure . . . . . . . . . . . . . . . . . 11 5.3. Composition with Other Verification Paths . . . . . . . . 12 6. Authorization Chain . . . . . . . . . . . . . . . . . . . . . 12 6.1. Human Authorization Through vLEI Role Credentials . . . . 12 6.2. Agent Deployment Authorization . . . . . . . . . . . . . 13 6.3. Carriage in AGTP . . . . . . . . . . . . . . . . . . . . 13 6.4. AUTH Credential as the Delegation Sequence Origin . . . . 14 6.5. Use in Authority Decisions . . . . . . . . . . . . . . . 15 7. Composition with Other AGTP Bindings . . . . . . . . . . . . 15 7.1. Composition with AGTP-MERCHANT-IDENTITY . . . . . . . . . 15 7.2. Composition with AGTP-TRUST Credit Rating Providers . . . 16 7.3. Composition with AGTP-Presence . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. LEI Verification Independence . . . . . . . . . . . . . . 16 Hood Expires 3 May 2027 [Page 2] Internet-Draft AGTP-LEI October 2026 8.2. GLEIF Resolution Unavailable . . . . . . . . . . . . . . 16 8.3. vLEI Credential Revocation . . . . . . . . . . . . . . . 17 8.4. QVI Compromise . . . . . . . . . . . . . . . . . . . . . 17 8.5. Role Credential Misuse . . . . . . . . . . . . . . . . . 17 8.6. Cross-Jurisdictional Considerations . . . . . . . . . . . 17 8.7. Privacy of LEI Lookups . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. Verification Path Value . . . . . . . . . . . . . . . . . 18 9.2. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. Reason Tokens . . . . . . . . . . . . . . . . . . . . . . 18 9.4. AGTP-CERT Extension Field . . . . . . . . . . . . . . . . 18 10. Implementation Considerations . . . . . . . . . . . . . . . . 19 10.1. Path to Pilot Deployment . . . . . . . . . . . . . . . . 19 10.2. Adoption Considerations for Regulated Industries . . . . 19 11. Engagement with GLEIF and the vLEI Ecosystem . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Changes from v00 . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Legal Entity Identifier is the de facto international standard for identifying legal entities in financial transactions. Defined by [ISO17442], the LEI is a 20-character alphanumeric code uniquely identifying a legal entity participating in financial transactions. The Global Legal Entity Identifier Foundation operates the global LEI system as a nonprofit organization [GLEIF], with GLEIF acting as the root of trust for the LEI ecosystem. The LEI is operationally mature. Every regulated financial entity in G20 jurisdictions has or can obtain an LEI. Banking regulators, securities regulators, derivatives reporting requirements, anti-money laundering frameworks, and supply chain compliance regimes use the LEI as the canonical institutional identifier. The Financial Stability Board, the Basel Committee, the European Securities and Markets Authority, and the U.S. Securities and Exchange Commission all rely on LEI for entity identification in regulated reporting. The verifiable LEI extends this infrastructure into the digital trust ecosystem. The vLEI is a cryptographically verifiable credential issued by Qualified vLEI Issuers to legal entities, built on the Key Event Receipt Infrastructure [KERI] and the Authentic Chained Data Container specification [ACDC]. The vLEI Ecosystem Governance Framework [VLEI-EGF] defines the operational model with GLEIF as root of trust, QVIs as accredited credential issuers, and Legal Entities Hood Expires 3 May 2027 [Page 3] Internet-Draft AGTP-LEI October 2026 as credential holders. Three additional vLEI credential types extend institutional identity to the human authorization layer: the Official Organizational Role (OOR) credential per [ISO5009], the Engagement Context Role (ECR) credential, and the Authorization (AUTH) credential. For AGTP, the question is how an agent deployed by a regulated legal entity inherits the institutional identity verifiable through the vLEI infrastructure. The answer matters because financial regulators, banking compliance officers, and institutional risk managers ask the question Tom Roberts surfaced in conversation with major banks: "How do we know who is an agent, and on whose authority does it act?" The LEI answers the institutional half of that question. The vLEI provides cryptographic verification. This document specifies how AGTP composes with that infrastructure to answer the agent half. 1.1. Conventions and Terminology 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. This document uses terminology from [AGTP], [AGTP-IDENTIFIERS], [AGTP-TRUST], and [AGTP-CERT]. Selected additional terms from the LEI and vLEI infrastructure: LEI: Legal Entity Identifier. A 20-character alphanumeric code per [ISO17442] that uniquely identifies a legal entity. Issued by an LEI Issuer accredited by GLEIF. vLEI: verifiable Legal Entity Identifier. The cryptographically verifiable digital form of the LEI, issued as an ACDC credential through KERI infrastructure. Specified in [VLEI-EGF]. GLEIF: Global Legal Entity Identifier Foundation. The organization that operates the global LEI system and acts as the root of trust for the vLEI ecosystem. QVI: Qualified vLEI Issuer. An organization accredited by GLEIF to issue vLEI credentials to legal entities. KERI: Key Event Receipt Infrastructure [KERI]. The cryptographic identifier and key management protocol that underlies vLEI. AID: Autonomic Identifier. A KERI self-certifying identifier bound Hood Expires 3 May 2027 [Page 4] Internet-Draft AGTP-LEI October 2026 to a cryptographic key pair, used as the durable identifier for participants in the vLEI ecosystem. ACDC: Authentic Chained Data Container. The credential format used for vLEI credentials, supporting chained issuance from GLEIF through QVIs to legal entities. OOR Credential: Official Organizational Role vLEI credential. Issued by a Legal Entity (or QVI on its behalf) to a human officer in an ISO 5009 recognized role. ECR Credential: Engagement Context Role vLEI credential. Issued by a Legal Entity to a human in a contextual role for specific engagements. AUTH Credential: Authorization vLEI credential. Issued by a Legal Entity to authorize specific actions, typically chained from OOR or ECR credentials. 2. Scope This document specifies four composition surfaces between AGTP and the LEI/vLEI infrastructure: 1. How an LEI is carried as an agent's Owner-ID in its Genesis and Identity Document, providing institutional identification at the wire (Section 3). 2. How a vLEI Legal Entity credential composes with AGTP-CERT to provide cryptographic verification of institutional identity (Section 4). 3. How a new verification path (vlei-anchored) is added to AGTP- TRUST to support KERI-based verification of agent institutional identity (Section 5). 4. How vLEI Role Credentials (OOR, ECR, AUTH) express the human authorization chain that produced an agent, establishing accountability from the legal entity through human officers to the agent (Section 6). This document modifies none of the LEI standard, the vLEI Ecosystem Governance Framework, KERI, ACDC, or the existing AGTP specifications. It defines composition surfaces that allow agents deployed by LEI holders to carry verifiable institutional identity through the AGTP substrate. Hood Expires 3 May 2027 [Page 5] Internet-Draft AGTP-LEI October 2026 3. Owner-ID Binding 3.1. LEI as Owner-ID [AGTP-IDENTIFIERS] defines the Owner-ID as the identifier of the principal accountable for an agent's existence and operation, bound to the Agent-ID at registration, recorded as the owner_id field of the Agent Genesis ([AGTP]) and of the Agent Identity Document ([AGTP-IDDOC]), and resolved by a recipient from the Agent-ID of every request. Owner-ID rides in no request header; version 00 of this document showed it as one, and that form is withdrawn. For agents deployed by legal entities that hold an LEI, owner_id *MAY* carry the LEI directly: { "agent_id": "3a9f2c1d8b7e4a6f...", "owner_id": "lei:5493001KJTIIGC8Y1R12" } The lei: URI scheme prefix identifies the following string as an LEI per [ISO17442]. The 20-character LEI value follows. A verifier that resolves the Agent-ID to its Identity Document reads the LEI there, under the issuer's signature, and can resolve it through GLEIF's public LEI lookup service to retrieve the associated legal entity record. The Owner Identity Document of [AGTP-IDENTIFIERS] declares id_scheme: lei for such an owner. When owner_id carries an LEI, the agent's institutional identity is verifiable against the public LEI registry without requiring additional infrastructure. This composes with any AGTP verification path: an agent at Trust Tier 1 with dns-anchored verification still benefits from an LEI owner because the institutional identity is publicly verifiable independent of AGTP's verification mechanism. 3.2. Owner-ID Examples A bank deploying an agent for customer service, an asset management firm deploying a trading agent, and a regulated insurance entity deploying a claims processing agent each carry the LEI in the Identity Document the agent's Agent-ID resolves to: { "owner_id": "lei:5299002IZHCT9HFFP822" } { "owner_id": "lei:549300JR9TDP4FYQGW40" } { "owner_id": "lei:213800ULZN5RMQQUTM63" } In each case, the owner field communicates institutional identity verifiable against public infrastructure. Verifiers can apply institutional context (regulated entity, jurisdiction, parent Hood Expires 3 May 2027 [Page 6] Internet-Draft AGTP-LEI October 2026 relationships) to authority decisions without consulting any AGTP operator's private records. On responses, [AGTP] permits the server to surface the responding agent's owner in the Owner-ID response header; the value is the same lei: string. 3.3. Composition with Domain-Anchored Identifiers The LEI owner composes with the domain-anchored owner forms defined in [AGTP-IDENTIFIERS]. The Identity Document carries one owner_id; the Owner Identity Document it resolves to *MAY* record both the LEI as the primary institutional identifier and a domain as a secondary operational identifier: { "id_scheme": "lei", "owner_id": "lei:5493001KJTIIGC8Y1R12", "owner_id_secondary": "owner:acmebank.com", "owner_legal_name": "Acme Bank, N.A." } Verifiers resolving the primary identifier against GLEIF can verify the institutional identity. Verifiers operating only against domain- anchored identifiers can use the secondary form. The two identifiers refer to the same legal entity but provide different verification paths. 3.4. The Verification Ladder Three rungs of institutional verification are available to a relying party, each proving more and failing differently. A relying party *MUST* state, in the Attribution-Record's evaluation fields or in its policy, which rung it applied. Hood Expires 3 May 2027 [Page 7] Internet-Draft AGTP-LEI October 2026 +=============+===============+================+==================+ | Rung | What it | How it is | On failure | | | proves | verified | | +=============+===============+================+==================+ | Out-of-band | That the | By the relying | Outside AGTP; | | KYB | relying | institution's | the agent is | | (inherited) | institution | own process, | treated per the | | | has itself | outside AGTP | relying party's | | | onboarded the | | policy for | | | counterparty | | unknown | | | | | counterparties | +-------------+---------------+----------------+------------------+ | LEI in | That the | Resolve Agent- | Mismatch or | | owner_id | agent's | ID to the | lapsed LEI: | | | issuer | Identity | invalid; GLEIF | | | recorded a | Document, | unreachable: | | | specific | verify its | indeterminate | | | legal entity | signature, | with | | | as owner, and | resolve the | missing_input: | | | that the | LEI through | lei-resolution, | | | entity exists | GLEIF | and the relying | | | in the GLEIF | | party *MAY* fall | | | registry with | | back to cached | | | the recorded | | registry data no | | | status | | older than its | | | | | stated bound | +-------------+---------------+----------------+------------------+ | vLEI | That the | KERI signature | Chain or | | binding | legal entity, | chain, QVI | revocation | | | through a QVI | accreditation, | failure: | | | accredited by | revocation via | invalid; KEL or | | | GLEIF, holds | the KEL | OOBI | | | a verifiable | (Section 5) | unreachable: | | | credential | | indeterminate | | | bound to this | | with | | | Agent-ID, and | | missing_input: | | | (with role | | vlei-resolution | | | credentials) | | | | | which human | | | | | in which role | | | | | authorized | | | | | the agent | | | +-------------+---------------+----------------+------------------+ Table 1: Institutional Verification Ladder Hood Expires 3 May 2027 [Page 8] Internet-Draft AGTP-LEI October 2026 The outcomes use the three-outcome vocabulary of [AGTP] (valid, invalid, indeterminate); an indeterminate rung is never promoted to valid by policy, and a relying party that accepts an indeterminate rung records that it did. 4. Certificate Composition 4.1. vLEI Legal Entity Credential in AGTP-CERT AGTP-CERT specifies an X.509 v3 certificate extension carrying agent- governance-specific fields. This binding defines an extension mechanism for carrying or referencing a vLEI Legal Entity credential within the AGTP-CERT structure. The composition can take two forms: *Inline vLEI Credential.* The AGTP-CERT extension carries the vLEI Legal Entity ACDC credential directly as an embedded field. This provides offline verification: the vLEI credential is available to the verifier without requiring KERI infrastructure access. *Referenced vLEI Credential.* The AGTP-CERT extension carries a reference to the vLEI credential, typically as a KERI AID and an OOBI (Out-Of-Band Introduction) hint indicating where to retrieve the credential and its associated KEL (Key Event Log) for verification. Implementations *MAY* use either form. The inline form is preferred for high-volume agent deployments where verification latency matters. The referenced form is preferred where vLEI credentials are managed through dedicated KERI infrastructure and AGTP-CERT issuance is decoupled from vLEI credential lifecycle. 4.2. Extension Field Schema The AGTP-CERT extension carries a new field for vLEI composition. The schema is defined once and supports both the basic case (Legal Entity vLEI only) and the extended case (Legal Entity vLEI plus a chain of Role Credentials per Section 6): Hood Expires 3 May 2027 [Page 9] Internet-Draft AGTP-LEI October 2026 vLEIBinding ::= SEQUENCE { bindingType VLEIBindingType, leiCode PrintableString (SIZE(20)), legalEntityCredential OCTET STRING OPTIONAL, legalEntityAID PrintableString OPTIONAL, roleCredentialChain SEQUENCE OF RoleCredential OPTIONAL, oobiHint IA5String OPTIONAL } VLEIBindingType ::= ENUMERATED { inline (0), referenced (1) } RoleCredential ::= SEQUENCE { credentialType RoleCredentialType, credentialData OCTET STRING OPTIONAL, credentialAID PrintableString OPTIONAL } RoleCredentialType ::= ENUMERATED { oor (0), ecr (1), auth (2) } The leiCode field is *REQUIRED* in all cases and carries the 20-character LEI value, providing fast verification without requiring credential parsing. When bindingType is inline, the legalEntityCredential field *MUST* be present and *MUST* carry the vLEI Legal Entity ACDC credential. The roleCredentialChain *MAY* also be present carrying inline credentialData for each role credential. When bindingType is referenced, the legalEntityAID field *MUST* be present and the oobiHint field *SHOULD* be present indicating where to retrieve the KEL for verification. The roleCredentialChain *MAY* also be present carrying credentialAID references for each role credential. The roleCredentialChain is *OPTIONAL* in all cases. When absent, the binding establishes institutional identity through the Legal Entity vLEI alone. When present, it additionally carries the human authorization chain per Section 6. Hood Expires 3 May 2027 [Page 10] Internet-Draft AGTP-LEI October 2026 4.3. Verification Workflow A verifier processing an AGTP-CERT with a vLEI Binding extension proceeds as follows: 1. Extract the leiCode and confirm it matches the owner_id LEI value (per Section 3). 2. If bindingType is inline, parse the embedded legalEntityCredential and verify its signature chain through QVI to GLEIF root of trust per [VLEI-EGF]. 3. If bindingType is referenced, resolve the legalEntityAID through the oobiHint to retrieve the vLEI credential and KEL. Verify the key event log to establish current key state, then verify the credential signature chain. 4. Verify that the vLEI credential issuer is an accredited QVI per GLEIF's QVI registry. 5. If a roleCredentialChain is present, verify each credential in the chain through KERI signature verification per Section 6. 6. Apply the verified institutional identity (and the verified role credential chain, if present) to authority decisions per local policy. 5. Verification Path 5.1. The vlei-anchored Verification Path AGTP-TRUST defines verification paths (dns-anchored, log-anchored, hybrid, org-asserted) that specify the evidence mechanism backing a Trust Tier 1 assignment. This document defines a new verification path value: verification_path: vlei-anchored A Tier 1 agent with vlei-anchored verification path has its institutional identity anchored in the vLEI infrastructure, where the other Tier 1 paths anchor in DNS ownership or transparency logs. The verification mechanism relies on KERI key event verification and the vLEI Ecosystem Governance Framework. 5.2. Verification Procedure Verifying a vlei-anchored Tier 1 agent proceeds as follows: Hood Expires 3 May 2027 [Page 11] Internet-Draft AGTP-LEI October 2026 1. Resolve the Agent-ID to its Identity Document, read the LEI in owner_id, and retrieve the legal entity record from GLEIF. 2. Retrieve the vLEI Legal Entity credential, either inline from AGTP-CERT or via KERI AID resolution. 3. Verify the credential's KERI signature chain through the QVI that issued it, terminating at the GLEIF root of trust. 4. Verify that the QVI is currently accredited per GLEIF's QVI registry, and that the credential is still in good standing. 5. If the agent carries vLEI Role Credentials (OOR, ECR, AUTH) per Section 6, verify the credential chain from the Legal Entity vLEI through the role credentials. 6. Confirm institutional identity matches the LEI carried in owner_id and in the AGTP-CERT extension. 5.3. Composition with Other Verification Paths The vlei-anchored path *MAY* compose with other verification paths in a hybrid model. An agent might carry both DNS-anchored verification (proving domain control) and vLEI-anchored verification (proving institutional identity). The two are complementary: * DNS-anchored verification proves the agent is deployed at a domain the institution controls. * vLEI-anchored verification proves the institution is a regulated legal entity with cryptographic identity through GLEIF. Verifiers *MAY* require both for Tier 1 acceptance in regulated contexts. The compound verification path is represented as: verification_path: hybrid verification_evidence: ["dns-anchored", "vlei-anchored"] 6. Authorization Chain 6.1. Human Authorization Through vLEI Role Credentials The vLEI ecosystem extends institutional identity to human authorization through three credential types. These credentials provide the chain showing which human, in which role, authorized the deployment and operation of an agent. Hood Expires 3 May 2027 [Page 12] Internet-Draft AGTP-LEI October 2026 *Official Organizational Role (OOR) credentials* are issued by a Legal Entity (or QVI on its behalf) to humans in roles recognized under [ISO5009]. OOR credentials prove that a named human holds an official role within the legal entity (such as Chief Executive Officer, Chief Information Officer, Chief Risk Officer). *Engagement Context Role (ECR) credentials* are issued by a Legal Entity to humans in contextual roles for specific engagements. ECR credentials prove that a named human is engaged with the legal entity in a specified capacity (such as Project Lead, Authorized Representative for Specific Engagement). *Authorization (AUTH) credentials* are issued by a Legal Entity to authorize specific actions. AUTH credentials are typically chained from OOR or ECR credentials, establishing that the authorizer held a valid role at the time of authorization. 6.2. Agent Deployment Authorization When an agent is deployed by a Legal Entity, the deployment authorization *MAY* be expressed as a chain of vLEI credentials: 1. The Legal Entity vLEI establishes the institutional identity. 2. An OOR or ECR credential establishes the human officer's role authorized to deploy agents (typically a CIO, CTO, or designated AI governance role). 3. An AUTH credential issued by that officer authorizes the specific agent deployment, identified by the agent's Canonical Agent-ID. The AUTH credential's authorization scope *MAY* include limits on the agent's Authority-Scope, operational domain, financial exposure limits, or other constraints meaningful to the institutional governance. 6.3. Carriage in AGTP The vLEI Role Credential chain authorizing an agent *MAY* be carried in the AGTP-CERT extension alongside the Legal Entity vLEI, or referenced via KERI AIDs and OOBI hints. The unified vLEIBinding schema defined in Section 4 accommodates the role credential chain through its optional roleCredentialChain field, which is a SEQUENCE OF the RoleCredential structure defined in the same schema. When the role credential chain is populated: Hood Expires 3 May 2027 [Page 13] Internet-Draft AGTP-LEI October 2026 * The roleCredentialChain field carries the chain of OOR/ECR/AUTH credentials linking the Legal Entity vLEI to the specific agent deployment authorization. * Each RoleCredential in the chain carries either inline credentialData (for inline binding type) or a credentialAID reference (for referenced binding type), matching the parent vLEIBinding's bindingType. * The RoleCredentialType enumeration identifies whether the credential is an OOR, ECR, or AUTH credential. Verifiers processing an agent with a role credential chain *MUST* verify each credential in the chain through KERI signature verification, establishing that the chain is intact from the Legal Entity vLEI through the role credentials to the AUTH credential authorizing the specific agent. 6.4. AUTH Credential as the Delegation Sequence Origin [AGTP] specifies the Delegation Sequence: the ordered hops of DELEGATE that produced a request, carried in Delegation-Chain. The origin hop's token *MAY* carry an authority field referencing an authority assertion, a signed statement from an authority source of the powers the delegator could delegate, and [AGTP] names the vLEI Role Credential chain as one of the two assertion forms it recognizes. This section specifies that use. The authority field of the origin hop carries the SAID of the AUTH credential that authorized the originating agent, prefixed vlei:. An ACDC's SAID is a content digest, so the field is the digest reference [AGTP] calls for; the credential itself is obtained from the roleCredentialChain of the agent's certificate (Section 4) or through OOBI resolution. A verifier asked by policy to require authority evidence *MUST*: 1. Resolve the authority reference to the AUTH credential and verify it, with the OOR or ECR credential it chains from, through KERI signature verification to the Legal Entity vLEI and the accredited QVI (Section 5). 2. Confirm that the Legal Entity's LEI equals the owner_id of the originating agent's Identity Document, so that the assertion's delegator is the agent's owner as [AGTP] requires. 3. Confirm that the AUTH credential names the originating agent's Canonical Agent-ID. Hood Expires 3 May 2027 [Page 14] Internet-Draft AGTP-LEI October 2026 4. Confirm that the origin hop's scope is within the limits the AUTH credential states. 5. Check the AUTH, OOR or ECR, and Legal Entity credentials for revocation through the KEL. A sequence whose origin hop carries no authority reference under such a policy is indeterminate with missing_input: authority; one whose AUTH credential fails step 2, 3, or 4 is invalid; one whose KEL cannot be reached is indeterminate with missing_input: vlei- resolution. A sequence that passes traces from the request through every DELEGATE hop to a named human signatory holding a verifiable role at the legal entity that owns the originating agent, which is the signed-mandate shape regulated relying parties ask for. 6.5. Use in Authority Decisions Authority decisions for agents with verified vLEI authorization chains *MAY* consider the role credential context. For example: * An AUTH credential issued under a CISO's OOR credential *MAY* authorize the agent for security-related operations within the institution's security policy domain. * An AUTH credential issued under a Trading Desk Head's ECR credential *MAY* authorize the agent for trading operations within specified position limits. * An AUTH credential issued under a Compliance Officer's OOR credential *MAY* authorize the agent for regulatory reporting operations. The mapping from role credential to authority decision is governance policy defined and outside this document. What is specified is the structural carriage of the credential chain so that governance policy can evaluate it. 7. Composition with Other AGTP Bindings 7.1. Composition with AGTP-MERCHANT-IDENTITY [AGTP-MERCHANT-IDENTITY] specifies how agents acquire merchant identifiers analogous to payment network Merchant IDs. For agents deployed by LEI-holding legal entities, the merchant identifier *SHOULD* include or reference the LEI of the deploying entity. This composition allows payment networks to verify both the institutional identity (via LEI/vLEI) and the merchant identity (via AGTP-MERCHANT- IDENTITY) of an agent transacting on behalf of a regulated entity. Hood Expires 3 May 2027 [Page 15] Internet-Draft AGTP-LEI October 2026 7.2. Composition with AGTP-TRUST Credit Rating Providers [AGTP-TRUST] positions credit bureau infrastructure (Experian, Equifax, TransUnion, and similar) as composable trust providers for agent trust scoring. For agents with vLEI-anchored verification, the institutional identity provides high-quality input to trust scoring: the LEI is a stable, regulated identifier that trust providers can correlate with their existing institutional credit and compliance records. Credit bureaus operating as agent trust providers *SHOULD* prefer LEI-anchored institutional identity over self-declared organizational identifiers when both are available. 7.3. Composition with AGTP-Presence AGTP-Presence partition dimensions include owner-domain for organizational scoping. For LEI-holding entities, the partition dimension *MAY* be expressed using the LEI directly: owner-domain: lei:5493001KJTIIGC8Y1R12 This provides cryptographically anchored organizational scoping for Presence overlays. Agents in the same LEI-scoped overlay are verifiably deployed by the same legal entity. 8. Security Considerations This document inherits the security considerations of [AGTP], [AGTP-TRUST], [AGTP-CERT], [VLEI-EGF], and [KERI]. This section addresses considerations specific to the composition. 8.1. LEI Verification Independence The LEI lookup against GLEIF's public registry *MUST* be performed independently of any AGTP infrastructure operator's claims. An agent operator that controls both the agent and a representation of LEI verification is in a conflict-of-interest position. Verifiers *SHOULD* consult GLEIF's authoritative LEI registry directly or through trusted intermediaries free of operational dependency on the agent being verified. 8.2. GLEIF Resolution Unavailable A relying party whose GLEIF or KEL resolution fails at verification time holds an indeterminate result on that rung of Section 3.4; policy cannot upgrade it to valid. Policies *MUST* state whether an indeterminate institutional rung is accepted for the operation class at hand and, if so, the maximum age of cached registry data that may stand in; the Attribution-Record records which case applied. An Hood Expires 3 May 2027 [Page 16] Internet-Draft AGTP-LEI October 2026 attacker who can make GLEIF unreachable to a relying party gains nothing beyond that relying party's own stated fallback. 8.3. vLEI Credential Revocation vLEI credentials can be revoked through KERI key event mechanisms. Verifiers *MUST* check current revocation status of vLEI credentials during verification; cached or previously verified state is insufficient. The KERI Key Event Log provides the authoritative revocation status. 8.4. QVI Compromise A compromised Qualified vLEI Issuer could issue fraudulent vLEI credentials. GLEIF maintains the authoritative QVI registry; verifiers *MUST* confirm that the issuing QVI is currently accredited at verification time. 8.5. Role Credential Misuse Role credentials (OOR, ECR, AUTH) bind authorization to specific humans in specific roles. If a role-holder leaves the legal entity or changes roles, the corresponding credentials *SHOULD* be revoked and re-issued as appropriate. Verifiers checking role-based authorization *MUST* verify credential freshness through the KEL. 8.6. Cross-Jurisdictional Considerations LEI is internationally recognized but legal entity recognition varies by jurisdiction. An LEI-anchored agent deployed by a regulated entity in one jurisdiction may operate cross-jurisdictionally. Verifiers *SHOULD* apply jurisdictional context to authority decisions where relevant, particularly for financial services, securities trading, and other regulated operations. 8.7. Privacy of LEI Lookups LEI lookups against GLEIF are public; querying an LEI reveals no operational intent. However, the pattern of LEI lookups may reveal which institutional counterparties an agent is investigating. Operators concerned about lookup patterns *MAY* cache LEI registry data locally to reduce query frequency. 9. IANA Considerations Hood Expires 3 May 2027 [Page 17] Internet-Draft AGTP-LEI October 2026 9.1. Verification Path Value This document requests registration of a new verification path value in the AGTP-TRUST verification path registry: +===============+=================================+===========+ | Value | Semantics | Reference | +===============+=================================+===========+ | vlei-anchored | Institutional identity verified | This | | | through vLEI infrastructure | document | +---------------+---------------------------------+-----------+ Table 2 9.2. URI Scheme This document requests registration of the lei: URI scheme for identifying LEI values: * Scheme name: lei * Scheme syntax: lei: followed by 20 alphanumeric characters per [ISO17442] * Status: Permanent * Reference: This document 9.3. Reason Tokens This document registers lei-resolution and vlei-resolution as missing_input values, and vlei: as an authority reference prefix, in the reason vocabulary of [AGTP]. 9.4. AGTP-CERT Extension Field This document requests registration of a new field in the AGTP-CERT extension namespace: * Field name: vLEIBinding * OID: TBD (to be assigned) * Description: Carries or references vLEI credentials for institutional identity * Reference: This document Hood Expires 3 May 2027 [Page 18] Internet-Draft AGTP-LEI October 2026 10. Implementation Considerations 10.1. Path to Pilot Deployment A legal entity considering pilot deployment of AGTP with vLEI binding follows roughly this path: 1. *Obtain LEI* (where none is held). LEI issuance is operated by accredited LEI Issuers. Most regulated financial entities and public companies already hold LEIs. 2. *Engage a Qualified vLEI Issuer.* QVIs are listed in GLEIF's public registry. The QVI issues the Legal Entity vLEI credential to the institution. 3. *Establish KERI infrastructure or KERI service relationship.* The institution either operates its own KERI infrastructure or uses a managed KERI service. 4. *Deploy AGTP-aware agents.* Agents are registered with owners carrying the LEI, AGTP-CERTs with vLEI Binding extensions, and verification paths set to vlei-anchored. 5. *Issue role credentials.* As needed, the institution issues OOR and ECR credentials to humans authorized to govern agent deployment, and AUTH credentials authorizing specific agents. 6. *Verify interoperability.* Test agent communication with counterparties to confirm that vLEI-anchored verification operates correctly across organizational boundaries. The path is staged so that institutions can adopt incrementally. LEI as owner is the smallest step; vLEI binding with KERI verification is the larger commitment. 10.2. Adoption Considerations for Regulated Industries For financial services institutions, the AGTP-LEI binding provides direct alignment with existing regulatory infrastructure. The LEI is already required for derivatives reporting under Dodd-Frank, EMIR, MiFID II, and similar regimes. Extending the LEI into AGTP agent identity provides regulators with continuity from existing entity reporting to new agent-mediated reporting. Hood Expires 3 May 2027 [Page 19] Internet-Draft AGTP-LEI October 2026 For payment networks (Visa, Mastercard, American Express, and similar), the AGTP-LEI binding composes with [AGTP-MERCHANT-IDENTITY] to provide both institutional identity (LEI) and merchant identity for agents transacting through payment infrastructure. The composition positions payment networks to extend their existing identification infrastructure to agent commerce. For supply chain and trade finance contexts, the LEI is already used in electronic bills of lading, ESG attestations, and customs declarations. AGTP-LEI extends this to agents acting on behalf of trading parties. 11. Engagement with GLEIF and the vLEI Ecosystem This document is published as an Internet-Draft to invite engagement from GLEIF, the Trust over IP Foundation, Qualified vLEI Issuers, LEI Issuers, and institutional adopters of the LEI infrastructure. The composition specified here builds on the operational maturity of the LEI ecosystem and extends it into the agent infrastructure layer. Feedback from GLEIF on the binding's alignment with the vLEI Ecosystem Governance Framework is particularly welcome. The binding is designed to compose with the vLEI ecosystem as specified and to modify none of it; if the binding requires adjustment to align with vLEI governance, this document will be revised accordingly. 12. References 12.1. Normative References [AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-10, 2026, . [AGTP-CERT] Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-04, 2026, . [AGTP-IDDOC] Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity- document-00, 2026, . Hood Expires 3 May 2027 [Page 20] Internet-Draft AGTP-LEI October 2026 [AGTP-IDENTIFIERS] Hood, C., "AGTP Identifier Stack and Attribution-Record", Work in Progress, Internet-Draft, draft-hood-agtp- identifiers-03, 2026, . [AGTP-TRUST] Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust- 03, 2026, . [ISO17442] "Financial services -- Legal entity identifier (LEI)", ISO 17442-1:2020, 2020, . [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, . 12.2. Informative References [ACDC] Trust over IP Foundation, "Authentic Chained Data Containers (ACDC)", n.d., . [AGTP-MERCHANT-IDENTITY] Hood, C., "AGTP Merchant Identity", Work in Progress, Internet-Draft, draft-hood-agtp-merchant-identity-03, 2026, . [GLEIF] "Global Legal Entity Identifier Foundation", n.d., . [ISO5009] "Financial services -- Official organizational roles", ISO 5009, n.d.. [KERI] Smith, S. M., "Key Event Receipt Infrastructure (KERI)", Work in Progress, Internet-Draft, draft-ssmith-keri, 2023, . Hood Expires 3 May 2027 [Page 21] Internet-Draft AGTP-LEI October 2026 [VLEI-EGF] Global Legal Entity Identifier Foundation, "verifiable LEI (vLEI) Ecosystem Governance Framework v4.0", 2026, . Appendix A. Acknowledgments The author thanks Tom Roberts for the strategic introduction to GLEIF and the broader LEI/vLEI ecosystem, and for the architectural framing that positions AGTP-LEI as a natural composition with the vLEI ecosystem. The author also acknowledges the foundational work of the GLEIF leadership, the KERI specification authors led by Samuel M. Smith, and the Trust over IP Foundation's stewardship of the vLEI ecosystem governance framework. Appendix B. Changes from v00 Version 01 is an alignment revision against draft-hood-independent- agtp-10. The vLEI binding schema, the vlei-anchored path, and the role credential chain are unchanged. * *Owner-ID is a document field.* Version 00 wrote Owner-ID: lei:... as a request header. The owner is the owner_id of the Agent Genesis and Identity Document, resolved from the Agent-ID, never transmitted on a request; the binding section and examples are rewritten, and the response-header form of [AGTP] is noted. * *AUTH credential as the Delegation Sequence origin* (Section 6.4): the origin hop's authority field carries the AUTH credential's SAID, with the five verification checks and the three-outcome results, as the vLEI form of the authority assertion [AGTP] recognizes. * *Verification ladder* (Section 3.4): out-of-band KYB, LEI in owner_id, vLEI binding, each with what it proves and how it fails; GLEIF-unavailable case added to Security Considerations. * Title changed to "AGTP Binding to the Legal Entity Identifier (LEI and vLEI)". * References made explicit and pinned: base -10, AGTP-IDENTIFIERS -03, AGTP-TRUST -03, AGTP-CERT -04, AGTP-MERCHANT-IDENTITY -03; AGTP-IDDOC added. House style pass. Author's Address Chris Hood Nomotic, Inc. Hood Expires 3 May 2027 [Page 22] Internet-Draft AGTP-LEI October 2026 Email: chris@nomotic.ai Hood Expires 3 May 2027 [Page 23]