Grant Management Lifecycle

[Ralph Bragg]

In current implementations globally, the grant has a life cycle that begins pre-authorisation that is queryable by clients. In the current proposals with GrantAPI, or when included with RAR, alone the grant is created at Authorisation and during the latest Australian Workshop it was presented as being created post successful user authentication and consent. This is a deviation from the current functionality within ecosystems which we need to consider.

Likewise, the grant may not be ‘authorised’ or 'completely authorised' when it is first authorisd by a single user e.g Multi Party Consent. So our language in terms of lifecycle needs to consider these transitions.

The PAR request doesn’t support status and has the strong recommendation to prevent replay, “Since the request URI can be replayed, its lifetime SHOULD be short and preferably limited to one-time use.”

[Torsten Lodderstedt]

That’s the case for implementations using a lodging intent kind of pattern. There are other implementations working the way I presented (e.g. the Polish API and all “traditional” OAuth implementations).

What use cases would break if the status of a grant is not be queryable before approval?

[Ralph Bragg]

Yes but if we’re going to encourage people to move away from a lodging intent pattern with a complete e2e lifecycle we need to cater for scenarios where the consent is not authorised during the authorisation flow. This is required for every jurisdiction and we’d have a hard time getting people to switch if MP consent / Life Cycle if it doesn’t support multi party / state.

This is critical for business payments in particular.

In terms of ‘consent, ‘not yet authorized but also not initially? authorised’ it would be very useful to get additional TPP input in terms of Consent Life Cycle. i.e did a ASPSP actually authenticate and then did a PSU abandon the process at a bank? (close screen not cancel). FData in particular are very hot on customer drop off and driving towards fixing root causes. Understanding where a customer was in the complete life cycle of a ‘grant’ is important but may be outside of scope of this standard. In which case i can’t see a migration from a lodging intent patter being universally adopted.

[Torsten Lodderstedt]

Can you please describe what you mean by “… the consent is not authorised during the authorisation flow …“. I’m assuming this is about multilateral consent?

[Ralph Bragg]

Yep -

• When another user's authorisation is required and this occurs after the original authorisation was granted by the user, the client can query the status of consent at any point after the authorization to determine if full user consent has been obtained

Whilst this use case is specifically mentioned, the lifecycle of a grant should be standardised (In My Opinion) and we do need to consider scenarios where the ‘grant’ did not pass the first hurdle.

• PAR Request is created but ‘customer doesn’t get to the bank'.
• PAR request is created, customer didn’t authenticaet (but the AS saw it).
• PAR request is authenticated (claimed) but user didn’t complete. (different to cancel).

This isn’t as big or immediate an issue with CIBA because there is a handle that I can query the status of a CIBA authorisation so a loss of an authorization code or a failure to return to the client isn’t a consideration.

Potentially a way to address this would be to include a ‘grant_id’ as a handle on the response from a PAR. i.e bring the lifecycle forward. It would also allow the same grant to then be ‘replaced’ should the authorisation process fail or not complete. e.g it is authorized which is where the majority of vendors will be creating the grant as the grant will need to interact with complex systems (retrieve accounts, look up additional steps for authorization etc). If a code exchange fails and subsequently a grant_id wasn’t returned to give a handle on what was created then you can have really sub optimal conditions where a bank is doing something but a client might not be aware off it.

Alternatively, we make it explicit and that the grant is only created on code exchange which will have additional complications where data to complete a grant needs to be presented to customers during authorisation and consent and then subsequently retrieved. A lot of this would be simplified if a grant_id is returned with a PAR request so at least there is a handle to the underlying grant that then is built up over time.

status. created, received, claimed (authenticated), authorization in progress, (initial authorization), authorized.

functional additional details added etc.

This also then brings into focus, for Grants that aren’t ‘authorised’, should the same back off retry mechanism be implemented that exists in CIBA to prevent status checking. Separate ticket raised.

[Yaron Zehavi]

Some thoughts on this topic:

