Subject: [OAUTH-WG] A question on token revocation.

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 15:05:42 +0530

I am sorry if this was already discussed in this list..

Looking at [1] it only talks about revoking the access token from the
client.

How about the resource owner..?

There can be cases where resource owner needs to revoke an authorized
access token from a given client. Or revoke an scope..

How are we going to address these requirements..? Thoughts appreciated...

[1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 6 Feb 2013 09:21:53 -0500

> There can be cases where resource owner needs to revoke an authorized 
access token from a given client. 

Why wouldn't the RO go through the client to revoke the token?

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Prabath Siriwardena <[email-masked]>
To:     "[email-masked] WG" <[email-masked]>, 
Date:   02/06/2013 04:36 AM
Subject:        [OAUTH-WG] A question on token revocation.
Sent by:        [email-masked]

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Feb 2013 09:49:09 -0500

These are generally handled through a user interface where the RO is 
authenticated directly to the AS, and there's not much need for a 
"protocol" here, in practice. There are larger applications, like UMA, 
that have client and PR provisioning that would allow for this to be 
managed somewhat programmatically, but even in that case you're still 
generally doing token revocation by a "client" in some fashion. In UMA, 
though, several different pieces can play the role of a "client" at 
different parts of the process.

Revoking a scope is a whole different mess. Generally, you'd want to 
just revoke an existing token and make a new authorization grant with 
lower access if you don't want that client getting that scope anymore. 
If you just want to downscope for a single transaction, you can already 
do that with either the refresh token or token chaining approaches, 
depending on where in the process you are. The latter of these are both 
client-focused, though, and the RO doesn't have a direct hand in it at 
this point.

  -- Justin

On 02/06/2013 04:35 AM, Prabath Siriwardena wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 20:34:52 +0530

> Why wouldn't the RO go through the client to revoke the token?

RO needs not to go through the client to revoke. Resource owner should have
the capability to revoke an acces token by client.

Thanks & regards,
-Prabath

>
>  *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email-masked]*
>
>
>
>
> ------------------------------
>
>
>
> [1] *http://tools.ietf.org/html/draft-ietf-oauth-revocation-04*<http://tools.ietf.org/html/draft-ietf-oauth-revocation-04>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *
> **http://blog.facilelogin.com* <http://blog.facilelogin.com/>*
> *
> *http://RampartFAQ.com* <http://rampartfaq.com/>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 20:43:49 +0530

On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <[email-masked]> wrote:

> "protocol" here, in practice.
>

Why do you think leaving access token revocation by RO to a proprietary API
is a good practice ? IMO this an essential requirement in API security.

IMHO token revocation done my RO is more practical than token revocation
done by the Client.

> There are larger applications, like UMA, that have client and PR
> provisioning that would allow for this to be managed somewhat
> programmatically, but even in that case you're still generally doing token
> revocation by a "client" in some fashion. In UMA, though, several different
> pieces can play the role of a "client" at different parts of the process.
>
> Revoking a scope is a whole different mess. Generally, you'd want to just
> revoke an existing token and make a new authorization grant with lower
> access if you don't want that client getting that scope anymore. If you
> just want to downscope for a single transaction, you can already do that
> with either the refresh token or token chaining approaches, depending on
> where in the process you are. The latter of these are both client-focused,
> though, and the RO doesn't have a direct hand in it at this point.
>

Why do you think it a mess. If you revoke the entire token then Client
needs to go through the complete OAuth flow - and also needs to get the
user consent. If RO can  downgrade the scope, then we restrict API access
by the client at RS end and its transparent to the client.

Thanks & regards,
-Prabath

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

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: William Mills <[email-masked]>
Date: Wed, 6 Feb 2013 07:19:30 -0800 (PST)

+1

________________________________
 From: Prabath Siriwardena <[email-masked]>
To: Todd W Lainhart <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]>; [email-masked] 
Sent: Wednesday, February 6, 2013 7:04 AM
Subject: Re: [OAUTH-WG] A question on token revocation.

On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart <[email-masked]> wrote:

> There can be cases
where resource owner needs to revoke an authorized access token from a
given client.  
>Why wouldn't the RO go through the client
to revoke the token?

