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