>From http://www.intertwingly.net/wiki/pie/PaceSecurityConsiderations:
<snip> Implementations SHOULD use client authentication mechanisms to prevent posting or editing by unknown or unauthorized sources. The type of authentication used is a local decision made by the server. Accordingly, clients are likely to face authentication schemes that vary across multiple implementations. Servers utilizing authentication MUST reject unauthorized or unauthenticated requests using the HTTP 401 "Unauthorized" response message. Per [RFC2616], 401 Unauthorized responses MUST include a WWW-Authenticate header identifying the authentication scheme that is to be used. Servers utilizing authentication mechanisms that involve the clear-text transmission of a password (e.g. HTTP Basic Authentication) MUST secure the connection using, for example, a Transport Layer Security (TLS) connection. </snip> - James Kyle Marvin wrote: > > 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 >> >> > >
