Yes it's old, 1 week form expiring too. The specs seem to be stabilizing now so it's worth updating. Has there been any other discovery proposal yet?
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, January 19, 2011 9:46 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Thanks. Seems like this draft is based on an old version of the v2 specification. Stuff like signature and endpoint location is long gone... EHL From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:39 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00.txt From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, January 19, 2011 9:16 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme You're going to make me do all the work... Where's the spec? EHL From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:06 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme My initial implementation of a SASL mechanism is now published at https://github.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as well as the fact that there's no automake and such. Please feel free to create issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide this discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major differences in-band I'm OK. I spinning back up on the SASL mechanism (now that I finally was allowed to opensource it), and my current in-band discovery is pretty clean using WWW-Authenticate. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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
