Requiring PAR for authorization code flow

[Mark Verstege]

Given that PAR is required, should the profile clearly state that the require_pushed_authorization_requests property be set to true? In RFC9126 the default value for this property is false.

This may be a statement in 5.3.1.2. to the effect of

shall require the require_pushed_authorization_requests parameter be set to true

‌

[Filip Skokan]

shall require the require_pushed_authorization_requests parameter be set to true

This would prohibit authorization servers from simultaneously acting on behalf of FAPI 1 and FAPI 2 ecosystems since there are FAPI 1 profiles that don’t require the use of PAR.

As a sidenote, in the FAPI 2.0 conformance suite plans, servers that accept non-PAR requests are already detected and can not certify.

Authorization servers that only take part in FAPI 2.0 are of course allowed to signal this requirement via discovery but it shouldn’t be made a general requirement like so to allow for the aforementioned simultaneous operation.

[Mark Verstege]

Thanks @Filip Skokan - that make sense. I wasn’t thinking about it from that perspective - I was thinking of the profile being enacted in isolation. In effect, an AS supporting only FAPI 2 could choose to do so.

‌

[Dima Postnikov]

@Filip Skokan does it mean that AS that supports both FAPI 1 (without PAR) and FAPI 2 cannot pass FAPI 2 conformance test?

[Filip Skokan]

@Dima Postnikov it absolutely can, but it has to require the use of PAR for FAPI2 clients through client-level setting rather than a global server one.

[Dave Tonge]

Agreed on the call that the property isn't required for AS as it can be configured at Client level

[Dima Postnikov]

The rationale why we cannot require it makes sense.

Side note: it is a reasonable question that will probably be asked again - is there anything we could add to the spec or implementation considerations to make it clear? @Dave Tonge