OK, I see the use case, although I don't find it particularly compelling.
________________________________
From: Justin Richer <[email protected]>
To: William Mills <[email protected]>
Cc: Hannes Tschofenig <[email protected]>; Torsten Lodderstedt
<[email protected]>; "[email protected] WG" <[email protected]>
Sent: Tuesday, September 11, 2012 8:58 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
The use case for a client revoking a token is one of a well-behaved and
well-intentioned client being "logged out", uninstalled, or otherwise
decommissioned. In these cases, you want to have a mechanism for a
client saying to the AS, "Hey, I don't need this token anymore, get rid
of it. Incidentally, if anyone else tries using it, then it's not me."
As you point out, it doesn't help the case of a client being compromised
-- since why would a compromised client revoke its own tokens?
-- Justin
On 09/11/2012 11:21 AM, William Mills wrote:
> I think a resource server might validly revoke a token, but that a client
> will not.
>
> -bill
>
>
> ----- Original Message -----
> From: Hannes Tschofenig <[email protected]>
> To: William Mills <[email protected]>
> Cc: Hannes Tschofenig <[email protected]>; Torsten Lodderstedt
> <[email protected]>; Justin Richer <[email protected]>; "[email protected]
> WG" <[email protected]>
> Sent: Tuesday, September 11, 2012 1:49 AM
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
>
> Hi Bill,
>
> if I read your post correctly then you are saying that you do not like what
> is in <draft-ietf-oauth-revocation-00>
>
> Did I understood you correctly?
>
> Ciao
> Hannes
>
> On Sep 11, 2012, at 7:45 AM, William Mills wrote:
>
>> Well, the only way the client would request revocation is if the client
>> thinks the token is compromised, e.g. that the client has done dumb stuff.
>> In that sense I think the client requesting revocation makes no sense.
>>
>> I am also not in favor of token introspection endpoints at all, the client
>> should already have all of the information it needs about the token.
>>
>> From: Torsten Lodderstedt <[email protected]>
>> To: Justin Richer <[email protected]>
>> Cc: "[email protected] WG" <[email protected]>
>> Sent: Monday, September 10, 2012 12:55 PM
>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
>>
>> +1
>>
>> Am 10.09.2012 15:49, schrieb Justin Richer:
>>> That requires the client and/or resource server to run an endpoint of their
>>> own at all times, and it requires the AS to keep track of all instances of
>>> a client and RS. This isn't likely to be particularly desirable, scalable,
>>> or usable. I don't see too much harm in trying to define it, but I don't
>>> think it will see much adoption.
>>>
>>> Besides, the client can find out the token is revoked by just presenting it
>>> to the RS and getting back a 40x code. Clients don't really need anything
>>> faster than that for security reasons, and any shortcuts would be for
>>> performance. The connection between the RS and AS isn't defined -- but I
>>> think this is another instance where the generic token introspection
>>> endpoint makes more sense. If the RS wants to check, the AS can just tell
>>> it (via introspection) that the token was revoked so don't honor it.
>>>
>>> -- Justin
>>>
>>> On 09/10/2012 08:25 AM, Hannes Tschofenig wrote:
>>>> The current draft defines an additional endpoint, the token revocation
>>>> endpoint, so that clients can request the revocation of a particular token.
>>>>
>>>> Wouldn't it make sense to also allow Authorization Servers to tell Clients
>>>> or Resource Servers to revoke tokens?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
