Are duplicates of the response_type, and scope values necessary when using PAR?
Part 2 currently says:
shall additionally send duplicates of the
response_type
,, andscope
parameters/values using the OAuth 2.0 request syntax as required by the OAuth and OpenID Connect specifications;
Should this have a “if not using request_uri” qualification? It seems unnecessary to send these if using PAR, given PAR is an IETF spec and can remove (/has removed) the underlying OAuth2 requirement for the duplicates.
Comments (15)
-
reporter -
I would agree - although maybe for FAPI 2? I think we left this in for interoperability reasons.
-
reporter I think mostly we were clarifying the existing requirement in OIDC which in turn did it to be technically compliant with OAuth2. (And I think some vendor implementations could not process OpenID Connect requests if those parameters were missing.)
It’d be nice for clients not to have to send scope via the browser if it’s not necessary (though probably the privacy considerations in doing so are minimal in most cases), and it’s potentially incompatible with RAR to require a scope.
I think the expectation would be that people deploying PAR are doing so using vendor support for it (as opposed to attempting to retrofit PAR onto existing authorization server by, say, implementing on a different server in custom code that tries to verify client authentication perhaps by accessing private client management APIs in the AS).
If that expectation is also correct, then I think it’s reasonable to expect the Authorization Servers to be fully compatible with JAR/PAR, so it would be unnecessary for the client to send the duplicates in that case. i.e. when PAR is in use, I don’t think the backwards compatibility arguments apply so much, as PAR is a brand new standard vendors are only now adding support for.
I’d prefer to weaken the clause, at least when PAR is in use.
-
That makes sense to me.
I don’t think we should make it conditional though - we can just require client id, in the same way as jwsreq does?
I suppose there could be a problem if an AS who previously gained conformance with FAPI, rejected requests that didn’t have the duplicate params? How would we deal with that?
-
reporter Changing it for the non-PAR case is definitely problematic and likely a breaking change; I’m pretty certain several vendor products that UK banks have managed to get signed request objects working with do require the duplicate parameters, or rather without the duplicate parameters the Authorization Endpoint just won’t get past some of their core processing.
Changing it just for PAR isn’t really a breaking change as the previous implementers draft didn’t include PAR, and because the PAR spec doesn’t require the duplicates to be sent. Or put another way, one way of viewing it is that when we added PAR to FAPI we accidentally ended up with the statement about duplicates applying to PAR.
-
Yep - I see.
So how about this:
shall additionally send duplicates of the
response_type
,client_id
, andscope
parameters/values using the OAuth 2.0 request syntax as required by the OAuth and OpenID Connect specifications, unless using [PAR] in which case only theclient_id
shall be duplicated.
We should probably check if any other clauses need adjusting
-
reporter Thanks Dave - your suggested wording sounds good.
I had a scan through and no other clauses leapt out a problematic.
The only thing that does occur to me is that we could make a transition to FAPI 2 easier by suggesting that when using PAR clients should send PKCE, regardless of whether the server supports it or not. Or we could just mandate PKCE when using PAR, it wouldn’t be a breaking change due to the previous draft not mentioning PAR. (If you remember I believe we almost made PKCE mandatory in FAPI-RW, due to many clients not checking s_hash and hence not actually getting the protection s_hash provides - the major reason we didn’t do so was that we didn’t want to impose a breaking change on the UK ecosystem.)
-
reporter - changed title to Are duplicates of the response_type, and scope values necessary when using PAR?
- edited description
-
reporter I’ve created a new issue to cover the PKCE discussion: https://bitbucket.org/openid/fapi/issues/307/fapi-rw-require-pkce-when-using-par
-
- changed status to open
Are we done with the discussion?
-
reporter yes, I think we agreed this - I raised https://bitbucket.org/openid/fapi/pull-requests/188/clarify-that-duplicate-parameters/diff to updated the spec, which I think is ready to be merged.
-
- changed status to closed
Merged in par-duplicates (pull request #188)
Clarify that duplicate parameters requirement doesn't apply to PAR
- Clarify that duplicate parameters requirement doesn't apply to PAR
As per discussion here:
https://bitbucket.org/openid/fapi/issues/304/are-duplicates-of-the-response_type
with fixed c&p error & clarified language as per comments from Brian Campbell
closes
#304Approved-by: Dima Postnikov Approved-by: Dave Tonge Approved-by: Nat Sakimura
→ <<cset 0b6071d0d932>>
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
Actually the latest PAR and https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-26 make clear that
client_id
is required both inside and outside.So the question is only about
response_type
andscope
.