Services

IDK services are pre-built, deployable components that expose IDK functionality as HTTP endpoints. Each service is a separate Gradle module you can include in your server application. They use the Ktor integration plugin and a command-based HTTP adapter pattern to translate incoming HTTP requests into IDK operations.

Available Services

Service	Module	Description
KMS REST API	services/kms	Exposes key management operations (generate, store, list, sign, verify) as REST endpoints
OAuth2 Authorization Server	services/oauth2-as	Full OAuth2/OIDC authorization server with token, authorize, introspect, revoke, PAR, and JWKS endpoints
OID4VCI Issuer	services/oid4vci-issuer	Holder-facing OID4VCI issuance endpoints plus issuer-side integration APIs for creating and managing issuance flows
OID4VCI Holder	services/oid4vci-holder	Holder (wallet) endpoints for credential acquisition: session management, auth code exchange, proof creation, and credential requests
OID4VP Verifier	services/oid4vp-verifier	Wallet-facing OID4VP verifier endpoints plus the verifier-facing Universal OID4VP adapter
Ktor Plugin	services/ktor	The KotlinInjectPlugin that bridges IDK's Metro DI with Ktor's request pipeline. Used by all other services

CommandBackedHttpAdapter Pattern

Every service follows the same structural pattern. HTTP endpoints are implemented as individual HttpEndpointCommand instances. Each command handles a single operation: parsing the inbound request, invoking the relevant IDK service, and returning a response.

Commands are grouped into a CommandBackedHttpAdapter, which maps URL paths and HTTP methods to the appropriate command. At startup, the DI system auto-discovers all adapters contributed to the service's scope and registers them with the HTTP adapter dispatcher. This means adding a new endpoint is a matter of writing a command class and contributing it to the adapter. No manual route wiring required.

Composing Services

You can run multiple services in a single Ktor server by including their Gradle modules and installing their adapters. For example, a server that provides both credential issuance and verification would include the services/oid4vci-issuer and services/oid4vp-verifier modules. The Ktor plugin merges all contributed adapters into one dispatcher, so there is no conflict between services as long as their endpoint paths do not overlap.

fun Application.module() {
    install(KotlinInjectPlugin) {
        appGraph = myAppGraph
    }

    // All adapters from included service modules
    // are auto-discovered and mounted
    installUniversalHttpAdapters {
        pathPrefix = "/api"
    }
}

Next Steps

• Ktor Server Integration: Details on the KotlinInjectPlugin and Universal HTTP Adapters
• Dependency Injection: Understanding the App/User/Session scope architecture
• Examples: Working applications that combine multiple services