Fw: A review of Web Security Context's Scope and Use Cases -- Last Call

While it's after LC, a number of these are straightforward and desirable. 
Here is my proposal.

public-usable-authentication-request@w3.org wrote on 01/06/2008 10:53:12 
AM:

> <note
> class="inTransmittal>
> 
> Reviewed Document: Web Security Experience, Indicators and Trust: 
> Scope and Use Cases 
> Reviewed Document version URL:
> http://www.w3.org/TR/2007/WD-wsc-usecases-20071101/
> 
> Here are some comments that have received rough consensus support in
> the Protocols and Formats Working Group.
> 
> We realize that they are late but hope that you can still implement 
these
> changes in the 'Note' -status version.  We believe that these wording
> changes are clarifications, not changes in your intent.  We hope these
> changes will make your intent to develop a universally-designed solution
> clearer in a few spots.
> 
> There are also some spelling errors noted.
> 
> Al
> /chair, PFWG
> 
> </note>
> 
> Section 1 - General Comments
> 
> 1. Section 5.4 states: 
> 5.4 New security information
> 
> The Working Group will neither create nor extend any protocol or data
> format, nor create recommendations for protocols or data formats that
> are not yet widely deployed. Recommendations will only be made for
> the presentation of currently deployed security information.
> 
> Reviewer's Comments: We suggest the word "Protocol" be substituted
> with "network protocol", and the words "presentation of"
> 
> with "management of the user experience as it deals with", resulting in: 
 
> 
> The Working Group will neither create nor extend any network protocol
> or data format, nor create recommendations for protocols or data
> formats that are not yet widely deployed. Recommendations will only
> be made for the management of the user experience as it deals with
> currently deployed security information.
> 
> Rationale: 'presentation' is too narrow when including the case with AT
> such as screen readers in the loop.  As discussed and understood at
> the TPAC lunch.
> 

I believe that the substitution of "network protocol" mirrors the intent 
of the charter. I propose we accept this change. 

I'm less comfortable with the substitution of "management" for 
"presentation". I understand the accessibility concern, but where I come 
from, management tends to have administrative connotations. And 
"presentation" is actually in our charter. And it's consistent with the 
changes suggested below. I propose we stick with "presentation". 

> 2. Section 6.5 contains a table and a bulleted list.
> 
> Reviewer's Comments: This section should be restructured as it is
> very dificult to understand, when read with a screen reader. We would
> like to offer to work with you on a re-styling of this section. Not
> to make substantive changes, but to achieve better access.

If they had sent a change, I would have proposed to drop it in; better 
access is desirable. We've got a heartbeat requirement in 2 weeks, and I'd 
like to put usecases to bed as part of that. I propose we ask for 
something we can "drop in" by Jan 25. If we get it by then and can make it 
work, we take it. 

> 
> 3. A segment of Section 6.5 states:
> 
> Betty tries to connect to a web site at <
> https://www.example.com/
> >. Her user agent's SSL implementation detects that the domain name
> specified in the certificate differs from www.example.com
> . What should the user agent display?
> 
> Reviewer's Comments: We suggest the word "present" or "do" be used in 
the
> place of the word "display". Please note, we would like to propose
> this as an option and not as a requirement. 

I like "present", as it's consistent with the charter, and has better 
accessibility connotations. I propose we make the substitution with 
"present". 

> 
>  4. Again a segment of section 6.5 states:
> 
> Betty is planning a trip to a foreign country. Searching the web, 
> she finds a widely recommended local travel agency. When she 
> connects to their web site, her user agent does not recognize the 
> certificate authority that issued the travel agency's SSL server 
> certificate. What should the user agent display?
> 
> Reviewer's Comments: Once again, We suggest the word "present" or
> "do" be used in the place of the word "display". Please note, we
> would like to put forth this as an option and not as a requirement. 

ditto - I propose we use "present".

> 5. Section 10.2.11 states:
> 
> 10.2.11 Consistency
> 
> The cues should be displayed consistently in location and across 
> sites and web user agents in an attempt to prevent spoofing and 
userconfusion.
> 
> Reviewer's Comments: We suggest the word "displayed" be substituted 
> with "presented".
> 

