Module Identity-Development-Kit (IDK)

Reference webapp showing how to combine the IDK OID4VCI issuer and OID4VP verifier services end to end in a single server process. Useful as executable documentation when you are wiring your own issuer or verifier deployment: it illustrates what is minimally required to boot the command graphs, mount the REST adapters, and drive an issuance or verification round-trip.

Ktor server plugin that bridges IDK's DI-scoped services into request handling. It lets route handlers resolve services from the same dependency graph that powers the rest of an IDK application, and derives per-request child graphs so that request-scoped state (tenant, principal, session) can be looked up cleanly from within a handler.

Runtime CBOR encoder and decoder for the data model declared in lib-cbor-public. It handles canonical encoding, tagged values, and indefinite-length items, the combination required by ISO 18013-5 mdoc and COSE. Pull it in whenever code needs to actually serialize or parse CBOR rather than just describe its shape.

Public CBOR data model (RFC 8949) shared by every IDK module that speaks a binary format, primarily ISO 18013-5 mdoc and COSE. It defines only the item hierarchy and related types; no runtime encoder or decoder lives here.

Property-source adapter that plugs the multiplatform-settings library into the IDK configuration system. It lets configuration values flow in from platform-native key-value stores: NSUserDefaults on iOS, SharedPreferences on Android, the Windows Registry, or an in-memory store for tests. Reach for it when an app needs user-preference or device-local configuration to participate in the same layered property hierarchy as YAML and environment sources.

Compose Multiplatform binding layer for IDK theming. It projects the tenant-scoped branding data exposed by lib-conf-theme-core-public into Compose Material colour, typography, and shape schemes, and handles adaptive concerns like dark-mode palettes and accessibility state. Pull it into a Compose app or shared UI module to get IDK branding applied without reimplementing the token resolution logic per surface.

Runtime that realises the theming contracts declared in lib-conf-theme-core-public: it resolves branding metadata for a tenant and caches the result so downstream Compose or web layers do not re-derive tokens on every render.

Public theming and branding model. It defines the tenant-scoped branding metadata, CSS and media policy configuration, and default design-token primitives that let IDK apply a consistent visual identity across mobile (Compose) and web surfaces without the core layer knowing anything about a specific rendering stack.

Web-side binding layer for IDK theming. It projects the tenant-scoped branding data from lib-conf-theme-core-public into CSS custom properties, handles legacy token aliases, and ships the small bootstrap script used to avoid a flash of unstyled content while the theme is being applied. Reach for this in a browser-rendered UI when you want IDK-managed branding to drive the stylesheet without writing bespoke CSS-token glue.

YAML property-source contributions for the IDK configuration system. It adds YAML loading at each tier of IDK's layered property hierarchy (App, Tenant, and Principal), so the same configuration machinery that merges environment and platform-native sources can also pull values from YAML files. Reach for it when you want file-based configuration without introducing a separate loader.

Default runtime realising the contracts declared in lib-core-api-public. It is the baseline application plumbing every IDK-based app needs before any domain modules are layered on: command execution wiring, scoped caching, a streaming codec registry (with the JSON codec registered), and the standard startup graph that brings the AppScope to life.

The foundational contract layer that every other IDK module depends on. It defines the primitives the whole SDK is built around: the IdkResult monad for explicit success and error flow, the Command hierarchy (including chained, pipelined, and compensatable forms) that every domain module exposes business logic through, execution context and session abstractions, the configuration and logging surfaces, the HTTP client adapter contract, caching interfaces, and the service identity and auth header primitives services use to talk to each other.

JMH microbenchmarks for the IDK core runtime. Guards against regressions on the hot paths that matter most across the platform: serialization, command dispatch, and scoped cache access. Not part of the runtime API surface; only relevant when working on the core runtime itself.

Runtime for the typed event hub declared in lib-core-events-public. It realises the application event service, the in-process hub, the default event builder, and the command-execution extension that lets commands emit lifecycle events without the command author wiring anything by hand.

