Could you clarify what the "confusing mess" part is? The cited reference [1] is not useful.
It is good to adhere to the challenge-response model of 2617 for wider interoperability and discoverability (yes, WWW-Authenticate with a well-known scheme name helps discovery and lack thereof reduces protocol visibility). Subbu On Jan 14, 2011, at 10:32 PM, Eran Hammer-Lahav wrote: > One of the main problems with OAuth in general has always been the unsanitary > mix of authorization and authentication (“it’s an authentication protocol… > authorization protocol… authentication protocol” [1]). It has always been a > confusing mess. The work on 2.0 has provided a valuable abstraction and > separation of the two components, especially the recent document split. In > addition, the recent work on the bearer token document and the MAC token type > have raised issues about OAuth and its relationship with HTTP authentication. > > I would like to suggest we drop the ‘OAuth2’ WWW-Authenticate header > completely from the specification for the following reasons: > > 1. Draft oauth-v2 is clearly not an authentication protocol. It > *utilizes* client authentication. It offers one fully defined method for > client authentication (which is basically HTTP Basic+), provides a half-baked > client assertion authentication hook, and leaves all end-user authentication > out of scope. > 2. The WWW-Authenticate header has absolutely no value, > interoperability-wise or otherwise. Discovery was rules to be beyond the > scope of this specification. Having a protected resource declare it supports > authentication using some unspecified credentials obtained using some > unspecified client flow is confusing at best. In the future, an interoperable > discovery mechanism will be needed to allow clients to interact with > completely unknown protected resources, but this has been consistently ruled > to be premature standardization at this point. > 3. OAuth is agnostic to token authentication, and we already have three > discrete token type proposals – all with active deployment plans in the > coming months. Two of these methods have already defined a full HTTP > authentication scheme (even if the bearer token specification has not yet > been updated to change its scheme name). > 4. HTTP *authentication* is not an appropriate facility to negotiate > *authorization*. OAuth authorization discovery can be added to HTTP > authentication schemes as attributes, but makes no sense as a scheme of its > own. The issues we are having with ‘realm’ is one of the examples showing > that we are abusing the header. > 5. Again, as specified, it adds no value and I am not aware of any > existing OAuth 1.0a implementation making use of the response header for > client interoperability (yes, many include it, but how many clients actually > rely on it, and if they do, how?). > > For these reasons I would like to suggest we: > > 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from > the specification, leaving it up to each token type to define its own > authentication flow. In the future, a comprehensive discovery specification > should define a new HTTP response header for providing discovery information. > I have suggested using Link: rel=’authorization’ as a simple yet powerful > solution. > 2. Rename the document to ‘The OAuth 2.0 Authorization Protocol’ to > make it clear what this document is really about. > > Comments? Counter argument? > > EHL > > [1] http://www.youtube.com/watch?v=0IBZocFkXGY > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
