Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

From: Justin Richer <[email-masked]>
Date: Mon, 18 Jan 2016 06:47:54 -0500

Yes, this is common practice. Give the user the option to remember the decision. This is known as "trust on first use", or tofu. Our server, MITREid Connect, implements this as do many others. 

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Sergey Beryozkin <[email-masked]> 
Date: 1/18/2016  5:59 AM  (GMT-05:00) 
To: [email-masked] 
Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? 

Hi All

The question relates to the process of showing the authorization 
code/implicit flow consent screen to a user.

I'm discussing with my colleagues the possibility of avoiding asking the 
same user whose session has expired and who is re-authenticating with AS 
which scopes should be approved.

For example, suppose the OAuth2 client redirects a user with the 
requested scope 'a'. The user signs in to AS and is shown a consent 
screen asking to approve the 'a' scope. The user approves 'a' and the 
flow continues.

Some time later, when the user's session has expired, the user is 
redirected to AS with the same 'a' scope.

Would it be a good idea, at this point, not to show the user the consent 
screen asking to approve the 'a' scope again ? For example, AS can 
persist the fact that a given user has already approved 'a' for a given 
client earlier, so when the user re-authenticates, AS will use this info 
and will avoid showing the consent screen.

That seems to make sense, but I'm wondering, can there be some security 
implications associated with it, any recommendations/advices will be welcome

Sergey

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 18 Jan 2016 12:44:21 +0000

Hi Justin, thanks for the advice,

Cheers, Sergey
On 18/01/16 11:47, Justin Richer wrote:
> Yes, this is common practice. Give the user the option to remember the
> decision. This is known as "trust on first use", or tofu. Our server,
> MITREid Connect, implements this as do many others.
>
>
>
> -- Justin
>
> / Sent from my phone /
>
>

---

From: William Denniss <[email-masked]>
Date: Mon, 18 Jan 2016 19:10:15 -0800

Agree with Justin, this is pretty common. We support it for re-auth as well
as incremental auth (where the user has already approved scope "a" and is
presented with a request for scopes "a b", they will only need to approve
scope "b").  In fact if you don't do this, then incremental auth isn't
really viable.

Regarding security: don't do this for non-confidential clients where you
can't verify the identity of the app by the redirect (e.g. a localhost
redirect to an installed app).

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 19 Jan 2016 09:59:18 +0000

Hi William

Thanks for the advice. FYI we are also on the way to supporting the 
incremental authorization of scopes - thanks for highlighting the 
importance of this process on this list...

