Grant Create and Access Methods

[Stuart Low]

From @Yaron Zehavi  https://bitbucket.org/openid/fapi/issues/407/grant-management-lifecycle#comment-60599018

1 Authorization Request - What is the need to support grant_management_action=create? Aren't approved authorization requests already creating grants implicitly without this new parameter?

2 Grant Management API -> API authorization - I suggest to consider securing the Grant Management API with the refresh token used as bearer token. This achieves several benefits:

• Removes burden from client to request a separate access token
• Simplifies AS implementation as it removes the need to look up the grant, instead relying on extracting grant id from the refresh token
• Provides stronger API security in case an attacker has succeeded to impersonate the client. Attacker would not be able to manipulate or query grants without also obtaining the individual refresh tokens

3 Query Status of a Grant - Keep in mind that the proposed API probably cannot fully replace open banking GET /consents/{ConsentID} because consent details may differ from grant details

‌

[Ralph Bragg]

I’m confused about the last point, we discussed how Grant Management can be used to replace the consent id in Open Banking GET as the current Open Banking model is a combination of an ‘intent to create something' which can be replaced by grant mangement, a resource and a resource that has its own lifecycle. I discussed splitting apart these concerns conceptually and why it fits quite well.

A better example of this is to use the OBIE UK https://openbankinguk.github.io/read-write-api-site3/v3.1.8/profiles/vrp-profile.html#steps VRP specification. That splits out the ‘consent to create payments’ from the payment resource creation lifecycle. This is actually a step towards the model proposed by grant management already.

[Dima Postnikov]

Authorization Request - What is the need to support grant_management_action=create? Aren't approved authorization requests already creating grants implicitly without this new parameter?

In ecosystems that support concurrent consent, “create” forces AS to create a new grant (even if there is another existing grant). This is more defined behaviour, otherwise some AS might replace or update existing grant between AS, Client and a user. Client knows better what they are trying to do and they are given a choice: create, update or replace.

[Torsten Lodderstedt]

I suggest to further split this ticket as the three bullets are pretty different.

[Dima Postnikov]

#1 and #3 possibly are answered already. Yaron, please confirm.

I will separate #2 into a separate issue.

‌

[Torsten Lodderstedt]

re 1): ASs work differently. Some create a grant for every approved authorization request, others determine a pre-existing grant using the client id and user id as combined key. As long as the client does not request a certain behavior, we won’t have an interoperable solution.

[Yaron Zehavi]

@Dima Postnikov I confirm

[Dima Postnikov]

Resolved