Secure Asset Transfer Protocol N. Smith Internet-Draft Independent Intended status: Standards Track 4 September 2025 Expires: 8 March 2026 A SATP Core Binding for vLEI Identities draft-smith-satp-vlei-binding-latest Abstract The verifiable Legal Entity Identifier (vLEI) is a cryptographically verifiable extension of the LEI standard, designed to automate trust in organizational identity. Governed by the Global Legal Entity Identifier Foundation (GLEIF), the vLEI system uses Authentic Chained Data Containers (ACDCs), Self-Addressing Identifiers (SAIDs), and Key Event Receipt Infrastructure (KERI) to issue and verify credentials for legal entities and their authorized representatives. It enables secure, machine-readable identity assertions across financial, regulatory, and supply chain ecosystems, supporting role-based delegation and interoperability with decentralized trust frameworks. This specification defines vLEI for verifiable gateway operator identities and cryptographically links the gateway operator identity to the gateway identity. Thus SATP core lock assertions are cryptographically linked to gateway operator identities. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://nedmsmith.github.io/draft-smith-satp-vlei-binding/draft- smith-satp-vlei-binding.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-smith-satp- vlei-binding/. Discussion of this document takes place on the Secure Asset Transfer Protocol Working Group mailing list (mailto:sat@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sat/. Subscribe at https://www.ietf.org/mailman/listinfo/sat/. Source for this draft and an issue tracker can be found at https://github.com/nedmsmith/draft-smith-satp-vlei-binding. 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/. 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 8 March 2026. Copyright Notice Copyright (c) 2025 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 2. Conventions and Definitions 3. Architecture 3.1. SATP Messages Containing vLEI Credentials 3.1.1. LegalEntityIdentityvLEICredential Credentials 3.1.2. LegalEntityEngagementContextRolevLEICredential Credentials 3.1.3. OfficialOrganizationalRolevLEICredential Credentials 3.1.4. Key Structures 3.2. SATP Message Wrapper Schema 3.3. vLEI Media Types 3.4. Example SATP Credential Payload 4. Identities 4.1. Identity Binding 5. Verification of vLEI Payloads 6. Security Considerations 7. IANA Considerations 7.1. Media Type Registration: application/acdc+json 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Author's Address 1. Introduction The SATP architecture [I-D.ietf-satp-architecture] defines an interoperability architecture for interconnection between networks or systems that anticipates a secure asset transfer protocol that satisfies security, privacy, atomicity and liveliness requirements in the transfer of assets. The SATP core protocol [I-D.ietf-satp-core] is a protocol for exchanging digital assets that ensures the state of the asset is preserved across inter-domain transfers. It is an extensible protocol where fields containing identity and payload values that are not defined by SATP core may be defined by companion specifications. This specification defines a SATP core protocol binding for Verifiable Legal Entity Identifiers (vLEI) [ISO17442-3] used to identify SATP gateways and the organizations that operate them. In some use cases, the assets being transferred have legal considerations such that officers of the organization are expected to authorize digital asset transfers. This specification details the various vLEI credentials needed and how to integrate them with SATP core messages. SATP core message binding anticipates use of a message wrapper that uses media type [STD91] and content format [RFC7252] identifiers to facilitate interoperability with vLEI and other credential types. 2. Conventions and Definitions 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. Architecture The SATP core protocol [I-D.ietf-satp-core] defines several extensible protocol fields that contain identity and other values not defined by SATP core. To facilitate interoperability these fields SHOULD contain a media type [STD91] or content format [RFC7252] wrapper. This specation requests IANA assignment of media type and content format identifiers for vLEIs which are serialized as Composable Event Streaming Representation (CESR) [CESR-Spec] objects in JSON format. See Section 7. 3.1. SATP Messages Containing vLEI Credentials The following SATP messages are extended to contain vLEI credentials: +=+====================================+==============================================+ |#|SATP Message |Credential Type | +=+====================================+==============================================+ |1|verifiedOriginatorEntityId, |LegalEntityvLEICredential | | |verifiedBeneficiaryEntityId, | | | |senderGatewayOwnerId, | | | |receiverGatewayOwnerId | | +-+------------------------------------+----------------------------------------------+ |2|senderGatewayId, recipientGatewayId,|LegalEntityEngagementContextRolevLEICredential| | |senderGatewayNetworkId, | | | |recipientGatewayNetworkId | | +-+------------------------------------+----------------------------------------------+ |3|assetControllerCredential, |LegalEntityvLEICredential, | | |lockEvidenceIssuerCredential, |OfficialOrganizationalRolevLEICredential, | | |commitAuthorizingCredential |LegalEntityEngagementContextRolevLEICredential| +-+------------------------------------+----------------------------------------------+ |4|originatorPubkey, beneficiaryPubkey,|JOSE or COSE Key | | |senderGatewaySignaturePublicKey, | | | |receiverGatewaySignaturePublicKey, | | | |senderGatewayDeviceIdentityPubkey, | | | |receiverGatewayDeviceIdentityPubkey,| | | |lockEvidenceVerificationKey, | | | |commitVerificationKey, | | | |postCommitSecureChannelKey | | +-+------------------------------------+----------------------------------------------+ Table 1: SATP messages containing vLEI and other credentials The SATP Messages in row 4 of Table 1 SHALL be a JSON Web Key as defined by [RFC7517] or a COSE Key as defined by [STD96]. 3.1.1. LegalEntityIdentityvLEICredential Credentials The SATP Messages in row 1 of Table 1 SHALL be a LegalEntityvLEICredential as defined by the LEvLEIC (https://github.com/GLEIF-IT/vLEI-schema/blob/main/legal-entity-vLEI- credential.json) schema. These messages are realized using a Legal Entity vLEI Credential (LEvLEIC) because these message identify legal entities. Gateway owner identities area form of legal entity as they identify the owner of a gateway rather than the gateway itself. 3.1.2. LegalEntityEngagementContextRolevLEICredential Credentials The SATP Messages in row 2 of Table 1 SHALL be a LegalEntityEngagementContextRolevLEICredential as defined by the LEECRvLEIC (https://github.com/GLEIF-IT/vLEI-schema/blob/main/legal- entity-engagement-context-role-vLEI-credential.json) schema. These messages are realized using a Legal Entity Engagement Context Role vLEI Credential (LEECRvLEIC) because these message identify the gateways and hosts within the respective networks involved in transferring digital assets. 3.1.3. OfficialOrganizationalRolevLEICredential Credentials The SATP Messages in row 3 of Table 1 SHALL be one of a LegalEntityvLEICredential, LegalEntityEngagementContextRolevLEICredential, or OfficialOrganizationalRolevLEICredential as defined by the LEvLEIC (https://github.com/GLEIF-IT/vLEI-schema/blob/main/legal-entity-vLEI- credential.json), LEECRvLEIC (https://github.com/GLEIF-IT/vLEI- schema/blob/main/legal-entity-engagement-context-role-vLEI- credential.json), and LEOORvLEIC (https://github.com/GLEIF-IT/vLEI- schema/blob/main/legal-entity-official-organizational-role-vLEI- credential.json) schemas. These messages are realized using various vLEI credentials depending on use case context. Examples: * LEvLEIC is used if an asset controller, lock evidence issuer, or commit authority are legal entities. * LEECRvLEIC is used if an asset controller, lock evidence issuer, or commit authority are machine hosts facilitating SATP gateways or network hosts. * Official Organizational Role vLEI Credential (OORvLEIC) is used if an asset controller, lock evidence issuer, or commit authority are organizational roles. 3.1.4. Key Structures Keys embedded in hardware or firmware may not easily be converted to an interoperablel format, hence support for multiple key formats ensures the SATP protocols can be implemented by a wide variety of systems. The SATP messages in row 4 of Table 1 SHALL be encoded using JSON Web Key (JWK) [RFC7517] or COSE key [STD96] formats. The key structure SHOULD be extensible to support additional key formats. 3.2. SATP Message Wrapper Schema The following CDDL [RFC8610] defines the wrapper and application to SATP fields. ; ===================================================================== ; --- SATP Message (Entry Point) --- ; ===================================================================== satp-message = { ; --- Stage 1 --- ? verifiedOriginatorEntityId: wrapped-vlei ; always "leid" ? verifiedBeneficiaryEntityId: wrapped-vlei ; always "leid" ? senderGatewayOwnerId: wrapped-vlei ; always "leid" ? receiverGatewayOwnerId: wrapped-vlei ; always "leid" ? senderGatewayId: wrapped-vlei ; always "ecr" ? recipientGatewayId: wrapped-vlei ; always "ecr" ? senderGatewayNetworkId: wrapped-vlei ; always "ecr" ? recipientGatewayNetworkId: wrapped-vlei ; always "ecr" ? originatorPubkey: wrapped-key ? beneficiaryPubkey: wrapped-key ? senderGatewaySignaturePublicKey: wrapped-key ? receiverGatewaySignaturePublicKey: wrapped-key ? senderGatewayDeviceIdentityPubkey: wrapped-key ? receiverGatewayDeviceIdentityPubkey: wrapped-key ; --- Stage 2 --- ? assetControllerCredential: wrapped-vlei ; can be "leid", "ecr" or "oor" ? lockEvidenceIssuerCredential: wrapped-vlei ; can be "leid", "ecr" or "oor" ? lockEvidenceVerificationKey: wrapped-key ; --- Stage 3 --- ? commitAuthorizingCredential: wrapped-vlei ; can be "leid", "ecr" or "oor" ? commitVerificationKey: wrapped-key ? postCommitSecureChannelKey: wrapped-key } ; ===================================================================== ; --- Wrapped vLEI Payloads --- ; ===================================================================== wrapped-vlei = { vleitype: tstr content: content-ref payload: bstr / tstr } content-ref = { ? mt: tstr ; TBA e.g., "application/acdc+json" ? cf: uint ; TBA content format id ? cbt: bool ; payload contains CBOR tagged content in the TN() range if true ? oid: tstr ; generated from content-format-id e.g., "1.3.6.1.4.1.37476.2.1.5" } ; ===================================================================== ; --- Wrapped Key Definitions --- ; ===================================================================== wrapped-key = $key-type $key-type /= cose-key $key-type /= jwk-key $key-type /= pkix-key $wrapped-key-content /= "application/cose;cose-type=cose-key" $wrapped-key-content /= "application/jwk+json" $wrapped-key-content /= "application/pkix-cert" $wrapped-key-content /= uint cose-key = { content: "application/cose;cose-type=cose-key" / uint, encoding: "cbor" / "base64", payload: bstr / tstr } jwk-key = { content: "application/jwk+json" / uint, payload: tstr } pkix-key = { content: "application/pkix-cert" / uint, encoding: "PEM" / "DER", payload: tstr / bstr } 3.3. vLEI Media Types vLEI credentials are expressed as Authentic Chained Data Containers (ACDC) [ACDC-Spec]. Section Section 7 request IANA assignment of ACDC media types [STD91]. SATP messages as JSON can contain JSON wrapped ACDCs, but other ACDC formats are possible. The follwing media types MAY be used when supplying ACDC credential payloads: +========================+ | Media Types | +========================+ | application/acdc+json | +------------------------+ | application/acdc+cbor | +------------------------+ | application/acdc+msgpk | +------------------------+ | application/acdc+cesr | +------------------------+ | application/said+cesr | +------------------------+ Table 2: vLEI media types +=====================================+============================+ | Profile name | Profile ID | +=====================================+============================+ | Legal Entity Identity (LEI-ID) | ;profile="urn:vlei:lei-id" | +-------------------------------------+----------------------------+ | Engagement Context Role (ECR) | ;profile="urn:vlei:ecr" | +-------------------------------------+----------------------------+ | Official Organizational Role (OOR) | ;profile="urn:vlei:oor" | +-------------------------------------+----------------------------+ | Legal Entity Authorizing Role (LAR) | ;profile="urn:vlei:lar" | +-------------------------------------+----------------------------+ | Qualified vLEI Issuer (QVI) | ;profile="urn:vlei:qvi" | +-------------------------------------+----------------------------+ | vLEI Root Authority (vRA) | ;profile="urn:vlei:vra" | +-------------------------------------+----------------------------+ Table 3: vLEI profiles The various vLEI credential types can be specified in a media type using the profile option. Table 3 summarizes the profile identifiers for the various vLEI credential types. A comprehensive listing of vLEI profiles is provided even though some of the vLEI credential types are not anticipated by the vLEI binding to SATP at this time. 3.4. Example SATP Credential Payload The following SATP wrapper examples show synthetic vLEI data: { "verifiedOriginatorEntityId": { "vleitype": "verified-originator-entity-id", "content": { "mt": "application/acdc+json;profile=urn:vlei:leid" // JSON serialization of an ACDC credential (LEID profile) // CESR framing in plain text, not CBOR }, "payload": "ACDC10JSON...SAID...i:did:keri:..." // literal CESR/ACDC JSON text, not base64 } } { "verifiedBeneficiaryEntityId": { "vleitype": "verified-beneficiary-entity-id", "content": { "mt": "application/said+cbor;profile=urn:vlei:leid;base64=true", "cbt": false // no TN() CBOR tag; payload is base64 of raw CBOR }, "payload": "QUNEQzEwQ0JPUkJhc2U2NEVuY29kZWQvLi4u" // base64 of binary CBOR serialization of SAID credential (LEID profile) } } { "senderGatewayOwnerId": { "vleitype": "sender-gateway-owner-id", "content": { "mt": "application/acdc+msgpk;profile=urn:vlei:leid" // cf, cbt, oid omitted here — optional in schema }, "payload": "ACDC10MSGP...SAID...i:did:keri:..." // MessagePack serialization of an ACDC credential (LEID profile) } } { "receiverGatewayOwnerId": { "vleitype": "leid", // always "leid" for this field "content": { "mt": "application/said+cesr;profile=urn:vlei:leid;base64=true" // could also include cf, cbt, oid if known }, "payload": "QUNEQzEwQ0VTUkJhc2U2NEVuY29kZWQvLi4u" // ⟶ Base64 of binary CESR stream encoding of SAID credential } } { "senderGatewayId": { "vleitype": "sender-gateway-id", "content": { "mt": "application/acdc+cesr;profile=urn:vlei:ecr" // cf, cbt, oid omitted — optional in schema }, "payload": "ACDC10CESR...SAID...i:did:keri:..." // CESR-encoded ACDC credential (ECR profile) as plain text } } { "recipientGatewayId": { "vleitype": "recipient-gateway-id", "content": { "mt": "application/acdc+cbor;profile=urn:vlei:ecr", // from vlei-media-type enum "cf": 0, "oid": "1.2.3.4.6" // actual OID for this credential type }, "payload": "ACDC10CBORTESTSAIDi:did:keri:EXAMPLERGWNETID" // raw CBOR bytes or base64/base64url string, but not CBOR-tagged } } { "senderGatewayNetworkId": { "vleitype": "sender-gateway-network-id", "content": { "mt": "application/acdc+cbor;profile=urn:vlei:ecr;base64=true", "cbt": false // no TN() CBOR tag; just base64 of raw CBOR }, "payload": "oWJ0ZXN0LWVjci1jcmVkZW50aWFs..." // base64 of the CBOR-encoded ACDC (ECR profile) } } { "senderGatewayNetworkId": { "vleitype": "sender-gateway-network-id", "content": { "mt": "application/acdc+cbor;profile=urn:vlei:ecr;base64=true", "cbt": false }, "payload": "gEEBAQ..." // base64 of CBOR-encoded ACDC (ECR profile) } } The following SATP wrapper examples show synthetic key data: { "originatorPubkey": { "content": "application/jwk+json", "payload": "{ \"kty\": \"EC\", \"crv\": \"P-256\", \"x\": \"...\", \"y\": \"...\" }" }, "beneficiaryPubkey": { "content": "application/cose;cose-type=cose-key", "encoding": "base64", // explicitly flagging representation "payload": "aEtNQnBRLi4u" // base64 of CBOR COSE_Key bytes }, "senderGatewaySignaturePublicKey": { "content": "application/jwk+json", "payload": "{ \"kty\": \"RSA\", \"n\": \"...\", \"e\": \"AQAB\" }" }, "receiverGatewaySignaturePublicKey": { "content": "application/cose;cose-type=cose-key", "encoding": "base64", "payload": "aEtNQ3BBLi4u" }, "senderGatewayDeviceIdentityPubkey": { "content": "application/pkix-cert", "encoding": "PEM", "payload": "-----BEGIN CERTIFICATE-----\nMIIB...==\n-----END CERTIFICATE-----" }, "receiverGatewayDeviceIdentityPubkey": { "content": "application/pkix-cert", "encoding": "DER", "payload": "MIIB..." // base64 DER }, "lockEvidenceVerificationKey": { "content": "application/jwk+json", "payload": "{ \"kty\": \"OKP\", \"crv\": \"Ed25519\", \"x\": \"...\" }" }, "commitVerificationKey": { "content": "application/cose;cose-type=cose-key", "encoding": "base64", "payload": "aEtNQ3BBLi4u" }, "postCommitSecureChannelKey": { "content": "application/jwk+json", "payload": "{ \"kty\": \"EC\", \"crv\": \"P-384\", \"x\": \"...\", \"y\": \"...\" }" } } 4. Identities 4.1. Identity Binding 5. Verification of vLEI Payloads 6. Security Considerations TODO Security 7. IANA Considerations 7.1. Media Type Registration: application/acdc+json Type name: application Subtype name: acdc+json Required parameters: None Optional parameters: profile — Indicates the credential conforms to a specific schema registry (e.g., "vlei") base64 — Indicates the CESR stream is base64-encoded for transport in JSON wrappers charset — Optional; default is UTF-8 Encoding considerations: 8bit; CESR text encoding is UTF-8 compatible and self-framing. When base64=true, the CESR stream is base64-encoded for safe embedding in JSON. Security considerations: CESR payloads are cryptographically signed and self-framing. Signature verification is required to ensure authenticity and integrity. Schema SAIDs must be validated against the GLEIF vLEI Credential Schema Registry (https://www.gleif.org/media/pages/organizational- identity/introducing-the-verifiable-lei-vlei/introducing-the-vlei- ecosystem-governance-framework/60ede5e451-1755158176/2023-12- 15_vlei-egf-v3.0-technical-requirements-part-3-vlei-credential- schema-registry_v1.1-final.pdf). Credential provenance must be anchored to the GLEIF Root AID via ACDC edges. Interoperability considerations: CESR supports dual text-binary encoding; this media type assumes CESR text encoding. When base64=true, payloads are safely embeddable in JSON-based SATP wrappers. Compatible with SATP, ACDC, and KERI protocols. Published specification: Composable Event Streaming Representation (CESR) — draft-ssmith-cesr-03 (https://www.ietf.org/archive/id/ draft-ssmith-cesr-03.html) GLEIF vLEI Credential Schema Registry — GLEIF Registry PDF (https://www.gleif.org/media/pages/organizational-identity/ introducing-the-verifiable-lei-vlei/introducing-the-vlei- ecosystem-governance-framework/60ede5e451-1755158176/2023-12- 15_vlei-egf-v3.0-technical-requirements-part-3-vlei-credential- schema-registry_v1.1-final.pdf) Applications that use this media type: GLEIF vLEI issuance and verification systems SATP-compliant credential exchange platforms Forensic credential chaining and audit systems Fragment identifier considerations: None Additional information: Magic number(s): None File extension(s): .cesrj Macintosh file type code(s): None Person & email address to contact for further information: N. Smith spec-author@example.org (mailto:spec-author@example.org) GLEIF IT Team vlei-support@gleif.org (mailto:vlei- support@gleif.org) Intended usage: COMMON Author: TBD, GLEIF IT Team Change controller: IETF / GLEIF 8. References 8.1. Normative References [REQ-LEVEL] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [I-D.ietf-satp-core] Hargreaves, M., Hardjono, T., Belchior, R., Ramakrishna, V., and A. Chiriac, "Secure Asset Transfer Protocol (SATP) Core", Work in Progress, Internet-Draft, draft-ietf-satp- core-11, 7 August 2025, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, . [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [STD91] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [GLEIF-vLEI-TechReq-Part1] Global Legal Entity Identifier Foundation, "Technical Requirements Part 1: KERI Infrastructure", GLEIF vLEI-EGF- TechReq-Part1-v1.3, 16 April 2025, . [GLEIF-vLEI-TechReq-Part2] Global Legal Entity Identifier Foundation, "Technical Requirements Part 2: vLEI Credentials", GLEIF vLEI-EGF- TechReq-Part2-v1.1, 15 December 2023, . [GLEIF-vLEI-TechReq-Part3] Global Legal Entity Identifier Foundation, "Technical Requirements Part 3: vLEI Credential Schema Registry", GLEIF vLEI-EGF-TechReq-Part3-v1.1, 15 December 2023, . [ISO17442-3] International Organization for Standardization, "Financial services — Legal entity identifier (LEI) — Part 3: Verifiable LEIs (vLEIs)", ISO 17442-3:2024, 2024, . [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, . 8.2. Informative References [I-D.ietf-satp-architecture] Hardjono, T., Hargreaves, M., Smith, N., and V. Ramakrishna, "Secure Asset Transfer (SAT) Interoperability Architecture", Work in Progress, Internet-Draft, draft- ietf-satp-architecture-08, 31 July 2025, . [ISO17442-1] International Organization for Standardization, "Financial services — Legal entity identifier (LEI) — Part 1: Assignment", ISO 17442-1:2020, 2020, . [KERI-Spec] Trust Over IP Foundation, "Key Event Receipt Infrastructure (KERI) Specification, v0.9, Draft", TOIP TSWG-KERI-2023, 2023, . [ACDC-Spec] Trust Over IP Foundation, "Authentic Chained Data Containers (ACDC) Specification, v0.9, Draft", TOIP TSWG- ACDC-2023, 2023, . [CESR-Spec] Trust Over IP Foundation, "Composable Event Streaming Representation (CESR) Proof Format Specification, v0.9, Draft", TOIP TSWG-CESR-2023, 2023, . [GLEIF-vLEI-EGF] Global Legal Entity Identifier Foundation, "Verifiable LEI (vLEI) Ecosystem Governance Framework: Primary and Controlled Documents", GLEIF vLEI-EGF-v3.0, 16 April 2025, . Acknowledgments TODO acknowledge. Author's Address Ned Smith Independent Email: ned.smith.ietf@outlook.com