While the Atom Publishing Protocol leaves implementations free to use whatever method of authentication they please, historical circumstances have associated the Protocol with an obscure authentication method that has neither a name nor a specification.

I refer of course to the method described in this article. I hesitate to call the method Atom Authentication (because that suggests a closer association with the Protocol than exists), but I can’t come up with anything better.

The idea is sound - it functions as designed and has a few advantages over Digest authentication (mostly for people stuck with crappy hosts). The algorithm is well described in WS-Security’s UsernameToken profile (which “Atom Authentication” is based on). The general form of the challenge and response are described in the Mark Pilgrim article.

But common practice and the article have diverged. While the article (and Sam Ruby) produces an ASCII nonce and sticks it straight in the X-WSSE header, all the client code I’ve seen base64s the nonce before it goes in the header, and servers seem to require it. I can’t find this specified anywhere.

This sucks. Don’t use “Atom Authentication” unless you absolutely must, and if you absolutely must please write a proper spec first.

Back in 2003 there was a lot of buzz surrounding the (then new) Atom syndication format and its sister, the Atom API. Mark Pilgrim published an article about the API on XML.com, it was implemented in some high-profile applications (including Blogger and TypePad) and it generally wormed its way into people’s brains.

Shortly afterward its name was changed to the Atom Publishing Protocol, erasing all that lovely brand recognition. Since then, the specifics of the Protocol have changed significantly. Most notably, the API is based on a draft version of the Atom format (now deprecated), while the Protocol is based on Atom 1.0. The two formats are just different enough to cause problems (barring extremely lenient software).

The similarity of the two names and the plethora of existing material about the API (Google turns up twice as many results for “atom api” as for “atom publishing protocol”) are already confusing people. The Protocol will be an RFC any day now*, and it won’t be good for anyone if implementors are looking at the wrong specs and users at the wrong clients.

I’ve seen this mistake made several times recently (1, 2); let’s try to end the confusion.

* I’ve been saying that for months.