On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
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
It doesn't make any sense to solve discovery *just* for revocation,
which you seem to be advocating. Of course it has an impact on security
-- this is a security protocol we're talking about, that goes without
saying. It also impacts security where I send the user for
authorization, and everything else that you do.
I would rather see discovery solved properly for all of OAuth including
all of its endpoints. UMA has taken a crack at this, there's a draft
defining XRD link types, OIDC has a solution for this as well (in the
provider configuration .well-known doc).
2. OK, make this explicit in specification
Fair enough. Got specific language to suggest?
3. if you have an auth_code you should be able to use it, agree not all will
have it but some will
You shouldn't have an auth code anymore -- you're supposed to throw it
away since it's single use (per 10.5 of RFC6749). Why wouldn't you just
use the token? You're guaranteed to have the token in all cases. I see
no value in sometimes sending an auth code and sometimes sending a token
when I am guaranteed to always have the token.
4. MAY seems a better choice
Possibly -- I think SHOULD is fine here but I'm curious what others say.
5. Make it explicit in the spec one way or the other, too vague now
Explicit how? It can explicitly go either way. From the client's
perspective, it's supposed to be immediate. From the server's
perspective, it could take a while to actually enforce that.
6. How does one find the policy, as this has an impact on #7
How does one find any other implementation specific policy? There was
already a big discussion about this a while ago. It used to be a MUST to
cascade, then as I recall, Google objected to it because their access
tokens in the wild can't be revoked at all, so revoking a refresh token
revokes only that token. The current language allows the server to
decide what it has to do.
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
You're conflating things here. If the client revokes the refresh token,
they must not use that refresh token again. They can try to use any
access or other tokens if they want to, but that refresh token is off
the table. The server is allowed to also nuke any access tokens that it
wants to, but if the client wants to be really, really sure, it can
revoke all of its access tokens separately.
-- Justin
-----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
