Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03

From: Mark Wubben <[email-masked]>
Date: Sun, 2 Dec 2012 17:27:09 +0000

The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.

In "1. Introduction" it is stated:

>  A
>    revocation request will invalidate the actual token and, if
>    applicable, other tokens based on the same access grant and the
>    access grant itself.

then, in "2. Token Revocation":

>  In the next step, the authorization server invalidates the token and
>    the respective access grant.  If the particular token is a refresh
>    token and the authorization server supports the revocation of access
>    tokens, then the authorization server SHOULD also invalidate all
>    access tokens based on the same access grant

This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.

If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.

---

I spotted a typo in "3. Implementation Note":

> Whether this is an viable option or
>    whether access token revocation is required should be decided based
>    on the service provider's risk analysis.

"an viable option" should be "a viable option".

On 24 Nov 2012, at 18:13, Hannes Tschofenig <[email-masked]> wrote:

> Hi all, 
> 
> this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
> 
> Please send you comments to the OAuth mailing list by December 10, 2012.   
> 
> Thanks,
> Hannes & Derek
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn

---

From: [email-masked]
Date: Mon, 3 Dec 2012 08:51:22 +0800

http://datatracker.ietf.org/doc/draft-zhou-oauth-owner-auth/

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 3 Dec 2012 12:12:35 +0900

Could you kindly explain the use case a little more, please?

Nat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: [email-masked]
Date: Mon, 3 Dec 2012 14:35:26 +0800

Well, there is a related thread 
http://www.ietf.org/mail-archive/web/oauth/current/msg09946.html

But my use case is different from Siriwardena's. 

what OAuth does: 
-I deposit my child(precious resource) at kindergarden(Resource Server)
-when someone tries to take him outside of the kindergarden, the teacher 
will
inform me(Resource Owner) "do you authorize this guy do it
-I authorize this person and it gose on.

my use case(RO-initiated delegation):
-I deposit my child(precious resource) at kindergarden(Resource Server)
-I delegate a few persons,e.g., grandparents of my child, to pick up my 
child at the kindergarden
-when someone tries to take him outside of the kindergarden,  the teacher 
will ask him/her to show my delegation
 statement, no statement, no taking my child. 

Thomas Hardjono's use case: 
- I deposit my Child at the Kindergarten.
- I delegate my old Grandmother to pick up the Child.
- My Grandmother takes a taxi.
- The taxi Driver acts as proxy to my old Grandmother who stays in the
taxi.
- The taxi Driver needs to show 2 forms of Delegation to the Teacher.
- The Taxi driver walks the Child to the taxi.

Nat Sakimura <[email-masked]> 
2012-12-03 11:12

收件人
[email-masked]
抄送
"[email-masked] WG" <[email-masked]>
主题
Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?

Nat

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 3 Dec 2012 15:44:22 +0900

Your usecase sounds a little bit like the assertion flow.
The RO issues an assertion and the rest goes.
Is there reasons that an assertion flow cannot do?

Nat

---

From: [email-masked]
Date: Mon, 3 Dec 2012 16:18:16 +0800

My use case is indeed similar to  assertion flow "section 6.3.  Client 
Acting on Behalf of a User".
Differences are:
1.  if my use case is carried out in assertion framework, "pricipal" 
should be client, while assertion document does not 
include client as an option when client is acting on behalf of a 
user(resource owner), it says  " an authorized accessor for which the 
access token is being requested (typically the resource owner, or  an 
authorized delegate)."
2.  if my use case is carried out in assertion framework, "issuer" should 
be resource owner, while assertion document only includes 
client and token service 

In my use case the "assertion" is more like a private output, while in 
assertion flow "assertion " is generated by a thrid party token service or 
by client itself.

2012-12-03 14:44

收件人
[email-masked]
抄送
"[email-masked] WG" <[email-masked]>
主题
Re: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?

Nat

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 Dec 2012 12:24:03 +0100

Hi Mark,

thanks for reviewing the draft. Comments inline.

> The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource o…

That's correct.

> This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking de…

You raised an interesting point. Is it desirable to share an access 
grant among different client instances? I would like to discuss this 
topic in the working group.

If we assume it is desirable, how would the authorization process look 
alike?

I would assume that as result of the authorization process of the 1st 
client instance, the authorization server stores an access grant, which 
is identified by the client_id and the user_id of the resource owner. 
Moreover, it creates a refresh token, which the 1st client instance uses 
to obtain new access tokens. As this client is public, the refresh token 
is the credential the intial client uses to prove its identity.

How does the 2nd client instance join the party? I would assume the 2nd 
client to initiate another code grant type flow (using the same 
client_id as the 1st client). I see two ways the authorization server 
could process this process:

