ACTION-545: Put together "rearranged" document for review

I suggested reordering the sections of wsc-ui in my response to  
action-531 (Ian's comment about readability for UI readers).

I'm suggesting the following as the new table of contents. Notice that  
the current section numbers remain, hopefully that helps readability  
rather than hurting it ...


1 Overview

(I suggested combining sections 3 and 4. Mez pointed out there might  
be a standards reason for the current organization).

3 Conformance
     3.1 Product classes
     3.2 Language conventions
     3.3 Conformance levels
     3.4 Conformance claims
4 Interaction and content model
     4.1 Overview
     4.2 Terms and definitions
         4.2.1 Common User Interface elements

7 Robustness
     7.1 Chrome and User Interface Practices
         7.1.1 Use Shared Secrets to Establish a Trusted Path
         7.1.2 Keep Security Chrome Visible
     7.2 Do not mix content and security indicators
     7.3 Managing User Attention
     7.4 APIs Exposed To Web Content
         7.4.1 Obscuring or disabling Security User Interfaces
         7.4.2 Software Installation
         7.4.3 Bookmarking APIs
         7.4.4 Pop-up Window APIs

6.4 Error handling and signalling
         6.4.1 Common Error Interaction Requirements
         6.4.2 Notifications and Status Indicators
         6.4.3 Warning/Caution Messages
         6.4.4 Danger Messages

6 Indicators and Interactions
     6.1 Identity and Trust Anchor Signalling
         6.1.1 Identity Signal
         6.1.2 Identity Signal Content
     6.2 Additional Security Context Information
     6.3 TLS indicator
     6.5 Chrome Reconfiguration

8 Security Considerations
     8.1 Active attacks during initial TLS interactions
     8.2 Certificate Status Checking Failures
     8.3 Certificates assure identity, not security
     8.4 Binding "human readable" names to domain names
     8.5 Warning Fatigue
     8.6 Mixing Augmented Assurance and Validated Certificates

5 Applying TLS to the Web
     5.1 Certificate Handling and Information
         5.1.1 Interactively accepting trust anchors or certificates
         5.1.2 Augmented Assurance Certificates
         5.1.3 Validated Certificates
         5.1.4 Logotype Certificates
         5.1.5 Self-signed Certificates and Untrusted Root Certificates
         5.1.6 Petnames
     5.2 Types of TLS
     5.3 Mixed Content
     5.4 Error conditions
         5.4.1 TLS errors
         5.4.2 Error Conditions based on Third Party or Heuristic  
Information
         5.4.3 Redirection chains
         5.4.4 Insecure form submission

2 Acknowledgments
9 References



If anyone's interested in the justifications for the changes this is  
copy/pasted from the action-531 email:

> The sections should be reordered to present the more general UI  
> advice first. Section 5 addresses the application of a specific  
> technology and it's presented as the first section of content. We  
> have a lot to say about TLS, but I think it should be more toward  
> the end of the document because it's so specific. We should also  
> consider adding an intro paragraph to 5 about why it's the most  
> worked example.
>
> Section 7 is has the most general UI advice and should be the first  
> section of content after the overview and scoping/definitions. We  
> should follow it up with is separate section for communicating error  
> messages (error handling and signalling). That's one of our stronger  
> sections and we should highlight its importance for the design of  
> future interactions/interfaces. The remainder of the current section  
> 6 should follow.
>
> Section 8's name is too general. I think we're presenting this  
> information as security lessons learned from  the mistakes/ 
> oversights of others. We don't have concrete advice on how/when each  
> of them will come up but we want people to be aware of these issues  
> when they're designing security indicators. I don't have a great  
> suggestion for a new name but the entire document is asking them to  
> consider security, so this name doesn't feel precise enough. Maybe -  
> "Additional Security Threats to Consider".
>
> We should combine sections 3 and 4, both sections contain  
> definitions that relate to the document as a whole and tell the  
> reader what the document is focused on.
>
> The section could look something like:
> Working Definitions and Assumptions
> 	- Document Scope
> 		- Product Classes (3.1)
> 		- Interaction Model (most of 4.1)
> 		- Content (rest of 4.1)
> 	- Terms and Definitions (4.2)
> 		- Common UI Elements
> 	- Language Conventions
> 	- Levels of Conformance
> 	- Claiming Conformance




-- Maritza

	http://www.cs.columbia.edu/~maritzaj/