Public event model for the IDK event hub: the typed Event surface, its context envelope, the application event service contract, and the configuration hooks used by commands and services to publish and observe events in a uniform way. It also defines the encryption hook for sensitive event payloads, so downstream services can enforce confidentiality policy at the hub boundary.

Mobile-oriented LogService implementation with a persistent ring-buffer repository, designed for the constraints of on-device logging: structured entries, capped retention, and a repository surface so an app can export diagnostics bundles without shipping every log line to a server. Pull it into iOS or Android apps when you need the IDK logging surface to persist across process restarts and stay exportable.

Test fixtures for modules that sit on top of lib-core-api-public. It provides a minimal application graph stub so unit tests can exercise commands, configuration, and caching against a working runtime without booting the full IDK stack. Reach for it in library tests; it is not intended for production wiring.

Runtime for the claims-mapping surface declared in lib-credential-claims-mapper-public. It projects claims out of credentials (SD-JWT today, with room for other formats) onto target attribute sets such as DCQL outputs or OIDC id_token claims, driven by the mapping DSL configured elsewhere.

Public contract for projecting credential claims onto a target attribute schema. The mapping DSL lets an issuer or verifier configure, declaratively, how claims from a credential (for example an SD-JWT VC) translate into the attribute shape a consumer expects (for example a DCQL response or an OIDC id_token). The module also exposes the DCQL adapter surface used by the OID4VP layer.

Runtime for the COSE and JOSE contracts declared in lib-crypto-core-public. It implements COSE signing and verification, key encoding, and the CBOR codecs COSE structures need, and adapts those operations through the IDK command system so higher layers (mdoc, SD-JWT, OAuth2/OIDC) share a single crypto surface.

Public crypto model shared by everything in IDK that signs, verifies, or encodes keys: the KMS provider family, the mdoc stack, SD-JWT, and the OAuth2/OIDC layer. It defines COSE header and key types, COSE MAC structures, algorithm identifiers, and the CBOR-codec surface COSE depends on.

Public contract for a tenant-scoped store of key references. The store persists pointers to keys held by a KMS, not the key material itself: IDK treats private keys as always living inside a KMS, and this layer records which tenant owns which KMS-held key for which purpose.

Orchestration layer on top of the key-reference contracts in lib-crypto-key-persistence-api. It selects the appropriate backing store, registers newly managed keys, and resolves the operational mode (for example which store to read from when multiple are available).

SQLDelight-backed durable implementation of the KeyReferenceStore contract from lib-crypto-key-persistence-api. Reach for this module when you need key references to survive process restarts on a platform that can host a SQLite database (JVM, mobile, native). For ephemeral or test setups the no-op store from the -api module is often sufficient.

KMS provider that delegates signing and key operations to AWS KMS. Private key material never leaves AWS-managed HSMs; IDK only holds references and issues operations over the AWS SDK.

KMS provider that delegates signing and key operations to Azure Key Vault. Private key material stays inside Azure-managed HSMs; IDK only holds references and issues operations over the Azure SDK.

KMS provider backed by on-device secure enclaves: iOS Secure Enclave and Android Keystore. It lets a wallet or other mobile app generate and use signing keys that never leave the device's hardware-backed key store, which is the baseline expectation for holder-bound credentials and device-bound mdoc presentations.

Remote KMS provider that delegates every crypto operation to a REST KMS server, typically an instance of services-kms-rest. Reach for this in deployments that want the actual key material centralised in a single KMS service, while other IDK components (issuer, verifier, wallet backend) stay stateless with respect to keys.

In-process software KMS provider. Keys are generated, stored, and used directly in the application process using the platform-native cryptography engine. It is the default provider for development, unit and integration tests, and deployments where offloading keys to an external KMS is not a requirement.

Public Bluetooth Low Energy transport primitives: the error and event model, permission helpers, response envelope, and state-guard used by proximity flows. It is a platform-neutral surface; the actual BLE stack lives behind platform-specific code under the mdoc BLE transport and under Compose / mobile app glue.

