Tim was responding positively to this Pace: http://www.intertwingly.net/wiki/pie/PaceFixSecurityConsiderations
which says in part > Implementations of the Atom Publishing Protocol SHOULD be protected using > HTTP Authentication mechanisms as defined by or derived from [RFC2617]. If > implementations choose to implement support for HTTP Basic Authentication, > they SHOULD support encryption of the session using TLS [RFC2246] Which I'm fine with as well, but note that it does add a SHOULD to the spec in the hope of promoting interoperability. I'm +1 on this wording too, because it at least gives a signpost for people who care about interoperability[1]. I again point at Ecto, which doesn't follow RFC2617 at all, as an example of what will happen if we simply say nothing. (Remembering that unfortunately, WSSE or 'CGI Authentication' is going to be out there and documented in blog posts for the next N decades... and that's what people are finding when they search for "Atom authentication" right now.) John [1] I don't care what people who don't care about interoperability do w.r.t. authentication. I'm not advocating some kind of 'least bad practices' security for security's sake, but for interoperability's sake. Kyle Marvin wrote on 6/7/2006, 2:04 PM: > I feel like Tim did a pretty good job of summarizing the issues around > auth in this thread from late February: > > http://www.imc.org/atom-protocol/mail-archive/msg04533.html > > His last point is a key one: "having had considerable experience with > security-admin and security-architect types, I suspect that our > specification has relatively little chance of influencing their > actions" > > This is 100% true, so if you think by adding this SHOULD in the spec > you are going to maximize interop, it's probably a false hope. > > I can guarantee you that a client can expect "problems" at least with > some Google APP services in regards to this constraint. I'm not > playing hardball, I'm just being honest. I can say that whatever we > do w.r.t. authentication will be well-documented, as minimally > intrustive to client developers as possible, and secure for our users. > > -- Kyle > > On 6/7/06, John Panzer <[EMAIL PROTECTED]> wrote: > > > > Thomas Broyer wrote: > > > > > > > > 2006/6/7, Tim Bray <[EMAIL PROTECTED]>: > > > > > >> > > >> On Jun 7, 2006, at 10:21 AM, Paul Hoffman wrote: > > >> > > >> > Note that in IETF parlance, a "SHOULD" is "MUST but with a few > > >> > stated exceptions". I don't feel that that is what people were > > >> > saying +1 to. > > >> > > >> Gack; seems to me it would be way out of line to point a MUST at any > > >> one of the options. Among other things I expect APP to be longer- > > >> lived than any particular web-authent flavor. -Tim > > > > > > > > > +1 > > > > > > HTTP/1.1 doesn't mandate support for any authentication scheme, so > why > > > would APP do? Nothing more should be said than "you, as a server > > > implementor, might want to consider protecting your APP endpoints > with > > > whatever mechanism you choose –presumably using HTTP authentication, > > > SAML, NTLM or something else– and clients implementors should be > aware > > > of that". > > > > It would be good to say at least that and include client > implementors as > > well; my experimentation with Ecto indicates that it doesn't really pay > > attention to HTTP authentication negotiation and simply tosses WSSE > > headers into its requests. So there is already an interoperability > > problem, deployed in the field today. > > > > > > > > Eventually, something like "at the time of this writing, Basic+TLS > > > seems a good catch and widely deployed solution, so client > > > implementors should at least support HTTP-Basic and TLS", > > > > I think this is the very least we need to do. > > > > If the objection to making this a SHOULD is that eventually basic+https > > might be superceded by technically superior solutions that take over > the > > market at some point in the future... well, isn't that a valid > reason to > > ignore a SHOULD at that point in time? > > > > Here are two proposed sentences, which can be expanded as needed, but I > > think they capture the essential differences: > > > > (A) At the time of this writing, supporting HTTP Basic Auth over TLS > > provides a sufficiently secure and widely deployed solution for clients > > and servers. Clients are advised to support HTTP Basic Auth over TLS > > for maximum interoperability. > > > > (B) Atom clients and servers wishing to support authentication SHOULD > > support HTTP Basic Auth over TLS. > > > > I'm +0 on A and +1 on B. > > > > -- > > John Panzer > > System Architect, AOL > > http://abstractioneer.org > > > > -- Abstractioneer John Panzer System Architect http://abstractioneer.org
