RAR requirement may be unnecessary?

[Joseph Heenan]

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.)

‌

[Brian Campbell]

agree w/ Joseph here

[Filip Skokan]

I also agree with Joseph.

[Torsten Lodderstedt]

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.

[Filip Skokan]

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.

[Joseph Heenan]

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.

[Brian Campbell]

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.

[Torsten Lodderstedt]

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.

[Filip Skokan]

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?

[Torsten Lodderstedt]

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?

[Daniel Fett]

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.

[Joseph Heenan]

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?

Let’s split this into 4 cases to make it clear in which situations insisting on RAR might cause extra unnecessary problems:

1. I have an ecosystem that’s starting from scratch and I want to use FAPI 2 but my use cases are simple

This can be argued either way. Given some much software (on the OP and RP) expects/requires the use of scopes it’s introducing an unnecessary degree of confusion to insist on RAR when scopes would work. The opposing argument is that by FAPI 2 requiring RAR, that software would be updated more quickly to have good RAR support.

‌

2. I have an ecosystem that’s starting from scratch and I want to use FAPI 2 and I need RAR-style complex things

Clearly a no brainer to require RAR.

‌

3. I have an ecosystem already that doesn’t need RAR/lodged intent/etc and I want to migrate to FAPI2

Similar to ‘1' I think you can argue this either way, though the fact that it’s a migration makes introducing RAR less desirable I think.

‌

4. I have an ecosystem already that does need RAR-style complex things and I want to migrate to FAPI 2

This is a tricky one. RAR is not a complete replacement for OBUK pre-lodged intent (RAR and grant management might be). If FAPI2 says pre-lodged intent must not be used, then OBUK systems can’t migrate to FAPI2 until the OBUK specs are updated to set out how to use their APIs with RAR and how intents are managed. (Or to be technically compliant, banks end up using pre-lodged intent and RAR at the same time - even that I think still needs updates to the OBUK specs to make it clear how that is done).

Daniel’s above suggestion to add an exception for legacy cases is a good idea, but perhaps still leaves a gap for the cases where RAR on it’s own isn’t a full solution for the problem.

‌

‌

[Torsten Lodderstedt]

RAR is not a complete replacement for OBUK pre-lodged intent (RAR and grant management might be).

What is the gap between RAR and pre-lodged intent? I assume revocation/deletion of the the grant?

[Joseph Heenan]

What is the gap between RAR and pre-lodged intent? I assume revocation/deletion of the the grant?

Yep - and renewal of an existing grant (at 90 days due to PSD2), and querying the status, I think

‌

[Torsten Lodderstedt]

I would assume a client would renew the grant by “just” send another authorization request with the same RAR object to extend or re-gain the access. Anything I’m missing?

What is the purpose of the status query? I’m asking since a client will immediately recognize it lost access (or the grant scope was reduced), when it receives a 401 or 403 with an API response.

Revocation could be solved with token revocation (especially with refresh tokens) or (a small portion of) grant management.

[Joseph Heenan]

I would assume a client would renew the grant by “just” send another authorization request with the same RAR object to extend or re-gain the access. Anything I’m missing?

How deep do you want to go down this rabbit hole? There are various properties that renewing has, like it must be done by the same user at the OP and must result in access to the same set of resources. (So if a user has ‘account a’ and ‘account b’ at a bank, and has shared ‘account a’ with a RP, renewing that grant must retain access to ‘account a’.)

What is the purpose of the status query? I’m asking since a client will immediately recognize it lost access (or the grant scope was reduced), when it receives a 401 or 403 with an API response. 

We’re stretching at the limits of my knowledge of OB now, but I believe it does allow the status to be queried so that an RP can preemptively renew a few days before expiry, rather than only renewing once it’s access has ended - and that needs to be a query (rather than the RP remembering when it last renewed) as the grant can also be extended directly between the OP and the user without the RP being involved.

[Torsten Lodderstedt]

How deep do you want to go down this rabbit hole? 

As deep as needed to understand requirements and differentiate them from “well, we just do it that way”

Why must the TPP ensure the same user account is used at the ASPSP? Assuming the TPP controls the user identity yon its side, it shall be up to the user to decide what user account she uses with the bank. Even if that means the user change the user account with the bank in subsequent authorization processes. If the TPP wants to ensure it gets access to specific bank accounts, it can just list those in subsequent authorization requests.

[Dave Tonge]

I think I agree with you Torsten. If starting from scratch with RAR in the OBUK ecosystem I would advocate the following:

• introspection (or similar) endpoint that returns metadata around SCA expiry, so that a TPP can know when re-authentication needs to take place
• guidance for TPPs that if they want an optimised “re-auth” journey they should send to the bank the explicit accounts that the user is re-authenticating. If the bank detects that the authenticated user has a previous “grant” for the same accounts, the user can be take through an optimized journey.

By sending through the previously authenticated account ids (which may well be PPIDs) the bank will have the full information to know that the TPP would like to re-authenticate, rather than start a new connection flow.

I’m in favour of mandating support for RAR. If we look at something like OBUK, it would be silly for them to keep the existing lodged intent and then add PAR as well. If they have to implement PAR then they may as well implement RAR as well (nb I’m not sure if OBUK will move to FAPI2 for a long time).

For ecosystems without the need (initially) for rich authorization requests, then perhaps the AS could simply have an empty array in the authorization_data_types_supported metadata. This would mean that initially, only scope would be supported, but it would provide an easier upgrade path for when that ecosystem eventually needs rich authorization requests (which most will).

‌

[Dave Tonge]

We discussed on the call today and agreed to add text along these lines:
”If an ecosystem needs to support rich authorization data, it should use RAR”

‌

‌

[Stuart Low]

The concern I have with should is that vendors consider this an optional requirement to complete FAPI2 certification. While broadly speaking RAR may not be required for some use cases the lack of requirement may result in vendor functionality governing the use case decisions.

[Dima Postnikov]

"FAPI 2 Ready" vendor product shall support RAR. If an ecosystem needs to support rich authorization data (scope not sufficient to carry authorization data), it shall use RAR.

We would need new certification level "FAPI 2 Ready".

[Torsten Lodderstedt]

I fully agree that ecosystems shall be able to decide what mechanisms they use for authorization. My intention is to foster vendor adoption of RAR as prerequisite for choice. If vendors don’t support RAR, I assume ecosystems will use whatever seems to be possible.

Could we separate those perspectives (vendors vs ecosystems) in the spec?

[Daniel Fett]

Proposal: https://bitbucket.org/openid/fapi/commits/e1365ad6073f5e1ca7a23deb0cb735afb4741cb7

[Filip Skokan]

@Daniel Fett proposal seems alright

[Torsten Lodderstedt]

consensus in the call today: the spirit of the proposal is well received, however the text shall be tweaked.

Proposal:

shall support the ‘authorization_details’ parameter according to [@I-D.ietf-oauth-rar] to convey the authorizations clients want to obtain if the `scope` parameter is not expressive enough for that purpose

‌

[Brian Campbell]

+1 to @Torsten Lodderstedt 's tweaked proposal but I think that “authorizations” should be just “authorization”

[Daniel Fett]

Updated in master.

[Daniel Fett]

Updated text in https://bitbucket.org/openid/fapi/commits/8c419e35c245de992e02579ee52c2a64e171a693