JWEHeader fails to parse valid JWK epk values due to strict [String: String] decoding

[sawo]

The current implementation of JWEHeader assumes the epk (ephemeral public key) field in a JWE header can only be decoded as a [String: String] dictionary. This breaks compatibility with standards-compliant JWKs that may include fields such as key_ops, x5c, or oth, which are valid JSON arrays or nested objects per RFC 7517 and RFC 7518.

Problem:
When the JWE header contains a valid epk object like:

{
"epk": {
  "kty": "EC",
  "crv": "P-256",
  "x": "...",
  "y": "...",
  "key_ops": ["deriveKey"],
  "x5c": ["..."]
}

The decoder fails, because it attempts to parse the entire epk as [String: String].

This breaks interoperability with valid JWE implementations, including Microsoft’s JsonWebKey class from the .NET ecosystem, which emits standard-compliant epk values.

According to the JWK spec (RFC 7517, Section 4): "Members MAY contain any values that are valid JSON data types."

This includes strings, arrays, objects, booleans, and null.

Repro Steps

• Create a JWE using a library like Microsoft.IdentityModel.Tokens.JsonWebKey in .NET.
• Include an epk with fields like key_ops or x5c.
• Try to parse it using JOSESwift.JWEHeader.
• Observe deserialization failure.