Scripted test drivers that drive the BLE client and peripheral sides from integration tests. Together with lib-data-link-ble-test-fixtures, this is what you use to exercise mdoc BLE flows end to end without touching a real Bluetooth stack.

Fake BLE stack for tests: platform-client, peripheral, and channel doubles that let code depending on lib-data-link-ble-public run without a real Bluetooth adapter. Pair with lib-data-link-ble-robots for higher-level scripted flows.

Runtime for the legacy HTTP client contracts in lib-data-link-http-client-public, supplying the command bodies that let the rest of the platform fetch remote URIs and parse URI queries through the IDK command system rather than calling a raw HTTP client directly.

Legacy HTTP client contracts retained for modules that still consume the older LegacyHttpClientFactory and the legacy TLS / SSL configuration surface. The associated command bindings let older code fetch URIs and parse URI queries through the IDK command system.

NFC transport runtime for the types declared in lib-data-link-nfc-public: APDU dispatch and tag-scanning, which together back ISO/IEC 7816 exchanges and NFC-initiated device engagement.

Public NFC transport primitives shared by higher-level flows: command APDUs, NDEF messages and records, and the handover request / select records used to hand an NFC-initiated session off to BLE. Platform-neutral model only; runtime dispatch lives in lib-data-link-nfc-impl.

HTTP client backing that makes a remote blob service look like a local BlobStore to the rest of the platform. Reach for this when an application keeps blob state in a central service but wants modules that consume blobs (credential design, schema registry, asset storage) to stay agnostic about where the bytes actually live.

Common runtime shared by the concrete BlobStore backings. It supplies the content-addressable layer, the default blob-info resolver, and the blob-store command surface that every backing benefits from, so per-backing modules only have to provide the storage-specific pieces.

Filesystem-backed BlobStore implementation. A pragmatic choice for single-node deployments and local development, where blob content sits on a mounted filesystem rather than in a remote service.

BlobStore implementation layered on top of any KvStore from lib-data-store-kv-public. Useful when you have already committed to a particular key-value backing (memory, Kottage, etc.) and want blobs to live in the same substrate without standing up a second storage system.

In-memory BlobStore implementation. Intended for tests and short-lived or CI deployments where blob state need not survive a restart.

BlobStore implementation that delegates to an OKD (Onderwijs Koppeling voor Documenten) document service via the generated client in lib-data-store-okd-openapi. Reach for this in Dutch MBO education contexts where credential artefacts and attachments must live in the OKD platform rather than in IDK-local storage.

Public blob / object-storage contracts. It defines the descriptor, metadata, info-resolver, and event model that higher-level modules (credential design, schema registry, tenant asset storage) use to treat blob content uniformly, independent of where the bytes actually live.

Runtime for the credential-design surface in lib-data-store-credential-design-public. It stores render metadata, localisation, and branding for issued credentials, typically on top of a BlobStore so design artefacts live alongside the other per-tenant assets.

Public contract for credential-design storage: render metadata, localisation data, and branding that drive how an issued credential is presented to a holder or verifier. Depend on this module from issuer-side code that needs to look up or write design data without binding to a particular storage backend. Runtime implementations live in lib-data-store-credential-design-impl.

Shared runtime scaffolding for concrete KvStore backings. It supplies the delegation, serialization, and namespacing helpers every backing needs, so impl-memory, impl-kottage, and similar modules only have to implement the storage-specific pieces.

Kottage-backed KvStore implementation, suitable for durable multiplatform storage on mobile and JVM targets. Reach for this when session state, caches, or small persisted data need to survive process restarts without standing up a full database.

In-memory KvStore implementation. Intended for tests and short-lived session state where durability is not required.

Public key-value store contracts used across IDK for session state, caches, and lightweight persistence. It defines the KvStore surface, its factory and namespace model, and the codec abstractions (including a kotlinx.serialization JSON codec) so consumer code can stay agnostic of the underlying storage technology.

