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:
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
