Rich Authorization Requests (RAR)

[guymoyo]

[guymoyo]

Thanks @guymoyo for your proposal, this looks promising :)

I just have a few remarks inline.

Thanks @thomasdarimont, I will check your remarks.

[VinodAnandan]

New revision: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-07

[tnorimat]

@mposolda For https://github.com/keycloak/keycloak-community/pull/266#pullrequestreview-757411929 , OIDF's FAPI site mentions that FAPI 1.0 lodged intent be replaced with OAuth PAR + OAuth RAR. Therefore, at this time, it might be OK for us to focus only on supporting RAR.

[tnorimat]

@guymoyo , @mposolda , @thomasdarimont , As an design document, it seems to be OK to be merged after the current review comments are resolved.

IMO, when implementing it, the following points might be difficult to handle.

• showing an consent screen with respect to "authroization_details"
• enriching "authroization_details" on UI
• managing consents with respect to "authroization_details"

The last point is also related to dynamic scopes and FAPI 2.0 Grant Management for OAuth 2.0.

I think the current keycloak's consent model may need to be modified.

Also, on implementation, I think keycloak need not include any concrete RAR processor provider because it is highly dependent on specific use-cases. However, arquillian integration tests need to include some concrete RAR processor.

[mposolda]

@guymoyo , @mposolda , @thomasdarimont , As an design document, it seems to be OK to be merged after the current review comments are resolved.

IMO, when implementing it, the following points might be difficult to handle.

* showing an consent screen with respect to "authroization_details"

* enriching "authroization_details" on UI

* managing consents with respect to "authroization_details"

The last point is also related to dynamic scopes and FAPI 2.0 Grant Management for OAuth 2.0.

I think the current keycloak's consent model may need to be modified.

Also, on implementation, I think keycloak need not include any concrete RAR processor provider because it is highly dependent on specific use-cases. However, arquillian integration tests need to include some concrete RAR processor.

@tnorimat These are very good points. It will be good to consider RAR as a more powerful alternative to classic "scope" parameter, however dynamic scopes have lots of common things with RAR.

It turns that Keycloak team has some internal requirements and it looks that it may need to prioritize the work on dynamic scopes soon. There are some use-cases to dynamic scopes discussed here https://github.com/keycloak/keycloak/discussions/8486 and some other discussion started here https://github.com/keycloak/keycloak/discussions/8488#discussioncomment-1394572 .

Overally, we will need to figure some way how to do RAR and dynamic scopes together and make sure that whatever is done will match the requirements for both these use-cases.

For now, I am not 100% sure how to move forward. I suggest to anyone to comment on the mentioned discussions for dynamic scopes and eventually add feedback to them.

[stianst]

I haven't had time to read through this proposal yet, but I've come to the conclusion that we must not extend "scopes" without considering RAR, and at the same time we must not implement RAR as a separate thing. The two have very similar needs: a) client includes some additional details in authz request, b) some policies decide if it's permitted or not, c) the user optionally consents to some stuff, and d) some claims are added to tokens.