Questions about OIDC FAPI and mTLS

I am trying to make my OIDC provider FAPI compliant. I have enabled mTLS in which the relying party creates a key and CSR (certificate request) and we provide them with a PEM formatted public certificate to use in mTLS of /token

I also want to encrypt the ID Token using the public certificate that we provided the RP. They can then use their private key to decrypt.

1. Do I still need to encrypt if we are forcing mTLS?
2. Can I use the certificate we provided to the RP to encrypt? the spec refers to having a JWK format so I should just convert from PEM format to JWKS?
3. Should the RP generate a separate JWK keypair and expose an endpoint URI? That way they can rotate the keys themselves without requesting a new certificate.

Q1

Encryption is done to prevent information disclosure. An encrypted ID token would be returned to a client in a JWT that uses the 5 part JWE format rather than the better known 3 part JWS format.

FAPI 1.0 used to recommend the hybrid flow, where ID tokens were returned to the browser / front channel. The JWT could disclose personally identifiable information such as names and emails though, and be available in the browser history or server logs.

FAPI 2.0 instead recommends the code flow. ID tokens are then returned on the back channel. They could end up being used in the browser though, eg in RP initiated logout messages, so encryption can still be useful.

mTLS solves a different problem of a client credential that is harder to steal. FAPI recommends use of either client certificates or client assertions, both of which provide proof of ownership of a strong credential without disclosing it.

Q2

An OIDC provider produces a JWE format JWT using a public JWK and a dynamically generated symmetric key. The public JWK can be used directly or imported from an alternative format such as a public key certificate file.

The use of algorithms and keys is far from trivial though. You would need to take a look at the RFC7518 and RFC7516 standards.

Q3

This is an interesting option for dealing with client credentials. The OIDC provider only needs to be configured with a JWKS URI, and uses it when client assertions (JWTs used as client credentials) are sent to the token endpoint.

A trusted utility API can then provide the JWKS URI. This can be useful in B2B or high security mobile scenarios, when you want a party other than the OIDC provider to create and renew keys, and for them to automatically take effect in the OIDC provider.