Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Manger, James H
> Sent: Thursday, October 01, 2009 6:31 PM

> I think OAuth needs:
> 
> 1. A WWW-Auth scheme indicating that requests can be signed with a
> shared-secret key.

This is too specific. We need a scheme that indicate requests can be made with a token (vs. username).

> 2. A WWW-Auth scheme indicating that a web delegation flow can be used
> to get user authorization.

I am not sure this is the right way to provide delegation discovery (via the auth header). Using Link: headers is much more appropriate.
 
> The two are quite separate.
> The first would be defined in draft-ietf-oauth-authentication and would
> make no reference to delegation at all. "MAC" would be a good name.
> 
> <-  WWW-Authenticate: MAC realm="whatever"; algorithm="HMAC-SHA1 HMAC-
> SHA256 CMAC-AES";
>                      mode="HEADER URI POST" <perhaps some more
> parameters>
> 
> ->  Authorization: MAC realm="whatever"; algorithm="HMAC-SHA256";
> sig="65dFM…"; nonce…

The syntax differences from my proposal aren't significant. I think there is value in creating a family of authentication methods using a scheme and sub-scheme. It is better to support extensibility in the scheme than to force new methods to define new schemes. This will allow easier implementation of new sub-schemes.
 
> The option to encode the signature in a URI is worthwhile (eg a client
> can sign a URI then give it to another party to access, eg another
> party to click in a browser). Hence, the "mode" parameter above. I am
> less convinced by POST, but it is a small step from URI to POST so it
> is probably worth having.
> [HEADER = can put signature in HTTP Authorization request header;
>  URI = can put signature in URI query string;
>  POST = can put signature in HTML <form> POST]

Header server support should not be optional and hence does not need discovery.

Is it too much to ask all servers to support the URI mode? We are going to make supporting the auth headers mandatory in all implementations. Since we are dropping POST (no use cases, no matter how simple it is to keep) and headers are required, why not require support for a single URI header parameter?
 
> >	WWW-Authenticate: Token Plain realm=""
> >	Authorization: Token Plain <token> <secret>
> 
> This isn't necessary. Just use BASIC.
> A server may need to ensure usernames and tokens can be distinguished,
> but that is easy enough.

Yes it is. The idea of requiring servers to make this distinction is impractical. Basic auth is well defined and any attempt to overload it with new meaning is wrong.
 
> If an RSA-based mechanism is required a separate WWW-Auth scheme would
> be the best approach.

It is not clear what the RSA requirements are and how they should be managed yet. It should be a sub-scheme.
 
EHL