No, it will just be very short giving an introduction to how to use tokens in general, how to define token types, and will include two examples for bearer tokens and mac tokens.
EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Sunday, January 16, 2011 11:00 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme wouldn't that mean to drop section 6 completely? regards, Torsten. Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav: 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: 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. 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. 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). 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. 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: 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. 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
