recommend auth code flow using signed requests

[AxelNennker]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

This PR recommends using signed OIDC authoritzation code flow requests.

Which issue(s) this PR fixes:

Fixes #205

[mhfoo]

My apologies, I created #233, before seeing this PR. Possible to use #233 instead?
@AxelNennker @jpengar

[garciasolero]

I would like to clarify why the OIDC specification was chosen over RFC 9101. It is important because, although they are very similar, they have small but significant differences.

OIDC:

When the request parameter is used, the OpenID Connect request parameter values contained in the JWT supersede those passed using the OAuth 2.0 request syntax. However, parameters MAY also be passed using the OAuth 2.0 request syntax even when a Request Object is used; this would typically be done to enable a cached, pre-signed (and possibly pre-encrypted) Request Object value to be used containing the fixed request parameters, while parameters that can vary with each request, such as state and nonce, are passed as OAuth 2.0 parameters.

RFC 9101:

The client MAY send the parameters included in the Request Object duplicated in the query parameters as well for backward compatibility, etc. However, the authorization server supporting this specification MUST only use the parameters included in the Request Object.

From my point of view, it is more interesting to follow RFC 9101, as it would ignore parameters that the client did not have to send and could potentially change how an authorization server processes the request.

[garciasolero]

Both in OIDC and RFC 9101, the valid value for the aud field should be the issuer of the authorization server. I don't see any specification that recommends the Token Endpoint for signed request object.

Even in the CIBA specification, it is also established that the valid value should be the issuer of the authorization server.

[eric-murray]

@garciasolero
The CAMARA specification specifically makes this recommendation.

However, this applies to client authentication, and for authorisation code flow, it is only the /token endpoint where the client is authenticated. For signing the authorisation request, I agree that is does not necessarily follow that the aud should also be the URL of the token endpoint.

[garciasolero]

Yes, you are right, hence my comment. The recommendations apply depending on what type of assertion it is, and we should be aligned with what the standards say.

[mhfoo]

OIDC Core refers to [RFC9101], under section Explicit Endpoints, it is RECOMMENDED good practice to explicitly state the intended interaction endpoints, in this context the Authorization endpoint (authorization_endpoint)

I have the following concern on this phrase in OIDC Core:
The JWT MAY contain other Claims. Any Claims used that are not understood MUST be ignored." under the private_key_jwt section.

The aud claim explicitly stating the intended endpoint, will prevent misuse of the signed JWT.

[mhfoo]

Suggested change

	It is RECOMMENDED that signed authentication requests be used, as specified by [OIDC](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests). The same key MAY be used for signing the authentication request as is used for [client authentication](#client-authentication). This document recommends in the [client credentials section](#client-authentication) that the `aud` value SHOULD be the URL of the Authorization Server's [Token Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint). The same recommendation is given for the `aud` value of the signed request object.
	It is RECOMMENDED that signed authentication requests be used, as specified by [OIDC](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests). The same key MAY be used for signing the authentication request as is used for [client authentication](#client-authentication).
	This document recommends the value of `aud` (Audience) claim MUST be the Authorization endpoint as RECOMMENDED by [\[RFC9101\], Explicit Endpoints](https://www.rfc-editor.org/rfc/rfc9101.html#name-explicit-endpoints).

[mhfoo]

I would like to propose to append the following point regarding the sub claim for signed Request Object, as there are cases of implementation, the sub is wrongly included.

8< ------------------------
The sub (Subject) claim in the signed Request Object MUST NOT be present, to prevent cross-JWT confusion.

[mhfoo]

Suggested change

	The sub (Subject) claim in the signed Request Object MUST NOT be present, to prevent [cross-JWT confusion](https://www.rfc-editor.org/rfc/rfc9101.html#name-cross-jwt-confusion).

[mhfoo]

Added proposed changes, including references

[jpengar]

Pending topics:

• OIDC vs. RFC 9101 as a reference. Telefónica proposes to follow RF9101.
• aud value. Telefónica believes that the aud field should be the issuer of the authorization server as per standards (both OIDC and RFC 9101)
• sub claim requirement to avoid cross-JWT confusion.

Could we please resume and close these topics as it's under the Spring25 scope.
CC @garciasolero @AxelNennker @mhfoo @eric-murray

[mhfoo]

• aud value. Telefónica believes that the aud field should be the issuer of the authorization server as per standards (both OIDC and RFC 9101)

Referring to the aud value statement in ODIC:
"The aud value SHOULD be or include the OP's Issuer Identifier URL."

Breaking it down:
a) The aud value SHOULD be the OP's Issuer Identifier URL, or
b) The aud value SHOULD include the OP's Issuer Identifier URL.

Point b) is read as "OP's Issuer Identifier URL" is used as a prefix.

[mhfoo]

• sub claim requirement to avoid cross-JWT confusion.

Referring to OIDC, Client Authentication, private_key_jwt, the following statement is present:
"The JWT MAY contain other Claims. Any Claims used that are not understood MUST be ignored."

If this signed request object (for /authorize) aud value is the OP's Issuer Identifier URL and the 'sub' happens to be populated with the client_id of the OAuth Client, this could be used as the client_assertion for the /token or bc-authorize endpoint.