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

[Takahiko Kawasaki]

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/20200813/40981e2f/attachment-0001.html>