RS256 and ES256 both accepted by default — when mp.jwt.verify.publickey.algorithm is unset, tokens signed with any of RS256/384/512 and ES256/384/512 are accepted, and a JWK Set mixing RSA and EC keys is resolved by kid. 0.3.0 defaulted to RS256. To keep refusing EC-signed tokens, set mp.jwt.verify.publickey.algorithm=RS256. Supported algorithms, Upgrading from 0.3.0.

The configured algorithm is a family check — when mp.jwt.verify.publickey.algorithm is set, the token’s alg header must belong to the same family (RSA or EC), checked before any key is looked up: with RS256, an RS512 token passes and an ES256 token is rejected. Supported algorithms, Validation pipeline.

RSA or EC PEM keys, detected from the key — an inline (mp.jwt.verify.publickey) or file/classpath (mp.jwt.verify.publickey.location) PEM public key may be RSA or EC. With the algorithm unset, its type is read from the key itself; with it set, the key must belong to that family, or loading fails with not a valid RSA key / not a valid EC key. 0.3.0 read every PEM key as RSA unless the property named an EC algorithm. Signature verification keys.

MicroProfile JWT 2.2 TCK: 208 / 208 — the official 2.2 suite passes in full; it adds RsaAndEcSignatureAlgorithmTest (RS256 and ES256 tokens against one mixed RSA+EC JWK Set) and no longer ships the EJB, JACC and Servlet container tests. The runner script is now run-official-tck-mp-jwt-2.2.sh. TCK status.

A bad mp.jwt.* value stops the start — an unrecognised mp.jwt.verify.publickey.algorithm or mp.jwt.decrypt.key.algorithm (exact, case-sensitive names: RS256 not rs256, RSA-OAEP not rsa-oaep), or an unreadable verification or decryption key, now fails the container start with a DeploymentException naming the property, the value and the supported values. 0.3.0 started anyway: it read an unrecognised verification algorithm as RSA, rejected every encrypted token at request time for an unrecognised decryption algorithm (CERV-004), and reported an unreadable key only at the validator’s first injection. This is a behaviour change: values that used to be tolerated must be corrected. With no verification key configured, MP JWT stays off and the application starts as before; an http:// or https:// key location is still fetched at the first validation. When the configuration is validated, Upgrading from 0.3.0.

JwtConfig gains a seventh component — requiredAlgorithm (Optional<SignatureAlgorithm>), which carries mp.jwt.verify.publickey.algorithm for embedders who build a JwtConfig through cervantes-api. The six-argument constructor of 0.3.0 is kept, so code that builds a JwtConfig still compiles; a record deconstruction pattern on JwtConfig must add the new component. Upgrading from 0.3.0.

io.vidocq.cervantes.cdi.vauban reads jakarta.json — the cervantes-cdi-vauban descriptor now declares requires jakarta.json (CERV-006, cervantes#21): the @Claim resolver maps claims to JSON-P values, and 0.3.0 relied on another module to supply that read edge. It also declares uses org.eclipse.microprofile.config.spi.ConfigProviderResolver, for the start-time configuration check. Every Cervantes module-info is now compiled together with its code, so a missing edge of this kind fails the Cervantes build instead of reaching the published jar. Java modules.

Works on a class path, outside Vauban — CervantesClaimExtension is now also listed in META-INF/services (CERV-007, cervantes#24). 0.3.0 registered it only through the module descriptor, so on a class path (Weld, an application server, a WAR) @Claim injection points were unsatisfied. cervantes-cdi-vauban and cervantes-jaxrs also ship a META-INF/beans.xml (annotated), so a container that does not scan implicit archives still discovers their beans. On a class path.

Proven on Weld and Open Liberty — two new test modules run the Cervantes jars, unchanged, without Vauban: cervantes-it-weld on Weld SE 6.0 (class path), cervantes-it-openliberty as a WAR on Open Liberty 26.0.0.10 (MicroProfile 7, CDI 4.0) with Liberty’s own mpJwt and appSecurity off. Neither is published (cervantes#24). Other CDI containers.

vauban-api is now a runtime dependency of cervantes-cdi-vauban and cervantes-jaxrs — it was provided, so outside Vauban the request context, the token producer, the authentication filter and the @RolesAllowed feature, which carry a constructor taking io.vidocq.vauban.api.ProxyLink, could not be loaded, and the deployment failed (CERV-008). The module descriptors now requires io.vidocq.vauban.api (it was requires static). Nothing changes on the Vidocq runtime, which already has it. Other CDI containers.