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

[Takahiko Kawasaki]

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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200814/d0514489/attachment.html>