private_key_jwt, client_secret_jwt audience

[Filip Skokan]

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

aud
REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

The assertion, originally defined in https://tools.ietf.org/html/rfc7523#section-3

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.

When considering the different endpoints these client assertions are used to authenticate at (Token, Introspection, Revocation, PAR, CIBA, Device Authorization Grant) the SHOULD on use of the token endpoint URL as audience is REALLY confusing for both AS implementers as well as RP implementers. There has to be a clearer definition value to use, one that makes sense. It does not make sense to use the token endpoint URL when authenticating at the revocation or CIBA endpoints. To further complicate things, a client may use private_key_jwt auth at the token_endpoint under mtls_endpoint_aliases when it wants to get a mtls sender constrained access token, which audience should the client use then?…

The intention is to assert the identity of the AS (again as per RFC7523 - The authorization server MUST reject any JWT that does not contain its own identity as the intended audience.), for which we have the Issuer Identifier.

I suggest to include in the next Core 1.0 errata that

The Audience SHOULD be Issuer Identifier and MAY be the URL of the Authorization Server's Token Endpoint.

‌

[Ralph Bragg]

[Brian Campbell]

I think this would be a worthwhile to do but I do have some concern that it’s pretty close to the line as to what would be acceptable as errata.

This (or very similar) came up in CIBA and this ticket has a lot more context about it all https://bitbucket.org/openid/mobile/issues/155/

Also the PAR draft has some related suggestions at the end of sec 2 https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.html#section-2

‌

‌

‌

[Vladimir Dzhuvinov]

+1

(this has caused RP / OP interop issues in the past)

[Michael Jones]

Given that Connect and the RFC agree that the audience should be the Token Endpoint URL, as Brian commented, it’s not an errata action to change this to another value. I agree that, if we were to do this again, we probably should have used the issuer URL.

Also including the issuer identifier as an audience value, is likely OK, but that’s not something that’s in the spec.

[Joseph Heenan]

Corresponding conformance suite issue: https://gitlab.com/openid/conformance-suite/-/issues/877

[Filip Skokan]

A summary of the 21-03-25 call on the issue.

The attendees agreed the situation is not ideal, especially given this question pops up with every new client authenticated endpoint added to the oauth2 space, it happened for PAR, CIBA, Device Authorization Grant, is bound to happen again in the future. In retrospective the group would’ve chosen to use the Issuer Identifier value rather than the token endpoint URI.

@Brian Campbell and @ggfletch suggested to release some form of recommendation moving forward, whether that would take the form of a new OIDC draft, or an IETF draft that would deprecate RFC7523, or an OIDF blog post, is yet to be determined.

Nevertheless, an Authorization Server still MUST adhere to the following requirements, for which the Issuer Identifer as audience makes the most sense. The use of Token Endpoint URI is still a SHOULD, not a MUST.

The Authorization Server MUST verify that it is an intended audience for the token.
The authorization server MUST reject any JWT that does not contain its own identity as the intended audience.

The attendees stressed the point that the certification suite acts in err when it rejects an assertion with the Issuer Identifier as an audience.

If I understood the group correctly the certification suite should be adjusted to accept both token endpoint uri as well as the issuer identifier. OPs should be tested to accept both (separately, not in a single request) and issue a warning if one of them is not accepted, the warning should contain information about interoperability with other implementations being the reason for such warning. We did not come to a conclusion for the RP suite behaviour.

[Michael Jones]

On the 5-Apr-21 call, we agreed that it should remain an error if the Token Endpoint value isn't supported and that it should be a warning if the Issuer value isn't supported.

If we do this, we should also produce a guidance document on this topic.

[Rui Engana]

Agree normalisation of audience value (issuer, token endpoint, etc.), is way to go, however, until that happen OPs need to check audience from array lists and RPs libraries need to produce assertions with multiple values as audience (issuer, token endpoint, etc.),, otherwise, assertion based authentication isn’t usable due to lack of interoperability.

We see this across many entities in Open Banking UK that are strict in client assertion processing and not accepting audience array values.

Also, from RFC7521 https://tools.ietf.org/html/rfc7521#section-5.1 which underpins OIDC and governs Client Assertions Metamodel it’s said.

Audience
A value that identifies the party or parties intended to process
the assertion. The URL of the token endpoint, as defined in
of OAuth 2.0 [], can be used to indicate that
the authorization server is a valid intended audience of the
assertion. In the absence of an application profile specifying
otherwise, compliant applications MUST compare the Audience values
using the Simple String Comparison method defined in [].

‌

[Michael Jones]

Reviewing this thread again, this seems like a request for an amendment/addition to the spec rather than an errata action. Therefore, I’ve recategorized it from Errata to Amendment.

[Joseph Heenan]

I think there’s maybe more than one change needed here.

I think it would be within the scope of an errata (i.e. not a breaking change) to add “Authorization servers SHOULD also accept their issuer value for aud”, and that would help start to align things with the direction of travel in other OIDF & IETF standards. (If a ‘should’ is felt to be too strong, it would still have value if added as a ‘may’.)