Re: [http-auth] [saag] re-call for IETF http-auth BoF

[Nico Williams <[e-mail]>]

On Mon, Jun 6, 2011 at 3:30 AM, Hannes Tschofenig
<[e-mail]> wrote:
> For me, the main questions are:
>
>  * What is the biggest problem?
>    You, for example, point to the usage of forms for user authentication in Web pages in the agenda proposal.
>    The NSTIC fans seem to believe that passwords are the problem to begin with.

You know from the workshop that my view is that web authentication
should be pluggable with respect to authentication mechanisms.

Passwords are a HUGE problem if you must type them at untrusted
entities.  (Such as: kiosks, hotel business center desktops, other
people's laptops, or even pretty much any computer, given the current
state of local security on user desktops and, soon, if not already,
mobiles.  But also: untrusted web page forms -- the fact that TLS
server certs are used, when they are, is not enough.)

>  * What solution approach is most promising? (or multiple approaches)
>     You seem to suggest to standardize a strong-password based authentication mechanism in http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05
>     NSTIC fans seem to believe that the approach is towards stronger credentials (non-password-based) and the usage of federated log-ins.
>     Again others believe that we will never agree on a single authentication protocol and hence we need a framework that allows passwords to be plugged in dynamically.
>     Browser vendors are interested, as you may recall from the Identity in the Browser discussion, in standardizing username/password form indications  so that the user does not need to type their username & password too often into forms - but the browser does it instead.

My proposal:

http://www.w3.org/2011/identity-ws/slides/Williams.pdf
http://www.ietf.org/id/draft-williams-rest-gss-00.txt
http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_16.pdf

>  * How do we motivate the different stakeholders to implement and deploy our favorite solutions? (There is also the usability issue for the user.)
>    Whatever you come up with changes are needed on the client, and on the server side. That requires a lot of cooperation.

I'm trying...  I'm looking for: people who will want to implement one
aspect or another of REST-GSS because it successfully addresses
immediate problems for them (this would be, mostly, non-browser
HTTP-based applications and the server side of those).  I'm also
trying other angles.

But my approaches may be all wrong.  So I too want to hear your
opinions on how to get momentum going.

One possibility is to build consensus in the IETF and push the W3C
from there.  I'm not sure that's wise.  I think the best approach, for
now, is to demo solutions.  Since all solutions pretty much require
new UIs (and JavaScript APIs) in the browsers, we need to start by
implementing demos in the browsers themselves, now.

Finally, the incipient JavaScript crypto APIs will be successful in
that they will be widely popular.  They will not solve the real
problems because either users will still be typing secrets at
untrusted interfaces (scripts used by untrusted pages) or because
there will be no simple way to control access to cryptographic
material in software or hardware tokens/smartcards.  But I'm afraid
that the appearance of success will be enough to staunch progress in
any other areas, so it may be a now-or-never situation for any
alternatives other than JavaScript crypto APIs.

Nico
--