Upgrading from rc.10 to rc.11¶
What you must change, and what will behave differently, when you move a HelixIAM install from v1.0.0-rc.10 to v1.0.0-rc.11.
What rc.11 is
rc.11 (2026-10-15) closes out the EUDI Wallet program: EU reference-wallet interop, an OpenID Foundation conformance self-run, the W3C Digital Credentials API, a verify-only / step-up mode, EU trusted lists for wallet trust anchors, a Terraform resource for the wallet identity-provider connection, and realm-delete cleanup of wallet secrets. It also moves the application onto Jackson 3 and closes the Info/Low findings of an internal penetration test (see Internal penetration test, 2026-10-15). The source is the "Upgrade checklist" at the top of the rc.11 entry in CHANGES-1.0.md and docs/UPGRADING.md in the product repository.
Before you upgrade: checklist¶
| # | Do this | Applies if |
|---|---|---|
| 1 | Upgrade every replica in one step, or drain wallet transactions, or turn off trusted_authorities for the duration of the roll |
you use wallet providers and roll out gradually |
| 2 | Set signer-expiry-grace-days before upgrading if you use EU trusted-list sources |
you configured helix.wallet.trusted-lists.* |
| 3 | Turn on the flow engine before binding an eudi-wallet-verify step to a flow |
you use, or plan to use, the verify-only / step-up mode |
| 4 | No action needed for the new verified_claims scope, unless a client enumerates or restricts its realm's scopes |
always (informational) |
| 5 | Review the auditor role if you rely on it carrying no federation read access |
you use the built-in auditor role |
| 6 | Nothing to do for Flyway V81–V85 — applied automatically on startup | always (informational) |
| 7 | Rename spring.jackson2.* back to spring.jackson.* if you configure Jackson through Spring properties directly |
you set spring.jackson2.* / spring.jackson.* |
| 8 | Check any relying party that assumed single-fetch request_uri semantics |
you integrate a wallet over request_uri |
1. Rolling upgrades: wallet trusted_authorities¶
What changed. Each PID Credential Query can now carry trusted_authorities (OpenID4VP §6.1.1.1, required by HAIP §5) in the DCQL query. An rc.10-or-earlier node refuses a DCQL query carrying trusted_authorities.
What you must do, if you roll out gradually. A wallet transaction started on an upgraded node and answered on an old node that shares the Redis or PostgreSQL transaction store fails. Do one of:
- Upgrade every replica in one step.
- Drain wallet transactions first: stop new wallet logins on old nodes, then wait out
transactionTtlSeconds(300 s by default). - Set the HAIP-profile providers'
dcql.trustedAuthoritiesto Off (console: Credentials → "Name the trusted issuers in the request") for the duration of the roll, then back to Default.
rc.11 reads both forms: it accepts a DCQL query with or without trusted_authorities.
2. Trusted-list signer grace now defaults to 0¶
What changed (behaviour change). The signer-expiry grace for EU trusted lists is now split in two: signer-expiry-grace-days (admin-pinned top-level signers) now defaults to 0, separate from the new member-signer-expiry-grace-days (signers named by a verified LOTL), which defaults to 180.
What you must do. If you use helix.wallet.trusted-lists.* trusted-list sources, set signer-expiry-grace-days before upgrading, or the console will say a list is refused for an expired pinned signer. As of 2026-10-15:
- the EUDI test LOTL needs
signer-expiry-grace-days≥ ~120; - the EC acceptance LoTE needs
signer-expiry-grace-days≥ ~30.
3. eudi-wallet-verify needs the flow engine on¶
What changed. The new flow step eudi-wallet-verify (the verify-only / step-up mode, subject.strategy=NONE) requires the flow engine.
What you must do. With helix.flow-engine.enabled=false (the default), a login whose flow has the wallet-verification step is refused (error=flow), and such a flow cannot be saved or bound (400). Turn the flow engine on before binding a verify-only step to a flow.
4. New standard scope verified_claims¶
What changed. A new standard scope, verified_claims, is seeded (and backfilled onto existing realms) in every realm. A client must request it to receive the verify-only step's released claims in the ID token.
What you must do. Nothing, unless a client enumerates or restricts its realm's scopes — in that case add verified_claims to the allow-list for any client that uses the verify-only / step-up mode.
5. view-identity-providers is now on the built-in auditor role¶
What changed. The built-in auditor role is now seeded with the new view-identity-providers admin permission, in addition to view-users, view-clients and view-events. Auditor-role admins can now read identity providers and EU trusted lists over the admin API (GET /admin/realms/{realm}/trusted-lists); writes still need manage-identity-providers, and identity-provider configs and secrets (the identity-providers, verifier-keys and wallet groups) still need manage-identity-providers for both reads and writes. See Admin roles (RBAC).
What you must do. Review the auditor role if you rely on it carrying no federation read access at all.
6. Flyway V81–V85¶
What changed. New storage for EU trusted-list sources, their config-version guard, member lists, integrity MACs, and the wallet realm-delete cascade trigger.
What you must do. Nothing — applied automatically on startup, no manual step.
7. Jackson 3¶
What changed. The application is now on Jackson 3 (tools.jackson 3.2.3). Spring Boot's deprecated spring-boot-jackson2 module is removed, and the application's own mappers (stores, outbound payloads, wallet parsers) are configured to keep Jackson 2's formats.
What you must do.
- Nothing for an upgrade from rc.10 as far as stored state and wire formats go: authorizations and sessions are Java-serialized, and every Jackson-written store (wallet transactions, DCQL queries, trusted-list data,
config_json/secret_json, flow and messaging config, theme JSON, audit detail) reads what rc.10 wrote and writes the same bytes. A rolling update is safe in both directions as far as JSON is concerned. - If you configure Jackson through Spring properties directly,
spring.jackson2.*is no longer read — usespring.jackson.*(Jackson 3 property names, e.g.spring.jackson.datatype.datetime.*for date features). This reverses the rc.9 rename documented in Upgrading to rc.8 / rc.9, item 14. - Nesting and string limits. The nesting limit for parsed JSON is now 500 (Jackson 2's default was 1000);
max-string-lengthstays 20 MB.
8. Wallet request objects may be re-fetched¶
What changed (behaviour change). A wallet's request_uri now returns the same request again until the wallet answers, instead of 404ing after the first fetch. The first fetch binds the login to its flow; the same request_uri then returns the same request again until the response arrives, or the login ends or expires, at which point it is 404. The response itself stays single use.
What you must do. A relying party that assumed single-fetch request_uri semantics should not depend on that any longer.