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

[Torsten Lodderstedt <[e-mail]>]

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

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

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

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

- "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?

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

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

§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?

regards,
Torsten.