[Ietf-http-auth] Alignment of draft-hartman-webauth-phishing with W3C draft on user interface guidelines for usable authentication

[Sam Hartman <[e-mail]>]

As people here are probably aware, the W3C is last calling a draft on
user interface guidelines for web security context.  Please read
http://www.w3.org/TR/2008/WD-wsc-ui-20080724/ .

It seems like a really good document.  However I don't think it
obsoletes draft-hartman-webauth-phishing.  The W3 document is focused
on helping users get the indications they need for TLS to be useful
with today's authentication mechanisms.  My draft is focused on
requirements for authentication mechanisms that will reduce the impact
of mistakes.  If you believe that the W3C recommendations will be so
good that people will never be spoofed with a user agent that
implements them, then my draft is probably unnecessary.  I don't think
anyone--especially not the participants in the W3C security context
working group--believes that.  Instead, I believe we are all working
on a layered approach to security, trying to increase the probability
that when someone attempts to commit fraud, some mechanism somewhere
will detect that with high enough confidence that the user agent can
positively flag the situation.  It is critical that we do not generate
so many false positives that users lose confidence in fraud signals
when they do happen.

As such, I believe that new authentication mechanisms, security
context usability improvements, reputation systems and lists of known
frauds can all work together in improving web security.

It turns out that my draft is reasonably aligned with the W3C draft:

* They focus on creating situations where the user agent can raise a
  danger signal--interrupting the user's task and indicating that with
  high confidence something is risking the user's information.  My draft tries to create situations where the same signal can be raised by the authentication mechanism.

* The W3C draft recommends establishing trust in the UI via shared
  secrets.  They note that these mechanisms have questionable
  effectiveness.  I should note we're taking the same approach and
  continue my plan of accurately describing the limitations of this
  mechanism.

* The W3C draft seems consistent with the idea that making security
  context relevant to the transaction that the user is actually
  performing may help.

So, I propose to:

* Add a discussion of how these technologies can work together to the front.

* Add references from the discussion of trusted UI to the appropriate sections from the W3C draft.

In addition I will continue my plan to:

* Go through the document and clean up areas where the claims are stronger than is justified.

* Address Eric's comments about why we exclude mechanisms like pwdhash.

* Clean up and prepare for a discussion here and on the list.

I made some improvements before Dublin but other work got in the way
and I did not finish.  I expect to get to a version I think is ready
for discussion here within a couple of weeks.