Reference OKD server that implements the generated OpenAPI surface from lib-data-store-okd-openapi. It lets the OKD client and the OKD-backed BlobStore (lib-data-store-blob-impl-okd) be exercised end to end in local development and integration tests without depending on a real OKD deployment. Not intended as a production server.

Shared data model for IDK's "everything is a party" view of identity and tenancy. It exposes the filter and pagination types that identity, tenant, and contact stores use in a uniform way, so query code over those stores stays consistent across modules.

Runtime for the schema-registry contracts in lib-data-store-schema-registry-public. It wires the registry onto a BlobStore and the IDK command system so that versioned credential or data schemas can be fetched, published, and referenced through the same machinery as any other blob artefact.

Public schema-registry API for versioned credential and data schemas. It gives issuer and verifier code a stable contract to resolve, publish, and reference schema documents without knowing that the storage is a blob store underneath.

Shared capability model that every IDK DID method provider implements against. It describes what a method supports (key management, lifecycle operations, representation) and the metadata the DID manager and resolver need to pick the right provider per operation. Model-only; the method providers themselves live under lib-did-methods-*, and the manager and resolver runtimes live under lib-did-manager-* and lib-did-resolver-*.

Runtime for the DID manager contracts in lib-did-manager-public. It holds the provider registry, routes create, update, and deactivate calls to the right method provider, and drives the DID creation DSL through to the method layer. Method providers (lib-did-methods-key, lib-did-methods-jwk, lib-did-methods-web, etc.) plug in via the registry rather than being hard-coded here.

Public DID lifecycle API: the manager surface that owns creation, update, and deactivation of DIDs, the provider contract each DID method implements, and the creation DSL used by higher-level flows (for example when an OID4VCI issuer needs a new signing DID for a credential). Method-agnostic on purpose, so downstream code stays decoupled from which methods are actually registered.

did:jwk method provider and resolver. Adds support for DIDs whose document is derived directly from a JWK, which is a good fit for ephemeral issuer and holder keys that do not need any ledger or hosting infrastructure.

did:key method provider and resolver. Covers DIDs whose identifier is a self-describing encoding of a public key, which is the simplest option for keys that do not need to be discovered externally and ships with the curve-decoding utilities needed for the supported key types.

did:web method provider and resolver. Resolves DIDs to a /.well-known/did.json document (or a path-based variant) over HTTPS, which is the usual choice when a DID subject controls a public hostname and wants discoverable metadata without a ledger.

Public contract for storing managed DID records (identifiers, key references, lifecycle state). It is the surface the DID manager reads and writes against; concrete storage (in-memory or SQLite) lives in sibling modules.

In-memory implementation of the DidRepository contract from lib-did-persistence-api. Intended for tests and ephemeral deployments where DID records do not need to outlive the process.

SQLDelight-backed durable implementation of the DidRepository contract from lib-did-persistence-api. Reach for this when managed DIDs must survive process restarts on a platform that can host a SQLite database.

Runtime for the DID resolution contracts declared in lib-did-resolver-public. This is what you depend on when you actually need to resolve and dereference DIDs, rather than just describe them: the registry, the resolution cache, the external-identifier resolution service, and the command bodies that higher layers call into.

Public DID resolution API. It defines the resolver surface, the resolution and dereferencing types, the resolution cache contract, and the command bindings higher layers dispatch through when they need to resolve a DID without knowing which method is in play.

HTTP front-end that exposes the IDK resolver registry over the Universal Resolver contract. Pull it into a deployable Ktor server when you want other systems to consume IDK's resolver stack as a standard Universal Resolver endpoint rather than as an in-process library.

Runtime for the identity-matching contracts in lib-identity-matching-public. It realises the command bodies for creating, looking up, listing, and deleting privacy-preserving identity matches across sources, using hashed and encrypted identifiers so raw identity data never has to leave its origin.

Public API for privacy-preserving identity matching. It defines the hashed-identifier and encrypted-payload primitives, the reconciliation-oriented crypto surface, and the command bindings that let one source match an identity against another without disclosing raw identifiers.