• The AS and underlying business grant are currently decoupled. The AS is not aware of the approval process steps. Introducing support for status inquiries of the grant resource, requires higher coupling between the AS and the application layer where the request resource is managed, which might break existing solutions and prove to be limiting of future implementations
• Currently in redirect-based flows the RP is made aware of the result of the authorization request only when receiving the return redirect. "Lost in transit" redirects are indeed lost, but how often does it happen?
• CIBA flows provide higher traceability because there is a handle (auth_req_id) that can be queried. This still does not mean that the AS is aware of the intricate business status of the grant request
• PAR does not change this paradigm significantly, as it only offers a new mechanism to send authorization parameters (but offers no inquiry endpoints). Offering meaningful inquiry capabilities requires same higher coupling to application layer, OR giving the AS the role of managing lodged requests' lifecycle

‌

In short - I recognize the challenge but don’t support this proposal :-)

[Ralph Bragg]

Cheers

• The AS and underlying business grant are currently decoupled. The AS is not aware of the approval process steps. Introducing support for status inquiries of the grant resource, requires higher coupling between the AS and the application layer where the request resource is managed, which might break existing solutions and prove to be limiting of future implementations

  • Completely agree - So we’re now back to the reason and debate that ‘grant’ and ‘authorisation’ vs business consent. This is being proposed as a solution for the Australian data arrangement process and so at least needs to meet the ecosystem needs. Likewise it’s being considered for Brazil in the future but as it stands it doesn’t meet the needs of all participants.

I’m not proposing being able to query PAR with a grant_id, what needs to happen is that the grant_id needs to be returned as soon as possible so that the Grant can be queried. There is no agreed position on when a grant is created.

The issue I have will be recommending moving to Grant API without this basic capability or getting these fundamental issues addressed as they are ‘solved’ already in market for the UK, Brazil and NZ with the lodging intent pattern with a well understood life cycle and ownership.

FAPI 2 on first read tries to create a “hard” coupling to RAR and PAR however without a life cycle and the abilty to determine appropriate state at all times would just mean that we’d end up creatively telling Brazil that a ‘dynamic scope’ e.g consent:12345 which is being used to pass a reference to a Business Consent Resource, whilst not in the spirit of what RAR, PAR + grant management were meant to solve, is still spec compliant based on the current language.

‌

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

[Dima Postnikov]

So, to summarise a quick chat with Ralph and Stuart:

1. Grant lifecycle is largely defined. We can add more details though.
2. Ralph is suggesting to force grant and grant_id creation at PAR request time (if PAR is used), not at authorisation request time.
3. If we don’t, we potentially have an exception scenario: there is a period of time between PAR request and authorisation completion, where the flow was not complete and TPP can’t query the status of grant. This means that the whole process will need to be restarted again (even if the original process was successful).
4. This is also the current state in Australia. So if this is addressed, this will be the enhancement to the authorisation flow.
5. This has been a requirement in the UK (and was achieved with lodging intent).

Any comments are welcome.

And a question to implementors: Would your PAR implementation allow this?

‌

‌

‌

[Yaron Zehavi]

Thanks @Dima Postnikov

Some questions:

1. Do grant & grant_id get created in any other way except PAR request?
2. What is the difference between grant_id and request_uri created as successful PAR response? It is a unique handle, perhaps it can serve as grant_id for similar intents and purposes?
3. How are grant & grant_id used? Specifically, in which other endpoints are they passed?

‌

Cheers,

Yaron

‌

[Dima Postnikov]

Thanks @Yaron Zehavi for the questions.

Just to clarify we are talking about this specification here: https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md

Do grant & grant_id get created in any other way except PAR request?

You could use PAR or standard auth request. FAPI CIBA will be supported too.

‌

What is the difference between grant_id and request_uri created as successful PAR response? It is a unique handle, perhaps it can serve as grant_id for similar intents and purposes?

grant_id can be used to query grants via Grant Management APIs.

How are grant & grant_id used? Specifically, in which other endpoints are they passed?

Introduction of the spec has more info on grant concept which is existing.

‌

1. GET /grants/TSdqirmAxDa0_-DB_1bASQ
2. DELETE /grants/TSdqirmAxDa0_-DB_1bASQ
3. grant_id can be given as one the authorisation request parameters to indicate that new request is related to a previous grant.

‌

[Torsten Lodderstedt]

@Ralph Bragg My feeling is we are talking about three different topics:

1. multi-literal consent - we have some ideas how to support this with GM
2. obtaining (analytical) data about user journeys to be able to measure and improve conversion - very interesting and important topic but not strictly related to GM
3. a way to make the status of an authorisation transaction tangible from a client’s perspective (authz request lodged, auth request sent, …). I would like to understand the problems to be solved.

