Repository navigation
[OID4VCI] Support for ETSI Trust Lists #48106
Description
Description
Add native ETSI trust list / LoTE support to Keycloak as part of broader EUDI Wallet support.
The immediate consumer is issuance. When Keycloak acts as an issuer in EUDI Wallet flows, it needs to establish trust in the wallet based on the EUDI trust model. In that model, this trust is not derived from a (statically configured) key alone. It is derived from ETSI trust lists and the trust anchors and semantics they provide.
That being said, it will also be needed when Keycloak implements the verification part.
A LoTE is a List of Trusted Entities. In ETSI TS 119 602, a LoTE is not just a list of certificates or public keys. It represents which entities are trusted, under which trust scheme, for which service scope, and with which status (expiry).
The EUDI ARF requires the issuer-side party to validate wallet-provided attestation using trust anchors from the relevant Wallet Provider LoTE. In other words: Keycloak, as issuer, needs to trust the wallet based on ETSI trust material. The reverse trust direction also exists, where the wallet validates the issuer side against separate trusted lists, but this is out of scope of this proposal (though might be very well relevant later on so other verifiers can actually trust credentials issued by Keycloak).
Value Proposition
- Align Keycloak with the ARF trust model used in the EUDI Wallet ecosystem.
- Support issuer-side EUDI flows against real trust infrastructure instead of only static key configuration.
- Avoid duplicating ETSI trust-list handling across wallet-related features and extensions.
- Provide a foundation that can later be reused for verification support as well.
Goals
- Add native support for ETSI trust lists / LoTEs in Keycloak.
- Support issuer-side trust decisions based on:
- LoTE-Type/Scheme (for example
.../LoTEType/EUWalletProvidersList) - service scope (for example
http://uri.etsi.org/19602/SvcType/WalletSolution/Issuance) - the public keys in the correct scope
- trust-list authenticity (signature of the trust list itself)
- freshness / update handling (
NextUpdate)
- LoTE-Type/Scheme (for example
- Make this usable first for issuer-side EUDI Wallet support.
- Keep the design reusable for later verification-side support.
Non-Goals
Replace simple key- or certificate-based implementations where ETSI support is not needed.
Discussion
Keycloak OAuth-SIG
Notes
Possible Implementation Approach
Introduce a Trust Source SPI as an abstraction of different ways to establish trust. This was proposed by @dteleguin / @thomasdarimont in the OAuth-SIG.
It is notably another direction than the recent SPIFFE support, which relies on identity providers.
Trust List Example
A concrete example is the German sandbox environment, which publishes signed trust lists here:
https://bmi.usercontent.opencode.de/eudi-wallet/test-trust-lists/
References
-
EUDI ARF main document
https://eudi.dev/latest/architecture-and-reference-framework-main/ -
EUDI ARF Annex 2, high-level requirements by topic
Relevant here are the issuance requirements stating that the issuer-side party accepts trust anchors from the Wallet Provider LoTE, validates wallet attestation evidence against that LoTE, and that the Wallet Provider LoTE format complies with ETSI TS 119 602 v1.1.1 Annex .
https://eudi.dev/latest/annexes/annex-2/annex-2.02-high-level-requirements-by-topic/ -
ETSI TS 119 602 V1.1.1, Lists of trusted entities
https://www.etsi.org/deliver/etsi_ts/119600_119699/119602/01.01.01_60/ts_119602v010101p.pdf -
ETSI TS 119 182-1 V1.2.1, JAdES digital signatures; Part 1
Relevant for signed JWT/JAdES trust-list representations such as those published in sandbox environments.
https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.02.01_60/ts_11918201v010201p.pdf
Activity
dominikschlosser commentedon May 25, 2026
#48869 should now allow to introduce an ETSI based version of a trust idp
dominikschlosser commentedon Aug 13, 2026
I take this