RAR requirement may be unnecessary?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2020-11-19

FAPI 2 Baseline says the AS:

1. shall support rich authorization requests according to [I-D.ietf-oauth-rar]

I’m not sure I understand the reasoning here. It seems unnecessary for servers to support RAR if scopes or OIDC claims are sufficient for their use cases? (I can understanding the reasons for point people towards RAR if scopes/etc aren’t sufficient for their use case.)

‌

---

Bitbucket status: resolved

Bitbucket origin: issue 346

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2020-11-19

agree w/ Joseph here

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2020-11-19

I also agree with Joseph.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2020-11-19

One of the outcomes of our analysis of OpenBanking APIs was that all of them require some kind of extension to cope with the limitations of scopes to convey the data required to conduct the authorization process. In case of OpenBanking UK, for example, it’s the consent resource/consent_id construct (which is outside of the FAPI 1 scope).

RAR was developed as simplified and universal solution for those use cases. Since FAPI 2 is aiming at enabling such use cases, I think it makes sense to require RAR.

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2020-11-19

It is fine to have RAR required for FAPI2 based profiles that need to convey fine-grained authorization requests. But RAR itself does not improve security of the profile and for deployments that wish to have Financial**-Grade** deployment in terms of the security properties it is not necessary.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2020-11-19

Agree with Filip. Whilst FAPI2 should be able to serve OpenBanking use cases well, it should also be a good solution for simpler non-OpenBanking use cases.

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2020-11-19

FAPI 2 Baseline could recommend or even require RAR for cases where scope is insufficient or inappropriate. But such cases are far from a majority and generally requiring RAR is overstepping.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2020-11-19

Can you please explain the use cases FAPI aims to support? I would like to understand which of them can be solved (in an interoperable manner) with scopes.

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2020-11-19

Any existing OAuth 2.0 deployment that wants to improve its security properties using FAPI 2.0 should not need to reinvent its authorization request structure using RAR to justify this particular requirement. Or is there something RAR brings to the table when existing scope structure already works for those deployments?

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2020-11-20

The AS supporting RAR does not mean application cannot use scopes. However, one of the major differences between FAPI 1 and 2 is interoperable support for fine grain authorization data. While this is not strictly speaking a security improvement, it facilitates simple and interoperable designs for applications with higher security & privacy requirements, which is typically the case for all applications in open banking, but also eHealth. I thought FAPI is intended to specifically support such applications.

If RAR is not a mandatory part of FAPI 2 baseline, I suspect many implementation won’t support it, i.e. deployments will need to use proprietary mechanisms for fine grain authorization.

I basically also don’t understand the reservation to support RAR. In the end, it is a JSON representation of scope. Or do you see fundamental issues with it?

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2020-11-20

I expect that a more widespread adoption of RAR and more implementations will in the long run greatly help open banking ecosystems and other applications of FAPI 2. That said, I see the need to provide an easier upgrade path for everything that is working without RAR today. If we can convince legacy applications to adopt FAPI 2 that is already a big win. Since RAR is not a security topic, I suggest to add an exception for existing (legacy) applications.