Dealing with deciding about the SCE section in terms of June LC

We have only one section (with rfc2119 normative text) that we haven't 
made substantial progress on towards what (if anything) will be in the 
version that's ready for LC in June; the security confidence estimate 
section. 

Here is the current text:
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#page-score

The sense of the WG at the f2f was that something like SCE was desirable 
(some of us interpreted "something like SCE" to be anything between the 
current SCE text and the current padlock or SSL indicator practice). 

At next week's meeting, we're going to view proposals for (something like) 
SCE. We agreed that each proposal needs:
1) the RFC 2119 normative text
2) an (example) algorithm (if the existance is implied by #1)
3) a low fi prototype (anywhere from a picture representing a specific 
example, to a few pictures representing a few example states, or beyond). 
4) the point of the proposal (what are we trying to communicate to the 
user, or otherwise accomplish)

We don't usually have a web conf, so proposals need to be sent to the team 
by this Tuesday (11:59pm Hawaii time). That won't give everyone a chance 
to look them over; that's what we'll do in the meeting. I will be 
attempting to provide a web conf for this; I'll send connection 
information out on our members only list. 

It's not clear to me we have any proposal that covers all the required 
items (though I suspect only a slight amount of effort would produce one 
for the current text; as Martiza says, an hour or so of someone's time). 
As I've said several times, I want us to explicitly consider what (if 
anything) we have to say about currently SSL indicators. In that spirit, 
my proposal for (something like) SCE follows.

Title: TLS Indicator

[I'm using the current verson of xit as a reference. Items removed from 
that version for LC will also be removed from this proposal.]

1) normative text. 

Change 6.1.1 to refer to both Identity Signal and TLS indicator, for all 
normative text. Here's what it looks like when changed that way:
_______________________________
Web user agents MUST make information about the [[identity]] of the Web 
site that a user interacts with and the state of TLS protection available. 
The [Definition: [[identity signal]] ]  and [defn TLS indicator] SHOULD be 
part of primary user interface during usage modes which entail the 
presence of signalling to the user beyond only presenting page content. 
Otherwise, they MUST at least be available through secondary user 
interface. Note that there may be usage modes during which this 
requirement does not apply: For example, a Web browser which is 
interactively switched into a no-chrome, full-screen presentation mode 
need not preserve any security indicators in primary user interface.
User interactions to access this identity signal or the TLS indicator MUST 
be consistent across all Web interactions. This includes interactions 
during which the Web user agent has no trustworthy information about the 
[[identity]] of the Web site that a user interacts with, and when TLS has 
not been used to protect those interactions. In the former case, user 
agents SHOULD indicate that no information is available. In the latter 
case, they SHOULD indicate the interaction was not TLS protected. 
User agents with a visual user interface that make the identity signal and 
TLS indicator available in primary user interface SHOULD do so in a 
consistent visual position.
_______________________________

This is the part that has to change, since I don't remember what we 
decided with strong/weak. 

TLS Indicator

The TLS indicator MUST present a state this is only for strongly TLS 
protected pages. The TLS indicator SHOULD differentiate between a page 
that is  weakly TLS-protected, and one that has no TLS protection at all. 


2) I do not believe an algoriithm is needed for this, as I'm using 
definitions from xit. But let me know asap if one is. There is some 
fuzziness in the current definitions, since it allows for other, optional 
states that would map to weakly TLS protected besides weak crypto 
algorithms, use of DH_anon, and non validated certs. 

3) Here's the part that should inspire others, as I am seriously lame at 
lo fi prototyping. 



4) To communicate to a user who already understands something about TLS 
(that it provides protection against active on the wire attacks) and who 
is motivated to check for an indicator for whether or not TLS is doing so, 
whether or not TLS is in fact protecting against active on the wire 
attacks.