Re: Comments to WSC UI guidelines ( LC-2199)

 Dear <Anna.Zhuang@nokia.com>,

The Web Security Context Working Group has reviewed the comments you sent
[1] on the Last Call Working Draft [2] of the Web Security Context: User
Interface Guidelines published on 26 Feb 2009. Thank you for having taken
the time to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-usable-authentication@w3.org if you agree with it or not before 22
May 2009. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Web Security Context Working Group,
Thomas Roessler
W3C Staff Contact

 1.
http://www.w3.org/mid/D1E1C1C072023846AC4A55088BAA4B03309A4EE0F3@NOK-EUMSG-04.mgdnok.nokia.com
 2. http://www.w3.org/TR/2009/WD-wsc-ui-20090226/


=====

Your comment on :
> Dear WSC WG,
> 
> Below please find some comments to the guidelines.
> 
> Best regards,
> Anna Zhuang
> 
> ************************************
> 
> *** Rich internet capabilities and advanced browser behaviour is not
> very well covered by the guidelines. E.g. the document does not seem to
> address well cases when AJAX application initiates background HTTPS
> connections.In particular how should UI behave when self-certified
> certificates (or other "bordercases") are present. Main issue here is
> that user might not understand what is going on at all, as connection is
> really AJAX "internal implementation" thing. So normal rules presented
> in the document seem to be a bit problematic.
> 
> *** There is no any mentioning of the following problem: If several WEB
> pages are visible, and any security question pops up, how should user
> know which page intiates it? Of course the document cannot dictate one
> and only way to solve this, but problem itself should be at least
> mentioned. Again, in connection to AJAX, this can be even more
> confusing.
> 
> *** Term mobile is not mentioned at all - nor the UI and interaction
> constraints that brings. Generally, the document gives an impression
> that mibile environment has neither been considered nor being addressed
> at the time of writing the guidelines. E.g. in cases of error/warning
> conditions the user has to interact (ok so far, but depends on what you
> define as error/warning). However, limited real-estate of a mobile
> device is not considered at all. If the guideline wants to define UI
> elements (how they should look),  the issue is that UI elements that
> work for the PC do not necessarily work for the handheld.
> 
> *** 3.4 Conformance claims: SSLv3 reference URL is broken. Related:
> should you reference something that is not a formal specification.
> 
> *** 5.3 Mixed Content: "A Web User Agent that can display an AA
> indicator MUST NOT display this indicator unless all elements of the
> page are loaded from servers presenting a validated certificate, over
> strongly TLS-protected interactions." Why is not AA level required for
> all content? There is a warning about this mixing in "8.6 Mixing
> Augmented Assurance and Validated Certificates" but it is still
> allowed.
> 
> *** 6.4.3 Danger Messages: "These interactions MUST be presented in a
> way that makes it impossible for the user go to or interact with the
> destination web site that caused the danger situation to occur, without
> first explicitly interacting with the Danger Message." Even if the user
> desides to ignore the message and proceed, the danger should continue to
> be indicated. This requirement is rather hard. It impacts the UI design
> and and overall user experience. The can not be MUST requirements for
> the UI. Such requirements may not be universally achievable.
> 
> *** It is difficult to read - the informative (introductions/overviews)
> and the normative (must/must not | shall/shall not) could/should be
> separated for readibility.
> 
> *** The document has strange format for definitions [Definition: xxxx]
> Oftenly the text between square brackets does not give a good definition
> for a term but rather appears as part of continuous presentation of some
> concept. At the same time the document does not have any glossary at
> all. The document will benefit from all definitions to be moved to the
> glossary.
> 
> *** Many terms in the document don't have any definition at all. Some
> terms that are unique to this document don't have sufficient explanation
> of justification for their introduction:
> 
> *** Section 4.2.1 introduces terms Primary and Secondary UI. Later in
> the document, e.g. in 6.1.1 I see Primary and Secondary chrome. Are they
> the same? I would say that chrome is part of the UI but Primary and
> Secondary chrome is neither introduced nor explained
> 
> *** Section 5.1.2 introduces Augmented Assurance Certificate. What
> Augmented assurance actually is is not explained. Also in this section
> the achronym AAC is introduced but later in the document AA is used. I
> kept wondering what AA certificate (as opposed to AAC) actually meant
> and checked the web. The search result gave me several usages of AA
> certificate and those have no connection to IT or security whatsoever.
> 
> *** The bottom of the Section 5.1.2 mentions additional assurance
> level. Augmented assursance itself is not explained and now we have
> additional assurance as a mere mentioning without any elaboration.
> 
> *** There are many terms for certificates and root certificates in this
> document and they are either not explained or insufficiently explained.
> Also their relationship is not at all clear. You have validated
> certificate, locally configured trust anchor, special trust anchor,
> domain validated certificate, custom root certificate, self signed
> certificate, untrusted root certificate, extended validation
> certificates and may be some more. All of these terms have to appear in
> the glossary that is currently missing and either referenced to some
> standards where they are sufficiently ecxplained or have to be explained
> in WSC UI guidelines.
> 
> *** Section 5.1.3 third paragraph mentions  certificate chains pinned
> to a destination but the term "pinning" is only introduces later in
> section 5.1.4.
> 
> *** What does "pinning" mean in practice, technically? The term is
> introduced in 5.1.4 but not sufficiently explained. Is this term unique
> to the guidelines or has it been used elsewhere? If former is the case,
> need to give more explanation about the process of pinning. If latter is
> the case, need to give reference to a standard that originally
> introduced this idea.
> 
> *** At the end of 5.2 in point 1 there appears a term "chryptographic
> material" but what it is is not explained anywhere.
> 
> *** What is AA indicator? (Found at the bottom of 5.3). Again it is not
> explained.
> 
> *** 5.4 has a lot of forward referencing to sections 6.4.2 and 6.4.3.
> This hints me that 5.4 is wrongly placed and perhaps should appear
> somewhere at the end of chapter 6.
> 
> *** 6.1.1 introduced "identity signal" by saying "identity signal
> should be part of primary user interface". This still does not explain
> what identity signal is.
> 
> *** Section 6.2 point 4 uses the term "identity information" is it the
> same as identity signal. Identity information is not explained. What
> forms identity information?
> 
> *** Section 7.3 starts with "when confronted with multiple modal
> interactions", then it talkes about miltiple browser windows being
> opened. Multi modality means a different thing and user response to
> multiple windows opened lays in the same modality.
> 
> *** 7.4 starts with "user agent" whereas 7.4.1 starts with "web user
> agent". The document has to be checked for consistence in used
> terminology. Also it may be the case that achronyms introduced earlier
> in the document are not at all used. In such a case achronyms need not
> be introduced at all.
> 
> *** In 7.4.1 the term security user interface is introduced but does
> not seem to be explained anywhere.
> 
> *** There is no clear (logical) link between use cases, threat analysis
> and the actual guidelines document. The guideline document merely
> mentions "the companions" Reading threat analysis and use cases before
> or after reading the guidelines does not help to get a good picture of
> which use cases/use case groups were addressed by the guideline
> document. There is a need for somewhat clear mapping of the use cases to
> the guidelines. Use cases would then better explain the guidelines.
> 
> *** The guideline document does not have any examples/UI examples
> whatsoever. Although it is understandable that the guidelines don't want
> to influence implementation in any way, it can be very hard to
> understand some requirements without any accompanying example being
> provided. Providing examples would also better address the different
> approaches that might be taken by the PC and mobile environments and
> also examples would better bring accessibility into the scope of WSC UI
> guidelines. Accessibility is mentioned in the use case document but is
> not articulated in WSC UI guidelines.
> 
> *** The current text revolves around requirements. However separating
> normative text from informative is a hard task partly due to the
> structure of the document and partly due to the lack of introductory
> explanatory text  preceeding requirements. Without examples,
> introductions and clear link to supported use cases this document is
> hard to read for its prime audience: UI and user experience experts.


