BOF Report: WAE

BACKGROUND [cribbed from previous postings] 
HTTP has two native authentication mechanisms, Basic Authentication
(passwords in the clear in an HTTP header) and Digest Authentication
(a challenge-response handshake also in the HTTP header). Both
mechanisms depend on the client proving the possession of a shared
secret string (a password in all real cases) to the server. The server
is unauthenticated.

For a variety of reasons, including bad UI on the clients, nearly all
real-world Web applications use neither mechanism but rather use an
HTML form to prompt the user for his password. This password is then
sent in the clear over the HTTP connection.  The standard security
advice for how to secure this data is to use HTTPS (HTTP over SSL/TLS)
to encrypt the entire channel and use the server's certificate to
authenticate the server.  Practical difficulties with checking the
certificate have led to phishing attacks, in which the attacker
gathers the user's password and can then impersonate the user. An
additional problem is that it's hard for Web Services apps (e.g., DAV)
to use this kind of mechanism because HTML may not be involved and so
if it works at all you end up resorting to screen-scraping.

In principle, if you run HTTPS, you can leverage HTTPS's client
authentication mechanisms (client certificates and "pre-shared keys")
to authenticate the client, but in practice this is not done, probably
due to UI reasons and lack of familiarity with the TLS mechanisms
(this applies in particular to PSK).


PROBLEMS PEOPLE ARE TRYING TO SOLVE
Roughly speaking, people seem to be trying to solve three problems:

1. A phishing-resistant authentication mechanism.
2. "Single-signon" mechanisms which let you authenticate to
   multiple services with a single act.
3. A mechanism to let you prove facts about yourself to 
   some service providing party. E.g., I'm over 21.

You can find a long discussion/taxonomy about this here:
http://www.educatedguesswork.org/movabletype/archives/2006/06/notes_on_web_au.html


BOF REPORT
Agenda:
1. There was a modestly long and not-very-productive discussion of
   terminology which sort of led to not much. 

2. Discussion of a bunch of potential problems we might want to
   solve based on the taxonomy at the above link. This resulted
   in adding a few. No real attempt was made to decide which
   were in and out of scope.

3. Sam Hartman's presentation on Webauth and Phishing Requirements

   http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-01.txt

   I nitpicked on this a little bit, claiming that mutual authentication
   might or might not be required.
   
4. An attempt to focus on different complexes of things that people are
   trying to solve.

   The eventual list ended up as follows:

1: Fix HTTP authentication, with at least attention to the
   phishing issue.
2: Cross-site authentication (authenticate to site X and then
   leverage that to authentication to site Y).
3. Ability to have a third party assert claims about you to
   relying parties.
4. "Eliot's Dad's problem". Be able to have a single small
   set of credentials that you can use to authenticate to
   a lot of sites.

There seemed to me to be enthusiasm for working on 1,2, and 4
and fear that 3 was too complicated. 

The notion here isn't to form a new WG out of this. Rather, it's
to figure out what kind of BOFs to charter. IMO, none of this
is ready for charter as-is.