1) After authenticating the resource owner, the authorization server 
finds the existing access grant for the client_id/user_id combination 
and automatically issues tokens w/o further user consent. Since the 
authorization server cannot authenticate the client_id, a malicious 
client could obtain and abuse the access grant of the legitimate client. 
That's why the security considerations of the core spec 
(http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:

The authorization server SHOULD NOT process repeated authorization
    requests automatically (without active resource owner interaction)
    without authenticating the client or relying on other measures to
    ensure the repeated request comes from the original client and not an
    impersonator.

Validating the redirect URI won't help that much, since this URI is 
typically device local (custom scheme or localhost).

2) The authorization server asks the resource owner for user consent and 
issues another pair of access/refresh token to the 2nd client. In this 
case, why would one bind this tokens to the already existing access 
grant? This would limit the resource owners capability to revoke grants 
for particular instances. I would rather create another access grant.

Based on this thoughts I think it is not desirable to share an access 
grant among different client instances.

What do others think?

> If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's autho…

I would like to adopt your proposal if the WG agrees.

> I spotted a typo in "3. Implementation Note":

Thanks. Fixed.

regards,
Torsten.

---

From: John Bradley <[email-masked]>
Date: Wed, 26 Dec 2012 11:38:37 -0300

We don't want to share grant information across multiple instances of public client.

However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.

From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.

There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.

The language around grants has always been a bit philosophical for my taste.   

If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.

John B.

On 2012-12-25, at 8:24 AM, Torsten Lodderstedt <[email-masked]> wrote:

> You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.
> 
> If we assume it is desirable, how would the authorization process look alike?
> 
> I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.
> 
> How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:
> 
> 1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
> 
> Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).
> 
> 2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.
> 
> Based on this thoughts I think it is not desirable to share an access grant among different client instances.
> 
> What do others think?
> 
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Dec 2012 17:14:33 +0100

Hi John,

thanks for your feedback.

After having thought through this topic again I came to the conclusion 
that I want to have a simple spec, which doesn't unnessarily restricts 
implementations. OAuth leaves so much freedom to implementors (for good 
reasons), which we should preserve.

What does this mean? I would like to focus on the revocation of the 
token actually passed to the revocation endpoint and leave the impact on 
other related tokens and the authorization itself to the authorization 
server's policy. The authorization server may incorporate the client 
type into its revocation policy.

My base assumption is that a client must be prepared to handle 
invalidation of tokens at any time. So from an interoperability 
perspective, it's not necessary to dictate a certain revocation policy 
to authorization servers.

Current text:

