Re: What problems are we trying to solve?

> I understand that the goal it to specify how security-context
> information could be presentated in such a way as to make it
> useful for users in making trust decisions, but I think we ought
> to consider giving some higher-level explanation of what specific
> problems that will solve for users (and for Web content providers).
> 
> For example, will it help to prevent users from becoming victims
> of phishing attacks? And will it help content providers in some way?

Some of this has to be in the Note. Some of it will be iterative, based on 
the use case scenarios and foundational principles (which we need to get 
to first to start the iteration). But some of it we should start drafting 
up front, as part of the Note. 

Listing the specific problems we're solving as if that list were inclusive 
wouldn't work, since it would be a specific set of attacks, and what we do 
should be useful and effective in both unknown attack scenarios and 
non-attack use (as well as existing attacks on the user processor, often 
call social engineering). Listing some categories of current 
problems/attacks would be useful though. 

The general idea is that our work would preclude a number of spoofs, 
scams, and other social engineering attacks that rely on making the user 
believe something inaccurate about the identity or other security aspects 
of the server they're talking to. Phishing and its variants often 
(always?) rely on that. It would also usefully inform and assure the user 
when they are talking to the server they expect they are (when that server 
produces appropriate security context and the user agent follows our 
recommendations). 

On a related note, here's an initial list of in/out of scope things for 
this WG I put together to clarify early discussions I had with people. The 
in scope things look pretty obvious after the f2f (they were meant to 
clarify the charter). 

Within the scope of the WG:

web user agents (browser and rich) 
user agents that display security context information about a web session
Security context information (data or meta data) from web protocols (http, 
https, SOAP) about the putative server that the user agent or user can 
directly authenticate or has reason to trust 
security context information about the server from the web protocol
security context information about the server or URL from the user agent 
displaying the information (such as historical information) 
security context information about the server from some other source (PKI) 
 integrated into the user agent displaying the information 
usable display of the information (including simple error information) 
best practices for existing web user agent/protocol use cases 
general lessons learned, philosophy, techniques, or recommendations that 
can be used in the future 
techniques that render the display of security information more robust in 
the face of spoofing attacks

Out of scope:

non-web user agents
email-specific processing
non-web protocols (ftp, smtp, pop3)
calculations, algorithms, and functions that attempt to determine whether 
or not an attack is underway 
best practices for future looking web user agent/protocol use cases (the 
WG will use scenarios based on existing user agents, protocols, and 
security context) 
code based techniques to detect spoofing attacks
techniques to stop the user from taking an action because an attack has 
been discovered 
new protocol-level security features 
security context information that is inherently meaningless to the end 
user