Gap in CDS specs around the mandatory nature of 'redirect_uri' in the Token Request

[cdswizard]

There appears to be a gap in the CDS specs around the mandatory nature of 'redirect_uri' in the Token Request.

Neither the specs nor the non-normative example seem to suggest it is required:

1. Under Client Authentication (Data Recipients calling Data Holders), the mandatory fields
   (grant_type, code, client_id, etc.) do not include the 'redirect_uri', even though the Token endpoint is mentioned.

2. The non-normative example also doesn't include it:

POST /token HTTP/1.1
Host: www.holder.com.au
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=i1WsRn1uB1&
client_id=s6BhdRkqt3&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...

However, from looking in OAUTH/OIDC/FAPI it appears that it is mandated:

1. In OAUTH (4.1.3) Access Token Request:
   REQUIRED, if the 'redirect_uri' parameter was included in the authorization request...

2. In OIDC (3.1.3.2):
   Ensure that the redirect_uri parameter value is identical to the redirect_uri parameter value that was included in the initial Authorization Request.

3. But we also know from FAPI-R (5.2.2):
   "shall require the redirect_uri parameter in the authorization request;"

This suggests that FAPI demands 'redirect_uri' be present in the Authorization Request, hence
it must be included in the Token Request (so that it can be matched/validated against what was sent in the Authorization Request).

Am I missing something here?

[perlboy]

Umm @cdswizard redirect_uri is part of the authorization request (ie. /authorize) not the token claim via authorization_code (ie. /token) so it seems some wires are crossed in this query?

FWIW OAUTH/OIDC don't require redirect_uri in the authorise request if there is one (and only one) preregistered redirect_uri. However, as you've highlighted in FAPI it is mandated in all cases, I believe the examples demonstrate this already?

[jogu]

Here's an example of a token endpoint call from the FAPI conformance suite:

(line breaks added to improve readability)

grant_type=authorization_code&
code=RO3bPwZBtlJj7f3DKw5KqJXQEiwSR_4DnpnMwyr7qss&
redirect_uri=https%3A%2F%2Fwww.certification.openid.net%2Ftest%2Fa%2Ffintech-authlete%2Fcallback&
client_assertion=eyJraWQiOiJmYXBpLWp3dC1h<...>nHFunA&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer

I believe @cdswizard is correct that the example should include redirect_uri.

The example probably also doesn't need to include client_id (I'm not sure why the CDR spec appears to mandate that it's sent, that's not something that's mandated in any of the underlying specs for private_key_jwt authentication).

[perlboy]

Apologies, it was me with my wires crossed, right you are @jogu and @cdswizard, redirect_uri should be in the /token request as per RFC6749 4.1.3 because it is mandated in the authorization request by FAPI and must therefore match:

[kirkycdr]

This has been staged here:
ConsumerDataStandardsAustralia/standards-staging@25f0b6f