Issue

• An attacker-supplied JWT proof containing "crv": [] (an array instead of a string) in the JOSE header jwk field could trigger an unhandled ClassCastException in AbstractProofValidator.getKeyWrapper(), resulting in a 500 Internal Server Error instead of the expected invalid_proof response.

Root cause

• JWK.getOtherClaim("crv", String.class) internally calls String.class.cast(ArrayList), which throws a ClassCastException when the claim has an unexpected type. This exception was not handled by JwtProofValidator.validateProof(), whose catch block only handled JWSInputException, VerificationException, and IOException.

Fix

• Fix 1 – JWK.getOtherClaim() (root cause): Now catches ClassCastException and returns null. A type mismatch is treated the same as a missing claim, matching the method's contract. This provides a systemic fix for all callers, including AbstractProofValidator, JWKSUtils, and EdECUtilsImpl.
• Fix 2 – AbstractProofValidator.getKeyWrapper() (defense in depth): Wraps JWKParser.toPublicKey() in a try-catch(RuntimeException) and rethrows a VerificationException. This ensures malformed JWKs (for example, missing kty or required EC fields) follow the existing INVALID_PROOF error path instead of propagating unchecked exceptions.

Why not catch RuntimeException?

• Broadly catching RuntimeException in JwtProofValidator was intentionally avoided because VCIssuerException extends RuntimeException. Doing so would incorrectly convert issuer-specific errors (for example, INVALID_NONCE) into generic INVALID_PROOF responses.

Tests

• JWKOtherClaimTest: 5 unit tests covering valid retrieval, absent claim, wrong type returning null, null value, and correct type retrieval.
• OID4VCJWTIssuerEndpointTest.testRequestCredentialWithMalformedJwkCrvRejected(): Integration test verifying that a malformed "crv": [] JWT proof returns 400 INVALID_PROOF instead of causing an internal server error.

Closes #50749