Clarify `aud` values that should be accepted in `private_key_jwt` at the token (and other) endpoints

[jogu]

There's some unfortunate history around the aud value that you use in private_key_jwt client authentication assertions.

RFC7523 says:

        The JWT MUST contain an "aud" (audience) claim containing a
        value that identifies the authorization server as an intended
        audience.  The token endpoint URL of the authorization server
        MAY be used as a value for an "aud" element to identify the
        authorization server as an intended audience of the JWT.  The
        authorization server MUST reject any JWT that does not contain
        its own identity as the intended audience

The WG already tried to be a bit more specific, e.g. in PAR we say the issuer value 'SHOULD' be used and 'MUST' be accepted:

Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in Section 2.2 of [RFC7523] with private_key_jwt or client_secret_jwt authentication method names per Section 9 of [OIDC]). To address that ambiguity, the issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience. In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

It seems like we could add something in OAuth 2.1 to try and help people get this working in an interoperable fashion. Somewhere in https://drafts.oauth.net/oauth-v2-1/draft-ietf-oauth-v2-1.html#section-2.4 would seem like a possible place to offer a clarification. Perhaps something along the lines of:

When using private_key_jwt, In order to facilitate interoperability, the authorization server MUST accept its issuer identifier, token endpoint URL, or the endpoint URL that the assertion is being presented to as aud values that identify it as an intended audience.

[bc-pi]

Apologies again for the way things are.

[bc-pi]

Apologies again.

[bc-pi]

This is still relevant but what is done about it here, if anything, may change due to https://talks.secworkshop.events/osw2025/talk/R8D9BS/

[aaronpk]

I think we can just point at the updated language in RFC7523bis now rather than trying to recreate it here, yea?

[bc-pi]

I think we can just point at the updated language in RFC7523bis now rather than trying to recreate it here, yea?

Yeah, I think so. And the -03 is hopefully close to progressing to last call https://mailarchive.ietf.org/arch/msg/oauth/6rIP17LhENI1aKqNaS1rQy79pIg/