Received-SPF: softfail (mail220-co1: transitioning domain of microsoft.com
 does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21;
 envelope-from=tonynad@microsoft.com;
 helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; 
From: Anthony Nadalin <tonynad@microsoft.com>
To: Justin Richer <jricher@mitre.org>
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Thread-Index: Ac35p+wOnP9UzK9BQMG59YbBjTobdAAHPkAQAB4kyAAAA1FVAA==
Date: Thu, 24 Jan 2013 15:58:36 +0000
Message-ID: <269c48631ede4fc59c949b9f43f91c05@BY2PR03MB041.namprd03.prod.outlook.com>
References: <a7b55ec383284cee83ff199f0057acbb@BY2PR03MB041.namprd03.prod.outlook.com>
 <5101425A.6080905@mitre.org>
In-Reply-To: <5101425A.6080905@mitre.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Review
Precedence: list

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 wil=
l 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 hav=
e 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 server=
s policy. This should be a SHOULD not MUST

-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org]=20
Sent: Thursday, January 24, 2013 6:17 AM
To: Anthony Nadalin
Cc: oauth@ietf.org
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 t=
he same way other OAuth endpoints get found -- configuration documents, som=
e kind of discovery mechanism, or magic. Which is to say, that's not curren=
tly OAuth's problem.

> 2.       Any token type that is supported can be revoked, including refre=
sh 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 cr=
edentials, 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 sinc=
e 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 fi=
ne here.

> 5.       Does not say but is the revocation to be immediate upon the retu=
rn of the request ?
This is implementation dependent. Large scale distributed implementations c=
ould have trouble making this "immediate", but small systems are more likel=
y to be quick. From the client's perspective, if they get back a success re=
sponse, 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 pres=
cribing 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