Agree that these would be code breaking changes and cause interoperability issues late in the specification cycle
From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: [email protected] Subject: [OAUTH-WG] 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
