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

From: Anthony Nadalin <[email-masked]>
Date: Wed, 23 Jan 2013 23:54:03 +0000

Review:

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?

2.       Any token type that is supported can be revoked, including refresh token ?

3.       Why does one have to send the token, can't this just be an auth_code ?

4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS

5.       Does not say but is the revocation to be immediate upon the return of the request ?

6.       Does the revocation of the access token also revoke the refresh token (if it was provided) ? Or is this a revocation 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.

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jan 2013 09:16:58 -0500

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

> 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 Endpoin…
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 clie…
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

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jan 2013 15:58:36 +0000

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-masked]] 
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: [email-masked]
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:

> 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 Endpoin…
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).

> 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 clie…
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

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jan 2013 11:12:45 -0500

> 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 w…
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

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jan 2013 16:28:59 +0000

1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.
3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token
5. That is just the point, how does one know that the token id revoked
6. very poor choice, as no one know what is going on
7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy? 

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Thursday, January 24, 2013 8:13 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

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).

> 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.

> 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jan 2013 11:55:11 -0500

> 1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge seve…
Tony, I think you're misunderstanding what I'm saying. I completely 
agree that we should solve discovery and that we should use webfinger -- 
but this is a bigger problem than just revocation. Let's solve discovery 
for all of OAuth consistently. How would your rogue server "sign up" as 
it is? Get its URL into the documentation for a service? I think it's 
just as big of a problem for someone to say "hey I'm the token endpoint" 
and get clients to believe it, isn't it? And it's an even bigger 
problem, especially with bearer tokens, for someone to show up and say 
"I'm a protected resource!". Which is exactly why I say this needs to be 
solved for everything together, not just for revocation. Would you like 
to volunteer to draft a webfinger profile for all extant OAuth endpoints?

> 3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token
What you describe here is no longer token revocation, that's auth code 
revocation. That's a different operation and shouldn't be enabled by 
this endpoint. The auth code is supposed to eventually expire anyway, 
and that after a fairly short period of time. If you haven't gotten a 
token, you have to no token to revoke so you don't need to call the 
token revocation endpoint. If you just don't want to send your token, 
you just don't get to revoke it. What are you actually trying to 
accomplish by this added complexity?

In any case, it's impractical to implement. It's a big -- and novel -- 
burden for servers to keep around auth codes and tie them to the tokens 
that they represent anyway. I know our implementation doesn't track that 
link, and I doubt that many others do either. The auth codes are meant 
to be ephemeral.

> 5. That is just the point, how does one know that the token id revoked
The server will return if it's revoked the token. The effects of that 
revocation may take time to propagate to all PR's, so calling it 
"immediate" here could be misleading. As far as the client's concerned, 
it's immediate as soon as the server returns. This is why the client 
must throw the token out.

