Public keys are used to encrypt and private keys to decrypt. It's not natural for an IDP to use it's own public keys to encrypt its own tokens since the only recipient that can decrypt it would be itself. If this is done it would be some internal implementation detail, for instance to have some sort of stateless operation and not part of any specification. And if this is really desirable it would likely be better for the IDP to just use a symmetric key to encrypt and decrypt the data.

The token introspection endpoint is intended for resource servers to get information about (typically opaque) access tokens, or for more information that's not in the claims if it's a JWT access token. This is not really related to OIDC and is more just OAuth2. Unlike access tokens, which can either be opaque or a JWT token, ID tokens must be a JWT token. OIDC specifies a userinfo_endpoint where you can receive information about a user by using the access token.

The "Support for JWE encrypted ID Tokens and UserInfo responses in OpenID Connect providers" is working as is specified. The tokens and responses are encrypted so that only the intended recipient, ie the client, can decrypt the information. The client public keys are used to encrypt the information. The client will then use it's private decryption keys to decrypt.

Let's start from scratch if you allow...

• There's an OIDC IDP called, let's say, "Realcow." Realcow uses its private key to sign ID tokens and access tokens and encrypt them too because reasons.
• There's also (resource or web) server "Grassfield", which has a trust relationship with Realcow.
• Cow Fruh-fruh wants to use Grassfield and authenticates with Realcow via a redirect from Grassfield.
• Realcow does not have JWKS endpoint.
• Grassfield uses Realcow's token introspection endpoint to get information from an encrypted token because it can't decrypt it.
  ...
  And now Keycloak comes into play because another company uses it and wants Grassfield users to access their service called "Stalls&Breakfast." So, either custom user federation (Realcow is neither Kerberos not LDAP) or OIDC IPD federation should work, except the Realcow's token is encrypted and Keycloak has to read it...

Well, I can imagine that if cow Fruh-fruh now goes to Keycloak and wants to use Realcow to log in, Keycloak redirects Fruh-fruh to Realcow, and after Fruh-fruh is authenticated and redirected back to Keycloak, Keycloak get the token encrypted by Realcow's private key and can use Realcow's public key (available somehow) to decrypt the token. But...

... in what specification do they recommend that IDP (Realcow in our example) should use a public key of an identity broker (like Keycloak) to encrypt its ID tokens? Is there some OIDC identity provider federation (or any other) spec, which has such recommendation? Or is it something Keycloak recommends?

That's what I was asking. Anyway, if I understood your reply correctly...

It seem that Realcow has to recognize the redirect from Keycloak (and not from Grassfield) and, instead of using its private key (as usual), it has to go to Keycloak's JWKS endpoint, take the use: "enc" key from the set, encrypt the ID token and POST it back to Keycloak's redirect URL. Is it the workflow you were referring to?

It's a rather basic requirement to use the public key of the recipient for encryption otherwise the recipient then can't decrypt the data. Is this "Realcow" OIDC IDP a product or something custom developed?

In the Example JWE section of RFC7516 JSON Web Encryption (JWE)
Encrypt the CEK with the recipient's public key using the RSAES- OAEP algorithm to produce the JWE Encrypted Key.

In the Key Encryption section of RFC7516 JSON Web Encryption (JWE)
Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.

Your use case doesn't sound like identity federation. If "Grassfield" is a resource server and "Stalls&Breakfast" is an external resource server and each only accepts access tokens created by their respective authorization servers "Realcow" and "Keycloak" then actually if you don't need to propagate the user identity, "Grassfield" should use client credential flow to obtain an access token from "Keycloak" to call "Stalls&Breakfast" otherwise if the user identity is important, "Grassfield" would need to use token exchange to obtain the access token. Token exchange may be an issue for "Keycloak" as it's support for it is in preview and doesn't completely implement RFC 8693 OAuth 2.0 Token Exchange.