Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 7 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.
A listed identifier is a list of authorized did:webs identifiers and their associated methods contained within an ACDC's metadata section, providing an authorization mechanism for specifying which decentralized identifiers are permitted within a given credential context.
A listed identifier is a list structure within an ACDC (Authentic Chained Data Container) that contains authorized did:webs identifiers along with their associated methods. This list appears in the metadata section of the did:webs DID document.
This definition was paraphrased from Samuel Smith during a KERI development team Zoom meeting on November 9, 2023, indicating it represents current thinking on ACDC authorization patterns within the KERI ecosystem.
The listed identifier concept operates at the intersection of several KERI/ACDC technologies:
ACDCs are authentic chained data containers that provide verifiable credentials with graduated disclosure capabilities. The listed identifier mechanism appears to function as an authorization layer within this framework, allowing controllers to explicitly specify which did:webs identifiers are recognized or permitted within a particular ACDC context.
The specific use of did:webs identifiers indicates integration with the web-based DID method that combines:
When implementing listed identifiers:
Metadata Placement: Ensure the listed identifier structure is placed in the metadata section of the did:webs DID document, not in the main ACDC attribute or edge sections
Schema Validation: Define a clear JSON schema for the listed identifier structure to ensure consistency across implementations
Method Specification: Clearly define what "methods" mean in your implementation context - whether they represent authorization scopes, operation types, or service capabilities
Efficient Lookup: Implement efficient lookup mechanisms for checking if an identifier is in the list, especially for large authorization lists
Verifiers should implement:
Multi-Step Validation: Verify ACDC signature, check listed identifier presence, validate methods, and confirm DID control in sequence
Caching Strategy: Cache resolved DID documents and verification results to improve performance, but implement appropriate cache invalidation
Error Handling: Provide clear error messages distinguishing between missing identifiers, unauthorized methods, and cryptographic verification failures
Audit Logging: Log all authorization checks for security auditing and debugging
Signature Verification First: Always verify the ACDC signature before trusting the listed identifier content
DID Resolution Security: Use secure DID resolution methods and verify the integrity of resolved DID documents
Method Scope Enforcement: Strictly enforce method-based authorization - do not allow operations outside the specified methods
Revocation Checking: Check if the ACDC or any listed identifiers have been revoked through TEL registries
Selective Disclosure: Consider implementing selective disclosure for listed identifiers to reveal only necessary authorization information
By embedding the authorization list in the DID document metadata, the mechanism maintains the end-verifiable properties fundamental to KERI's design philosophy.
Based on the source material, the listed identifier serves to:
Authorization Control: Provides a mechanism for tracking and authorizing specific decentralized identifiers at the DID document level
Verifiable Authorization Records: Creates a verifiable record that can be checked during credential verification or presentation processes
Method Association: Links each authorized identifier with its associated methods (though the sources do not specify what these "methods" entail)
While the listed identifier is not a core KERI primitive, it appears to leverage KERI's foundational infrastructure:
ACDC Protocol: The primary context where listed identifiers appear, enhancing ACDC authorization capabilities by explicitly defining permitted identifiers.
IPEX Protocol: The Issuance and Presentation Exchange protocol uses ACDCs for credential exchange, where listed identifiers would presumably be checked during presentation exchanges.
KERI Infrastructure: The concept builds upon KERI's core technologies including AIDs (Autonomic Identifiers), KELs (Key Event Logs), and CESR encoding, though the specific integration mechanisms are not detailed in the available sources.
The source documents provide only a minimal definition of listed identifier. The following aspects are not specified in the available sources:
The term appears to be a relatively recent addition or clarification to the KERI/ACDC specification suite, and fuller documentation may be forthcoming as the concept matures within the ecosystem.
The listed identifier represents an authorization mechanism within the ACDC framework, specifically for managing did:webs identifiers. It provides a way to explicitly authorize which decentralized identifiers are permitted within a given ACDC context by maintaining a list in the metadata section of the DID document. However, the concept as documented in the available sources remains at a definitional level, with implementation details, operational procedures, and integration patterns not yet fully specified in public documentation.
Minimal Disclosure: Include only the minimum set of identifiers needed for the credential's purpose
Correlation Risks: Be aware that listed identifiers may enable correlation across different credential presentations
IPEX Protocol: Integrate listed identifier verification into IPEX presentation exchange flows
TEL Registries: Consider anchoring authorization changes to TEL registries for verifiable audit trails
Witness Networks: For high-assurance scenarios, consider requiring witness confirmation of authorization list changes
Agent Support: Ensure KERIA agents and other KERI infrastructure components properly handle listed identifiers during credential operations