> 7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoke…
... no, you've got it backwards. Revoking an *access token* doesn't 
revoke the *refresh token* (that wouldn't make much sense), but revoking 
a *refresh token* SHOULD revoke all *associated access tokens*. That's 
the what the implementor's note (section 3) says. As far as the client 
is concerned, that token is dead the moment it gets back a positive 
response from the revocation endpoint. The "this token" in that sentence 
above is the token that was sent in with the request, there's no 
guarantee of what happens with "related" tokens. However, it's a good 
idea for the server to also throw out active access tokens associated 
with a refresh token, thus the implementor's note.

Sure, the token could be good for another week, but the client won't 
care because it's thrown things out. It's not the client's problem 
anymore. An immediacy requirement at the server is unimplementable in 
distributed systems. Any related tokens that happened to be revoked that 
the client tries to use (such as an access token tied to a refresh token 
that the client just revoked) might fail if the client uses them again.

But the thing is, failed token requests aren't a big deal, because you 
just start doing OAuth again. The code path is very simple and 
straightforward and is exactly the same whether or not you're using the 
revocation endpoint.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jan 2013 17:16:51 +0000

Basically the spec has a lot of underspecified behaviors which will lead to issues, in security and in expectations of the client.

3. no, as I can't do anything with an auth_code except get a access_token
5. The client does not know what to throw out as it does not know the server's policy
7." no, you've got it backwards. Revoking an access token doesn't revoke the refresh token (that wouldn't make much sense), but revoking a refresh token SHOULD revoke all associated access tokens."  Don't agree, the specification is not clear, currently it's a policy choice in the specification  and thus the issues that this creates. Basically revocation is not well defined in this specification which leads to many issues

From: Justin Richer [mailto:[email-masked]]
Sent: Thursday, January 24, 2013 8:55 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

1. We have WebFinger lets use that as we have already been through the discovery issues, point being there are security issues at stake here w/o proper knowledge, next thing we know some rouge sever has signed up as a revocation sever.
Tony, I think you're misunderstanding what I'm saying. I completely agree that we should solve discovery and that we should use webfinger -- but this is a bigger problem than just revocation. Let's solve discovery for all of OAuth consistently. How would your rogue server "sign up" as it is? Get its URL into the documentation for a service? I think it's just as big of a problem for someone to say "hey I'm the token endpoint" and get clients to believe it, isn't it? And it's an even bigger problem, especially with bearer tokens, for someone to show up and say "I'm a protected resource!". Which is exactly why I say this needs to be solved for everything together, not just for revocation. Would you like to volunteer to draft a webfinger profile for all extant OAuth endpoints?

3. you can still have one if you have not used it and want to revoke it, I may not want to redeem the auth_code to get a token to revoke it, I may just not want to send the token
What you describe here is no longer token revocation, that's auth code revocation. That's a different operation and shouldn't be enabled by this endpoint. The auth code is supposed to eventually expire anyway, and that after a fairly short period of time. If you haven't gotten a token, you have to no token to revoke so you don't need to call the token revocation endpoint. If you just don't want to send your token, you just don't get to revoke it. What are you actually trying to accomplish by this added complexity?

In any case, it's impractical to implement. It's a big -- and novel -- burden for servers to keep around auth codes and tie them to the tokens that they represent anyway. I know our implementation doesn't track that link, and I doubt that many others do either. The auth codes are meant to be ephemeral.

5. That is just the point, how does one know that the token id revoked
The server will return if it's revoked the token. The effects of that revocation may take time to propagate to all PR's, so calling it "immediate" here could be misleading. As far as the client's concerned, it's immediate as soon as the server returns. This is why the client must throw the token out.

7. No I'm not conflating things here at all, please read the text. If I send a access_token and the server's policy says that the refresh_token associated with the access_token is also to be revoked then I have no way to know that "The client MUST NOT use this token again after revocation". What is "this" mean in the sentence, only the token I sent or any revoked token. Also how do I know when the token is actually revoked, could take a week or more given policy?
... no, you've got it backwards. Revoking an access token doesn't revoke the refresh token (that wouldn't make much sense), but revoking a refresh token SHOULD revoke all associated access tokens. That's the what the implementor's note (section 3) says. As far as the client is concerned, that token is dead the moment it gets back a positive response from the revocation endpoint. The "this token" in that sentence above is the token that was sent in with the request, there's no guarantee of what happens with "related" tokens. However, it's a good idea for the server to also throw out active access tokens associated with a refresh token, thus the implementor's note.

Sure, the token could be good for another week, but the client won't care because it's thrown things out. It's not the client's problem anymore. An immediacy requirement at the server is unimplementable in distributed systems. Any related tokens that happened to be revoked that the client tries to use (such as an access token tied to a refresh token that the client just revoked) might fail if the client uses them again.

But the thing is, failed token requests aren't a big deal, because you just start doing OAuth again. The code path is very simple and straightforward and is exactly the same whether or not you're using the revocation endpoint.

 -- Justin

-----Original Message-----

To: Anthony Nadalin

Cc: [email-masked]<mailto:[email-masked]>

here

3. if you have an auth_code you should be able to use it, agree not

all will have it but some will

  -- Justin

-----Original Message-----

To: Anthony Nadalin

Cc: [email-masked]<mailto:[email-masked]>

   -- Justin

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jan 2013 13:02:56 -0500

On 01/24/2013 12:16 PM, Anthony Nadalin wrote:
>
> Basically the spec has a lot of underspecified behaviors which will 
> lead to issues, in security and in expectations of the client.
>
Right. Which is *exactly* how I'm suggesting it remain. Are you 
reversing your previous position of wanting to use the auth_code to 
revoke an access token?

> 5. The client does not know what to throw out as it does not know the 
Yes it does, it throws out the token that it sent to the revocation 
endpoint. It can throw out that token without calling the revocation 
endpoint if it wants.

> 7." no, you've got it backwards. Revoking an *access token* doesn't 
> revoke the *refresh token* (that wouldn't make much sense), but 
> revoking a *refresh token* SHOULD revoke all *associated access 
> tokens." *Don't agree, the specification is not clear, currently it's 
> a policy choice in the specification  and thus the issues that this 
> creates.
>
The text states:

    Depending on the authorization server's revocation policy, the
    revocation of a particular token may cause the revocation of related
    tokens and the underlying authorization. If the particular token is
    a refresh token and the authorization server supports the revocation
    of access tokens, then the authorization server SHOULD also
    invalidate all access tokens based on the same authorization (see
    Implementation Note
    <http://tools.ietf.org/id/draft-ietf-oauth-revocation-04.html#impl>).

The cascade listed is refresh->access, not access->refresh. Note that it 
leaves the door open to other "related" tokens, such as OpenID Connect's 
ID Token, dynamic registration's Registration Access Token, or others. 
It's completely up to the server whether or not it wants to -- or even 
can -- cascade a delete operation. That's *all* that this is talking about.

Note that, as in regular old OAuth, tokens can be suddenly revoked with 
the client knowing about it at any time. The end user could revoke it, 
the AS could decide to recycle all tokens for a given client, the tokens 
could expire. This is by design. Any given token that a client might 
have might not work and clients MUST already be robust against this, 
without revocation coming into the picture. Revocation doesn't add any 
more mystery or bookkeeping.

> Basically revocation is not well defined in this specification which 
> leads to many issues
>

What issues specifically that haven't been addressed here?

  -- Justin

> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Thursday, January 24, 2013 8:55 AM
> *To:* Anthony Nadalin
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
>
>
>
> agree that we should solve discovery and that we should use webfinger 
> -- but this is a bigger problem than just revocation. Let's solve 
> discovery for all of OAuth consistently. How would your rogue server 
> "sign up" as it is? Get its URL into the documentation for a service? 
> I think it's just as big of a problem for someone to say "hey I'm the 
> token endpoint" and get clients to believe it, isn't it? And it's an 
> even bigger problem, especially with bearer tokens, for someone to 
> show up and say "I'm a protected resource!". Which is exactly why I 
> say this needs to be solved for everything together, not just for 
> revocation. Would you like to volunteer to draft a webfinger profile 
> for all extant OAuth endpoints?
>
>
> burden for servers to keep around auth codes and tie them to the 
> tokens that they represent anyway. I know our implementation doesn't 
> track that link, and I doubt that many others do either. The auth 
> codes are meant to be ephemeral.
>
>
> "immediate" here could be misleading. As far as the client's 
> concerned, it's immediate as soon as the server returns. This is why 
> the client must throw the token out.
>
>
>       
>
> revoke the *refresh token* (that wouldn't make much sense), but 
> revoking a *refresh token* SHOULD revoke all *associated access 
> tokens*. That's the what the implementor's note (section 3) says. As 
> far as the client is concerned, that token is dead the moment it gets 
> back a positive response from the revocation endpoint. The "this 
> token" in that sentence above is the token that was sent in with the 
> request, there's no guarantee of what happens with "related" tokens. 
> However, it's a good idea for the server to also throw out active 
> access tokens associated with a refresh token, thus the implementor's 
> note.
>
> distributed systems. Any related tokens that happened to be revoked 
> that the client tries to use (such as an access token tied to a 
> refresh token that the client just revoked) might fail if the client 
> uses them again.
>
> straightforward and is exactly the same whether or not you're using 
> the revocation endpoint.
>
>  -- Justin
>
>
>       
>
>       
>
>     Cc:[email-masked]  <mailto:[email-masked]>
>
>         Cc:[email-masked]  <mailto:[email-masked]>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Jan 2013 19:33:04 +0100

Hi Tony,

thanks for your review comments.

*** @Justin: thanks for jumping in. ***

I would like to recap the results of the discussion so far and propose 
some changes.

Am 24.01.2013 00:54, schrieb Anthony Nadalin:
>
> Review:
>
> 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?
>

Having read your arguments I realize the current text is a bit specific 
about the means to obtain the endpoint location (as it does not mention 
other means).

current text:

The location of
    the token revocation endpoint can be found in the authorization
    server's documentation.  The token endpoint URI MAY include a query
    component.

proposal:

The means to obtain the location of the revocation endpoint is out of scope of this specification.

There is a range of options. The client could, for example,
automatically discover this information (along with other server
andpoints and properties). Alternatively, the client developer could
also get to know the endpoint location from the server's documentation.

Note: As this endpoint is handling security sensible credentials, such information must be obtained from a trustworthy resource.

> 2.Any token type that is supported can be revoked, including refresh 
> token ?
>

The draft currently explicitly states support for access and refresh 
tokens. Do you want the draft to be weaker at this point and to allow 
for the revocation of any token?

> 3.Why does one have to send the token, can't this just be an auth_code ?
>

The draft is intended to support token revocation. I agree with Justin. 
Authz codes are short duration and one time use. I don't see a need to 
revoke them. I also don't see the need to use them to revoke the 
respective access token indirectly.

> 4.Says CORS SHOULD be supported, I think a MAY be better here since a 
> site may have issues supporting CORS
>

I'm fine with MAY since I tend to see CORS as an optional feature. What 
do others think?

> 5.Does not say but is the revocation to be immediate upon the return 
> of the request ?
>

The client must assume the revocation is immediate upon the return of 
the request. I could explicitly express this in the text

current text

In the next step, the authorization server invalidates the token.
    The client MUST NOT use this token again after revocation.

Proposal

   In the next step, the authorization server invalidates the token. The
client must assume the revocation is immediate upon the return of the
request. The client MUST NOT use the token again after the revocation.

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

As described by Justin, there are two use cases:

- if the token passed to the request is a refresh token and the server 
supports access token revocation, the server SHOULD also revoke them.
- if the token passed to the request is an access token, the server may 
decide to revoke the respective refresh token as well.

I think every client must be prepared to cope with "sudden" invalidation 
of any token type. So having different server policies with respect to 
related tokens shouldn't create interop problems.

What changes would you expect?

> 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.
>

The client should discard the token immediately after revocation.

regards.
Torsten.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Sat, 26 Jan 2013 11:06:09 -0800 (PST)

The draft should probably register a link relation type.  I'd register it with the others, but that draft is already in the individual submission pipeline.

________________________________
 From: Torsten Lodderstedt <[email-masked]>
To: Anthony Nadalin <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Saturday, January 26, 2013 10:33 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

Hi Tony,

I would like to recap the results of the discussion so far and
    propose some changes.

>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…
Having read your arguments I realize the current text is a bit
    specific about the means to obtain the endpoint location (as it does
    not mention other means). 

current text:

The location of the token revocation endpoint can be found in the authorization server's documentation.  The token endpoint URI MAY include a query component.
proposal:

The means to obtain the location of the revocation endpoint is out of scope of this specification. There is a range of options. The client could, for example, 

2.       Any token type that is supported can be revoked, including refresh token ?
The draft currently explicitly states support for access and refresh
    tokens. Do you want the draft to be weaker at this point and to
    allow for the revocation of any token?

3.       Why does one have to send the token, can’t this just be an auth_code ?
The draft is intended to support token revocation. I agree with
    Justin. Authz codes are short duration and one time use. I don't see
    a need to revoke them. I also don't see the need to use them to
    revoke the respective access token indirectly. 

4.       Says CORS SHOULD be supported, I think a MAY be better here since a site may have issues supporting CORS
I'm fine with MAY since I tend to see CORS as an optional feature.
    What do others think?

5.       Does not say but is the revocation to be immediate upon the return of the request ?
The client must assume the revocation is immediate upon the return
    of the request. I could explicitly express this in the text

current text

In the next step, the authorization server invalidates the token. The client MUST NOT use this token again after revocation.
Proposal

- if the token passed to the request is a refresh token and the
    server supports access token revocation, the server SHOULD also
    revoke them.
- if the token passed to the request is an access token, the server
    may decide to revoke the respective refresh token as well.

I think every client must be prepared to cope with "sudden"
    invalidation of any token type. So having different server policies
    with respect to related tokens shouldn't create interop problems.

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.
The client should discard the token immediately after revocation.

regards.
Torsten.

OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 29 Jan 2013 00:08:31 +0000

1. OK with new wording
2. My comment was meant for "token_type" (i.e. "bearer", "ID_Token", etc)?
3. Would like to see a way to revoke via auth_token in case someone wants to revoke before it is used, right now I have to retrieve it then revoke it
4. OK
5. OK with new text
6. I think clarifying words would help here
7. I prefer the wording you responded with and not the current text as it puts a requirement on the client

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Saturday, January 26, 2013 10:33 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review

Hi Tony,

I would like to recap the results of the discussion so far and propose some changes.
Am 24.01.2013 00:54, schrieb Anthony Nadalin:
Review:

Having read your arguments I realize the current text is a bit specific about the means to obtain the endpoint location (as it does not mention other means).

current text:

The location of

   component.

proposal:

The draft currently explicitly states support for access and refresh tokens. Do you want the draft to be weaker at this point and to allow for the revocation of any token?

The draft is intended to support token revocation. I agree with Justin. Authz codes are short duration and one time use. I don't see a need to revoke them. I also don't see the need to use them to revoke the respective access token indirectly.

I'm fine with MAY since I tend to see CORS as an optional feature. What do others think?

The client must assume the revocation is immediate upon the return of the request. I could explicitly express this in the text

current text

Proposal

- if the token passed to the request is a refresh token and the server supports access token revocation, the server SHOULD also revoke them.
- if the token passed to the request is an access token, the server may decide to revoke the respective refresh token as well.

I think every client must be prepared to cope with "sudden" invalidation of any token type. So having different server policies with respect to related tokens shouldn't create interop problems.

regards.
Torsten.

OAuth mailing list

[email-masked]<mailto:[email-masked]>