SL2 - to PAR or not to PAR?

[aaronpk]

Should IPSIE level SL1 require PAR?

FAPI requires PAR in the baseline security profile.

It is relatively uncommon for OpenID Connect implementations today to have PAR support, although many do.

[mcguinness]

My understanding is FAPI has a strong need for integrity protection and has constraints of authz request due to the parameters being passed and their use in FAPI flows (e.g. RAR). Its unclear at this moment if IPSIE is in the same boat. I would delay requiring PAR till we have strong need as its not used today in most enterprise SSO flows. Lets detail the required params for an IPSIE SSO flow and look at the threat models

[jogu]

If PAR was mandated, the IPSIE SL1 profile starts to look exactly like a profile of FAPI2 that selects private_key_jwt + DPoP + mandates a few extra things?

This would make it (in my somewhat biased opinion given I'm an author of FAPI2) a clear reason to use PAR given a bunch of vendors have FAPI2 support 'off the shelf', it's already formally analysed, many ecosystems have already mandated FAPI2 (or stated a clear intent to do so once it was final, which it now is), etc.

PAR prevents tampering with authorization requests, and hence we can start with assumptions like the set of "scopes I requested" is the same set as "scopes the authorization server got in the request from me" - not having that assumption can lead to unexpected results when attackers modify authorization requests.

PAR is such a simple spec that has very strong benefits and diverging from FAPI2 (and hence incurring all the burden of a formal security analysis / debating & maintaining a non-trivial separate spec / new conformance tests / etc) for just that reason seems quite a high cost to incur.

[mcguinness]

I think your comment @jogu is somewhat related to the question I asked with #61 .

If we decide SL1 IPSIE conformance requires a confidential client + private_key_jwt + DPoP then I think it probably makes sense to just reuse FAPI2 profile as-is which means requiring PAR so there isn't the need for yet another formal analysis and threat model for IPSIE as well as RP SDK. The lift for existing enterprise SaaS RPs is already high enough to change their implementations IMHO so removing PAR doesn't save much IMHO. This approach has the benefit of not only securing the SSO use case with an id_token but also ensuring an RP that wants to request scopes to other protected resources offered by the IdP platform is also secure. The cost is increased RP implementation overhead for SSO only.

If however we decide that SL1 conformance should be focused on just SSO and not API access for protected resources (no additional scopes beside those in OIDC) and we want to provide maximum reach for client technologies and app frameworks then we would need a different profile from FAPI2 and would need to resolve the security implications of a new profile.

Looking forward to hearing from others here as there are some good benefits and tradeoffs with each approach.

[brockallen]

As soon as the client libraries add support, PAR will eventually be as commonplace as PKCE, as it helps in security and is fairly easy to add. FWIW, I know the ASP.NET OIDC client library supports it (Duende did the work and contributed the PR).

[Macke]

It appears that this issue is driven by "not everyone supports PAR" without any real information about support by vendors and open source products.

If this is the case I suggest that it would be important to quantify the scale of the problem.
It seems likely that there will be a number of cases that we might wish to categorise products and services into:

• Directly Supports PAR
• Can be customised to support PAR
• Has PAR in near term roadmap < 1 year
• Has PAR in roadmap > 1 year
• No plan to support

[aaronpk]

Discussion on the last call landed on not requiring PAR for SL1, but probably requiring it for SL2.