In the next step, the authorization server invalidates the token and the 
respective authorization. If the particular token is a refresh token and 
the authorization server supports the revocation of access tokens, then 
the authorization server SHOULD also invalidate all access tokens based 
on the same authorization (seeImplementation Note <#impl>).

The client MUST NOT use the token again after revocation.

Proposal:

         In the next step, the authorization server invalidates the 
token. The client MUST NOT use this token again after revocation.

         Depending on the authorization server's revocation policy, the 
revocation of a particular token may cause the revocation of related 
tokens and the underlying authorization.
         If the particular token is a refresh token and the 
authorization server supports the revocation of access tokens, then the 
authorization server SHOULD also invalidate all access tokens based on 
         the same authorization (seeImplementation Note <#impl>).

Thoughts?

regards,
Torsten.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 27 Dec 2012 09:41:24 +0000

Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
> In the next step, the authorization server invalidates the token. The
> client MUST NOT use this token again after revocation.
>
> If the particular token is a refresh token and the authorization server
> supports the revocation of access tokens, then the authorization server
> SHOULD also invalidate all access tokens based on the same authorization
> (seeImplementation Note <#impl>).
>

This implies that some ASs may, in theory at least, allow the client to 
revoke the token but keep that specific client's authorization...

Cheers, Sergey

>> On 2012-12-25, at 8:24 AM, Torsten Lodderstedt<[email-masked]>  wrote:
>>
>>> Hi Mark,
>>>
>>>> On 24 Nov 2012, at 18:13, Hannes Tschofenig<[email-masked]>  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Hannes&  Derek

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 27 Dec 2012 11:44:01 +0000

Hi again,
> revoke the token but keep that specific client's authorization...

Perhaps, having an optional token type parameter (as discussed in the 
different thread) will make the proposed update more interesting, for 
example, it can be the policy of a given AS to revoke a related access 
token if the client requests the revocation of the refresh token only, 
this can be documented and the client can thus avoid issuing a 2nd 
revocation request

Sorry if it all misses the point :-)

thanks, Sergey

>>> However we don't necessarily want to preclude multiple instances of a
>>> private client, Though how the AS would tell them apart is a
>>> interesting side question.
>>>
>>> From a revocation point of view if you revoke the grant for one
>>> instance of a client you revoke it for all, though for a public
>>> client the grant is not doing anything anyway as the AS shield not be
>>> pre approving based on the grant.
>>>
>>> There are still some open questions about an extension to identify
>>> client instances, though personally I prefer to have each instance
>>> with it's own client ID.
>>>
>>> If I recall correctly in the code flow the code is the representation
>>> of the grant. In the implicit flow the grant is implicit in the
>>> access token.
>>> What construct (if any in the implicit case) is stored in the AS to
>>> represent this is mostly left to the imagination of the implementer.
>>>
>>> John B.
>>>
>>>
>>> On 2012-12-25, at 8:24 AM, Torsten
>>> Lodderstedt<[email-masked]> wrote:
>>>
>>>> Hi Mark,
>>>>
>>>>> The draft relies heavily on the definition "access grant", but no
>>>>> definition is provided in the draft or RFC 6749. It's been my
>>>>> interpretation that an "access grant" is the *fact* that a resource
>>>>> owner has authorized a client (potentially scoped) access to the
>>>>> protected resources. Once access is granted in this manner, further
>>>>> access tokens may be obtained without explicit permission by the
>>>>> end-user. That is, in the Protocol Flow there is no user input
>>>>> between steps A and B.
>>>> That's correct.
>>>>
>>>>> This implies that an access grant only applies to an app authorized
>>>>> on a single device. If an app is installed on multiple devices and
>>>>> the access grant is shared between both instances, revoking device
>>>>> A's access token results in the unexpected revocation of device B's
>>>>> token.
>>>> I would assume that as result of the authorization process of the
>>>> 1st client instance, the authorization server stores an access
>>>> grant, which is identified by the client_id and the user_id of the
>>>> resource owner. Moreover, it creates a refresh token, which the 1st
>>>> client instance uses to obtain new access tokens. As this client is
>>>> public, the refresh token is the credential the intial client uses
>>>> to prove its identity.
>>>>
>>>> How does the 2nd client instance join the party? I would assume the
>>>> 2nd client to initiate another code grant type flow (using the same
>>>> client_id as the 1st client). I see two ways the authorization
>>>> server could process this process:
>>>>
>>>> finds the existing access grant for the client_id/user_id
>>>> combination and automatically issues tokens w/o further user
>>>> consent. Since the authorization server cannot authenticate the
>>>> client_id, a malicious client could obtain and abuse the access
>>>> grant of the legitimate client. That's why the security
>>>> considerations of the core spec
>>>> 2) The authorization server asks the resource owner for user consent
>>>> and issues another pair of access/refresh token to the 2nd client.
>>>> In this case, why would one bind this tokens to the already existing
>>>> access grant? This would limit the resource owners capability to
>>>> revoke grants for particular instances. I would rather create
>>>> another access grant.
>>>>
>>>> Based on this thoughts I think it is not desirable to share an
>>>> access grant among different client instances.
>>>>
>>>> What do others think?
>>>>
>>>>> If "access grant" could be defined as "an authorization issued to
>>>>> the client, based on the single use of an Authorization Grant" it
>>>>> becomes clear than only the tokens spawning from the app's
>>>>> authorization on device A should be revoked.
>>>>> On 24 Nov 2012, at 18:13, Hannes
>>>>> Tschofenig<[email-masked]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> this is a working group last call for
>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft is
>>>>>> available here:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 27 Dec 2012 19:02:58 +0100

> This implies that some ASs may, in theory at least, allow the client 
> to revoke the token but keep that specific client's authorization...

yep, it does. If this makes sense from the ASs perspective.

regards,
Torsten.

>>> However we don't necessarily want to preclude multiple instances of 
>>> a private client,  Though how the AS would tell them apart is a 
>>> client the grant is not doing anything anyway as the AS shield not 
>>> be pre approving based on the grant.
>>>
>>> If I recall correctly in the code flow the code is the 
>>> representation of the grant.  In  the implicit flow the grant is 
>>> implicit in the access token.
>>>>> interpretation that an "access grant" is the *fact* that a 
>>>>> resource owner has authorized a client (potentially scoped) access 
>>>>> to the protected resources. Once access is granted in this manner, 
>>>>> further access tokens may be obtained without explicit permission 
>>>>> by the end-user. That is, in the Protocol Flow there is no user 
>>>>> input between steps A and B.
>>>> That's correct.
>>>>
>>>>>> token and
>>>>> This implies that an access grant only applies to an app 
>>>>> authorized on a single device. If an app is installed on multiple 
>>>>> devices and the access grant is shared between both instances, 
>>>>> revoking device A's access token results in the unexpected 
>>>>> revocation of device B's token.
>>>> grant among different client instances? I would like to discuss 
>>>> this topic in the working group.
>>>>
>>>> 1) After authenticating the resource owner, the authorization 
>>>> server finds the existing access grant for the client_id/user_id 
>>>> 2) The authorization server asks the resource owner for user 
>>>> consent and issues another pair of access/refresh token to the 2nd 
>>>> client. In this case, why would one bind this tokens to the already 
>>>> existing access grant? This would limit the resource owners 
>>>> capability to revoke grants for particular instances. I would 
>>>> rather create another access grant.
>>>>
>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft 
>>>>>> is available here:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 27 Dec 2012 19:13:39 +0100

