>> 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). Eran, I think some of the disconnect between our ideas revolves around what a 'token' is. In OAuth, a (access) token is an identifier for a delegation of some authority from a specific user to a client. It is chosen by the server. It is an opaque blob as far as the client is concerned — they just have to include it in subsequent requests. From the perspective of just the authentication part of OAuth (draft-ietf-oauth-authentication), a token is just an id. I don't see a token as any different from a username, or an app id, or an employee number, or a device id -- as far as any authentication protocol is concerned. The web hasn't needed different versions of BASIC for users (with usernames) and for applications (generally with long random app-ids). If we need BASIC for usernames and TOKEN PLAIN for delegation tokens, wont we also need something else for direct access by clients. Mightn't we need a different scheme for tokens issued by the OAuth web-delegation flow vs token issued via some other mechanism? >> 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. A Link header might work. 1 or 2 extra round-trips could be avoid with a WWW-Auth scheme compared to a Link relation, as a WWW-Auth scheme could be more descriptive (more scheme-specific parameters) that seems sensible to cram into a Link relation. >> -> Authorization: MAC realm="whatever"; algorithm="HMAC-SHA256"; > The syntax differences from my proposal aren't significant. Indeed, I wasn't suggesting any change here (other than "MAC" as a better scheme name). >> 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. So you want the "TOKEN" scheme to mean "delegation credentials", and the sub-scheme to be the authentication mechanism. I don’t think a special indicator for "delegation credentials" is necessary (use case?). If an indicator is necessary we should make it independent of the authentication mechanism: an extra parameter to add to existing WWW-Auth schemes; a special string to include in the realm values of existing WWW-Auth schemes; a separate HTTP response header identifying which WWW-Auth headers are meant for "delegation credentials"… >> 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. Could you explain what is impractical? If a server really cannot distinguish tokens it chooses from usernames it can use separate URIs for the two groups. I don't think treating an OAuth token as a username, or a shared secret as a password is a "new meaning". James Manger James.H.Manger at team.telstra.com Identity and security team — Chief Technology Office — Telstra
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.