Phil pointed me to a WG draft he put together as input to the HTTP Working Group - "HTTP Authentication Considerations". In section 2, he points out that authentication has several parts:
- credential presentation, and
- message (aka session) authentication.
The term 'authentication' tends to cause confusion due to the fact that there are actually three separate activities that it can refer to. When Alice establishes an account at a Web site, the site may verify her email address is correct. When Alice presents her username and password, the site verifies the data and if correct issues a HTTP cookie. When Alice re-visits the same Web site to make further requests, the cookie is verified each time. Each of these verifications is a form of authentication but they are totally different in character and only the last of these is a form of authentication that is directly related to HTTP.
Attempts have been made to distinguish between these as 'initial authentication' and 're-authentication' but this also creates confusion as some people consider the first contact with the user as the 'initial' authentication and others consider that to be the start of a Web session.I have seen a lot of confusion about the purpose of access tokens in OAuth. Some feel that there should be strong authentication with every HTTP requests. But when you look at it how Phil lays it out, it's clear that the job of message authentication is simply to maintain session state across multiple HTTP requests. It has very different requirements from credential presentation.
Phil also has some interesting commentary on some of the problems with passwords like promiscuity, recovery, phishing, and lock-in issues. Many of us have for some time been on a rant about killing the password - but Phil talks plainly about what 'passwords get right'.
This is a great read.