Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 171 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.
In KERI/ACDC, 'exp' (expose/exposition) is a message type that reveals previously sealed (encrypted or hidden) data, enabling selective disclosure of credential attributes or other cryptographically committed information.
exp is a KERI protocol message type abbreviation standing for "expose" or "sealed data exposition." According to the canonical glossary definitions (Documents 1 and 2), the term is defined minimally as:
This represents a message type within KERI's communication protocol, but the provided source documentation does not include detailed specifications, message structure definitions, or implementation guidelines for this message type.
The 'exp' term appears in the KERI/GLEIF canonical terminology databases (Documents 1, 2, 6, 12, 22) as a basic glossary entry without elaboration. Unlike extensively documented KERI concepts such as ACDC, KEL, or IPEX, the 'exp' message type lacks dedicated specification documents in the provided sources.
The minimal documentation suggests that 'exp' is either:
While the sources do not provide explicit 'exp' message specifications, several documents discuss concepts that suggest potential roles for an "expose" or "sealed data exposition" operation:
Implementations must verify that exposed data matches the previously presented SAID:
Implementations should track which SAIDs have been exposed to prevent replay attacks or inconsistent disclosures:
When implementing exp message handling:
For systems handling high volumes of credential presentations:
Document 3 describes graduated disclosure mechanisms in ACDCs, explaining that credentials can be presented at different levels:
The document states that "fully expanded" represents "the highest amount of disclosure for a given node in an ACDC graph structure," but does not explicitly connect this to the 'exp' message type.
Document 21 (IPEX specification) describes the Issuance and Presentation Exchange protocol, which "provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner." The IPEX specification defines several message types for credential exchanges, but the provided excerpt does not explicitly enumerate 'exp' among them or explain its role in the protocol.
Document 32 (another IPEX draft) similarly describes credential presentation workflows involving "disclosure of one or more ACDCs between a Discloser and a Disclosee," but again does not explicitly detail the 'exp' message type's function within these workflows.
Document 18 describes CESR Proof Signatures, which enable "transposable cryptographic signature attachments on self-addressing data (SAD)." This specification addresses signing ACDCs and other SADs that may be "embedded inside another SAD" with "CESR proof signature attachment can be transposed across envelope boundaries." While this relates conceptually to exposing previously sealed data, the document does not reference 'exp' messages as the mechanism for this operation.
Document 49 (ACDC specification header) describes how ACDCs support "selective disclosure" and "partial disclosure" mechanisms, allowing credential holders to reveal only necessary information. The specification mentions that "chained ACDCs support delegated credentials" and discusses cryptographic commitments through SAIDs, but does not explicitly define 'exp' as the message type implementing these disclosure operations.
Several other KERI message type abbreviations are documented with similar brevity in the glossaries:
These message types are fundamental to KERI protocol operations and are referenced throughout various specifications (Documents 8, 16, 38). However, unlike these core message types which appear extensively in KEL and event processing documentation, 'exp' does not feature prominently in the architectural descriptions provided.
Document 10 (SignifyTS credential presentation tutorial) demonstrates practical credential presentation workflows using the IPEX protocol, showing code for "presenting an ACDC from a Holder to a Verifier." The tutorial includes examples of:
However, the provided excerpt (which is incomplete, ending mid-operation) does not show explicit use of 'exp' message types in the code examples. The tutorial references "IPEX protocol" operations but does not detail the underlying message types used.
Document 27 (ACDC presentation and revocation tutorial) similarly demonstrates credential presentation workflows using KLI (KERI Command Line Interface), including:
Again, while these operations logically might involve "exposing" sealed credential data, the provided documentation does not explicitly identify 'exp' as the message type implementing these operations.
The term "sealed data exposition" in the 'exp' definition suggests a connection to cryptographic sealing mechanisms. Several documents discuss data sealing concepts:
Document 24 explains that SAIDs create "cryptographic commitments" where "any subsequent exposition must produce data that hashes to the same SAID." This creates a "tamper-evident disclosure mechanism where altered data would produce a different SAID." This aligns conceptually with the notion of "exposing" previously sealed data by revealing the pre-image of a cryptographic digest.
Document 3 describes how ACDCs can exist in "compact" form (with SAIDs representing sections) or "fully expanded" form (with complete data). The transition between these forms would logically require an "exposition" operation, though the document does not explicitly name this operation as 'exp'.
Document 14 (SPAC protocol) discusses the "PAC Trilemma" regarding privacy, authenticity, and confidentiality in identity systems. The protocol addresses "minimizing contextual linkability" while maintaining authenticity. An "expose" operation would be relevant to this security model by enabling controlled disclosure of information that was previously sealed for privacy, but the SPAC specification does not reference 'exp' messages explicitly.
Document 25 establishes a core KERI principle: "Security → Confidentiality → Privacy" hierarchy, where "security is non-negotiable at the foundational level." Any exposition mechanism would need to maintain this security priority while enabling necessary disclosure.
The analysis of 171 source documents reveals that:
This contrasts sharply with other KERI protocol elements like KEL events (extensively documented in Documents 8, 16, 38, 40), OOBI (detailed in Document 43), TEL (specified in Document 40), and IPEX (specified in Documents 21, 32).
Based on the available documentation, 'exp' is confirmed as a KERI protocol message type abbreviation meaning "expose" or "sealed data exposition," but detailed specifications for this message type are not provided in the 171 source documents analyzed. The term appears only in minimal glossary entries without implementation details, message format specifications, or usage examples.
While related concepts like ACDC graduated disclosure, IPEX credential presentation, and SAID-based cryptographic commitments suggest potential functional contexts where an "expose" operation would be relevant, the source material does not explicitly connect these architectural patterns to the 'exp' message type.
Developers seeking to implement or work with 'exp' messages would need to:
The minimal documentation level suggests 'exp' may be an implementation-specific construct whose detailed behavior is defined in code rather than specification documents, or it may be documented in KERI protocol specifications not included in the provided source set.