RO needs not to go through the client to revoke. Resource owner should have the capability to revoke an acces token by client.

Thanks & regards,
-Prabath

>From:      
 Prabath Siriwardena
<[email-masked]> 
>Date:      
 02/06/2013 04:36 AM 
>Subject:    
   [OAUTH-WG] A
question on token revocation. 
>Sent by:    
   [email-masked] 
>>________________________________
>
>
>
>
>Looking at [1] it only talks about revoking the access
token from the client. 
>There can be cases where resource owner needs to revoke
an authorized access token from a given client. Or revoke an scope.. 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Feb 2013 10:19:07 -0500

On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     These are generally handled through a user interface where the RO
>     is authenticated directly to the AS, and there's not much need for
>     a "protocol" here, in practice.
>
>
> Why do you think leaving access token revocation by RO to a 
> proprietary API is a good practice ? IMO this an essential requirement 
> in API security.
I think it makes more sense in the same way that having a "proprietary" 
UI/API for managing the user consent makes sense: unless you're doing a 
fully dynamic end-to-end system like UMA, then there's not much value in 
trying to squeeze disparate systems into the same mold, since they won't 
be talking to each other anyway.

And since you refer to it as an "API", what will the RO be using to call 
this API? Is there a token management client that's separate from the 
OAuth client?

>
> IMHO token revocation done my RO is more practical than token 
> revocation done by the Client.
They're both valid but require different kinds of protocols and 
considerations. This token revocation draft is meant to solve one 
problem, and that doesn't mean it can or should solve other seemingly 
related problems.

