Refresh Token Creation

[Stuart Low]

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

• 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?
• 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

‌

[Ralph Bragg]

Conceptually no i wouldn’t agree with this and this point is contradictory with the issue raised here: https://bitbucket.org/openid/fapi/issues/420/multi-party-consents

If a Grant is created but still requires multi party authorization, then your suggestion is not honour the code exchange but to allow the grant to be ‘polled’ using a CIBA type flow. In this case, when the grant is fully authorised, i would be given an access token for which i can then execute the desired action which might be one off.

Personally i don’t believe that grants should be tied to refresh token issuance at all and if a grant_id can be ‘re-used' as part of a subsequent auth code flow it is an interesting use case to that could be used to require the customer is present at the TPP in order to execute on said grant.

For example, You could have a Customer set up a grant giving a TPP access so the Banks doesn’t have to ask the customer(s) to re-consent, but the resource owner (or Bank) wants to make sure that the Grant is only exercised when the customer is using the TPP so I would issue the TPP a short lived AT from a code flow and not issue a refresh token for unattended access.

The Grant is perfectly legitimate with or without a refresh token, an ecosystem could define a property that explicitly required this behaviour, the grant itself could be fully Authorized (potentially requiring multi party AZ) but it is only exercisable if the resource owner was present. I don’t see a reason to tie the grant to the refresh token.

‌

[Dima Postnikov]

I agree with @Ralph Bragg : don’t see a reason to tie grant to the refresh token.

In the implementations that I have seen, grants were created for “one off+ or “short lived” consents where refresh tokens were not issued at all.

There is a requirement to inspect what has been authorised (via grant_id and GM APIs) even for these short lived consents.

‌

‌

[Torsten Lodderstedt]

It might make sense to issue a refresh token in a lot of cases where a grant id is issued, however I don’t see a need to make the refresh token issuance mandatory for grant management.

[Dima Postnikov]

@Yaron Zehavi does it answer your question? Is it Ok to close the ticket?

[Yaron Zehavi]

Yes thank you for the discussion, we can close the ticket

[Dima Postnikov]

confirmed as closed