FAPI 2.0 - Hard requirement to support Grant Management Requirement

[Ralph Bragg]

One of the goals of Grant Management is to enable the management of authorization_details / other scope controlling properties. RAR by itself does not provide any ability to manage or interrogate created authorization objects. ‘Grant’ Management and querying is supported in most lodging intent pattern implementations globally.

In order to replace current implementations of Open Banking Authorisation Management APIs, which make extensive use of lodging intent pattern, we need Grant Management functionality.

Currently the specification includes

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

The intent of this is obviously to get people to stop using ‘Lodging intent’ or other non standard ways of conveying rich authorisations however a strict interpretation would prevent implementations from being FAPI 2.0 compliant whilst they were still using lodging intent.

A less strict, but a literally interpretation, is that provided the ‘scope’ is conveyed in the ‘scope’ parameter of oAuth 2.0, even if it was a reference to the lodged intent, then an implementation is compliant.

What do we want to do to reconcile this.

[Ralph Bragg]

Need more sleep when i write a ticket.

[Renato Athaydes]

I just want to mention that another example of “other non standard ways of conveying rich authorizations” was discussed on ticket https://bitbucket.org/openid/fapi/issues/416/rar-if-scope-and-claims-param-not

I am sure there are many more, and I also believe RAR cannot replace not only the “lodging intent patern” but many of those as well. While we would be happy if RAR can evolve to achieve that one day, we believe we cannot wait for that to happen for FAPI2 to reach a final draft, hence we also would like to request that this sentence is not so restrictive with regards to how clients can request authorization (opening up the way for alternative specifications to be used for that).

[Dave Tonge]

There was discussion about this yesterday, but no agreement yet.

I suggest that some wording be proposed that the WG can consider.

‌

[Travis Spencer]

My proposed wording to address this issue can be found in Issue #416.

[Takahiko Kawasaki]

In my understanding, “Intent” exists independently of “Access Token”, so Open Banking implementations using the Lodging Intent pattern have to provide APIs to manage Intents. I guess that important operations on Intents are “query” and “revocation”. (If my assumption described here in this first paragraph is wrong, the following paragraphs have little meanings.)

On the other hand, “authorization_details” is information attached to “Access Token”. RFC 7662 (OAuth 2.0 Token Introspection) and RFC 7009 (OAuth 2.0 Token Revocation) can work as “query” and “revocation” operations on a single “authorization_details” (i.e. a single access token).

What FAPI Grant Management API is trying to achieve is more than simple “query” and “revocation” operations. If Open Banking Authorisation Management APIs provide functionalities more than simple operations, FAPI 2.0 will need Grant Management APIs to replace Open Banking implementations using the Lodging Intent competely. But otherwise, missing Grant Management APIs will not make it impossible to build a FAPI 2.0 compliant system that can do similar things to the Lodging Intent pattern.

In any case, descriptions in the FAPI 2.0 specification do not necessarily have to urge existing Open Banking implementations using the Lodging Intent pattern to move to FAPI 2.0 even if the intention of RAR (+ PAR + etc) is to become a replacement of the Lodging Intent pattern.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/279/add-reference-to-grant-management-api

This ticket can stay open as further discussion is needed. However on the WG call today we discussed adding the text in the above PR.

[Dima Postnikov]

We had a discussion in today’s WG call. Based on experience in multiple jurisdictions, here is a proposed scope for FAPI 2 family of specifications (FAPI 2 Trust Framework?).

The objective is to keep security profile separate from some of the other areas where we work on interoperable solutions to enable trust ecosystems like Open Banking.

What does everyone think?

‌

[Dima Postnikov]

Resolved as per https://bitbucket.org/openid/fapi/issues/432/fapi2-trust-framework-structure.

Advanced authorization profile (new) will have a hard requirement to support GM for a certain type of use cases.

[Dave Tonge]

#432 is dealing with this