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
