Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 36 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
The Internet Assigned Numbers Authority (IANA) is the organization responsible for coordinating global internet protocol resources, including IP address allocation, domain name system management, and the standardization and registration of media types (MIME types) used to identify file formats and content types in internet communications.
The Internet Assigned Numbers Authority (IANA) is the authoritative organization responsible for coordinating and managing critical internet protocol resources that enable global network interoperability. While the canonical glossary definition focuses on IP address allocation to Internet Service Providers (ISPs), IANA's responsibilities encompass a much broader scope of internet infrastructure coordination including:
IANA operates under the organizational structure of the Internet Corporation for Assigned Names and Numbers (ICANN), though its technical coordination functions predate ICANN's formation. IANA's role is fundamentally about namespace management and coordination—ensuring that the various identifier systems underpinning internet protocols remain globally unique, consistent, and interoperable.
IANA functions as the technical coordination body for internet protocol resources, working closely with the Internet Engineering Task Force (IETF) on protocol standardization. When IETF specifications define new protocol parameters, codes, or identifiers, IANA serves as the official registry maintaining these assignments. This relationship is critical for the evolution of internet standards:
While IANA itself is not a KERI-specific entity, KERI implementers should be aware of:
The KERI glossary acknowledges that experimental or proposed media types are valid during development phases, even before formal IANA registration. This pragmatic approach allows:
KERI implementations should:
application/vnd.keri+cesr) for experimental formatsThis governance model ensures that protocol identifiers remain centrally coordinated while protocol development remains decentralized—a critical balance for internet-scale systems.
A media type (historically called a MIME type, from Multipurpose Internet Mail Extensions) is a standardized two-part identifier indicating the nature and format of files or data streams transmitted over the internet. Media types follow the structure type/subtype, where:
application, text, image, audio, video, multipartjson, xml, jpeg, mpegExamples include:
application/json - JSON data formatimage/jpeg - JPEG image filestext/html - HTML documentsapplication/cbor - Concise Binary Object RepresentationMedia types serve a purpose similar to file extensions but are specifically designed for content negotiation in network protocols, particularly HTTP. When a server sends data to a client, the Content-Type HTTP header uses a media type to inform the client how to interpret the response body. Similarly, clients use the Accept header to specify which media types they can process.
IANA maintains the official registry of media types, providing:
The glossary documents specify two criteria for valid media types:
type/subtype structureThis pragmatic approach recognizes that protocol development requires using media types before formal standardization completes, while emphasizing that production systems should use officially registered types.
While the source documents don't provide exhaustive detail on the registration process, they indicate that:
For the KERI ecosystem, this process is critical for transitioning from experimental development to production-ready standardization.
The Composable Event Streaming Representation (CESR) protocol is a foundational encoding mechanism for the KERI ecosystem. The CESR specification draft explicitly works toward registering application/cesr as an official IANA media type. This registration is significant because:
HTTP Transport: KERI protocols use HTTP for many communications, including:
Proper media type identification enables:
KERI Event Streams: The did:webs specification references KERI event streams as "CESR stream resources" that may be serialized in files using CESR encoding. The specification explicitly notes these are referred to as "KERI event streams to simplify the vocabulary" while technically being CESR-encoded verifiable data structures comprising:
Official application/cesr media type registration would provide standardized identification for these streams in HTTP contexts, enabling interoperability between different KERI implementations and integration with standard web infrastructure.
The Authentic Chained Data Container (ACDC) specification defines verifiable credentials that can be serialized in multiple formats:
Serialization Options:
application/json)application/cbor)application/msgpack)application/cesr)The CESR-Proof specification addresses how to attach cryptographic signatures to ACDCs and other Self-Addressing Data (SAD) structures. The specification explicitly states that signed SADs can be "transmitted inline with other CESR content over TCP, UDP, or HTTP." This requires proper media type identification in HTTP contexts.
The IPEX protocol specification addresses credential exchange mechanisms and references the need for proper content type identification when ACDCs are:
exn) messagesrpy) messagesexp) eventsProper IANA-registered media types enable:
Interoperability: Different KERI implementations (KERIpy, KERIox, KERIml, etc.) can reliably exchange credentials knowing they will be correctly interpreted
API Standardization: REST APIs serving ACDC credentials can use standard HTTP content negotiation:
Accept: application/json;profile=acdc
Content-Type: application/cbor;profile=acdc
Credential Format Versioning: Media type parameters can indicate ACDC specification versions or profiles
Beyond media types, IANA maintains protocol parameter registries relevant to KERI:
Cryptographic Algorithm Identifiers: The CESR specification defines derivation codes that identify cryptographic algorithms. While CESR uses its own compact encoding system rather than IANA-registered codes, there may be value in registering CESR's cryptographic algorithm identifiers in IANA's cryptographic algorithm registry for cross-protocol recognition.
Port Number Assignments: KERI witness and watcher infrastructure may benefit from registered port numbers. While the source documents don't explicitly discuss this, standard port assignments would facilitate:
URI Scheme Registration: The did:keri and did:webs methods represent URI schemes that could potentially be registered with IANA's URI scheme registry, though DID methods are typically registered through W3C processes rather than IANA.
Multiple KERI ecosystem specifications exist as IETF Internet Drafts:
These drafts represent works-in-progress that will eventually:
IETF specifications include IANA Considerations sections that explicitly request registry actions. While the source documents show these sections are often marked as "TODO" in early drafts, they will eventually specify:
application/cesr, application/acdc+json)The CESR-Proof specification represents one example where IANA considerations are explicitly addressed, as it extends CESR with new attachment codes that must be coordinated across implementations.
The glossary documents acknowledge that experimental media types are valid during protocol development. This reflects the reality that:
application/x-cesr or application/vnd.keri.cesr during developmentThe KERI ecosystem appears to be following this pattern, with experimental implementations using CESR encoding while formal IANA media type registration is pursued through the IETF standards process.
The Global Legal Entity Identifier Foundation (GLEIF) serves as the root of trust for the verifiable Legal Entity Identifier (vLEI) ecosystem. The GLEIF Identifier Governance Framework documents establish that GLEIF exercises the "highest duty of care" in generating and administering:
These identifiers must be KERI Autonomic Identifiers (AIDs) - self-certifying identifiers verifiable through cryptography alone. This architectural decision means the vLEI ecosystem's security foundation depends entirely on KERI protocols, making KERI standardization through IETF critical for:
Regulatory Confidence: Financial regulators and legal entity identification systems require internationally recognized standards
Implementation Interoperability: Multiple Qualified vLEI Issuers (QVIs) must implement KERI protocols consistently
Long-term Stability: Production identity systems require stable, well-maintained specifications
The vLEI Ecosystem Governance Framework documents emphasize:
Technology-Agnostic Open Standards: The framework requires "technology-agnostic approach using open source standards," positioning IETF standardization as critical infrastructure
Interoperability Requirements: "Interoperability and portability of digital identity data" requires standardized protocols and data formats
ISO 20000 Certification: The framework maps governance requirements to ISO 20000 certification obligations, which may have implications for the maturity level expected of underlying protocols
These governance requirements create institutional pressure for KERI protocols to complete IETF standardization, including necessary IANA registrations.
While IANA's DNS root zone management role isn't explicitly discussed in the KERI source documents, there are implicit connections:
OOBI Protocol: Out-Of-Band Introductions associate URLs (which use DNS) with KERI AIDs. The OOBI specification explicitly addresses how DNS-based URLs provide initial service endpoint discovery while KERI provides the cryptographic root-of-trust for verifying the information obtained.
Percolated Discovery: The OOBI specification describes "Percolated Information Discovery (PID)" mechanisms that bootstrap from initial OOBIs to discover additional endpoints. This discovery mechanism operates over standard internet infrastructure (DNS, HTTP) while maintaining KERI's security properties.
did:webs Method: The did:webs specification explicitly uses HTTPS URLs that depend on DNS infrastructure for domain name resolution, while KERI provides cryptographic verification of the retrieved content.
This creates an interesting architectural relationship where IANA's DNS coordination role supports KERI's discovery mechanisms while KERI's cryptographic verification eliminates dependency on DNS security (DNSSEC).
While the source documents don't explicitly discuss IANA port number allocation, KERI infrastructure components that could benefit from standard port assignments include:
Witness Services: KERI witnesses provide key event receipt services that could use standard ports for:
Watcher Networks: Watchers operate in "promiscuous mode" monitoring for duplicity, potentially using standard ports for:
Agent Infrastructure: The KERIA (KERI Agent) specification describes cloud-based agents exposing multiple HTTP endpoints. Standard port assignments could facilitate:
Standardized ports would enable consistent firewall rules, service discovery mechanisms, and deployment documentation across KERI implementations.
Media types can include structured syntax suffixes that indicate the underlying serialization format while specifying a semantic profile. For example:
application/acdc+json: ACDC credential in JSON serializationapplication/acdc+cbor: ACDC credential in CBOR serializationapplication/acdc+msgpack: ACDC credential in MessagePack serializationThis approach, standardized in RFC 6838, enables:
Generic Parsers: Applications can process the base serialization format (+json, +cbor) even if they don't understand the semantic profile (acdc)
Content Negotiation: Clients can express preferences for semantic content independent of serialization:
Accept: application/acdc+json, application/acdc+cbor;q=0.9
Transformation Pipelines: Intermediaries can transcode between serialization formats while preserving semantic meaning
The ACDC specification's support for multiple serialization formats makes structured syntax suffixes particularly relevant for KERI media type registrations.
Media types support parameters that further refine content interpretation:
Content-Type: application/cesr; version=1.0; variant=text
Content-Type: application/acdc+json; profile="https://trustoverip.org/acdc/schemas/lei-credential/v1"
Parameters enable:
Version Negotiation: Clients and servers can indicate which protocol version they support
Profile Identification: Credentials can indicate which schema or governance framework they conform to
Encoding Variants: CESR's text and binary encodings could be distinguished via parameters
Proper use of media type parameters in KERI protocols would require specification in the IANA Considerations sections of IETF drafts.
Based on the source documents:
IETF Drafts Active: Multiple KERI specifications exist as Internet Drafts under active development
Implementation Experience: Multiple implementations (KERIpy, KERIox, KERIml, CESRox, Keep, Signify) provide real-world validation
Production Deployments: GLEIF vLEI ecosystem represents production use driving standardization requirements
Community Coordination: Regular KERI community meetings (documented in agenda files) coordinate implementation and specification work
Specification Maturity: Some Internet Drafts contain "TODO" sections indicating ongoing development
Cross-Dependencies: KERI specifications reference each other (CESR depends on KERI, ACDC depends on CESR and SAID, IPEX depends on ACDC and OOBI), requiring coordinated advancement
Standardization Timeline: IETF processes require substantial time for working group formation, consensus building, and RFC publication
Early Adoption Risk: Production systems (like vLEI) using pre-standardized protocols assume risk of breaking changes, though implementation experience reduces this risk
For the KERI ecosystem, IANA serves as critical internet infrastructure enabling:
Standardized Media Type Registration: Official recognition of CESR, ACDC, and related content types for HTTP-based protocols
Protocol Parameter Coordination: Registry maintenance for cryptographic algorithm identifiers and other protocol parameters
Namespace Protection: Prevention of identifier conflicts as KERI protocols achieve broader adoption
Documentation Authority: Authoritative public registries that implementations worldwide can reference
Interoperability Foundation: Standardized identifiers that enable different implementations to interoperate reliably
While IANA's role may seem bureaucratic, it provides essential coordination that prevents the "balkanization" of protocol implementations—where different systems use incompatible identifiers for the same concepts. For KERI protocols aspiring to internet-scale adoption as trust spanning infrastructure, IANA registration through the IETF standards process represents not optional bureaucracy but essential infrastructure for achieving the interoperability and stability that production identity systems require.
The vLEI ecosystem's production deployment creates institutional pressure for completing this standardization work, as financial regulators and legal entity identification systems require internationally recognized standards rather than proprietary protocols. IANA's role in media type registration and protocol parameter coordination, while technical in nature, ultimately enables the governance and regulatory confidence necessary for KERI-based identity systems to achieve mainstream adoption in high-stakes contexts like legal entity identification and financial services.