Grant Management and Semantics

[mdoujak]

I am not convinced that Grant Management will solve more problems than it creates and I would like to explain in this issue, what my reservations are.

In the context of bLink Grant Management will be used as follows:

• Banks will run Grant Management Servers that hold all the grants given by their customers to various fintechs.
• Fintechs will request sets of grants from their users which then in turn will authorize none, some or all of the requested grants.

So far this sounds very good. We have a protocol that allows us to CRUD grants and it is integrated with the chosen OAuth / OIDC protocol suite.

What we are lacking however is semantics. The standards do not define anything regarding the semantics and this is where the complexity explodes. For grants to work correctly, each Fintech must understand the Grant Management of every Bank to formulate the proper requests.

As I see it, there is only one way, how to resolve this. Mainly by standardizing grants accross all Banks. Due to the differences within the implementations of the Banks, this seems very difficult. At the same time, if we can achieve this, then we can stick to scopes where one scope references a well-defined grant.

I tried to visualize the problem in the picture below. Where each of the Fintechs has to support all the grants of every Bank. The grants are depicted as colored circles and the color corresponds with the colors of the Banks.

[mdoujak]

Which problem are we actually trying to solve?

• A customer (resource owner) may use the same TPP (client) with the same Bank (authorization server) to grant access to more than one back-end. (e.g. E-Banking, Wealth Management)

In this situation, we have two consents for entirely different use cases, but we cannot differentiate them since all OIDC actors are the same.

In bLink we currently already have the following mechanisms:

• remote consent management, where customers can grant and manage consent.
• username injection to inject the TPP username into the authorization code flow at the Bank

Based on this, I would suggest that we add another attribute (e.g. consent_type) that is added through all request (similar to the username) and that is respected by the remote consent management service to differentiate multiple grants:

• we now can user resource owner, client, Bank and consent_type to identify a consent and therefore differentiate consents for e-banking from those for wealth management.