Suggested document structure (Re: Recommendations Draft)

On 2007-06-08 16:28:53 -0400, Mary Ellen Zurko wrote:

> 1. Primary Security Context Indicators

> Proposals centering on what is displayed as SCI (and not) would
> go here.  Site identifying images in chrome, "what is a secure
> page" (when it gets put into template form - Yngve, have you done
> that yet?), secure internet letterhead, TrustMe,
> UrlRecommendation, IdentitySignal - recommendations, good
> practices, and antipatterns around the SCI that appear without
> user interaction, in the normal task flow, would appear here. 

Scanning through the proposals, and trying to organize the material,
I'm very tempted to move at least 90% of Yngve's material into a
distinct chapter that essentially profiles TLS for web use, and
serves as a normative definition for a "TLS-secured Web page."  A
normative reference to one of the specifications listed at [1] could
serve to deal with the keylength issue that came up repeatedly.

(I'm not sure which of the recommendations listed there is best as a
stable reference.  The problem with RFC 3766 is that it's 3 years
old... Stephen, Phill, Bill, any input?)

1. http://www.keylength.com

That term can then be referenced by other requirements and sections
that deal with how to tell users about such TLS-secured Web Pages,
or when not to assume that something happened securely.

> 2. Secondary Security Context Indicators

> Proposals centering around other forms of SCI - security protocol
> error presentation, page info summary, EV certs (I think), maybe
> parts of IdentitySignal (is hoverover primary or secondary?),
> revisiting past decisions would go here. 

I'm wondering if it's yet clear to what extent we will, e.g.,
propose that errors be primary or secondary SCIs (e.g., an active
error page vs. a foot note in a page info dialogue).  That might
indeed be different for different error conditions.

I'm therefore tempted to re-organize away from at least the
"primary" and "secondary" indicators, and just stick to "indicators"
in the first place.

> 3. SCI Robustness
> 
> Techniques to make the SCI (and chrome) robust against attacks
> (including spoofing). Trusted browser component (including the
> personalization aspect), and all the discussions of robustness
> we've had from the various browsers would go here. 
> 
> 4. Minimizing Trust Decisions 
> 
> Techniques to do away with some of the trust decisions users need
> to make today. PIIEditorBar, SBM, maybe browser lock down (I
> haven't read it yet) 

Overall, we might be able to make that structure work, BUT...  I
think the following might be much better to organize the different
proposals.

This includes deviating from the wiki template where it simply
doesn't make sense; I think we have by now learned that a number of
proposals don't fit in there very well.

So, here's my current outline:


- Overview

- Conformance (normative)

  * conformance model (more complex than now, since the current
    template doesn't fit some proposals very well)

  * conformance labels
    (markety buzzwords to describe specific combinations of
    requirements)

- Concepts and definitions

  * interaction and content model (informational)

  * terms (normative): user, web user agent, Web page (copy from
    WCAG 2 glossary; might change into normative reference)

- Applying TLS to Web Content (normative)

  * "What is a secure page"; mixed content (Yngve's material)

  * reference the EV OID (Phill's material)
  
  * reference the NoSecurityIndicator OID

  * self-signed certificates (much of Stephen's and my material,
    phrased as definitions)

  * key lengths
  
  * change of security level

    + change of trust anchor
    + change of crypto
    + what else?
    
    -> this might feed into error signalling below

- Indicators and Interactions (normative)
  
  * Identity and Trust Anchor Signalling
  
    (IdentitySignal meets EV meets SecureLetterhead meets
    self-signed meets RecRevisiting PastDecisions -- this is
    probably where the bulk of material will go)

  * Error Signalling

    + abstract practices

    + concrete handling of certificate errors that aren't covered
      above
      
    + what conditions should lead to a hard stop in the user's
      interaction?
      
    (I could see some of SBM, some of Tyler's material, some of Mike
    McCormick's material, and the various failure conditions for TLS
    go here.)

- Ceremonies for Secure Data Entry (normative)

  * Secure attention sequence to cause lock-down (SBM)
  
  * PII Editor Bar (or something like it)
  
  * TrustedBrowserComponent?

- Robustness

  * no favicons in the location bar, please

  * restrictions on scripting; that's not yet done, and I believe it
    to be in MEZ's and Johnath's field

- Authoring and deployment best practices

  * use TLS for login pages

  * don't use security indicators in content, since that confuses
    people

  * don't teach people to trust what they shouldn't trust

The main mis-fit for this structure is Tim Hahn's BrowserLockDown
proposal; I'm not sure where to put it, and there might be a scope
issue to it.  We might wish to clarify that.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 28 July 2007 20:50:33 UTC