Runtime for the identity-reconciliation contracts in lib-identity-reconciliation-public. It realises the session lifecycle (create, get, complete, cancel) that drives reconciliation of attributes coming in from multiple identity sources into a single canonical view.

Public API for reconciling identity attributes across sources. It exposes the attribute-mapping and normalisation surface, the canonical-attribute rule model, and the OIDC connection resolver, so attributes collected from multiple providers can be reshaped into a canonical form for matching and resolution.

Runtime for the identity-resolution contracts in lib-identity-resolution-public. It resolves a subject to a matched identity by composing the matching primitives from lib-identity-matching-public with the application's resolution policy.

Public identity-resolution API. It defines the resolver surface, the command bindings, and the error model callers use to resolve an input subject into a matched identity without binding to a particular matching backend. Sits one level above lib-identity-matching-public: matching asks "do these refer to the same person", resolution asks "given this input, which identity record is it".

OIDC driver for IDK Identity Verification. It performs a verification run by delegating to an external OpenID Connect identity provider and mapping the returned claims back onto the IDV attribute model. Reach for this when the trusted authority for a given IDV flow is an existing IdP (for example a national or federated OIDC provider), rather than a credential held in a wallet.

Public contract for Identity Verification (IDV): the command surface that describes an IDV definition, runs a driver-agnostic verification flow, and evaluates predicates over the returned attributes. It deliberately does not pick a verification mechanism; that is the job of a driver module such as lib-idv-oidc (OIDC IdP) or lib-idv-wallet (OID4VP wallet).

Wallet driver for IDK Identity Verification. It runs an IDV flow by requesting credentials from a holder wallet over OID4VP, taking advantage of the verifier stack already present in IDK. Reach for this when the source of truth for a verification is a credential in a user-controlled wallet, not an external IdP.

Aggregator module that bundles the -public model and the -impl codec runtime for ISO 18013-5 mdoc into a single dependency. Reach for it from consumer modules that want the full mdoc core surface in one artifact and do not care to separate contract from implementation.

Runtime CBOR codecs for the ISO 18013-5 mdoc document structures modelled in lib-mdoc-core-public: device authentication, document envelope, issuer-signed items, and device-signed items. It is the module that actually encodes and decodes mdoc payloads over the CBOR primitives from lib-cbor-*.

Public data model for ISO/IEC 18013-5 mdoc, the mobile driving licence and more general mdoc document formats. It defines the data-element model, device-authentication types, item-request shapes, and the codec contracts the rest of the mdoc stack relies on.

Aggregator that bundles the -public and -impl halves of the mdoc engagement / data-transfer layer. Reach for it from consumer modules that want the full engagement surface in one artifact.

Runtime for the mdoc engagement contracts in lib-mdoc-datatransfer-public. It orchestrates a device-engagement instance end to end: picking the right transport (BLE, NFC, OID4VP, REST), assembling the engagement payload on the holder side, and dispatching lifecycle events through the internal mdoc event hub so higher-level UI and logging can follow along.

Public API for mdoc device engagement and data transfer. It defines the engagement-factory surface, the engagement-instance lifecycle, configuration validation, the presets used to pre-pick common transport combinations, and the event adapter downstream code subscribes to.

Reader-side of the mdoc exchange. It covers the engagement manager, the device-request builder, and the reader connection surface that a verifying application uses to consume an mdoc presentation, in both the ISO 18013-5 proximity scenario and the -7 online scenario.

Runtime for the mdoc BLE transport surface declared in lib-mdoc-transport-ble-public. It is the central-role (reader-side) implementation that turns the platform-neutral BLE primitives from lib-data-link-ble-public into the ISO 18013-5 device-retrieval transport.

Public surface of the BLE transport for mdoc (ISO 18013-5 device retrieval): the central-service and connection-method contracts, the data-channel model, and the event-dispatcher that higher layers subscribe to.

NFC engagement and handover for mdoc (ISO 18013-5). It builds the handover-select message a reader presents over NFC, handles the associated CBOR codecs, and maps the handover payload into the BLE connection method used for the actual data exchange. In other words: NFC here is the rendezvous, not the data transport.

