> -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Friday, February 04, 2011 9:39 AM
> >> > - schemes are not easily reusable outside OAuth. > >> > >> Sure. But I really don't see this group trying to create generic > >> authentication schemes. > > > > MAC is exactly that. > > May or may not be. My point is that this group is not focused on creating > generic authentication schemes. Are you aware of any other protocols that > might use MAC or BEARER? Are we willing to put in the effort to create > generic schemes? Is it our charter? We are chartered to produce one such generic HTTP authentication scheme: "The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenario)." My team is using MAC outside of OAuth. Also keep in mind that MAC is not a working group item or document. It is an individual submission aimed at producing an HTTP authentication scheme that is useful on its own but with OAuth binding. > >> > - existing frameworks usually switch on scheme name, not on sub > >> > scheme, which will cause difficulty in some deployments. > >> > >> I can see this as a potential problem. But considering that there > >> wasn't much objection to use "OAuth" as a scheme name before (total > >> overlap with OAuth 1, and the suggested solution was to look for the > >> signature > >> parameter) I don't see how this is suddenly an issue. > > > > There was pretty strong objection to reusing OAuth. > > Yes, because there was no sub-scheme nor version (and the grammar was > totally broken). Even so, lots of implementations went ahead and did it. > Were there any scheme switching issues we are aware of? There was a wide range of reasons. At the end, we are talking about a literal string. Code doesn't care what humans make of it. > >> > - requires its own discovery method for which schemes are supported. > >> > >> Why is this a downside only for this option? > > > > Because the other options get this for free by using the WWW- > Authenticate header (since each scheme has a unique name). You can list > multiple headers in the 401 response. > > I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > work for sub-schemes as well? It can. But it is not as trivial. With different schemes, the existing 2617 framework does everything for you. You just include multiple headers. With sub-schemes, it is awkward to repeat the same scheme multiple times (but probably allowed), so you need to define some key="value, value, value" format for specifying multiple sub-schemes. And then if each sub-scheme has other parameters, it gets tricky. IOW, you are moving functionality provided to you by HTTP into one you are making up. What's the point? Where is the value? I think the core difference here is you are more concerned about the HTTP scheme namespace and I am more concerned about inventing new authentication framework facilities. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
