Eran, > I agree
Thanks. > , BUT. > I don’t think it is very practical at this point. Defining new authentication > schemes (i.e. SAML assertion) means slower deployment due to lack of support > in existing applications. There are no existing apps that support the SAML flow as it was only written a few days ago. I guess some might support the WRAP SAML flow. It is incompatible, but similar enough for an easy change. But moving the fields to a “Authorization: SAML” header is easy too. > Reusing existing authentication schemes for a new set of credentials has its > own deployment challenges (conflict with another set of credentials like > users, access to header from clients, reliance on different layers of the > infrastructure). I don’t think this is an issue since requests for an access token are only done by client apps, not users. Also the credentials will often not be a new set. They will be client credentials used to access non-OAuth-protected resources already. Access to header from client, reliance on different layers etc could be issues — but that is a great reason for OAuth not to try to pick one answer. One answer has no chance of satisfying everyone, hence items like the SAML flow being introduced. > As currently written, the spec defines a new authentication scheme using > assertions (which if defined as a general purpose scheme requires much more > specificity than this group shown an interest in), and provides an > alternative to Basic using parameters instead of headers. > I would be opposed to this group spending time on a general purpose assertion > authentication scheme (but don’t care if someone decides to create one > elsewhere). I also don’t want the group spending time on general purpose assertion auth (or request auth) schemes. The only way to avoid that is to decouple them from OAuth-specific bits. This is what I am suggesting. Currently, people who want to use SAML (which is not me particularly) need to argue about OAuth core because the other OAuth flows prevent use of SAML by choosing an OAuth-specific shared secret mechanism. Recognizing that OAuth access token requests are independent of client auth would really help. It would be obvious how to use OAuth (unchanged) with other client auth mechanisms. > As for using Basic, I don’t have a strong objection but I am certain it will > cause confusion and will make the spec harder to use. I am equally certain that client developers will not be confused at all if a service says “use HTTP BASIC with your client id and secret to authenticate calls to the AS to get and renew access tokens”. > There is nothing to stop anyone from defining new flows which use other > authentication methods. The spec offers a practical set that is in line with > how most of the participants expect to deploy it. > So while I agree with your sentiment here, I would not be supportive of it > unless the primary companies looking to deploy this in the next few months > are on board. I have no interest in producing a cleaner spec that no one > wants to use. OAuth has been successful in the past primarily because > pragmatism is the OAuth way. The fact that WRAP redid OAuth, and the IETF are redoing it again -- with no backward compatibility -- suggests to me that we didn’t take quite enough time to cleanly separate the aspects of the spec that can be independent. I hope we don’t make the same mistake again. I doubt any of the “primary companies looking to deploy this in the next few months” need interoperability from client apps not written specifically for their proprietary API, at least not “in the next few months”, but I think an IETF OAuth spec must provide that. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
