FAPI 2 Basline - Interop Question Clarification over the use of PAR

[Ralph Bragg]

The FAPI 2.0 Baseline specification obliges all parties to use PAR however i could not find any reference the behaviour that should be expected by authorisation servers where one particular request parameter was not included in the PAR request but was included as part of the redirect.

One well known Open Source vendor used by a provider in a new Australian Ecosystem has raised an issue with a client implementation where the ‘prompt’ parameter (not sent as part of the PAR request) and is failing to process the request (the prompt parameter is not defined as required in this profile). Other vendors are either honouring the requirement to present a consent prompt by merging / processing the prompt parameter communicated outside of the par request or by other means (feedback sort from vendors as to their behaviour) in this scenario.

A reading of FAPI 2 baseline implies that everyone uses PAR (and only PAR) but it doesn’t go as far to explicitly mandate that elements conveyed outside of the PAR request should be ignored. Appreciate language to this effect might be challenging as client_id for example must always be sent outside of the PAR request but baring this exclusion is there any reason why we wouldn’t ban additional request parameters and standardize the behaviour when they’re included.

To improve interoperability it would be great if we could land on an expected consistent behaviour for this case.

PAR

Authorization server policy MAY dictate, either globally or on a per-
   client basis, that PAR be the only means for a client to pass
   authorization request data.  In this case, the authorization server
   will refuse, using the "invalid_request" error code, to process any
   request to the authorization endpoint that does not have a
   "request_uri" parameter with a value obtained from the PAR endpoint.

      |  Note: Authorization server and clients MAY use metadata as
      |  defined in Sections 5 and 6 to signal the desired behavior.

A potential issue may be that some authorisation servers, whilst enforcing the use of PAR, are happy to also accept additional parameters in addition to mandating a request_uri. The expected behaviour is inconsistent and may not be clear for implementors when PAR is used and additional parameters are passed should it be.

1. A hard reject? if so then the wording in the PAR spec won’t work.
2. Ignore? Possibly the most logical approach however are there any other parameters other than client_id that would need to be factored in? And do we have tests for this for all parameters or at least a list of important ones?
3. Merge and Incorporate? This would undermine the security profile.

‌

[Daniel Fett]

While its not explicit in PAR, I guess the expectation is that request_uri is treated similar to how it’s defined in JAR:

“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.”

Besides the problem that you mentioned, there’s another problem: Parameters sent in the front-end might leak to an attacker, even if the AS ignores them.

I think for FAPI, we should clarify that (a) AS shall ignore any parameters sent in the front-end except for client_id and request_uri, and (b) Clients shall not send any parameter except for client_id and request_uri in the front-end.

[Filip Skokan]

I don’t believe the PAR spec lends itself to the interpretation that passing additional arguments to the authorization endpoint is meant to be a thing.

PAR Authorization Request: https://www.rfc-editor.org/rfc/rfc9126.html#name-authorization-request
The client uses the request_uri value returned by the authorization server to build an authorization request as defined in [RFC9101].

<and client_id as per the validated errata>

‌

JAR reference Authorization Request: https://www.rfc-editor.org/rfc/rfc9101.html#name-authorization-request

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.

‌

And do we have tests for this for all parameters or at least a list of important ones?

The FAPI 2.0 Baseline conformance suite does have a test, inherited and adapted from FAPI 1.0 Advanced, which omits a state in PAR but then adds one in the Authorization Request query. The expectation is either to error, or to honour the request whilst ignoring the state value. It is the *-state-only-outside-request-object-not-used test and its description reads:

This test uses a request object that does not contain state, but state is passed in the url parameters to the authorization endpoint (hence state should be ignored, as FAPI says only parameters inside the request object should be used). The expected result is a successful authentication that returns neither state nor s_hash. It is also permissible to show (a screenshot of which should be uploaded) or return an error message: invalid_request, invalid_request_object or access_denied.

‌

[Filip Skokan]

I think for FAPI, we should clarify that (a) AS shall ignore any parameters sent in the front-end except for client_id and request_uri, and (b) Clients shall not send any parameter except for client_id and request_uri in the front-end.

I agree with both a) and b).

a) just to dispell any doubt that that’s how it should be. Although I would say to not break existing implementations it’s fine to both ignore or error, that’s what the conformance suite’s expecting already.
b) because it correctly profiles what the PAR>JAR dependency explicitly allows (passing duplicated parameters) for FAPI.

[Ralph Bragg]

Thanks gents and i agree with both a) and b).

[Brian Campbell]

I read things similar to Filip - for the front channel authorization request PAR refers to JAR where only client_id and request_uri are used and there’s text saying that other parameters may be sent but the AS can’t use them. It’s a little convoluted reading the layered specs but that’s what it says. FAPI could clairify with both a) and b) mentioned but strictly speaking I think it’s already in the specs.

‌

‌

‌

‌

[Dave Tonge]

We discussed on the call that we should:

1. add the restriction on the client: Clients shall not send any parameter except for client_id and request_uri in the front-end
2. repeat the existing behaviour for the AS

For no.2 we should maybe do this as a note and explain the rationale so that implementers don’t reject requests because of the client restriction

‌

[Dima Postnikov]

So for #2 we provide a note but don’t expect AS to change their existing behaviour (reject or ignore)? This is for existing implementations, what about green field ones, should we point to the preferred behaviour (reject?)?

[Filip Skokan]

preferred behaviour (reject?)

I don’t think we’d easily agree on what’s preferred.

[Dima Postnikov]

for #1 something like this? https://bitbucket.org/openid/fapi/pull-requests/407

[Dima Postnikov]

@Filip Skokan I suspect that… but then every (new) AS / OP implementer has to make that choice (reject or ignore) themselves which can take some time especially with no background..

[Dima Postnikov]

FYI This is what CDR (Australian Open Banking+) is doing in their profile of FAPI1+PAR

Authorisation request data MUST only be accepted using PAR.

‌

[Dave Tonge]

PR merged