You wrote: "Those who still want to advocate for it need to show not only
consensus for keeping it...". This seems backwards to me. In particular,
given the industry consensus that draft 10 was "nearly done", the onus to
establish consensus should fall on advocates of any proposals to remove
features - not the other way around - particularly so when the features are
implemented and in use.
It's also pertinent that the implementation call went out for draft 11.
Therefore, we should not be removing draft 11 features without decisive
consensus for doing so.
-- Mike
From: Eran Hammer-Lahav [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 10:13 AM
To: Mike Jones
Cc: [email protected]
Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP
Authentication Scheme
I agree that at this stage, we should do our best to avoid making breaking
changes. But first, we need to establish what is going to break and how.
The argument that removing the client assertion credentials affects
interoperability or breaks implementations is without merit.
As currently specified, the text is useless for any level of interoperability
or implementation. This means you must have your own specification providing
the actual meaningful information. At most, removing this section will require
you to register the two parameter names it defines. Since neither is being used
for a new purpose, removing this section creates no conflict. Hopefully, your
parameter registration will provide more meaningful information about them than
currently offered.
If you are going to object to my conclusions, you first need to show where my
arguments are wrong. I have seen nothing to contradict a single point I have
made about both issues. This goes for both the client assertion credentials and
OAuth2 scheme.
Just in case, I'll repeat my points.
Client assertion credentials:
1. The mechanism is under specified, especially in its handling of the
client_id identifier (when used to obtain end-user authorization).
2. It does not contain any implementation details to accomplish any level of
interoperability or functionality.
3. The section is a confused mix of security considerations sprinkled with
normative language.
4. Those who still want to advocate for it need to show not only consensus
for keeping it, but also active community support for deploying it. Deployment,
of course, will also require showing progress on public specifications
profiling the mechanism into a useful interoperable feature. Which open source
library supports or plan to support it?
'OAuth2' WWW-Authenticate header:
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.
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.
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.
EHL
From: Mike Jones [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: [email protected]
Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP
Authentication Scheme
Having spoken to a number of people implementing the spec here, I've
encountered strong objections to removing Client Assertion Credentials and the
OAuth2 HTTP Authentication Scheme. It's also not clear to me why we would make
substantial breaking changes to the specification when it is essentially ready
for approval. I've summarized the reasons I believe we should keep these two
features below.
Client Assertion Credentials: Many of the scenarios we care about require this
capability. They were key motivators for the Assertion Profile in WRAP (see ยง
5.2), have been part of OAuth 2 for quite a while, and we have running code
that requires this support. For example, the Azure Access Control Service is a
cloud Authorization server that supports several protocols, including parts of
OAuth 2.0 draft 10 (autonomous and web server profiles). We are happy to update
our implementation to subsequent drafts & agree that the spec leaves a lot of
ambiguity.
In our implementation of the autonomous and web server profiles, ACS allows
clients to authenticate using a signed assertion as well as with a
username/password. The username/pwd option is for clients that don't mind
sending credentials over the wire, while the signed assertion mechanism is for
clients that are more reticent to send raw credentials and for scenarios where
it isn't possible. To illustrate an example where username/pwd isn't viable,
consider the case of a client that needs to use an enterprise identity to gain
access to a cloud service. In many cases, corporate policy demands that a
client use an identity managed by the organization. This means that the client
should obtain an assertion from an enterprise identity provider (Active
Directory, Tivoli, etc.) and use that assertion to obtain an access token which
grants access to various web service APIs. Many of our key MSFT customers and
internal partner teams rely on this mechanism and reverting exclusively to
username/pwd isn't an option for us.
'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like a
huge step away from interoperability. As one data point, Microsoft implements
this in our WIF OAuth2 protected resource code. All up, clients need a way to
authenticate to the protected resource. Also, existing WRAP implementations
need this functionality to migrate to OAuth2. For all these reasons, we
support retaining this functionality in OAuth2.
Thanks,
-- Mike
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
