Subject: [OAUTH-WG] draft-ietf-oauth-revocation-00

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2012 15:25:30 +0300

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 10 Sep 2012 09:49:26 -0400

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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 Sep 2012 21:55:08 +0200

+1

Am 10.09.2012 15:49, schrieb Justin Richer:
> 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
>
>> 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
>>

---

From: William Mills <[email-masked]>
Date: Mon, 10 Sep 2012 21:45:39 -0700 (PDT)

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-masked]>
To: Justin Richer <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]> 
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
>

---

From: William Mills <[email-masked]>
Date: Mon, 10 Sep 2012 21:50:20 -0700 (PDT)

Revocation endpoint discovery can be handled through standard discovery mechanisms.  I don't think clients should request revocation (see earlier message).

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: "[email-masked] WG" <[email-masked]> 
Sent: Monday, September 10, 2012 5:25 AM
Subject: [OAUTH-WG] draft-ietf-oauth-revocation-00

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2012 11:48:41 +0300

Hi Justin, 

I completely agree that a mechanism for the Authorization Server to notify the Clients may not be desireable in all cases.  
However, if the Authorization Server hands out long lived tokens then it may want to notify the Clients (particularly when those are Web servers) about revocations. 

Alternatively, one could argue for short-lived tokens. 

In my view it is quite realistic that the Authorization Servers finds out that it has to revoke an Access Token.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2012 11:49:50 +0300

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Sep 2012 10:25:32 -0400

It's perfectly reasonable that the AS needs to revoke an Access Token, 
yes; but why does the client need to know ahead of time? The client will 
find out as soon as it tries to use the bad token at the RS, won't it?

It's a different question entirely of how the RS finds out that a token 
has been revoked at the AS, but I would argue that the AS-RS connection 
is very different from the AS-Client and Client-RS connections, and 
should be approached differently. This is where token introspection can 
really come into play -- a backchannel means of finding out what a token 
is good for. As Bill pointed out, the Client generally doesn't care 
about what's in the token or what it's good for in a 3-legged OAuth 
case. But the eventual audience of that token, the RS, does care, and if 
it's been separated from the AS, then introspection is a simple, general 
way to solve that.

  -- Justin

---

From: William Mills <[email-masked]>
Date: Tue, 11 Sep 2012 08:21:38 -0700 (PDT)

I think a resource server might validly revoke a token, but that a client will not. 

-bill

----- Original Message -----
From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Torsten Lodderstedt <[email-masked]>; Justin Richer <[email-masked]>; "[email-masked] WG" <[email-masked]>
Sent: Tuesday, September 11, 2012 1:49 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

Hi Bill, 

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Sep 2012 11:58:13 -0400

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

---

From: William Mills <[email-masked]>
Date: Tue, 11 Sep 2012 11:41:38 -0700 (PDT)

OK, I see the use case, although I don't find it particularly compelling.

________________________________
 From: Justin Richer <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; Torsten Lodderstedt <[email-masked]>; "[email-masked] WG" <[email-masked]> 
Sent: Tuesday, September 11, 2012 8:58 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

  -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Sep 2012 14:37:52 +0300

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:
> ------------------------------------------------------------------------
> *From:* Justin Richer <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Torsten Lodderstedt
> <[email-masked]>; "[email-masked] WG" <[email-masked]>
> *Sent:* Tuesday, September 11, 2012 8:58 AM
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
>
>  > From: Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>
>  > To: William Mills <[email-masked]
> <mailto:[email-masked]>>
>  > Cc: Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>; Torsten Lodderstedt
> <[email-masked] <mailto:[email-masked]>>; Justin
> Richer <[email-masked] <mailto:[email-masked]>>; "[email-masked]
> <mailto:[email-masked]> WG" <[email-masked] <mailto:[email-masked]>>
>  > if I read your post correctly then you are saying that you do not
> like what is in <draft-ietf-oauth-revocation-00>
>  >
>  >> 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-masked]
> <mailto:[email-masked]>>
>  >> To: Justin Richer <[email-masked] <mailto:[email-masked]>>
>  >> Cc: "[email-masked] <mailto:[email-masked]> WG" <[email-masked]
> <mailto:[email-masked]>>
>  >>> 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
> 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
>  >>>
>  >>>> [email-masked] <mailto:[email-masked]>
>  >>> [email-masked] <mailto:[email-masked]>
>  >> [email-masked] <mailto:[email-masked]>
>  >> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 17 Sep 2012 21:03:56 +0200

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).
>