Cheers, Sergey
On 19/01/16 03:10, William Denniss wrote:
> Agree with Justin, this is pretty common. We support it for re-auth as
> well as incremental auth (where the user has already approved scope "a"
> and is presented with a request for scopes "a b", they will only need to
> approve scope "b").  In fact if you don't do this, then incremental auth
> isn't really viable.
>
> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         From: Sergey Beryozkin <[email-masked]
>         <mailto:[email-masked]>>
>         To: [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 26 Jan 2016 18:04:28 +0000

Hi

I'm not sure if the next question is off topic or too low level, 
hopefully not,

When the repeated authorization is skipped or only new scopes are 
requested to be authorized as per the incremented auth approach, is it 
reasonable to assume that the record that is used to track it all is 
actually the existing access token or is totally OIDC implementation 
specific ?
I think using the existing token as a record is reasonable because it is 
time scoped and if we do not use the access token for keeping the track 
of the multiple approvals, etc, then one need to introduce one more 
record mirroring to some extent the access token...

For example, the user session may have expired but the access token that 
was issued to a client web app on behalf of this user is still active, 
so when the user returns and signs in again, and for example, approves 
few more scopes, then the existing access token (the record) gets 
updated, instead of a new token being created.

If it is reasonable then does it mean the sticky or incremental 
authorization works as long as the access token is available 
(refreshable) ?

Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jan 2016 15:33:08 -0300

The grants should be tied to the refresh token, or a grant record tied to the confidential client.  

For native iOS I have seen  people bind it to the client_id if the client is not confidential.  That way if the user installs the same app on another device it gets the same grants.
I am however not a big fan of that and prefer to keep the grants segmented per device.   

John B.

> On Jan 26, 2016, at 3:04 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
> 
> I'm not sure if the next question is off topic or too low level, hopefully not,
> 
> When the repeated authorization is skipped or only new scopes are requested to be authorized as per the incremented auth approach, is it reasonable to assume that the record that is used to track it all is actually the existing access token or is totally OIDC implementation specific ?
> I think using the existing token as a record is reasonable because it is time scoped and if we do not use the access token for keeping the track of the multiple approvals, etc, then one need to introduce one more record mirroring to some extent the access token...
> 
> For example, the user session may have expired but the access token that was issued to a client web app on behalf of this user is still active, so when the user returns and signs in again, and for example, approves few more scopes, then the existing access token (the record) gets updated, instead of a new token being created.
> 
> If it is reasonable then does it mean the sticky or incremental authorization works as long as the access token is available (refreshable) ?
> 
> Sergey
> 
> 
> 
>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 26 Jan 2016 18:57:26 +0000

Fwiw, at Ozwillo, we track grants per user per client_id (we don't support
native apps; only web flows for now), and we don't do "incremental grants"
like Google: if you request scope B and the user had only granted scope A,
you'll get a token for scope B only. This is partly because our tokens are
not for our own APIs only, contrary to Google, so we want to allow clients
to get tokens with narrow scopes so they could have one token per
third-party API and prevent rogue resources from trying to use received
tokens at other APIs.

UI-wise, we tell the user what he already granted to the client, and even
let him grant scopes that the client has pre-registered as "possibly needed
at some time" (through a custom provisioning protocol), but the issued
token is always for the exact scopes that the client requested in this
specific request.
And if all requested scopes have already been granted, then we do a
transparent redirect without showing anything to the user (which is what
most other implementations do too)

Le mar. 26 janv. 2016 19:04, Sergey Beryozkin <[email-masked]> a

---

From: Justin Richer <[email-masked]>
Date: Tue, 26 Jan 2016 18:03:12 -0500

In MITREid Connect we track grants per client_id per user, and we have a separate database object for storing them. I wouldn’t recommend simply updating an access token that’s already in the wild with more power — that just sounds wrong.

 — Justin

> On Jan 26, 2016, at 1:57 PM, Thomas Broyer <[email-masked]> wrote:
> 
> Fwiw, at Ozwillo, we track grants per user per client_id (we don't support native apps; only web flows for now), and we don't do "incremental grants" like Google: if you request scope B and the user had only granted scope A, you'll get a token for scope B only. This is partly because our tokens are not for our own APIs only, contrary to Google, so we want to allow clients to get tokens with narrow scopes so they could have one token per third-party API and prevent rogue resources from trying to use received tokens at other APIs.
> 
> UI-wise, we tell the user what he already granted to the client, and even let him grant scopes that the client has pre-registered as "possibly needed at some time" (through a custom provisioning protocol), but the issued token is always for the exact scopes that the client requested in this specific request.
> And if all requested scopes have already been granted, then we do a transparent redirect without showing anything to the user (which is what most other implementations do too)
> 
> Le mar. 26 janv. 2016 19:04, Sergey Beryozkin <[email-masked] <mailto:[email-masked]>> a écrit :
> Hi
> 
> >> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin <[email-masked] <mailto:[email-masked]>
> >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >>         From: Sergey Beryozkin <[email-masked] <mailto:[email-masked]>
> >>         <mailto:[email-masked] <mailto:[email-masked]>>>
> >>         To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>         https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>     https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >
> >
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 27 Jan 2016 11:17:54 +0000

Hi,

Many thanks to all who provided the feedback.

As far as the existing token update is concerned I was thinking about it 
in the context of the incremental authorization which we haven't 
implemented yet so we'll need to review how to handle it later on.

Right now we are only prototyping the code for not challenging the user 
with a consent screen if the requested scopes have already been approved 
(per a given user + client id combination, and which is a base for 
supporting the incremental auth at a next step).

I'm a bit confused about the use of a 'grant' term in your replies.

So consider a confidential client redirecting the user and requesting 
some scope, as part of the authorization code flow. The user authorizes 
the client and the client gets a code *grant* which is according to the 
spec can live for up to *10 min*. The client exchanges this grant for a 
token with the token preserving the fact the user has authorized a given 
scope for this client. I guess this is all quite common.

Note the code 'grant' has already gone by now, because it was already 
used once, withing a 10 mins period, which is another spec requirement.

That is why I'm referring to the existing access token record which can 
be used for keeping the track of the scopes approved by a given user for 
a given client. This token can be refreshed if needed.

When the user's session with a confidential client's web app has 
expired, the user is redirected to authenticate, with some scopes 
requested. At this point the record which keeps the approved scopes for 
a given user/client is an existing access/refresh token.

This is why I'm confused about the use of the 'grant' term in your 
replies. I guess this can be a 'grant' record for keeping the list of 
the approved scopes/etc not related to a record representing a transient 
authorization code record. But as I said, using the live access/refresh 
token info seems reasonable, sorry, may be it is becoming too 
implementation specific...

Cheers, Sergey

On 26/01/16 23:03, Justin Richer wrote:
> In MITREid Connect we track grants per client_id per user, and we have a
> separate database object for storing them. I wouldn’t recommend simply
> updating an access token that’s already in the wild with more power —
> that just sounds wrong.
>
>   — Justin
>
>> On Jan 26, 2016, at 1:57 PM, Thomas Broyer <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Fwiw, at Ozwillo, we track grants per user per client_id (we don't
>> support native apps; only web flows for now), and we don't do
>> "incremental grants" like Google: if you request scope B and the user
>> had only granted scope A, you'll get a token for scope B only. This is
>> partly because our tokens are not for our own APIs only, contrary to
>> Google, so we want to allow clients to get tokens with narrow scopes
>> so they could have one token per third-party API and prevent rogue
>> resources from trying to use received tokens at other APIs.
>>
>> UI-wise, we tell the user what he already granted to the client, and
>> even let him grant scopes that the client has pre-registered as
>> "possibly needed at some time" (through a custom provisioning
>> protocol), but the issued token is always for the exact scopes that
>> the client requested in this specific request.
>> transparent redirect without showing anything to the user (which is
>> what most other implementations do too)
>>
>>     >> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin
>>     <[email-masked] <mailto:[email-masked]>
>>     >>         decision. This is known as "trust on first use", or
>>     tofu. Our
>>     >>         server,
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>
>>     >>         Subject: [OAUTH-WG] Can the repeated authorization of
>>     scopes be
>>     >>         avoided ?
>>     >>
>>     >>         Hi All
>>     >>
>>     >>         I'm discussing with my colleagues the possibility of
>>     avoiding
>>     >>         asking the
>>     >>         same user whose session has expired and who is
>>     re-authenticating
>>     >>         with AS
>>     >>         screen asking to approve the 'a' scope. The user
>>     approves 'a'
>>     >>         and the
>>     >>         flow continues.
>>     >>
>>     >>         Would it be a good idea, at this point, not to show the
>>     user the
>>     >>         consent
>>     >>         screen asking to approve the 'a' scope again ? For
>>     example, AS
>>     >> can
>>     >>         persist the fact that a given user has already approved
>>     'a' for
>>     >>         a given
>>     >>         client earlier, so when the user re-authenticates, AS
>>     will use
>>     >>         this info
>>     >>         That seems to make sense, but I'm wondering, can there
>>     be some
>>     >>         security
>>     >>         implications associated with it, any
>>     recommendations/advices
>>     >>         will be welcome
>>     >>
>>     >>         Sergey
>>     >>

-- 
Sergey Beryozkin

Talend Community Coders

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 27 Jan 2016 12:02:33 +0000

As fat as I'm concerned, grant==authorisation (English is not my native
language so forgive me if I'm misusing some words).
When the user clicks the authorize button on the consent screen, we save
the scopes in the database. Tokens are independent from that (except for
the business rules that we don't issue a token for a scope that hasn't been
authorized and will revoke tokens for scopes that the user later
"unauthorizes"), each token has its list of scopes maintained independently
from the list of authorized scopes.

Le mer. 27 janv. 2016 12:17, Sergey Beryozkin <[email-masked]> a
écrit :

> >>     >>         requested scope 'a'. The user signs in to AS and is
> shown a
> >>     >> consent

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 27 Jan 2016 12:17:06 +0000

Your English is better than mine :-), thanks for the feedback.

Well, I guess it can become quite implementation specific. We keep the 
the list of authorized scopes in the access token record, and if this 
access token can also be refreshed then I guess it can be a long term 
record (as far as preserving the history of the scopes previously 
authorized by a given a user for a given client)...Perhaps this is not 
ideal and may need to be reviewed....

Sergey

On 27/01/16 12:02, Thomas Broyer wrote:
> the business rules that we don't issue a token for a scope that hasn't
> been authorized and will revoke tokens for scopes that the user later
> "unauthorizes"), each token has its list of scopes maintained
> independently from the list of authorized scopes.
>
>
> Le mer. 27 janv. 2016 12:17, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>     Hi,
>
>     <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >> Le mar. 26 janv. 2016 19:04, Sergey Beryozkin
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> a
>     écrit :
>      >>
>      >>     Hi
>      >>
>      >>     I think using the existing token as a record is reasonable
>     because
>      >>     it is
>      >>     time scoped and if we do not use the access token for
>     keeping the
>      >>     track
>      >>     >> Regarding security: don't do this for non-confidential
>     clients
>      >>     where you
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>     >> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>      >>     >>
>      >>     >>         Yes, this is common practice. Give the user the
>     option to
>      >>     >>         remember the
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>     >>         <mailto:[email-masked]
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >>     >>         For example, suppose the OAuth2 client redirects
>     a user
>      >>     with the
>      >>     >>         requested scope 'a'. The user signs in to AS and
>     is shown a
>      >>     >> consent
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 07:54:51 -0500

