RE: Problems with the current user interface

> I'm going to push on this some more, because I think we're giving up on
> one of the few sources of reliable security context information that we
> actually have.

Browser password management is not information about the security context 
of a web server, with the exception of what you point out below. 

> "Anything that's about managing the password for the user" seems far to
> broad to me. Our use cases, such as the Email Lure use case, culminate
> in the collection of the user's username/password by the phishing site.
> The password collection is what we're trying to prevent. 

No, it is not our charter to prevent password collection. If it were, I 
would not expect new protocols to be out of scope. It is absolutely one of 
the attacks that motivates our charter. But we should not confuse the 
natural desire to prevent a particular attack with our work here, which 
will either prevent or assist in preventing attacks. 

> In addition to this pragmatic argument, I also have some definition
> based arguments:

I will insert a bit on my pragmatic reasons for restricting us as closely 
as possible to our charter (which I believe to be a good, useful, and 
important charter, and wholely sufficient for exciting and important work 
worthy of this team, which I'm quite impressed with). 

We're doing standards work (in part) on usability. That's ground breaking 
all alone (as far as I know; I'd be delighted to learn from any previous 
examples). On top of that it's usable security, which you well know is 
less far along as a discipline than usability in general. In addition, 
this is not an "old style" standards group with specific, concrete 
technology that's got deployment experience we want to standardize around. 
It's not even a "new style" standards group with a going-in specification, 
even one that will be chucked out. There's research, but that's not the 
same. I'm certain we're up to the job, but I do see that we have a number 
of challenges, some traditional and some special, and I want to ensure we 
succeed. We will not in fact hit our marks totally for our first 
milestone. We were to have had public drafts of the Note and 
Recommendations by January. We don't have editor(s) yet for the 
Recommendations, but I expect us to have a good solid draft of the Note by 
our next f2f. Not hitting our marks (yet) is an indicator that we need to 
be cautious about extending ourselves beyond our charter. 

> 1. A user password is a client authentication credential. Why is a
> client authentication credential not web "security context information"?
> If the client's authentication credentials are out of scope, why are the
> server's authentication credentials in scope, meaning the server's X.509
> certificate?

Information about the server, such as the server's x.509 certificate, is 
security context information on which users may base trust decisions, 
because it's about the server. The user's password is not about the 
server, except in the limited and accurate case you point out....

> 
> 2. We've already declared historical browsing information as in scope.
> Why are the user's accumulated authentication credentials not historical
> browsing information?

To the extent they are historical browsing information, then they are in 
scope (data you've sent to the server before).

        Mez