# 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`.

!!! info "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](../compliance/compliance-program.md#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`](#1-rolling-upgrades-wallet-trusted_authorities) for the duration of the roll | you use wallet providers and roll out gradually |
| 2 | Set [`signer-expiry-grace-days`](#2-trusted-list-signer-grace-now-defaults-to-0) before upgrading if you use EU trusted-list sources | you configured `helix.wallet.trusted-lists.*` |
| 3 | Turn on the [flow engine](#3-eudi-wallet-verify-needs-the-flow-engine-on) 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](#4-new-standard-scope-verified_claims), unless a client enumerates or restricts its realm's scopes | always (informational) |
| 5 | Review the [`auditor` role](#5-view-identity-providers-is-now-on-the-built-in-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](#6-flyway-v81v85) — applied automatically on startup | always (informational) |
| 7 | Rename `spring.jackson2.*` back to `spring.jackson.*` if you configure [Jackson](#7-jackson-3) through Spring properties directly | you set `spring.jackson2.*` / `spring.jackson.*` |
| 8 | Check any relying party that assumed [single-fetch `request_uri` semantics](#8-wallet-request-objects-may-be-re-fetched) | 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:

1. Upgrade every replica in one step.
2. Drain wallet transactions first: stop new wallet logins on old nodes, then wait out `transactionTtlSeconds` (300 s by default).
3. Set the HAIP-profile providers' `dcql.trustedAuthorities` to **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)](admin-roles.md).

**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 — use `spring.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](upgrade-rc8-rc9.md#14-renamed-spring-properties).
- **Nesting and string limits.** The nesting limit for parsed JSON is now **500** (Jackson 2's default was 1000); `max-string-length` stays **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.

## See also

- [Upgrades & migrations](upgrades.md)
- [Upgrading to rc.8 / rc.9](upgrade-rc8-rc9.md)
- [Admin roles (RBAC)](admin-roles.md)
- [EUDI Wallet](../federation/eudi-wallet.md)