Multipaz Developer Documentation

website·Indexed 33 days ago

https://developer.multipaz.org

Technical documentation for Multipaz, featuring the org.multipaz.crypto library with HPKE cipher suites (including DHKEM, HKDF, and AES-GCM), the org.multipaz.presentment model, and legacy Android identity components for credential data requests, access control profiles, and device request parsing.

Tokens
977.2K
Snippets
7.6K
Records
9.7K
Agent score
67%

What's inside Multipaz

  1. Overview of the Identity Credential project

    The Identity Credential project by OpenWallet Foundation Labs enables decentralized identity issuance and verification. It supports standards including OpenID for Verifiable Credential Issuance (OpenID4VCI) and OpenID for Verifiable Presentations (OpenID4VP). The project provides a Kotlin Multiplatform (KMP) library for mobile wallets to issue and present credentials, as well as server components for issuing and verifying those credentials.
  2. Overview of CredentAgent consent layer

    CredentAgent provides a human-in-the-loop credential check for AI agents. It ensures that before an agent completes a consequential action (like checking out a cart or unlocking restricted content), the user must prove a verifiable credential from their phone wallet. The system treats identity, age verification, loyalty memberships, and payment as credentials within the same policy framework. Currently, it enforces credential disclosure and binding (WebAuthn/OpenID4VP), but does not yet enforce issuer trust.
  3. Overview of Holder app responsibilities and components

    A Holder app is responsible for the provisioning and storage of digital identities, specifically focusing on the creation, secure storage, and presentation of mDocs (mobile Documents). The implementation of a Holder app involves several key functional areas: initializing secure storage and cryptographic infrastructure, setting up document repositories, provisioning mDoc credentials, managing and fetching documents, presenting credentials to verifiers, and managing trust relationships with verifier apps.
  4. Overview of SoftwareSecureArea

    The SoftwareSecureArea class is an implementation of SecureArea that creates and manages software-based cryptographic keys. It supports all curves and algorithms defined by SecureArea, including passphrase-protected keys.

    Key technical details:

    • Storage: Key material is managed via the Storage abstraction.
    • Encryption: Passphrase-protected keys are encrypted using AES-GCM with 256-bit keys. The encryption key is derived from the passphrase using HKDF.
    • Platform Implementation: On JVM and Android, it utilizes the Crypto library and its implemented algorithms and curves.
    • Instantiation: Use the SoftwareSecureArea.create companion method to create an instance.
  5. Overview of TrustManager implementations

    Multipaz uses the TrustManager interface to manage and validate trust relationships. There are three primary implementations available:

    • LocalTrustManager: Manages trust using local files.
    • VicalTrustManager: Implements trust based on VICAL, following the ISO/IEC 18013-5 standard.
    • CompositeTrustManager: Allows the stacking of multiple trust managers to combine different trust sources.
  6. Overview of the CredentAgent SDK

    CredentAgent is a consent layer for AI agents designed to prevent agents from performing consequential actions (such as payments, age-gating, or access grants) without first proving a verifiable credential from the user's wallet. It ensures that identity and authorization are cryptographically backed and enforced server-side, rather than relying on LLM assertions. The SDK is compatible with Claude, ChatGPT, and Goose and is distributed via two npm packages: a host-agnostic 'Gate' and a ready-made 'Storefront'.
  7. Overview of VerticalCardListModel

    The VerticalCardListModel is a UI-agnostic state model and interaction coordinator for a vertical card list (wallet card stack/pass deck). It manages the display order of cards, drag-and-drop state machines, cooldown timers, and tap action resolution. It works in tandem with CardListLayoutCalculator, which handles the mathematical calculations for card dimensions, offsets, and visual states (scale, elevation, alpha, zIndex).
  8. Overview of OpenID4VCIBackendUtil

    OpenID4VCIBackendUtil is a utility object used to implement an OpenID4VCI backend. Because these utilities often require private keys for signing, they should typically be executed on a secure server in production environments to prevent private keys from being embedded in client applications. In test environments, they may be invoked directly within a client app for simplicity.
  9. Overview of IdentityCredentialStore

    IdentityCredentialStore is an abstract interface providing a secure store for user identity documents. It is designed to be general, leaving the specific message formats and communication semantics for credential verification devices and issuing authorities (IAs) to be implemented by credential-specific applications. It adheres to the ISO/IEC 18013-5:2021 standard.

    Each credential in the store consists of:

    • A document type (string).
    • Namespaces (recommended as reverse domain names) to disambiguate value names.
    • Name/value pairs for each namespace (values are CBOR-typed) with associated access control profile IDs.
    • Access control profiles defining conditions for data release.
    • A CredentialKey (asymmetric key pair) for authentication to the Issuing Authority.
    • Reader authentication public keys to authenticate authorized readers.
    • Signing keys for collections of values and session transcripts.
  10. Overview of DocumentStore

    The DocumentStore class is used to store real-world identity documents (e.g., ISO/IEC 18013-5:2021 Mobile Driving Licenses). It is format-agnostic and supports various presentation and issuance protocols. It relies on a SecureArea for managing authentication keys, which is abstracted via the SecureAreaRepository interface. A key guarantee of the store is that once a document is created via createDocument, subsequent calls to lookupDocument will return the same Document instance.