I saw this technote DT426123 titled "conditionally Encrypt id_token based on specific oauth client" in my email notifications I get from IBM.  I figured I would throw this out there before someone reinvents the wheel.

This is currently possible with the product; albeit it requires a lot of mapping rule coding.  I can't recall exactly how I made it work as it has been several years since I coded it.  However, it has to do with setting these STSUU context attributes:  encryption.jwks, kid, enc, and alg.  Also signing.jwks, kid, ang alg.  These are documented in the JWT STS documentation.  You can control all this in the token pre mapping rule.

Within the context of the mapping rule STSUU for ID tokens, they control the signing and encryption.  So I have this function I wrote that reads in the API client metadata (compensates for static and dynamic clients), then reads in the OIDC spec fields that control the signing and encryption.  For example, jwks, jwks_uri, id_token_signed_response_alg, id_token_encrypted_response_alg, and id_token_encrypted_response_enc can all be specified on each client registration.  It looks like I get the jwks from the client using OAuthMappingExtUtils.getClient(client_id) then calling .getJwks() and getJwksUri().  My function will either use the jwks provided in the metadata or will fetch the URI data from an allowed remote endpoint.

Anyway, it's not easy, it took me a while to write all this out and get it tested.  But it is possible to control both the ID tokens and OAuth JWT tokens signing and encryption parameters on a per client basis (granted these have to use a custom STS anyway that is called from the mapping rules) via the mapping rule code.  Hence, I was surprised to see the tech note saying this was not possible unless I am misreading something or forgetting what I had done.  It's not possible out of the box for sure, but IVIA/ISVA is extremely powerful once you start customizing the token flows with the mapping rules.

Maybe someone will find this useful since the technote was likely generated by someone asking for support.