OID4VP binding that carries an mdoc exchange over the ISO 18013-7 online flow. It adapts the verifier-initiated OID4VP request onto the mdoc transport surface, and maps DCQL queries into mdoc device-requests so the same wallet and reader code can participate in either the proximity (18013-5) or online (18013-7) scenario.

REST-based transport for mdoc exchanges, useful when the parties speak over an HTTP back-channel rather than a proximity link. Typically used in server-to-server integrations and in test setups that do not involve a physical BLE or NFC stack.

Runtime for the OAuth2 client contracts declared in lib-oauth2-client-public. It handles the client-side flows end to end: constructing authorization-request URLs (including JAR and PAR variants), applying client authentication to token requests, and parsing authorization and token responses.

Public OAuth2 client contract. It defines the client surface and the command bindings for the authorization-code lifecycle, JAR (JWT-secured authorization requests), PAR (pushed authorization requests), metadata discovery, and token exchange. The API is deliberately protocol-focused: higher-level flows (for example OID4VCI holder) build on top of these commands rather than replicating them.

Runtime for the shared OAuth2 / OIDC command surface declared in lib-oauth2-common-public. It supplies the pieces both clients and servers need in identical form: id_token validation, JARM (JWT-secured authorization response mode) creation and verification, and OIDC token-claim extraction, so these concerns do not get re-implemented per side.

Shared OAuth2 / OIDC command contracts used identically by clients and servers: client authentication, DPoP proof handling, id_token operations, token introspection, and revocation. Centralising these avoids subtle drift between client and server implementations of the same primitives.

Public JWT validation contracts for OIDC-fronted services: the validation-service surface, the JWKS provider abstraction, and the IdP registry and configuration types. It is what resource servers or OID4VCI issuers depend on when they need to validate a JWT without baking in a specific IdP or JWKS fetch strategy.

Runtime JWT validation for OIDC-fronted services. It discovers IdP metadata, caches JWKS, and verifies signatures, issuer, and audience claims against the registered IdP configuration, realising the contracts in lib-oauth2-jwt-validation-api.

Runtime for the Authorization Server contracts declared in lib-oauth2-server-authorization-public. It realises the full authorization-server command graph: authorization code, session and response construction, attestation-based challenges, and the discovery metadata endpoint. Supports authorization code, PAR, JAR, and attestation flows in one coherent graph.

Public command API for building an OAuth2 / OIDC Authorization Server. It defines the endpoint-oriented command surfaces (authorization, client authentication, discovery, attestation, IAE, id_token) that the deployable AS services call into to drive each protocol endpoint.

Runtime for the Resource Server contracts declared in lib-oauth2-server-resource-public. It validates access tokens, introspects tokens against the AS, verifies DPoP proofs, and keeps the token and DPoP-nonce caches that the hot path relies on (in-memory by default; swap in durable caches when the deployment needs them).

Public command API for an OAuth2 / OIDC Resource Server: the access-token validation, introspection, and DPoP-proof verification surface, plus the token and DPoP-nonce cache contracts.

Runtime for utilities shared across the OID4VC family (OID4VCI and OID4VP). Today it is primarily the default QR code service used to render credential-offer and authorization-request QR codes at an issuer or verifier.

Shared types for the OpenID for Verifiable Credentials family (OID4VCI and OID4VP): credential format identifiers, cryptographic binding methods, display properties, proof types, and QR code options. It is the lowest common layer so issuer, holder, and verifier modules agree on the terminology without depending on each other.

Shared OID4VCI runtime used by both the issuer and holder sides: validators for credential offers, credential requests, issuer metadata, and notifications, plus the external-identifier resolution service that maps issuer identifiers onto trust metadata.

Shared OID4VCI model and DSLs used by both issuer and holder sides. Data classes mirror the OID4VCI spec wire format (credential configurations, value objects, and so on), and the DSLs let issuer and holder code compose command pipelines, metadata, and issuer-authenticated-encryption (IAE) payloads without per-side duplication.

