Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT)

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 15 Jun 2013 19:58:26 +0200

Hi Richard,

thanks for your review. Please find my comments inline.

@oauth WG: I would like to gather opinions regarding an issue raised by 
Richard thus I'm dispatching this to the list as well.

regards,
Torsten.

Am 29.05.2013 21:08, schrieb Richard Barnes:
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-revocation-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> D1. The mandate for TLS usage actually seems backward here.  Suppose a
> server receives a request over HTTP.  At this point, the credentials have
> been exposed, so you would *want* the token to be invalidated!  Suggest:
> -- Clients MUST NOT send over HTTP
> -- Server revocation URIs MUST be HTTPS
> -- Servers MAY support HTTP to the corresponding URI, just in case the
> client screws up

I see your point. Doesn't the last bullet contradict the first bullet?
>
> D2. Why are the requirements TLS versions different here than in RFC
> 6749?  Especially in a way that makes them worse.  Suggest deleting the
> sentence starting "The authorization server MUST support TLS 1.0 ..."

subject to ongoing discussion on the WG list.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> C1. "Depending on the authorization server's revocation policy..."
> It seems really bad for interop to have all of this be at the server's
> discretion and opaque to the client.  While its true that clients have to
> be able to handle unilateral revocation, at the very least this leads to
> unpredictable user experience.  (Why am I being asked to authenticate
> again?)  Suggest that the document either place constraints on the
> server, or have the server's response say exactly which tokens have been
> revoked.  The latter option might leak some information if tokens are not
> opaque, but doesn't present a security risk, since by definition the
> tokens are no longer good.

It is at the discretion of the authorization server and the resource 
owner to invalidate any token at any time w/o notifying the client. So I 
don't see a reason to handle propagated token revocation any different 
here. I agree this causes unpredictable UX but I don't see a interop issue.

>
> C2. "unsupported_token_type" -- This seems insufficient.  What if a
> server can invalidate some access tokens and not others?  (For example,
> if it has different relationships with different resource servers.)  It
> seems like what you really  want here is just a statement by the server
> that "I can't revoke this token".

Good point. Our assumption so far is that an authz server uses excactly 
one access token implementation and either supports access token 
revocation or not. What you envisions is an authz servers, which uses 
different access token implementations for different resource servers 
(probably even use cases). Correct? In order to support this use case, 
we would need to change the error name and description. I would like to 
discuss this in the WG.

Any opinion from the WG?

>
> C3. It might be helpful to describe what happens if a client tries to
> revoke something other than a valid token.  If the token is bogus (not
> issued by the Authorization Server), then it seems like "invalid_grant"
> makes sense.  However, if the token was issued and revoked by the
> Authorization Server, then it seems like the request should return
> success -- not "invalid_grant", as RFC 6749 implies.

We had a long discussion about this and decided to not notify the client 
but just return 200.