Mike, As assertion use is described in the spec, a client assertion does not provide any security whatsoever. How do you handle subject confirmation in your implementation? (See section 2.4.1.1 of the SAML specification.) In other words, how does the authorization server know that the client sending the assertion is actually the subject of the assertion?
Francisco --- On Tue, 1/18/11, Mike Jones <[email protected]> wrote: From: Mike Jones <[email protected]> Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme To: "Eran Hammer-Lahav" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Tuesday, January 18, 2011, 5:35 PM 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 -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