Runtime for the OID4VCI holder contracts declared in lib-openid-oid4vci-holder-public. It realises end-to-end holder (wallet) behaviour: constructing authorization requests, exchanging authorization codes and pre-authorized codes for tokens, and producing credential-request proofs bound to the holder's key. Config-driven so wallets can stay data-driven about which issuers and flows they support.

Public API for the OID4VCI holder (wallet) side. It defines the holder command surface and the flow DSLs for credential-offer, authorization-code, and pre-authorized-code flows, so wallet code can walk an issuance flow without open-coding the protocol.

Runtime for the OID4VCI issuer contracts declared in lib-openid-oid4vci-issuer-public. It realises core issuer behaviour: building issuer metadata (signed and unsigned), creating credential offers, bridging to the authorization server, and providing a default (no-op) attribute contributor that downstream code typically replaces with its own projection from business data onto credential claims.

Public API for the OID4VCI issuer side. It defines the issuer command surface, the issuer and issuance-policy configuration model, the authorization-server bridge contract, and the credential-attribute contributor hook an application implements to project business data into credential claims.

Service-layer runtime that sits between the raw OID4VCI issuer commands and the deployable REST server. It realises the session-oriented endpoints a typical deployment needs (create, delete, and status for credential offers), backed by a key-value credential-offer session store.

REST-facing service contract for OID4VCI issuers. It adds the operational concerns that the core protocol surface deliberately does not cover: session management for credential offers, a deployable configuration model, typed events for observability, and the session-store abstraction so sessions can live in any KvStore-backed substrate.

Runtime for the auth-bridge contracts in lib-openid-oid4vp-auth-bridge-public. It drives the session lifecycle that turns an OID4VP verification into a first-class authentication outcome: creating an auth session tied to a VP request, completing the session once a presentation arrives, and tracking status in between. It also integrates with the reconciliation layer so claims gathered from the wallet land in the canonical-attribute pipeline.

Authentication bridge that lets a service use an OID4VP verification as an authentication step. It defines the bridge surface, a configuration provider, the projection hook that maps wallet-disclosed attributes onto an application's auth subject, and the error model for the flow.

Runtime for the shared OID4VP contracts in lib-openid-oid4vp-common-public: parsing and validating client IDs, resolving scopes, and parsing transaction-data parameters, reused by both holder and verifier sides.

Shared OID4VP model used by both holder and verifier: authorization-request shape, client-ID scheme, client metadata, credential format identifiers, and the command bindings both sides dispatch through. Keeps the two sides talking the same vocabulary without a direct dependency.

Digital Credentials Query Language (DCQL) data model used by OID4VP verifiers to describe what they want presented and by holders to reason about what they can present. It covers the query shape, the response structure, per-format metadata (mdoc, SD-JWT VC, and so on), and the trusted-authority and error types the query layer needs.

Runtime for the OID4VP holder contracts in lib-openid-oid4vp-holder-public. It parses the verifier's authorization request, resolves client metadata, and constructs the authorization response (including the selected-credential payload). This is the holder-side counterpart to the verifier module.

Public API for the OID4VP holder (wallet) side. It defines the holder surface, the holder-side models, and the command bindings a wallet uses to respond to a verifier's authorization request.

Runtime for the universal OID4VP service layer declared in lib-openid-oid4vp-universal-public. It manages verifier-side authorization-request sessions end to end (create, delete, status) and assembles the verified-data projection a deployed service hands back to its callers.

Public API for the OID4VP universal service layer, which sits above the raw verifier runtime and coordinates authorization-request sessions across request, status, and delete phases. It is the surface a deployable verifier service works against when it has to manage many concurrent OID4VP sessions (create, poll for status, tear down) rather than orchestrate a single request.

Runtime for the OID4VP verifier contracts declared in lib-openid-oid4vp-verifier-public. It builds unsigned and signed authorization requests, produces the authorization-request URIs wallets consume, and drives the request-object signing configuration from the verifier's declared policy.

