walt.id Documentation

website·Indexed 34 days ago

https://docs.walt.id

Documentation for walt.id's digital identity infrastructure, featuring both Community (open-source) and Enterprise stacks. It covers decentralized identity concepts, DIDs, and credential formats including W3C VC, SD-JWT VC, and ISO/IEC 18013-5 mDL/mdoc. The guides detail data exchange protocols such as OpenID4VCI, OpenID4VP, and the W3C Digital Credentials API (DC-API), as well as the Digital Credentials Query Language (DCQL) and trust systems like EU Trust Lists.

Tokens
400.6K
Snippets
1.4K
Records
2.5K
Agent score
68%

What's inside walt.id

  1. Overview of ISO/IEC 18013-5 mDL Issuance Components

    Issuing a mobile driver's license (mDL) requires a PKI structure consisting of two primary roles:

    1. IACA (Issuing Authority Certification Authority): The root of trust. It is represented by a self-signed X.509 digital certificate published to verifiers.
    2. DS (Document Signer): The entity that cryptographically signs the mDL credentials. The DS holds a private key and an X.509 certificate issued by the IACA. DS certificates are typically short-lived and rotated periodically.

    Technical Constraints:

    • mDLs are encoded in CBOR (binary format).
    • Only secp256r1 keys are currently supported for onboarding IACAs, DSs, and issuing mDLs.
  2. Overview of Digital Credentials Query Language (DCQL)

    DCQL (Digital Credentials Query Language) is the mechanism used by verifiers in OpenID4VP requests to specify which credentials a wallet should present and in what combinations. Introduced in OpenID4VP Draft 22 (October 2024) and part of the v1.0 specification, it replaces the Presentation Exchange / Presentation Definition approach with a simpler structure based on named fields, a specific claim path syntax, and explicit AND/OR operators.
  3. Overview of walt.id wallet service applications

    The walt.id wallet service provides a wallet API and a set of white-label applications to accelerate the development of use-cases. One such application is the Web Wallet, which is a custodial web-wallet (PWA) solution designed for managing credentials and tokens.
  4. Overview of PKCS#11 HSM Integration

    The Enterprise Stack Key Management Service (KMS) can use PKCS#11 tokens to store signing keys. Private keys are generated on the token and never leave it; the Enterprise Stack only stores the public key and a reference to the token object. This integration requires a self-hosted Enterprise Stack deployment because the vendor PKCS#11 library and token must be locally available to the API process. In multi-replica deployments, every replica must have the same library and access to the same token.
  5. Overview of Host Aliases in Enterprise Stack

    Host aliases enable custom domain routing in the Enterprise Stack, allowing organizations and tenants to be accessed via their own domain names (e.g., credentials.example.com) instead of the default subdomain structure (e.g., myorg.enterprise-sandbox.waltid.dev).

    When a request arrives, the system looks up the incoming host in the host alias table to determine the organization and tenant context. This is used for custom branding, tenant isolation, and simplified URLs. When active, all generated service URLs (like credential offer URLs) use the custom domain.

  6. Overview of walt.id Verifier API Verification Policies

    The walt.id verifier API provides a set of predefined verification policies used to verify verifiable credentials. These policies are categorized into three types based on their flexibility and use cases: Static, Parameterized, and Dynamic verification policies.
  7. Overview of Issuer2 Verifiable Credential Service

    Issuer2 is an open-source HTTP API service used for creating, signing, and distributing verifiable digital credentials. It implements the OID4VCI v1.0 specification and utilizes a profile-based architecture to streamline issuance.

    Supported standards include:

    • Credential Formats: SD-JWT VC (IETF), W3C VC (v1.1+, v2.0), and ISO 18013-5 mDL.
    • Credential Exchange: OID4VCI (v1.0).
    • Signing Algorithms: ed25519, secp256k1, secp256r1, and RSA.
  8. Overview of the DID Registry Service API

    The DID Registry Service provides endpoints to list registered DIDs, resolve did:web documents, and manage service dependencies. The API is organized into three primary endpoint groups:

    • Registry: Used to list and resolve did:web identifiers (endpoints starting with /registry/…).
    • Dependencies: Used to add or remove DID Store dependencies.
    • Configuration: Used to view and update the service configuration.
  9. Overview of walt.id Wallet-API capabilities

    The Wallet-API allows developers to offer identity wallets that handle Decentralized Identifiers (DIDs), various credential types, and the receipt and presentation of credentials using the OIDC4VC protocol. It also supports web3 wallet integration for viewing tokens from blockchain ecosystems such as Ethereum and Polygon.
  10. Overview of supported event types

    The Enterprise Stack records and stores events by default in the connected database. Currently supported event types include:

    • IssuanceEvent: Tracks the status of credential offers initiated via the credentials/issue endpoint of the issuer service.
    • VerificationEvent: Tracks the status of credential requests initiated via the credentials/verify endpoint of the verifier service.
  11. Overview of Verification Policy Configuration Levels

    The verification policy system uses a hierarchical structure to apply rules at different scopes. Policies are executed in a specific sequence: first at the Verifiable Presentation (VP) level, then globally across all extracted credentials, and finally for specific credentials based on their query ID. All policies at a given level run in parallel. The overallSuccess flag is only true if all policies at all levels succeed.
    data class DefinedVerificationPolicies(
        /** Policies to run on the presentations (VP-level) */
        val vp_policies: VPPolicyList? = null,
        
        /** Policies to run on all credentials (Global VC-level) */
        val vc_policies: VCPolicyList? = null,
        
        /** Policies to run on specific credential query IDs (Specific VC-level) */
        val specific_vc_policies: Map<String, VCPolicyList>? = null
    )