I propose we use "presented". 

> 6. A segment of Section 10.4 states:
> 
> Automation of the tests will be considered but is unlikely, as the
> tests will require human visual confirmation. Clear descriptions of
> what to expect and how to judge outcome will be part of each test.
> 
> Reviewer's Comments: We suggest that the words "human visual
> confirmation" be replaced with "human confirmation" to make them more
> generic.

Seems a bit too vague to me. I propose "human sensory confirmation".

> 
> 7. Section 10.2.2 states: 
> 
> 10.2.2 Conceptual model
> 
> A user will develop a personal model of what something does and how
> it works. The user interface should present cues that assist the
> formation of this model and ensure that the actual and perceived
> state of the system are consistent [454][Design of Everyday Things].
> 
> Reviewer's Comments: We suggest the addition of the following to this 
passage:
> "Furthermore, the user should be encouraged to customize the look and
> feel of these queues to their own preferences, whereupon the browser
> will then insure that this same look and feel is not adopted by
> content. This will make spoofing significantly more difficult, thus
> enhancing security."

This is moving outside the reference, and outside the bounds of usecases, 
into xit. I propose that we do not make this change. This is part of xit, 
our recommendations. 

> 
> 8. Section 10.2.3 states:
> 10.2.3 Match between system and the real world
> 
> The system should speak the users' language, with words, phrases and
> concepts familiar to the user, rather than system-oriented terms.
> Follow real-world conventions, making information appear in a natural
> and logical order [456][Ten Usability Heuristics].
> 
> Reviewer's Comments: We suggest an edit of this passage to something
> similar to the following: 
> 
> The system should speak the users' language, with words, phrases text
> and foreground/background attributes, icons and sonicons, and other
> concepts familiar to, or customized by, the user...

This too goes outside the intention of the section, to reference specific 
existing usability expertise, into xit and recommendations. I realize how 
hard that is and look forward to similar engagement on xit. I propose we 
do not make this change. 

> 
> Section 2 - Spelling Mistakes

I propose we fix all spelling mistakes referenced here.


> 
> 1. Spelling mistake in the Abstract section:
> 
> The abstract states:
> 
> Since this Note discusses the assumptions, goals, and processes the
> group will use to develop its recommendations, the intended audience
> is similiar to that of the charter of the Working Group;...
> 
> Reviewer's comments: the word "similiar" seems to have been misspelt.
> 
> 2. Spelling mistake in Section 6.5:
> 
> While on the move, Alice suddenly remembers she has to make an urgent
> banking transaction. She has used her mobile browser previously for
> retrieving information from the web, but this time she decides to use
> her phone due to the urgency. She starts her mobile phone browser and
> enters a URL that she recalls having seen on her home desktop
> browser. After some delay, longer than usual, the phone starts
> showing a page. Due to screen size, Alice notices that the layout is
> somewhat familiar, but still not the same as the one in her dekstop.
> She can't see the full URL either. Alice scrolls and spots the link
> that takes her to the transaction page and clicks on it. After some
> delay, the phone displays a page asking her to enter her usual bank
> credentials. How is Alice to know that her bank credentials can be
> safely entered into the page?
> 
> Reviewer's Comments: The second occurrence of the word "desktop" is
> misspelt as "dekstop".
> 
> 3. Spelling mistake in Section 9.3.2:
> 
> 9.3.2 Hostname
> 
> DNS is a hierarchical name space. Name assignments on upper layers of
> this name space are controlled by various policy and business
> processes and often thought of as identifiers for real-world
> entities; name assignments on the lower layers are typically choosen
> freely and often thought of as identifiers for individual hosts or
> services. However, these intricacies are not widely understood.
> Studies show that users will interpret brand names that occur on any
> level of a domain name as a signal that allows them to assume some
> kind of reliable association between the brand and the domain name
> [Security Toolbars].
> 
> Reviewer's Comments: The word "chosen" is misspelt as "choosen".