Re: [OAUTH-WG] First draft of OAuth 2.0

[David Recordon <[e-mail]>]

Inline and thanks for the feedback!

On Tue, Mar 23, 2010 at 11:14 AM, Torsten Lodderstedt
<[e-mail]> wrote:
> Hi David,
>
> I have a couple of questions/comments:
>
> §2 - The flows use shared secrets for client authentication only. What about
> adding support for public-key-based signatures for that purpose as an
> alternative? That's one of the use cases on
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy

I think it's reasonable to design a flow which uses public-keys to
authenticate the client for an access token. You'd probably do
something like this for the device flow if you actually want to
authenticate the device as TPM is becoming more prevalent.  Including
the secret over SSL keeps the protocol simpler for developers.


> §2.4 - Looks like a POST-Request in combination with a password-based user
> authentication. What about using a standard BASIC Authorization Header
> instead of oauth_username and oauth_password? In that way, existing code for
> BASIC-Authentication can easily be ported to OAUTH.

You're the first to mention that AFAIK. I'd be interested in if it
would be useful to service providers like Twitter who already use
basic and digest auth.  My guess is that just including the username
and password as parameters is actually simpler given that you'll be
building this in an authorization flow.  Most sites which use
basic/digest for API authentication are doing so to actually make API
requests so they'll need to write new code to support OAuth in the
first place.


> §3
> - Why is the parameter oauth_client_secret required for refreshing access
> tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a
> secret. Does this imply such client are not entitled to refresh tokens? I
> would suggest to simply remove this parameter.

It shouldn't be required.  Fixed!
http://github.com/daveman692/OAuth-2.0/commit/a30843724f241f3ea1052c83dcfec0127a11fe00


> - Why is the refresh method the only way to obtain token secrets? This
> forces every client needing a token secret to perform two calls (and get a
> useless access token in the first call). I would suggest to add the
> parameter oauth_want_secret to all flows in §2.

Protocol simplicity. Signatures are meant to be used in advanced cases
and should not distract 95% of developers who will never touch them.
The main use cases for signatures is based around performance in
extremely high volume API interactions. Thus one extra HTTP request at
the start should pale in comparison to the number of API requests
which will actually be made using that secret.


> - "If an access token secret is included in the response, the protected
> resource MUST NOT allow the use of the corresponding access token without
> its secret .... " Why is that neccessary?

When acting as a bearer token the access token is all powerful and
must be kept secret between the client and servers. In the signature
flow (if you're not also using SSL) then the access token is sent over
the wire. Thus a MITM could get the access token and make SSL requests
without this requirement.


> - response value oauth_signature_methods: Why is it the obligation of an
> autorization server to know the signature methods a protected resource
> supports? IMHO this is a question of the protocol between client and
> protected resource and the client should pass in to the request the desired
> signature method. In that way the authorization server is able to create
> adequate secret.

hmm. I guess the protected resource(s) always knows about the
authorization server though it's conceivable that the authorization
server doesn't know about every protected resource. This seems far
simpler than the client needing to negotiate the signature mechanism
with each protected resource. Is there someone developing a deployment
where the drafted model (from 1.0a) doesn't work?


> §4.1 Why do you want to enforce such a strong coupling between bearer tokens
> and TLS per spec? I would recommend to split protocol definition and
> security considerations as in RFC2617. There, BASIC authentication is
> defined without any references to transport security mechanisms and the
> relevant considerations/recommandations are discussed in the security
> consideration section. IMHO this would simplify the specification because
> bearer token requests and requests w/ access tokens + signature would just
> be variant of the same protocol definition.

I think this comes out of making the spec really easy to implement.
The style of the spec is very much designed for implementors writing
code as they're reading.


> §4.2.2 The WWW-Authenticate header does not give the client any hint what
> signature methods to use. How shall the client that information obtain?

Right now it's obtained via the signature methods parameter. Is there
an easy way to add it in this 401 response?

Thanks!
--David

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