Am 27.12.2012 12:44, schrieb Sergey Beryozkin:
>>> the

How do you imagine the token type parameter to determine the 
authorization servers revocation policy?

regards,
Torsten,

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 Dec 2012 10:15:41 -0500

I'm fine with this approach, though I'd leave in a RECOMMEND for the 
refresh token -> access token cascading delete, since it will be a 
common one.

  -- Justin

On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:
> implementations. OAuth leaves so much freedom to implementors (for 
> good reasons), which we should preserve.
>
> token actually passed to the revocation endpoint and leave the impact 
> on other related tokens and the authorization itself to the 
> authorization server's policy. The authorization server may 
> incorporate the client type into its revocation policy.
>
> the respective authorization. If the particular token is a refresh 
> access tokens based on the same authorization (seeImplementation Note 
> <#impl>).
>
> authorization server supports the revocation of access tokens, then 
> the authorization server SHOULD also invalidate all access tokens 
> based on         the same authorization (seeImplementation Note <#impl>).
>
> Thoughts?
>
> regards,
> Torsten.
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 28 Dec 2012 15:45:26 +0000

Hi Torsten
> yep, it does. If this makes sense from the ASs perspective.
is it something OAuth2 allows ?

For example, what if the end user (as opposed to the client owning the 
token) goes and revokes a token for a given client via some UI console 
interacting with AS, I guess the end user expectations here is that the 
affected client won't be able to access this user's resources unless 
re-authorized again.

Why would it be different for a client revoking its access token ?

thanks, Sergey

---

From: Mark Wubben <[email-masked]>
Date: Sun, 30 Dec 2012 13:53:54 +0100

On 25 Dec 2012, at 12:24, Torsten Lodderstedt <[email-masked]> wrote:
> 1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client.

…

> Based on this thoughts I think it is not desirable to share an access grant among different client instances.

My specific use case is an official mobile app that takes user credentials and exchanges them directly for an access token. There is no explicit user consent. The AS could reuse the existing access grant, or create a new one.They would have the same scope regardless. Other than increased storage requirements on the server there is no difference.

Creating different access grants for every authorization would allow the grant for device A to be revoked while device B keeps working. The user could also remove the app from device A and then re-install it, which leaves the old access grant intact and not revoked. That may be solved by tying authorizations to specific devices, which OAuth currently does not cover. I'm also not sure whether that'd be feasible technically.

--
Mark Wubben

http://novemberborn.net

---

From: Mark Wubben <[email-masked]>
Date: Sun, 30 Dec 2012 13:53:55 +0100

On 26 Dec 2012, at 17:14, Torsten Lodderstedt <[email-masked]> wrote:
> What does this mean? I would like to focus on the revocation of the token actually passed to the revocation endpoint and leave the impact on other related tokens and the authorization itself to the authorization server's policy. The authorization server may incorporate the client type into its revocation policy.  
> 
> My base assumption is that a client must be prepared to handle invalidation of tokens at any time. So from an interoperability perspective, it's not necessary to dictate a certain revocation policy to authorization servers.  
> 
> Current text:
> 
> In the next step, the authorization server invalidates the token and the respective authorization. If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on the same authorization (see Implementation Note).
> 
>         In the next step, the authorization server invalidates the token. The client MUST NOT use this token again after revocation. 
>  
>         Depending on the authorization server's revocation policy, the revocation of a particular token may cause the revocation of related tokens and the underlying authorization. 
>         If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on         the same authorization (see Implementation Note).
> 
> Thoughts?

That works for my use case I think, assuming "authorization" doesn't specifically mean "access grant" but whatever the AS takes it to mean.

--
Mark Wubben

http://novemberborn.net

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 30 Dec 2012 14:49:06 +0100

Am 30.12.2012 um 13:53 schrieb Mark Wubben <[email-masked]>:

> Creating different access grants for every authorization would allow the grant for device A to be revoked while device B keeps working. The user could also remove the app from device A and then re-install it, which leaves the old access grant intact and not revoked.

> That may be solved by tying authorizations to specific devices, which OAuth currently does not cover. I'm also not sure whether that'd be feasible technically.

I would assume that the app revokes its refresh token during uninstall, which should cause the revocation of the authorization as well. Or it's automatically invalidated after some inactivity period.

regards,
Torsten.