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
