[Openid-specs-fapi] Comments on Grant Management for OAuth 2.0

Torsten Lodderstedt torsten at lodderstedt.net
Wed Sep 30 10:08:42 UTC 2020

Hi Taka,

thanks for your feedback and apologise for the delay in answering it.

> On 12. Aug 2020, at 17:05, Takahiko Kawasaki via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> Hello,
> My comments on "Grant Management for OAuth 2.0" ( https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md ) are as follows.
> [1] Multiple Grant IDs
> If the spec allows multiple grant IDs to be issued to a particular combination of a client application and a resource owner, there are no big differences between grant IDs and access/refresh tokens. I'm afraid that benefits gained won't be so big compared to efforts that would have to be made for the introduced complexity.

The main benefit is a decoupling of grants and refresh tokens. A refresh may function as representation of the grant. A separation between grant and refresh tokens allows the following use cases:
- the client may obtain multiple refresh tokens on different devices
- the client can re-connect to a grant after a refresh token has expired or way revoked. 

In both cases, the grant/consent is retained, i.e. the user does not have to consent again. Additionally if required by the respective regulation, the client can retain the data obtained via a certain grant even if the refresh token ceases to exist. 

> [2] Single Grant ID (or No Grant ID)
> If the spec ensures that the number of grant IDs issued to a particular combination of a client application and a resource owner is at most one, the spec can be simpler. I guess it would be possible to omit even issuance of grant IDs. "grant_management_mode=(update|replace)" without "grant_id" would be enough.

Right. The spec would only define two modes for updating or replacing the (implicitly identified) grant, which is more or less what https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz does (without the normative requirement to obey to the requested behaviour).

> I don't think another access token is needed to call Grant Management APIs. In other words, I think the same access token that has been issued as a result of an authorization request can be used to call Grant Management APIs.

That’s an option. We envision use cases where the client wants to mint a fresh/dedicated access token. The key question is whether the client is automatically given access to the grant API without the need to dedicated scope values. I think this is the clearer design.  

> In addition, because an access token has information about a client application and a resource owner, information about a grant ID won't be necessary in the API path or as a request parameter.

I can imagine to introduce this as an option. Whether it works depends on the access token design. A self contained access token issued for a certain RS does not need this data.

But even if the access token has information about its underlying grant, this does not address the use case of a client having multiple grant ids. 

best regards.

> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

More information about the Openid-specs-fapi mailing list