Created a JWETokenDecrypter for decryption.

Updated the BasicJOSEObjectCredentialResolver to allow for an extension point for post-processing credentials (like the SAML BasicProviderKeyInfoCredentialResolver).

Updated the LocalJOSEObjectCredentialResolver to implement the post-processing credentials extension point (similar to the LocalKeyInfoCredentialResolver). The resolver attempts to find local credentials based on matching public keys (with or without a ‘kid’ if available), in addition to local credentials resolved from ‘kid’ alone. Both are added to a list of returned credentials - duplicate credentials (same public and private keys) are removed.

Removed the ‘kid’ criterion from the JWTDecrypter, because that is now handled by the LocalJOSEObjectCredentialResolver specifically, rather than being applied across all resolvers.

I've changed over the StaticJOSEObjectCredentialResolver to be a CollectionJOSEObjectCredentialResolver as it is filterable based on the EvaluableCredentialCriterion, which is more inline with the CollectionCredentialResolver.

I've added a LocalJOSEObjectCredentialResolver which extends the BasicJOSEObjectCredentialResolver and hence AbstractCriteriaFilteringCredentialResolver. For now it just calls the local collection credential resolver mentioned above. It currently filters credentials based on usual algorithm parameters and 'kid' if one exists (built as criteria in the JWTDecrypter class). I now need to optionally resolve and filter private keys based on any corresponding public keys found by the BasicJOSEObjectCredentialResolver in the JOSE header ('jwk' or fetched from 'jku'). It is possible that only the 'kid' is defined, so we must also resolve those local credentials without having a corresponding public key to match.

Of note, for encryption, we (the OIDC OP and RP) do not seem to support adding the public key to the JOSE header, only the ‘kid’, maybe we should. I added in a ticket in case it will be useful at some point

All key management modes have the following criterion:

1. KeyUsage

2. KeyID (if present)

3. JOSEObject included - not used atm.

I’ve added the following criterion specific to the following key management modes:

1. Direct Encryption. As the RP can resolve the actual encryption key, we can filter on:

   1. Encryption KeyAlgorithm e.g. AES.

   2. KeyLength

2. Key Encryption. We do not validate the un-encrypted key, the Nimbus decrypted does.

   1. KeyAlgorithm from key management mode ('alg') algorithm e.g. RSA for RSA-OAEP

3. Key Wrapping. We do not validate the un-warpped key, the Nimbus decrypted does.

   1. KeyAlgorithm from key management mode ('alg') algorithm e.g. AES for A128KW

   2. KeyLength - extracted from the algorithm e.g. 128 bit for A128KW

4. Key Agreement

   1. Not yet working.

Credentials from the various resolvers are filtered against these by the AbstractCriteriaFilteringCredentialResolver.

The JWT decrypted class still contains further and slightly overlapping JOSE Header v credential (albeit a filtered down set) validation.

Although I need to look at which algorithm is forming the criteria. WIP.