Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

[Justin Richer <[e-mail]>]

Not to jump in and answer for Torsten, but I thought I'd  offer at least 
my understanding of the document:

On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
> 1.       Since not stated I assume that the Revocation Endpoint can exist on a different server from the Authorization server (or is it assumed that they are 1), if so how is the Revocation Endpoint found?
It could be separate if your architecture can support that. It gets 
found the same way other OAuth endpoints get found -- configuration 
documents, some kind of discovery mechanism, or magic. Which is to say, 
that's not currently OAuth's problem.

> 2.       Any token type that is supported can be revoked, including refresh token ?
That's the idea. We've implemented this on our OIDC server so that you 
can also revoke ID Tokens for session management purposes.

> 3.       Why does one have to send the token, can't this just be an auth_code ?
You don't always use an auth code to get a token (think implicit, client 
credentials, assertion, or resource owner credentials flows), and auth 
codes are supposed to be thrown away after use anyway.

> 4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
If they have issues, which is to say "A good reason not to", then they 
don't have to support it. That's the semantics behind "SHOULD", and so 
it is fine here.

> 5.       Does not say but is the revocation to be immediate upon the return of the request ?
This is implementation dependent. Large scale distributed 
implementations could have trouble making this "immediate", but small 
systems are more likely to be quick. From the client's perspective, if 
they get back a success response, they shouldn't count on that token 
being good anymore (see section 2 note about client behavior).

> 6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation policy decision ?
That's a policy decision.

> 7.       Section 2 says "the client MUST NOT use this token again", well that seems odd, not sure this should be here as the client could try to use it gain, there is no need to put support in client to prevent this.
Why would a client want to use a token that they just revoked? This is 
prescribing the desired correct behavior to a client so that client 
developers will do the right thing when they implement it. Isn't that 
the point of the spec?

  -- Justin