<div dir="ltr"><div>Explanation in detail is as follows.</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best Regards,</div><div>Takahiko Kawasaki</div><div>Authlete, Inc.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 12:05 AM Takahiko Kawasaki <<a href="mailto:taka@authlete.com">taka@authlete.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<br><br>My comments on "Grant Management for OAuth 2.0" ( <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md" target="_blank">https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md</a> ) are as follows.<br><br>[1] Multiple Grant IDs<br><br>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.<br><br>[2] Single Grant ID (or No Grant ID)<br><br>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.<br><br>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.<br><br>Best Regards,<br>Takahiko Kawasaki<br>Authlete, Inc.<br></div>
</blockquote></div>