I read @Dima Postnikov 's comment to be part of (3).

If we don’t, we potentially have an exception scenario: there is a period of time between PAR request and authorisation completion, where the flow was not complete and TPP can’t query the status of grant. This means that the whole process will need to be restarted again (even if the original process was successful).

Can you please explain the problem you want to solve? The TPP is in full control of the process. It has created the PAR and is the party to kick off the authorization request. Do you want to query the authorization request while it is “in flight”?

[Torsten Lodderstedt]

My take aways are:

• TPPs want to be able to leverage an approved grant even if the ASPSP was unable to deliver the authz code to the TPP - we could allow the client to pre-set the grant id (would work with traditional and pushed authorization requests) and use this id to pinpoint and query the status of a grant using this grant id
• TPPs want more insight in the user journey - I would love to dig into this topic. I think it requires a different solution than GM

‌

[Torsten Lodderstedt]

@Ralph Bragg does the lodging intent as used on UK OB support authz transaction state tracking?

[Ralph Bragg]

@Torsten Lodderstedt

@Torsten Lodderstedt

• yes it does.

‌

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/pisp/domestic-payment-consents.html

Look at states; when a payment is ‘made’ the state transitions to ‘consumed’.

There are a lot of different examples of this

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/resources-and-data-models/pisp/file-payment-consents.html

All of the ‘consents' have their own life cycle and states with a lot of similarities between them. In addition checkout

https://openbankinguk.github.io/read-write-api-site3/v3.1.8/profiles/payment-initiation-api-profile.html

‌

[Torsten Lodderstedt]

thanks!

The state machines seem to represent the lifecycle of a certain authorization transaction for a certain type of API (e.g. AwaitingUpload and Consumed for file payments).

They cannot be mapped easily to the lifecycle of a grant, since the grant can (a) spawn multiple authorization transaction and (b) contain authorization data for different APIs.

The states can be partially mapped to the standard state machine of an OAuth transaction:

• Awaiting Authorization: authz request sent to AS (known to client)
• Rejected: authz error response (known to client)
• Authorized: authz response/token response (known to client)

If the AS shall make intermediate states available to the client I think we need a dedicated API with the AS for status query. I could envision this API to work with client created transaction/process ids for this purpose.

If an application wants to maintain an API specific state (such as consumed), I think that should be covered in an API specific resource or request (e.g payments/xyz/status).

WDYT?

[Dave Tonge]

I agree that a payment status cannot be mapped to a grant. They are two different concepts. I don’t think grant management is needed for single payments at all

From my perspective with PAR/RAR/Grant management the payment API would work as follows:

1. TPP posts PAR with RAR containing all payment metadata
2. TPP redirects user to request_uri received from Bank
3. User authenticates at Bank and is redirected with code

4. TPP exchanges code for token and at this point 2 things happen:

   1. grant is created
   2. payment resource is created and payment is initiated

5. TPP can now query the status of the payment using the access token received

6. TPP can query the status of the grant if they want, but there is unlikely to be any benefit whatsoever from doing that.

The difference between lodging intent and PAR is that a PAR is not a restful resource and has no associated state. This makes more sense than lodging intent - where there are loads of abandoned “account access consents” that a bank has to manage and keep hold of.

What would a TPP do with the information that the user authenticated at the bank, but there was a problem redirecting with the auth code? This should be a failure case, and essentially the user can try again. I don’t think this needs to be baked into PAR/GM

‌

‌

‌

[Ralph Bragg]

4. So you’re proposing that a grant then triggers the creation of a ‘external payment resource that has its own lifecycle’ that is intrinsically linked to a grant?

Architecturally i don’t think this is a good idea to mix concerns. I would prefer at Step 4 a TPP can then use the access token to create a payments resource at the Bank. This then allows the Payments resource to be managed in the systems that manage payments.

At this point the payments system does what ever it needs to become authorised (which is going to follow completely separate processes than an OAuth 2.0 Grant). When the resource is ‘fully authorised’ a TPP can execute it.

This is lodging intent - i’d really like to see more payments / bank technologists talk about the feasibility of managing OAuth 2.0 resource ‘grants’ in an IDP for this use case.