Public API for the OID4VP verifier side. It defines the verifier command surface, the authorization-session contract an application implements to persist and look up verification flows, the client-metadata and DCQL-query configuration model, and the callback shape the verifier uses to notify the embedding app about session state transitions.

Runtime for the SD-JWT contracts declared in lib-sdjwt-public. It issues SD-JWTs with per-claim disclosures and optional key binding, constructs holder presentations that reveal only the required subset, and verifies both envelope signatures and the disclosure digests that tie claims back to the issued token.

Public contracts for IETF SD-JWT (Selective Disclosure JWT). It defines the issue, present, and verify command surface, the disclosure and key-binding model, and the configuration hooks consumers need to produce or validate SD-JWTs without coupling to the runtime.

Runtime for the trust-core contracts in lib-trust-core-public. It drives entity discovery, trust-anchor refresh, and revocation checking, dispatching to whichever source-specific validators (lib-trust-etsi, lib-trust-x509, lib-trust-did, lib-trust-oidfed) happen to be on the classpath.

Core trust framework contract. It defines the cross-cutting surface every trust source in IDK implements against: entity discovery, trust-anchor retrieval and refresh, and revocation checking. The point of this module is to give the rest of the platform a single trust abstraction that does not care whether the underlying trust mechanism is ETSI LOTL, X.509, DID, or OpenID Federation.

DID-based trust validator plugged into the trust-core framework (lib-trust-core-public). It treats DIDs as the trust anchors, resolving the DID document (via IDK's DID resolver stack) and deriving entity info and validation decisions from the verification methods and service endpoints it declares.

ETSI / eIDAS trust-list validator plugged into the trust-core framework. It resolves ETSI Lists of Trusted Lists (LOTLs), walks them into concrete trusted-service certificates, and validates counterparty certificates against the resulting anchor set. Reach for this in EU-regulated deployments where trust must be grounded in the eIDAS LOTL.

Data model for ETSI Lists of Trusted Lists (LOTLs), as used by eIDAS trust-list processing. It describes the typed shape of a LOTL entry (identity, jurisdiction, roles, service endpoints, localised metadata) so that LOTL payloads can be parsed and matched without coupling consumers to the XML schema.

OpenID Federation trust validator plugged into the trust-core framework. It walks entity statements, follows the trust chain up to configured anchors, and produces the validation decision the trust-core runtime exposes to callers.

X.509 PKI trust validator plugged into the trust-core framework. It validates counterparty certificates against configured trust stores (PKIX path building, revocation where supplied) and extracts entity info from the certificate subject and extensions.

Shared Compose Multiplatform primitives for component-level theming. It defines the component-token surface (the fine-grained tokens an individual Compose component reads from its environment) and the CompositionLocal that carries them through the tree, so that downstream component libraries do not each have to invent their own token plumbing.

Deployable Ktor server that exposes the IDK KMS over HTTP. It is the server-side of the remote-KMS split: applications running on constrained platforms (or that want to centralise key custody) run the REST KMS provider client (lib-crypto-kms-provider-rest) against this service, while the actual cryptographic operations stay behind the service boundary.

Deployable Ktor server that exposes an OAuth2 / OIDC Authorization Server over HTTP. It mounts the authorization-server command graph from lib-oauth2-server-authorization-impl behind standard OAuth2 and OIDC endpoints (authorization, token, introspection, and so on), producing a ready-to-deploy AS that the rest of the platform (including the OID4VCI issuer) can federate against.

Deployable Ktor server that exposes an OID4VCI issuer over HTTP. It mounts the OID4VCI endpoint surface (credential offer, issuer metadata, credential, deferred credential, and the issuer-metadata variants for JWT VC profiles) on top of the OID4VCI issuer runtime, producing a deployable issuer service.

Deployable Ktor server that exposes an OID4VP verifier over HTTP. It mounts the universal OID4VP service layer (lib-openid-oid4vp-universal-impl) behind REST endpoints for creating authorization requests, polling their status, and tearing them down, which is the shape an embedding application typically wants from a verifier: stateful session management, not per-request orchestration.