Working Group Resolution (LC-2199):
Thank you for your excellent review. 

We are looking at additional information on AJAX, if it is covered by
current best practices, which is the target of this specification, under
ISSUE-225 
<http://www.w3.org/2006/WSC/track/issues/225>
We have also augmented our security considerations section on this topic
<http://www.w3.org/2006/WSC/track/actions/579>

Current best practice is not consistent on the topic of pop ups if several
web pages are visible. 

We extensively discussed mobile in the working group. References to smart
phones and minimal chrome modes reflect the results of those discussions.

We have fixed the SSLv3 reference.

AA is only the root since it is vouching for everything it controls. See
discussion at
<http://www.w3.org/2008/05/13-wsc-minutes.html#item11>

6.4.3 The MUST scopes the need for the user to interact with the message
in the case of verifiable danger. Additional text attempts to make this
clear
<http://www.w3.org/2006/WSC/track/actions/573>

We now have a list of terms in the document 
<http://www.w3.org/2006/WSC/track/actions/576>

4.2.1 comment - we will make that more consistent
<http://www.w3.org/2006/WSC/track/actions/577>

We have cleaned up AA and AAC terminology
<http://www.w3.org/2006/WSC/track/actions/578>

5.1.2 cleaned up
<http://www.w3.org/2006/WSC/track/actions/580>

We have clarified "pinning"
<http://www.w3.org/2006/WSC/track/actions/581>

5.2 - have clarified
<http://www.w3.org/2006/WSC/track/actions/584>

We will clarify "identity signal"
<http://www.w3.org/2006/WSC/track/actions/586>

We will clarify 6.2
<http://www.w3.org/2006/WSC/track/actions/587>

We will clarify 7.3
<http://www.w3.org/2006/WSC/track/actions/588>

We will clarify "user agent"
<http://www.w3.org/2006/WSC/track/actions/589>

7.4.1 will be clarified
<http://www.w3.org/2006/WSC/track/actions/590>

We are clarifying the relationship between our documents.
<http://www.w3.org/2006/WSC/track/issues/226>

The implementation reports during CR will reference existing browser
behavior which will provide examples of current best practice.





----

Received on Friday, 15 May 2009 12:53:56 UTC