[Torsten Lodderstedt]

The TPP can create the payment resource in step 4. Why should the payment resource be authorized )again?

[Dave Tonge]

So, if mixing concerns is a problem then the access token can be used to submit a payment, whether that is a RESTful (POST /payments) or RPC (POST /submit-payment) - the response to that call could be the id of the payment.
There is nothing stopping a bank allowing GET requests against the payments API with client credentials based access tokens - this happens in OB.

[Ralph Bragg]

Yes exactly, the grant in this case would reflect and enforce the payment request creation. Which has its own life cycle. For single immediate payments this doesn’t offer many benefits. Though it does stop the initial resource being created waste fully. But for VRP or VRP types it does. The created resource would need management from a CC grant in the same way.

[Dave Tonge]

Conceptually from my viewpoint these are the differences:

• PAR - static authorization data (may include rich data needed to set up a payment)
• GM - dynamic authorization data - what scope/authorization_details are valid for a given grant id (and is that grant valid)
• Payment API - dynamic domain specific data (e.g. what is the status of the payment authorized with this access token)

With lodging intent you end up with 2 payment resources (payment consent and payment) - which in itself is confusing.

‌

[Dave Tonge]

OK I think I see where you are going, with VRP, grant management is useful, although arguably it would still be better to have a separate API for more detailed info about the payments.

The grant management API can just tell me if the grant is still valid, and help me confirm what the authorization_details are. Additional metadata such as:
- number of payments made under the mandate
- status of those payments, etc.

Can’t fit into grant management I don’t think

[Ralph Bragg]

Yeah exactly and this would be the same for any “create” type operation. Not just payments but anything that creates a resource. Beneficiary etc. It does remove the step of TPPs creating resources that aren’t associated to a customer which is a benefit. for a lot of the resources you’re essentially going to asking the Customer to authorise the creation of a specific resource.

Please authorise the creation of a [json blob resource]

Ok. Post json blob to endpoint.

‌

Rather than create and then authorised. I’d recommend getting Ghela and Fdata to look at the FCAs study on drop off rates and the additional MI recommendations that are going to be made. Further details on why grants weren’t completed at the AS is going to be asked for.

[Dima Postnikov]

https://bitbucket.org/openid/fapi/pull-requests/267

[Yaron Zehavi]

• Fully agree with the conclusions of Ralph and Dave, regarding not mixing concerns (exchanging a code for token should not submit payment for execution)

• Regarding multi-party consents:

  • Issuing tokens upon 1st approval but before full consent seems sub-optimal. I’m aware this is how some API standards like Berlin group get things done, but I’m against it as it introduces higher complexity due to tokens that are "half baked" in the sense that they don't represent full authority to act
  • Furthermore, managing authorization sub-resources is cumbersome for all parties. Additional challenges exist in multi-party flows as some consenting parties may not be digital-averse users, or may be digital but wish their identity remains unknown to client which contradicts with asking them to follow a redirect approval flow
  • Improved solutions can be suggested for multi-party consent. Actually that was the main reason I recently joined FAPI WG. I propose that an AS serving a redirect based flow upon receiving 1st approval of a multi-party consent, shall instruct client to use CIBA polling until full consent is reached. Technically, the return redirect would return CIBA error=authorization_pending, and would provide the client additional details for CIBA polling such as the handle (which can be used as a secure ephemeral container for consent details making additional persistence not necessary). Moving to CIBA to wait for pending multi-party consent decouples the client from subsequent approvals, maintains the other approvers' privacy and supports other ways of receiving approval including non-digital methods
  • WDYT?

• My understanding is that a grant is created only if and when a refresh token is issued. Would you agree that NO grant is created if no refresh token is issued?

• Regarding Grant Management for OAuth 2.0 spec:

  • 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?
  • Token Response - If you agree there’s a strong link between grant and refresh token, I suggest considering that grant_id shall only be returned if refresh token is also returned

  • 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

  • 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

‌

‌

[Dima Postnikov]

Hi @Yaron Zehavi , thanks a lot for your feedback.

Given that it’s a general feedback about Grant Management, I will move it to a separate issue, I hope you don’t mind.

[Dima Postnikov]

Feedback incorporated in PR https://bitbucket.org/openid/fapi/pull-requests/267