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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Sep 30 10:18:21 UTC 2020


Hi Taka,

I answered this question in ticket #316 (https://bitbucket.org/openid/fapi/issues/316/grant-management-and-incremental).

For the convenience of the mailing list readers, here is the comment.

Very good question!
Grant management is a super set of draft-ietf-oauth-incremental-authz. We discussed to build grant management as extension of draft-ietf-oauth-incremental-authz but realized the parameter include_granted_scopes does not force the AS to include the already scopes (update). The text states “the authorization server SHOULD include previously granted scopes“, which means the client cannot determine whether the parameter will be put into effect or not. We discussed this with the editor of draft-ietf-oauth-incremental-authz (William Dennis). He agreed regarding the interpretation of the spec language and promised to consider to make it a MUST. We are still waiting for conformation/change of draft.

best regards,
Torsten. 

> On 14. Aug 2020, at 07:01, Takahiko Kawasaki via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> Well, I noticed that some purposes of "Grant Management for OAuth 2.0" are similar to ones of "OAuth 2.0 Incremental Authorization" ( https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ ). How are the two specifications related? Is "Grant Management for OAuth 2.0" trying to replace "OAuth 2.0 Incremental Authorization" or become complementary to each other? (I'm sorry I don't know the background of development of "Grant Management for OAuth 2.0").
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> On Thu, Aug 13, 2020 at 6:04 PM Takahiko Kawasaki <taka at authlete.com> wrote:
> Explanation in detail is as follows.
> 
> The current specification will be able to make UI/UX better only while a resource owner is using an instance (Instance A) of a particular client application on a single device (Device A). However, when the resource owner tries to use the same client application on another different device (Device B) and give authorization to another instance (Instance B) of the client application on the device, she will be asked whether to give privileges to the instance B even if she has already given the same privileges to the instance A. This will happen because the authorization server will issue a different grant ID to each client application instance. I'm wondering whether this behavior is what the specification wants to achieve or not.
> 
> When the instance A on the device A requires another new privilege with grant_management_mode=update, the authorization server will show only the new privilege to her for confirmation and issues a new access token associated with the new privilege and other privileges that have already been granted. The specification ensures that the authorization server behaves in this way, but many service providers in the wild have already implemented a similar behavior. Such implementations will be able to issue access tokens with accumulated privileges when the instance B on the device B requires another new privilege, too. However, the specification will, rather, prohibit implementations from behaving in that way because multiple grant IDs are issued to one combination of a client application and a resource owner.
> 
> It may be possible to say that multiple grant IDs can cover use cases where each client application instance wants to have different privileges even when the resource owner is identical. However, most of such use cases can be covered by access/refresh tokens. This is the reason I said "benefits gained won't be so big compared to efforts". To be concrete, benefits can be gained mainly only when a client application requests additional privileges later. But the difference would be just the one between (1) listing all necessary scopes every time in an authorization request and (2) listing additional scopes only with a grant_id. I'm afraid client application developers won't find great benefits in the latter (2) compared to the traditional (1).
> 
> grant_management_mode=update will enable client applications to specify scopes for immediate use only but get an access token with accumulated privileges. This behavior is new. However, if each client application instance is issued a different grant ID and expected to manage it independently, there are no big differences between grant IDs and access/refresh tokens in terms of use cases.
> 
> My guess is that what people want to achieve by the new specification is "grant management per combination of a client application and a resource owner". If my guess is not wrong, I recommend not issuing multiple grant IDs to a particular combination of a client application and a resource owner. And, in turn, I would say that the new behavior would be able to be achieved without need to issue grant IDs.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> On Thu, Aug 13, 2020 at 12:05 AM Takahiko Kawasaki <taka at authlete.com> 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.
> 
> [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.
> 
> 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. 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.
> 
> 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