Hi Hannes,
in my opinion, the introduction clearly states the use cases of this
spec (see below). Having said that, I'm open to any suggestions
regarding a better or enhanced explaination.
regards,
Torsten.
This specification ... facilitates the following use cases:
o The end-user triggers revocation from within the client that sends
the appropriate revocation request to the autorization server.
From the end-user's perspective, this looks like a "logout" or
"reset" function. The request causes the removal of the client
permissions associated with the particular token to access the
end-user's protected resources. This use case makes it even more
comfortable to the end-user to revoke his access grant immediately
via the client.
o In contrast to revocation by a client, the authorization server
(or a related entity) may offer its end-users a self-care portal
to delete access grants given to clients independent of any token
storing devices. Such a portal offers the possibility to an end-
user to look at and revoke all access grants he once authorized.
In cases the token storing device is not available, e.g. it is
lost or stolen, revocation by a self-care portal is the only
possibility to limit or avoid abuse.
Am 17.09.2012 13:37, schrieb Hannes Tschofenig:
My take-away from this discussion is that we should add a few more
words to the introduction of the draft to explain the motivation. It
may also make sense to state what the document doesn't provide (just
like Justin did in this mail exchange).
Currently, neither the abstract nor the introduction provide the
necessary context.
Torsten, could you enhance the document and maybe Justin you could
review the text for correctness.
Ciao
Hannes
On 09/11/2012 09:41 PM, William Mills wrote:
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]
<mailto:[email protected]>>
> To: William Mills <[email protected]
<mailto:[email protected]>>
> Cc: Hannes Tschofenig <[email protected]
<mailto:[email protected]>>; Torsten Lodderstedt
<[email protected] <mailto:[email protected]>>; Justin
Richer <[email protected] <mailto:[email protected]>>; "[email protected]
<mailto:[email protected]> WG" <[email protected] <mailto:[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]
<mailto:[email protected]>>
>> To: Justin Richer <[email protected] <mailto:[email protected]>>
>> Cc: "[email protected] <mailto:[email protected]> WG" <[email protected]
<mailto:[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] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