The difference might be whether you want to store the scope consent by 
client "instance" vs client_id application "class". Assuming that the 
client is not using dynamic client registration, then storing scope 
consent by client_id applies to all instances of that client. In most 
cases this is sufficient. However, if you want to store scope consent on 
a client instance basis and are not using dynamic client registration, 
then you would need to introduce something that can be used to represent 
the client instance. The access token could be such a mechanism.

Thanks,
George

On 1/27/16 7:17 AM, Sergey Beryozkin wrote:
>>      >>     For example, the user session may have expired but the 
>> access
>>      >>     token that
>>      >>     >> Agree with Justin, this is pretty common. We support 
>> it for
>>      >>     re-auth as
>>      >>     >> well as incremental auth (where the user has already 
>> approved
>>      >>     scope "a"
>>      >>     >> and is presented with a request for scopes "a b", they 
>> will
>>      >>     only need to
>>      >>     >> can't verify the identity of the app by the redirect 
>> (e.g. a
>>      >>     localhost
>> <mailto:[email-masked]>>>>
>>      >>     >>         The question relates to the process of showing 
>> the
>>      >>     authorization
>>      >>     >>         Some time later, when the user's session has 
>> expired,
>>      >>     the user is

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 27 Jan 2016 16:07:43 +0000

On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <[email-masked]> wrote:

> client "instance" vs client_id application "class".
>

Correct me if I'm wrong but this only makes sense for "native apps", not
for web apps, right?
(of course, now with "installable web apps" –e.g. progressive web apps–,
lines get blurry; any suggestion how you'd do it then? cookies?)

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 11:43:17 -0500

Yes, I was thinking mostly of "native apps"... though you bring up a 
good point. It would be great if "installable" web apps could do dynamic 
client registration:)  I suppose for a "public" client that is loaded 
onto a device, the "installation" process could obtain a new client_id 
for that instance. Cookies might work, or have the app generate a unique 
identifier and use that in conjunction with the client_id?

Thanks,
George

On 1/27/16 11:07 AM, Thomas Broyer wrote:
>
>
> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The difference might be whether you want to store the scope
>     consent by client "instance" vs client_id application "class".
>
>
> Correct me if I'm wrong but this only makes sense for "native apps", 
> not for web apps, right?
> (of course, now with "installable web apps" –e.g. progressive web 
> apps–, lines get blurry; any suggestion how you'd do it then? cookies?)

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 11:53:38 -0500

My recommendation, like the others, is to store consent by 
client_id:user and then try and leverage dynamic client registration if 
instance level consent is needed.

On 1/27/16 11:43 AM, George Fletcher wrote:
> good point. It would be great if "installable" web apps could do 
> dynamic client registration:)  I suppose for a "public" client that is 
> loaded onto a device, the "installation" process could obtain a new 
> client_id for that instance. Cookies might work, or have the app 
> generate a unique identifier and use that in conjunction with the 
> client_id?
>
> Thanks,
> George
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 27 Jan 2016 17:11:34 +0000

Hi George

Thanks. I think I'll need to spend more time on thinking about the way 
it has to be implemented, but I guess one thing I realize is that using 
only access tokens as records for this purpose is not ideal/generic.

That said, it is not clear to me that a per-instance level consent 
makes sense only when the dynamic registration is used.

Suppose we have a statically registered client, with the client id 
shared between 100 devices or even confidential clients. I'm actually 
not sure how realistic it is that the same user works with more than one 
device sharing the same id, but assuming it is possible sometimes, and 
further, with incremental authentication in place,

we can have a situation where while working on device1 a user has 
approved 'a' while on device2 - scope "b", with both devices sharing the 
same client id.

May be I'm making it too complex :-)

Thanks, Sergey

-- 
Sergey Beryozkin

Talend Community Coders

---

From: William Denniss <[email-masked]>
Date: Wed, 27 Jan 2016 09:47:54 -0800

In our implementation we mostly record grants as per-user, per-client_id.
However, we treat public clients whose identity we can't verify as
ineligible for incremental auth. The reason is if a client is
counterfeiting another client, we don't want to return previous
authorizations (the user should at least have to grant permissions in the
context of this other counterfeiting application).  For a public client
where the return path can be guaranteed by the OS (e.g. Universal Links on
iOS), this rule can be relaxed, so it's more about public clients whose
identity cannot be verified (e.g. custom URI scheme, or localhost redirect).

I have an idea for how to solve those unverifiable clients too, where the
client would prove its previous authorization grant by providing the
current access token on the new "incremental" authorization request.

For verifiable clients, we have an option to "snowball" tokens and include
previous grants (with the exception of some scopes that need per-device
approval), using the non-standard param include_granted_scopes
<https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>.
Such a request results in a new token being issued with potentially
increased scope, we don't automatically increase the scope of previously
issued tokens.

Perhaps this group could consider standardizing Incremental OAuth. There
are valuable lessons & techniques that several people here have learnt and
implemented over the years, as shown by this thread. I might be willing to
put together a draft.

On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <[email-masked]>
wrote:

> Hi George
>
> Thanks. I think I'll need to spend more time on thinking about the way it
> has to be implemented, but I guess one thing I realize is that using only
> access tokens as records for this purpose is not ideal/generic.
>
> That said, it is not clear to me that a per-instance level consent makes
> sense only when the dynamic registration is used.
>
> Suppose we have a statically registered client, with the client id shared
> between 100 devices or even confidential clients. I'm actually not sure how
> realistic it is that the same user works with more than one device sharing
> the same id, but assuming it is possible sometimes, and further, with
> incremental authentication in place,
>
> we can have a situation where while working on device1 a user has approved
> 'a' while on device2 - scope "b", with both devices sharing the same client
> id.
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 28 Jan 2016 09:40:51 +0000

Hi

On 27/01/16 17:47, William Denniss wrote:
> In our implementation we mostly record grants as per-user,
> per-client_id. However, we treat public clients whose identity we can't
> verify as ineligible for incremental auth. The reason is if a client is
> authorizations (the user should at least have to grant permissions in
> the context of this other counterfeiting application).  For a public
> client where the return path can be guaranteed by the OS (e.g. Universal
> Links on iOS), this rule can be relaxed, so it's more about public
> clients whose identity cannot be verified (e.g. custom URI scheme, or
> localhost redirect).
>
> I have an idea for how to solve those unverifiable clients too, where
> the client would prove its previous authorization grant by providing the
> For verifiable clients, we have an option to "snowball" tokens and
> include previous grants (with the exception of some scopes that need
> per-device approval), using the non-standard param
> include_granted_scopes
> are valuable lessons & techniques that several people here have learnt
> and implemented over the years, as shown by this thread. I might be
> willing to put together a draft.

IMHO it would be very useful, +1

Thanks, Sergey

>
>
>
> On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <[email-masked]
>     Thanks. I think I'll need to spend more time on thinking about the
>     way it has to be implemented, but I guess one thing I realize is
>     that using only access tokens as records for this purpose is not
>     ideal/generic.
>
>     shared between 100 devices or even confidential clients. I'm
>     actually not sure how realistic it is that the same user works with
>     more than one device sharing the same id, but assuming it is
>     possible sometimes, and further, with incremental authentication in
>     place,
>
>     approved 'a' while on device2 - scope "b", with both devices sharing
>     the same client id.
>
>                 On Wed, Jan 27, 2016 at 1:54 PM George Fletcher
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Jan 2016 09:17:23 -0300

Some people want exactly that behaviour.  If the user approves scope A on device a and scope B on device b, they want both to have scopes A & B.

Given that many AS are custom built for a specific service this can work for them.   It really depends on the API/Service what policy you want.  

When doing a generic library if it is not selectable someone will complain because they wanted it the other way.

Personally I don’t like that approach but perhaps people like twitter etc know better.

John B.

> On Jan 27, 2016, at 2:11 PM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi George
> 
> Thanks. I think I'll need to spend more time on thinking about the way it has to be implemented, but I guess one thing I realize is that using only access tokens as records for this purpose is not ideal/generic.
> 
> That said, it is not clear to me that a per-instance level consent makes sense only when the dynamic registration is used.
> 
> Suppose we have a statically registered client, with the client id shared between 100 devices or even confidential clients. I'm actually not sure how realistic it is that the same user works with more than one device sharing the same id, but assuming it is possible sometimes, and further, with incremental authentication in place,
> 
> we can have a situation where while working on device1 a user has approved 'a' while on device2 - scope "b", with both devices sharing the same client id.
>

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Jan 2016 09:24:17 -0300

No web clients often make use of sticky grants.   Sharing client_id amongst multiple instances is a native app thing, but stick grants work best with confidential clients.

It is to some extent a UI decision by the AS, to tell the user you have already granted A & B , they are asking to add C,  or re-prompt the user for A, B and C without giving the context.

The other thing to consider is implicit clients without refresh tokens.   

If the client is JS in the browser then if you remember the grants the JS can do a prompt=none flow to refresh an expired AT in the background as long as the browser has a session with the AS.

If you are using an implicit client and don’t support sticky grants, you wind up having to have AT that have a lifetime grater than what is optimal.

John B.

> On Jan 27, 2016, at 1:07 PM, Thomas Broyer <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
> The difference might be whether you want to store the scope consent by client "instance" vs client_id application "class".
> 
> Correct me if I'm wrong but this only makes sense for "native apps", not for web apps, right?
> (of course, now with "installable web apps" –e.g. progressive web apps–, lines get blurry; any suggestion how you'd do it then? cookies?)