When the user being authenticated is different from the user of the grant

[Takahiko Kawasaki]

As a grant represents privileges given to a client by a user, a grant specified by the grant_id request parameter is associated with a user. How should an authorization server behave when the user being authenticated is different from the user of the grant? Examples of possible actions are as follows.

1. Force the user to login as the user of the grant (and return an error if the user fails to login).
2. Ignore the grant_id and grant_management_action (whose value is either replace or update) request parameters (and not perform grant management). In other words, perform grant management only when the authenticated user is identical to the user of the grant.

Or, should the decision be left to authorization server implementations?

[Joseph Heenan]

There’s also the situation where the users are different, but the new user is able to grant permission over the same set of resources. (e.g. both users are part of a joint bank accounts, or any kind of system where there are multiple ‘admin’ level users, etc). That situation does get pretty complex though, as there may not be a full intersection between the permissions the two users have and the permissions currently in the grant_id.

‌

[Tom Jones]

@ Joseph - that is the most common case in financial accounts. There is always the “First Named Holder”.

I suspect it NEVER the case that the grantee has the same privileges as the grantor. In Healthcare the privileges granted always come with a wide range of possible choices the grantee can exercise.

It is ALWAYS the case that all authorization is local. I can’t even imagine a case where the authorization server would cede all authority to make the final decision. That is even true for the RO itself. The server needs to decide by itself if the request is valid.

[Takahiko Kawasaki]

Thank you for the discussion in today's FAPI WG call. It sounds that the conclusion would be, for now, "dare not to mention the case in the specification" and "leave it to implementations".

[Dima Postnikov]

IMO

Grant is owned by an end user that authorised it. Only the original user can update or delete grant. If another user is trying to access grants, the AS should return an error.

‌

Grant can contain permissions related to resources that can be managed by other users as well. When these other users try to create a grant over the same resources, this would be a different grant.

Thoughts?

[Joseph Heenan]

Grant is owned by an end user that authorised it. Only the original user can update or delete grant. If another user is trying to access grants, the AS should return an error.

I don’t think this behaviour should be required by the spec.

The example I gave on the working group call a few weeks ago was based on UK / PSD2 rules, where in my company every 90 days someone needs to authorise our accounting system to continue to import transactions from our company bank account. There are several people at the company that have permission at the bank to share the data with the accounting package. If the person that originally setup the grant to the accounting package is no longer available, another user that has suitable permissions should be able to extend the grant. If they’re not able to extend the grant, they have to setup a new one from scratch - this would mean the accounting package would then have to make extra checks, to make sure that the user has granted access to the same set of accounts as originally done, and that the process is more error prone as the user could accidentally select a completely different account.

A bank’s authorization server should be free to allow the above behaviour, but equally another AS may choose not to allow that behaviour. It should be up to the AS.

‌

[Dima Postnikov]

OSW catch up:

1. change to text to a “resource owner“
2. preference is option 1 from Takahiko - more explicit behaviour, invalid_grant_id error we can check the text

‌

[Dima Postnikov]

Pull request created: https://bitbucket.org/openid/fapi/pull-requests/338

[Dima Postnikov]

PR merged