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.
How would a standard here relate to either the Microsoft CardSpace/WS-* work, or the IBM sponsored Higgins work, both of which at least have the goal of solving 1-4, with an emphasis on 3.
I think that there would be a very high probability of Cardspace/higgins interest. The groups are looking at the problem from different angles though. In Cardspace/Higgins the starting point is that there is a blank sheet of paper and there is complete freedom of design.
Unless you are Microsoft or IBM (or Microsoft AND IBM) proposing to do that is more or less delusional. The Identity 2.0 proposals are more organic.
That does not mean that the two cannot co-exist and make useful contributions to each other. I would like the low-infrastructure impact proposals to provide the on-ramp for eventual deployment of strong schemes.
That is why I disagree about the utility of the initial discussion. The important point was that we agreed that we could all use the existing terminology and not start inventing a new one as some have attempted to do. That makes it much more likely that the on-ramp we build will actually meet the highway under construction rather than lead to a new highway that has not been built.