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
