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
