AnkaSecure Key Management SDK - Overview
Version: 3.4.0
Language: Java 17
Artifact:co.ankatech:ankasecure-key-management-sdk:3.4.0(Maven Central)
Distribution: Signed, non-obfuscated JAR (client library, not a deployable service)
Get it: Downloads — Maven/Gradle coordinates, JAR, javadoc and checksums
Key management as an administrative workload — the counterpart to the Runtime SDK
The Key Management SDK creates, rotates, retires and requests the destruction of the keys of one tenant, and governs who may use them (exchange contexts, exchanges, capability grants, constraint policies, internal cryptographic use cases). It performs no cryptographic operation: encryption, signing and their inverses belong to the Runtime SDK.
The AnkaSecure Key Management SDK is a Java library for a product or a pipeline that manages the keys of one tenant without a person at the keyboard. It signs in as an administrative workload* of the tenant, and every call acts in the tenant the workload's token names: no method takes a tenant.
Its surface is fixed and deliberate. People administer everything else in the Admin Console: users, roles, tenants, tenant policies, key backends, and the approval or rejection of quorum requests. An operation the SDK does not expose is not reachable through it.
Runtime SDK (ankasecure-sdk) | Key Management SDK (ankasecure-key-management-sdk) | |
|---|---|---|
| Artifact | ankasecure-sdk-3.4.0.jar | co.ankatech:ankasecure-key-management-sdk:3.4.0 |
| Principal | A runtime actor (client_credentials) | An administrative workload (private_key_jwt or a federated token, DPoP-bound) |
| Does | Encrypt, decrypt, sign, verify, re-encrypt, re-sign, PKCS#7 migration, read-only key lookups | Keys, versions, rotation, destruction requests, exchange governance |
| CLI | AnkaSecureCLI | ankasecure-km |
1. What it covers
| Group | Accessor | Operations |
|---|---|---|
| Keys | keys() | list, get, create, update metadata, import a key, import or analyse a keystore, export the public part, lifecycle-cause verdicts, supported algorithms, suspend, reactivate, revoke, archive |
| Key versions | materials() | list, get, revoke |
| Rotation | rotation() | rotate now, rotation admissibility, the automatic-rotation schedule (read, replace) and its execution history |
| Destruction | destruction() | request the destruction of a key or of one version, cancel it, read the key's destruction orders |
| Own quorum requests | quorumRequests() | list, get, cancel (withdraw) — never approve or reject |
| Exchange contexts | exchangeContexts() | list, list per application, get, create, update, delete, suspend, resume, close |
| Exchanges | exchanges() | list, create, get, update, discard a draft, clone, validate, preview activation, activate, suspend, resume, revoke |
| Capability grants | capabilityGrants() | list, create, preview, get, delete |
| Constraint policies | constraintPolicies() | list, create, get, update, delete |
| Internal cryptographic use cases | internalCryptoUseCases() | list, create, get, delete, suspend, resume |
| Directory (read-only) | directory() | applications, actors, counterparty types |
Request and response bodies are the generated models of the Key Management contract (co.ankatech.keymanagement.client.keymanagement.model), so every member an operation accepts can be set. Each listing takes a query record (co.ankatech.ankasecure.keymanagement.query) whose components are exactly the operation's query parameters, starting from firstPage().
2. Key characteristics
- Workload sign-in only.
authenticateWorkload(WorkloadCredential)is the one sign-in. There is no person sign-in, no session store and no tenant switch. - No shared secret. The workload proves itself with a
private_key_jwtassertion signed by its own key, or with a token an issuer the platform trusts minted for it. The access token is DPoP-bound (RFC 9449) to a key generated in memory for the SDK instance and is renewed before it expires. - One origin. The SDK talks to the origin you configure, and the token endpoint the deployment publishes must be on that origin; DPoP proofs and the assertion audience name it. No request follows a redirect.
- Approval stays with people. A destruction request always opens a quorum request (Key Destruction); an operation the tenant's quorum policy gates throws
QuorumApprovalPendingExceptionwith the request's receipt. The SDK reads and withdraws its own requests; it cannot approve or reject them. - Typed errors. A refusal is a
KeyManagementSdkExceptionwith the HTTP status and the RFC 9457 problem members. - Secret hygiene. No key, assertion, proof or token appears in a log line, an exception message or
toString(). The client secret of a new internal cryptographic use case is returned once, in a zeroizable holder. - Java 17 language level, so older client runtimes can consume it.
3. Planes
The platform separates provisioning from operation. The Key Management SDK and the Runtime SDK are the two programmatic entry points, one per plane, and they hold different credentials: an administrative workload for key management, a runtime actor for cryptography. A product that does both registers both — the workload provisions the keys and the capability grants, and the runtime actor uses them.
See SDK & CLI Overview* for where each tool sits.
4. Where to go next
- Prerequisites — the workload, its key and its scopes.
- Quick Start — sign in and list the tenant's keys.
- Usage Guide — every group, with examples.
- Key Destruction — request, approval, cooling-off and automatic execution.
- Security Best Practices — custody of the workload key, error handling.
- Downloads — coordinates, JARs and checksums.
Version: 3.4.0
Last updated: 2026-10-26