W3C home > Mailing lists > Public > public-usable-authentication@w3.org > January 2009

Re: [LC Comment on Web Security Context: User Interface Guidelines] Missing an audience section? ( LC-2095)

From: Francois Daoust <fd@w3.org>
Date: Mon, 12 Jan 2009 09:06:57 +0100
Message-ID: <496AFA21.3040806@w3.org>
To: mzurko@us.ibm.com
CC: public-usable-authentication@w3.org


I agree with the group's decision.


mzurko@us.ibm.com wrote:
>  Dear Francois Daoust ,
> 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 24 Jul 2008. 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 26
> January 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/48CA9D24.6050201@w3.org
>  2. http://www.w3.org/TR/2008/WD-wsc-ui-20080724/
> =====
> Your comment on :
>> Hi,
>> I stumbled upon several obscure terms and sentences while reading the 
>> spec (see list below). The terms are not defined. As far as I can tell,
>> they are all basic terms when one is used to dealing with security on 
>> the Web.
>> Even though it contains "Security", the title looks friendly, and 
>> doesn't seem to infer that a technical background on security is 
>> required. Since there is no audience section, I expect I'm reasonably 
>> well-versed into Web matters to understand the spec. That is not the 
>> case: I understand the clauses, which is good, but I sometimes fail to
>> understand the rationale behind them.
>> Depending on the audience you are targeting, you may not want to define
>> these terms in the spec. That is the gist of this comment: the audience
>> is not defined. If your primary target is security experts, no need to
>> read the following list. If your primary target is user interface 
>> developers, you should clarify them. In any case, you should probably 
>> mention it and precise the expected knowledge before reading the spec
>> so 
>> that readers know what to expect beforehand.
>> Here is the list of security-related topics that are not so common for
>> other communities (well, "for me" at least, that is ;)):
>> - Section 5: The "TLS" acronym is actually never defined (only
>> mentioned 
>> in the references part).
>> - Section 5.1.5: "use of TLS provides confidentiality protection 
>> services against passive attackers". What is a "passive attacker"?
>> - Section 5.1.5: "this can be strong evidence that protection against
>> an 
>> active attacker has been achieved as well". What is an "active
>> attacker"?
>> - Section 5.1.5: "evidence that a man in the middle attack occurs". For
>> once, I know what a "man in the middle attack" refers to, but I'm not 
>> sure everyone does.
>> - Section 5.2: "for both confidentiality and integrity protection". I 
>> get the difference but that may be worth a little explanation as well.
>> - Section 7.1.1: same thing with "phishing" and "spoofing" although 
>> probably known by more people.
>> - Section 8.2: "OCSP" stands for?
>> As a side note, I am totally fine with the relative complexity created
>> by the multiple definitions the spec already contains. Precision is
>> good!
>> Thanks,
>> Francois Daoust,
>> W3C Staff Contact,
>> Mobile Web Best Practices Working Group.
> Working Group Resolution (LC-2095):
> Thank you. We've added a reference to OCSP. The TLSv11 reference defines
> TLS in this context. We will not be putting additional details of those
> protocols in our spec. We hope the reader will either be familiar with
> them, or follow up with the references or generic web searches of the
> concepts. 
> ----
Received on Monday, 12 January 2009 08:07:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:16 UTC