If you would like to see the RO-initiated token revocation go through 
(not grant revocation, mind you -- that's related, but different), then 
I would suggest that you start specifying exactly how that works. I 
predict it will be problematic in practice, though, as the RO often 
doesn't actually have direct access to the token itself.

>     programmatically, but even in that case you're still generally
>     doing token revocation by a "client" in some fashion. In UMA,
>     though, several different pieces can play the role of a "client"
>     at different parts of the process.
>
>     Revoking a scope is a whole different mess. Generally, you'd want
>     to just revoke an existing token and make a new authorization
>     grant with lower access if you don't want that client getting that
>     scope anymore. If you just want to downscope for a single
>     transaction, you can already do that with either the refresh token
>     or token chaining approaches, depending on where in the process
>     you are. The latter of these are both client-focused, though, and
>     the RO doesn't have a direct hand in it at this point.
>
>
> needs to go through the complete OAuth flow - and also needs to get 
> the user consent. If RO can  downgrade the scope, then we restrict API 
> access by the client at RS end and its transparent to the client.
>

Downgrading the scope of tokens in the wild is hardly transparent to the 
client (stuff that it expects to work will suddenly start to fail, 
meaning that most clients will throw out the token and try to get a new 
one), and in a distributed system you've got to propagate that change to 
the RS. If you bake the scopes into the token itself (which many do) 
then you actually *can't* downgrade a single token, anyway.

  -- Justin

>>     Looking at [1] it only talks about revoking the access token from
>>     the client.
>>
>>     There can be cases where resource owner needs to revoke an
>>     authorized access token from a given client. Or revoke an scope..
>>
>>     Mobile : +94 71 809 6732 <tel:%2B94%2071%20809%206732>
>>
>>     [email-masked]  <mailto:[email-masked]>

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 6 Feb 2013 10:30:42 -0500

> If you would like to see the RO-initiated token revocation go through 
(not grant revocation, mind you -- that's related, but different), then I 
would suggest that you start specifying exactly how that works.

+1

Todd Lainhart
Rational software
IBM Corporation

From:   Justin Richer <[email-masked]>
To:     Prabath Siriwardena <[email-masked]>, 
Cc:     "[email-masked] WG" <[email-masked]>
Date:   02/06/2013 10:21 AM
Subject:        Re: [OAUTH-WG] A question on token revocation.
Sent by:        [email-masked]

Why do you think leaving access token revocation by RO to a proprietary 
API is a good practice ? IMO this an essential requirement in API 
security.
I think it makes more sense in the same way that having a "proprietary" 
UI/API for managing the user consent makes sense: unless you're doing a 
fully dynamic end-to-end system like UMA, then there's not much value in 
trying to squeeze disparate systems into the same mold, since they won't 
be talking to each other anyway. 

IMHO token revocation done my RO is more practical than token revocation 
done by the Client.
They're both valid but require different kinds of protocols and 
considerations. This token revocation draft is meant to solve one problem, 
and that doesn't mean it can or should solve other seemingly related 
problems.

If you would like to see the RO-initiated token revocation go through (not 
grant revocation, mind you -- that's related, but different), then I would 
suggest that you start specifying exactly how that works. I predict it 
will be problematic in practice, though, as the RO often doesn't actually 
have direct access to the token itself. 

There are larger applications, like UMA, that have client and PR 
provisioning that would allow for this to be managed somewhat 
programmatically, but even in that case you're still generally doing token 
revocation by a "client" in some fashion. In UMA, though, several 
different pieces can play the role of a "client" at different parts of the 
process.

Downgrading the scope of tokens in the wild is hardly transparent to the 
client (stuff that it expects to work will suddenly start to fail, meaning 
that most clients will throw out the token and try to get a new one), and 
in a distributed system you've got to propagate that change to the RS. If 
you bake the scopes into the token itself (which many do) then you 
actually *can't* downgrade a single token, anyway. 

 -- Justin

Thanks & regards,
-Prabath

 -- Justin 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 21:01:31 +0530

On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <[email-masked]> wrote:

> API is a good practice ? IMO this an essential requirement in API security.
>
> trying to squeeze disparate systems into the same mold, since they won't be
> talking to each other anyway.
>

This is required in distributed setup for each API platform from different
vendors to perform in an interop manner.

> this API? Is there a token management client that's separate from the OAuth
> client?
>

I didn't get your question right... If you meant the how to invoke
revocation end point, the the resource owner needs to know the consumer key
(represents the OAuth Client app) & scope to revoke the access token for a
given client.

> suggest that you start specifying exactly how that works. I predict it will
> be problematic in practice, though, as the RO often doesn't actually have
> direct access to the token itself.
>

Resource owner needs to know the consumer key (represents the OAuth Client
app) & scope to revoke the access token for a given client.

> you bake the scopes into the token itself (which many do) then you actually
> *can't* downgrade a single token, anyway.
>

Yes.. that is the expected behavior. I mean the process is transparent.
Client will notice at runtime.

Thanks & regards,
-Prabath

>>  Mobile : +94 71 809 6732 <%2B94%2071%20809%206732>
>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 6 Feb 2013 10:34:09 -0500

> Resource owner needs to know the consumer key (represents the OAuth 
Client app) & scope to revoke the access token for a given client. 

I see - you're saying that requiring client credentials on the end point 
is the problem?

Todd Lainhart
Rational software
IBM Corporation

From:   Prabath Siriwardena <[email-masked]>
To:     Justin Richer <[email-masked]>, 
Cc:     "[email-masked] WG" <[email-masked]>
Date:   02/06/2013 10:31 AM
Subject:        Re: [OAUTH-WG] A question on token revocation.
Sent by:        [email-masked]

I didn't get your question right... If you meant the how to invoke 
revocation end point, the the resource owner needs to know the consumer 
key (represents the OAuth Client app) & scope to revoke the access token 
for a given client. 

 

Thanks & regards,
-Prabath

 -- Justin

Thanks & regards,
-Prabath

 -- Justin 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath 

Mobile : +94 71 809 6732 

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 21:04:30 +0530

Sure that can done.. Do you see any issues having discuss that under the
same spec.. The purpose of both are the same. Only the actor differs.

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 9:00 PM, Todd W Lainhart <[email-masked]> wrote:

> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer <[email-masked]*<[email-masked]>>
> wrote:
> Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732>
> *
> **http://RampartFAQ.com* <http://rampartfaq.com/>
>
>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
> *
> **http://RampartFAQ.com* <http://rampartfaq.com/>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 21:07:08 +0530

> I see - you're saying that requiring client credentials on the end point

In fact what I meant was - when RO authorizes the an access token for
client for particular scope. Those information are kept at the AS.

Now - if the RO want to revoke access from the client - the RO needs to
authenticate him self to the AS and pass the consumer key and the scope. So
AS can revoke access.

Thanks & regards,
-Prabath

> On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer <[email-masked]*<[email-masked]>>
> wrote:
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 6 Feb 2013 19:25:54 +0100

Hi Prabath,

we tried to address both use cases in the first revisions of the draft. The API was well suited for client-driven revocation but not the resource owner - driven use case. There are definitely differences with respect to the protocol design, at least regarding authentication and authorization of the respective actors. This made the spec more complex and caused ambiguities and confusion. Moreover, the working group seemed not convinced by the the latter use case.

Therefore the working group decided to focus on the single use cases of the revocation by clients. This makes a lot of sense since this interface is most important with respect to interoperability.

I'm focusing right now on finishing this draft. And the open issues discussed on the list in the last couple of weeks illustrate that even this poses a considerable amount of work. So I'm very reluctant to add support for a whole new use case at that point of the process.

If you feel this is an important use case worth an RFC, don't hesitate to publish a new I-D.

regards,
Torsten.

Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena <[email-masked]>:

>> > Resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client.  
>> 
>> I see - you're saying that requiring client credentials on the end point is the problem?
> 
> In fact what I meant was - when RO authorizes the an access token for client for particular scope. Those information are kept at the AS.
> 
> Now - if the RO want to revoke access from the client - the RO needs to authenticate him self to the AS and pass the consumer key and the scope. So AS can revoke access.
> 
> Thanks & regards,
> -Prabath
>  
>> 
>> 
>> 
>> 
>> Todd Lainhart
>> Rational software
>> IBM Corporation
>> These are generally handled through a user interface where the RO is authenticated directly to the AS, and there's not much need for a "protocol" here, in practice. 
>> 
>> Why do you think leaving access token revocation by RO to a proprietary API is a good practice ? IMO this an essential requirement in API security. 
>> I think it makes more sense in the same way that having a "proprietary" UI/API for managing the user consent makes sense: unless you're doing a fully dynamic end-to-end system like UMA, then there's not much value in trying to squeeze disparate systems into the same mold, since they won't be talking to each other anyway. 
>> 
>> This is required in distributed setup for each API platform from different vendors to perform in an interop manner. 
>>   
>> 
>> And since you refer to it as an "API", what will the RO be using to call this API? Is there a token management client that's separate from the OAuth client? 
>> 
>> I didn't get your question right... If you meant the how to invoke revocation end point, the the resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client.  
>> 
>> 
>> 
>> IMHO token revocation done my RO is more practical than token revocation done by the Client. 
>> They're both valid but require different kinds of protocols and considerations. This token revocation draft is meant to solve one problem, and that doesn't mean it can or should solve other seemingly related problems.
>> 
>> If you would like to see the RO-initiated token revocation go through (not grant revocation, mind you -- that's related, but different), then I would suggest that you start specifying exactly how that works. I predict it will be problematic in practice, though, as the RO often doesn't actually have direct access to the token itself. 
>> 
>> Resource owner needs to know the consumer key (represents the OAuth Client app) & scope to revoke the access token for a given client.  
>> 
>>   
>> 
>>   
>> There are larger applications, like UMA, that have client and PR provisioning that would allow for this to be managed somewhat programmatically, but even in that case you're still generally doing token revocation by a "client" in some fashion. In UMA, though, several different pieces can play the role of a "client" at different parts of the process.
>> 
>> Revoking a scope is a whole different mess. Generally, you'd want to just revoke an existing token and make a new authorization grant with lower access if you don't want that client getting that scope anymore. If you just want to downscope for a single transaction, you can already do that with either the refresh token or token chaining approaches, depending on where in the process you are. The latter of these are both client-focused, though, and the RO doesn't have a direct hand in it at this point. 
>> 
>> Why do you think it a mess. If you revoke the entire token then Client needs to go through the complete OAuth flow - and also needs to get the user consent. If RO can  downgrade the scope, then we restrict API access by the client at RS end and its transparent to the client. 
>> 
>> 
>> Downgrading the scope of tokens in the wild is hardly transparent to the client (stuff that it expects to work will suddenly start to fail, meaning that most clients will throw out the token and try to get a new one), and in a distributed system you've got to propagate that change to the RS. If you bake the scopes into the token itself (which many do) then you actually *can't* downgrade a single token, anyway. 
>> 
>> Yes.. that is the expected behavior. I mean the process is transparent. Client will notice at runtime. 
>> 
>> Thanks & regards, 
>> -Prabath 
>>   
>> 
>>  -- Justin 
>> 
>> 
>> Thanks & regards, 
>> -Prabath 
>>   
>> 
>> 
>>  -- Justin 
>> 
>> 
>> Looking at [1] it only talks about revoking the access token from the client. 
>> 
>> There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. 
>>

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 7 Feb 2013 00:02:28 +0530

Hi Torsten,

Thanks for your feedback.. I will submit a draft...

Thanks & regards,
-Prabath

On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi Prabath,
>
> we tried to address both use cases in the first revisions of the draft.
> The API was well suited for client-driven revocation but not the resource
> owner - driven use case. There are definitely differences with respect to
> the protocol design, at least regarding authentication and authorization
> of the respective actors. This made the spec more complex and caused
> ambiguities and confusion. Moreover, the working group seemed not convinced
> by the the latter use case.
>
> Therefore the working group decided to focus on the single use cases of
> the revocation by clients. This makes a lot of sense since this interface
> is most important with respect to interoperability.
>
> I'm focusing right now on finishing this draft. And the open issues
> discussed on the list in the last couple of weeks illustrate that even this
> poses a considerable amount of work. So I'm very reluctant to add support
> for a whole new use case at that point of the process.
>
> On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart <[email-masked]>wrote:
>
>> This is required in distributed setup for each API platform from
>> different vendors to perform in an interop manner.
>>
>>
>> would suggest that you start specifying exactly how that works. I predict
>> it will be problematic in practice, though, as the RO often doesn't
>> actually have direct access to the token itself.
>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Thu, 7 Feb 2013 15:19:48 +0800

I guess RO could initiate access token revocation for a client by 
including authorization code in the request to AS.
Comments? 

> On Wed, Feb 6, 2013 at 11:55 PM, Torsten Lodderstedt 
<[email-masked]
> > wrote:
> Hi Prabath,
> 
> we tried to address both use cases in the first revisions of the 
> draft. The API was well suited for client-driven revocation but not 
> the resource owner - driven use case. There are definitely 
> differences with respect to the protocol design, at least regarding 
> authentication and authorization of the respective actors. This made
> the spec more complex and caused ambiguities and confusion. 
> Moreover, the working group seemed not convinced by the the latter use 
case.
> 
> Therefore the working group decided to focus on the single use cases
> of the revocation by clients. This makes a lot of sense since this 
> interface is most important with respect to interoperability.
> 
> discussed on the list in the last couple of weeks illustrate that 
> even this poses a considerable amount of work. So I'm very reluctant
> to add support for a whole new use case at that point of the process.
> 

> > Resource owner needs to know the consumer key (represents the 
> OAuth Client app) & scope to revoke the access token for a given 
client.  

> In fact what I meant was - when RO authorizes the an access token 
> for client for particular scope. Those information are kept at the AS.
> 
> Now - if the RO want to revoke access from the client - the RO needs
> to authenticate him self to the AS and pass the consumer key and the
> scope. So AS can revoke access.
> 
> Thanks & regards,
> -Prabath
>  
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation

> proprietary API is a good practice ? IMO this an essential 
> requirement in API security. 
> I think it makes more sense in the same way that having a 
> "proprietary" UI/API for managing the user consent makes sense: 
> unless you're doing a fully dynamic end-to-end system like UMA, then
> there's not much value in trying to squeeze disparate systems into 
> the same mold, since they won't be talking to each other anyway. 
> 
> And since you refer to it as an "API", what will the RO be using to 
> call this API? Is there a token management client that's separate 
> from the OAuth client? 
> 
> revocation end point, the the resource owner needs to know the 
> consumer key (represents the OAuth Client app) & scope to revoke the
> access token for a given client.  
> 
> 
> 
> problem, and that doesn't mean it can or should solve other 
> seemingly related problems.
> 
> If you would like to see the RO-initiated token revocation go 
> through (not grant revocation, mind you -- that's related, but 
> different), then I would suggest that you start specifying exactly 
> how that works. I predict it will be problematic in practice, 
> though, as the RO often doesn't actually have direct access to the 
> token itself. 
> 
> programmatically, but even in that case you're still generally doing
> token revocation by a "client" in some fashion. In UMA, though, 
> several different pieces can play the role of a "client" at 
> just revoke an existing token and make a new authorization grant 
> with lower access if you don't want that client getting that scope 
> anymore. If you just want to downscope for a single transaction, you
> can already do that with either the refresh token or token chaining 
> approaches, depending on where in the process you are. The latter of
> these are both client-focused, though, and the RO doesn't have a 
> direct hand in it at this point. 
> 
> Why do you think it a mess. If you revoke the entire token then 
> Client needs to go through the complete OAuth flow - and also needs 
> to get the user consent. If RO can  downgrade the scope, then we 
> restrict API access by the client at RS end and its transparent to 
> the client. 
> 
> 
> Downgrading the scope of tokens in the wild is hardly transparent to
> the client (stuff that it expects to work will suddenly start to 
> fail, meaning that most clients will throw out the token and try to 
> get a new one), and in a distributed system you've got to propagate 
> that change to the RS. If you bake the scopes into the token itself 
> (which many do) then you actually *can't* downgrade a single token, 
anyway. 
> 
> Yes.. that is the expected behavior. I mean the process is 
> transparent. Client will notice at runtime. 
> 
> Thanks & regards, 
> -Prabath 
>   
> 
>  -- Justin 
> 
> 
> Thanks & regards, 
> -Prabath 
>   
> 
> 
>  -- Justin 
> 
> 
client.

---

From: Prabath Siriwardena <[email-masked]>
Date: Thu, 7 Feb 2013 12:55:02 +0530

> including authorization code in the request to AS.

That creates a dependency on the grant type.

Thanks & regards,
-Prabath

> [email-masked]

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Thu, 7 Feb 2013 16:46:26 +0800

During the four grant types of Oauth,
  1. authorization code: RO knows the authorization code upon which 
access-tokens-to-be-revoked are issued 
  2. implicite flow: RO knows the access-tokens-to-be-revoked
  3. password and client credential types: RO has no way of knowing access 
tokens. 

So,IMO,  it is not proper for RO to revoke an each access token 
individually,
rather it could revoke some access tokens by specifying conditions, such 
as client_id, time_period, scope 
Comments? 

Prabath Siriwardena <[email-masked]> 写于 2013-02-07 15:25:02:

> > Moreover, the working group seemed not convinced by the the latteruse 
case.
client. 

anyway.

---

From: Justin Richer <[email-masked]>
Date: Thu, 7 Feb 2013 11:06:07 -0500

This, I think, points out that the RO is generally more concerned with 
revoking an authorization grant than a token itself, with the latter 
potentially encompassing several tokens. The revocation draft isn't 
really intended to solve that problem, as Torsten points out below.

  -- Justin

On 02/07/2013 03:46 AM, [email-masked] wrote:
>   3. password and client credential types: RO has no way of knowing 
> access tokens.
>
> rather it could revoke some access tokens by specifying conditions, 
> such as client_id, time_period, scope
> Comments?
>
> Prabath Siriwardena <[email-masked]> ?? 2013-02-07 15:25:02:
>
> >
>
> > [email-masked] ?? 2013-02-07 02:32:28:
> >
> > > Hi Torsten,
> > >
> > > Moreover, the working group seemed not convinced by the the 
> latteruse case.
> > >
> > > (which many do) then you actually *can't* downgrade a single 
> token, anyway.
> > >

---

From: [email-masked]
Date: Fri, 8 Feb 2013 08:04:51 +0800

But what is the motivation for a malicous client to request to revoke 
remaining access tokens?

Justin Richer <[email-masked]> 写于 2013-02-08 00:06:07:

> This, I think, points out that the RO is generally more concerned 
> with revoking an authorization grant than a token itself, with the 
> latter potentially encompassing several tokens. The revocation draft
> isn't really intended to solve that problem, as Torsten points out 
below.

individually,
> > > On Wed, Feb 6, 2013 at 9:04 PM, Todd W Lainhart 
<[email-masked]>
> > > OAuth Client app) & scope to revoke the access token for a 
givenclient.