Ugggg uggg 1. we keep punting on discovery, this has an impact on security of where I send my credentials and token, can't see punting yet again here 2. OK, make this explicit in specification 3. if you have an auth_code you should be able to use it, agree not all will have it but some will 4. MAY seems a better choice 5. Make it explicit in the spec one way or the other, too vague now 6. How does one find the policy, as this has an impact on #7 7. There is a big difference here in enforcement, the client should not have to enforce this rule, the client may not know due to policy that revoking 1 token revokes other tokens thus the client would have to know the servers policy. This should be a SHOULD not MUST
-----Original Message----- From: Justin Richer [mailto:[email protected]] Sent: Thursday, January 24, 2013 6:17 AM To: Anthony Nadalin Cc: [email protected] Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review 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
