Problem description
Referring to the CIBA specs, the aud claim of the private_key_jwt can be any of the 3 options mentioned below.
The proposal is to prevent reuse of the private_key_jwt at other endpoints.

The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, such as the authentication methods from Section 9 of [OpenID.Core] or authentication methods defined by extension in other specifications. Note that there's some potential ambiguity around the appropriate audience value to use when JWT client assertion based authentication is employed. To address that ambiguity the Issuer Identifier of the OP SHOULD be used as the value of the audience. To facilitate interoperability, the OP MUST accept its Issuer Identifier, Token Endpoint URL, or Backchannel Authentication Endpoint URL as values that identify it as an intended audience.

Possible evolution
Enforce the aud claim of the private_key_jwt to be the URL of the respective endpoint (as a string) at which the assertion is received, it must not be an item in an array.
The URLs of the endpoint can be populated from the OpenID Provider's /.well-known/openid-configuration with the following metadata:

• token_endpoint
• backchannel_authentication_endpoint

Example: If the endpoint at which the assertion is being received is the backchannel_authentication_endpoint, the Relying Party will populate the aud claim of the private_key_jwt to be the URL of the backchannel_authentication_endpoint as per the OpenID Provider's /.well-known/openid-configuration.

Alternative solution
N.A

Additional context
OIDC profile is being defined for CAMARA