Atom Authentication

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

On Oct 25, 2004, at 5:30 PM, Robert Sayre wrote:

> [see atom-syntax for the rest of this thread]
>
> Dare Obasanjo wrote:
> > --- Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:
> > However we have a major blogging tool
> > vendor claiming that they plan to ignore that part of
> > the spec which makes the spec not worth the much. More importantly, 
> > restricting what authentication
> > mechanisms people can use is just plain silly.

Agreed.

I don't see any reason to limit what authentication methods people use, 
but in the interests of interoperability and user experience, is it 
valuable to put forth one or a small number of options that clients 
should support? I think it is.

Not by limiting the options, but by promoting a small number of good 
choices. The spec could say, "Atom clients SHOULD support one or more 
of the following methods..." A server  which couldn't support any of 
the given options might still be a legitimate Atom implementation, but 
it "SHOULD" support some kind of authentication. Clients, of course, 
end up having to support the spec'd ones as well as any popular 
alternatives (Kerberos, say). If we choose the promoted options 
carefully, then in practice most clients would be able to support them 
all, and most servers would be able to support at least one. Is there 
any reason to think that interop will be harder to achieve here than it 
is in SMTP auth?

My vote for the list would include "HTTP Digest" and "HTTP Basic Over 
TLS." This covers servers that can't support TLS, as well as those that 
can't handle a hashed password. Are there any other constituencies we 
should be thinking about?

Ezra