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.