Select release
Overview

Home

Concepts and Architecture

PowerAuth Integration

EUDI Wallet Flows

Backend Key Storage

Comparison with the German Model

API Reference

General Principles

PowerAuth Unit API

EUDI API

Backend Keys API

Operations

System Requirements

Configuration Properties

Database Setup

Docker Deployment

HSM Setup

Monitoring

Development

Build and Test

SoftHSM2 Development Setup

Reference

Key Naming Conventions

Glossary

Glossary

Edit on Github Send Feedback develop

Terms and abbreviations used in the Secure Keystore documentation, in alphabetical order.

Term Meaning
Activation A PowerAuth activation: the registration of one app installation on one device in PowerAuth Server.
ARF The EUDI Architecture and Reference Framework, which defines the roles and requirements of an EUDI wallet.
Backend caller A backend that calls the keystore with a bearer token (mutual TLS later): the Wallet Integration Server (unit calls) or a backend component (backend-key calls).
Backend component A Wultra server that keeps its long-term signing keys in the keystore: PowerAuth Server or a diw-gateway service.
Bind key The AES-256-GCM key bind-<domain>-<n> that seals each wrapped key together with what binds it (owner, purpose and, for user keys, the device-key thumbprints). A copied or edited wrapped key is refused.
c_nonce A fresh value from the credential issuer that a key attestation or proof JWT must contain, so it cannot be replayed.
Credential key A user key (purpose CREDENTIAL) to which an issuer binds one credential. The wallet signs presentations with it.
Device keys The private keys of a PowerAuth activation, kept in the PowerAuth SDK’s vault on the phone: ECDSA P-384, plus ML-DSA for a hybrid activation. They sign every user request.
diw-gateway Wultra’s EUDI issuance and verification backend, with the services diw-issuer, diw-connector (the OAuth authorization server) and diw-verifier.
Domain A group of HSM keys with one algorithm family and one storage mode, for example user-ecdsa or powerauth-activation-ecdsa. See Key Naming Conventions.
DPoP Demonstrating Proof of Possession (RFC 9449): binds OAuth tokens to a key held by the client.
eIDAS level of assurance The confidence level of an electronic identification means under the eIDAS regulation: low, substantial or high.
Envelope The end-to-end encryption of a user request and its response between the PowerAuth SDK and the keystore. See End-to-End Encryption Envelope.
FFM The Java Foreign Function & Memory API, which the keystore uses to call the PKCS#11 library.
Generation <n> The number of a key set. A new generation is added when keys rotate; older ones keep working until they are retired.
HAIP The OpenID4VC High Assurance Interoperability Profile, which fixes the options of OpenID4VCI and OpenID4VP for high-assurance wallets.
HSM Hardware security module: a device that keeps keys and performs cryptographic operations without exposing the keys.
KA Key attestation: a JWT signed by the wallet provider that vouches for credential keys and how they are protected. Issuers require it before they issue a credential.
KB-JWT Key-binding JWT: the JWT a wallet signs with the credential key when it presents an SD-JWT VC, so the verifier knows the holder has the key.
Key set One generation <n> of a domain’s wrap key and bind key.
Key type The algorithm of a key: ECDSA_P256, ECDSA_P384, MLDSA_65 or MLDSA_87.
mdoc A mobile document in the ISO/IEC 18013-5 format, the alternative to SD-JWT VC for credentials.
OpenID4VCI OpenID for Verifiable Credential Issuance, the protocol for issuing credentials to a wallet.
OpenID4VP OpenID for Verifiable Presentations, the protocol for presenting credentials to a verifier.
PAR Pushed authorization request (RFC 9126): the wallet sends its OAuth authorization request to the authorization server directly.
PKCS#11 The standard API for talking to an HSM.
PoP Proof of possession: a JWT signed with the WIA key that the wallet sends together with the WIA, so the authorization server knows the wallet holds the key.
PowerAuth Server Wultra’s server that manages activations, verifies vault unlocks and provides the decryption keys of the envelope.
Proof JWT The OpenID4VCI proof of type jwt that some issuers require in a credential request. The keystore can sign it with a credential key.
Provider CA The wallet provider’s certificate authority that issues the certificates of the KA and WIA signing keys.
Purpose What a user key may be used for: CREDENTIAL, WALLET_INSTANCE or USER_SIGNING. It is sealed in the wrapped key.
SD-JWT VC Selective-disclosure JWT verifiable credential: a credential format whose claims the holder can disclose one by one.
Seal To encrypt a wrapped key with the bind key (AES-GCM), together with what binds it.
Signed request The JWS, in the general JSON serialization, that the wallet signs with the device keys for every user request. See Signed Request.
Storage mode How a domain’s keys are kept: resident (a persistent object in the HSM) or wrapped (handed out wrapped, nothing kept in the HSM).
Token A PKCS#11 token: a logical HSM partition with its own PIN, for example keystore-<env>-user. See Tokens.
TS3 An EUDI wallet technical specification that defines the wallet unit and key attestations.
Unit The keystore’s record of one PowerAuth activation. The unit id is the activation id.
User-signing key A user key (purpose USER_SIGNING) for signatures outside the EUDI protocols. One per activation: P-384, plus ML-DSA for a hybrid activation.
Vault unlock The PowerAuth step in which the user enters the PIN or uses biometry, PowerAuth Server verifies it, and the SDK releases the device keys.
Wallet Integration Server The wallet provider’s backend. It serves the vault unlock, registers and revokes units, and forwards the wallet’s requests to the keystore.
WIA Wallet instance attestation: a JWT signed by the wallet provider that proves a genuine wallet to issuers. It names the WIA key.
WIA key A user key (purpose WALLET_INSTANCE) that the WIA names in cnf. The wallet signs PoPs with it.
Wrap key The AES-256 key wrap-<domain>-<n> that encrypts (wraps) private keys inside the HSM. Every key it restores is non-extractable and sign-only.
Wrapped key A private key encrypted under the wrap key and sealed under the bind key. Its holder stores it and sends it back for each signature.
WSCA / WSCD Wallet secure cryptographic application / device: in the ARF, the component that protects the wallet’s keys, and the hardware behind it. Here, the keystore and its HSM.
Last updated on Nov 11, 2026 (21:37) Edit on Github Send Feedback
On this page:

develop

Secure Keystore