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

Re: [fwd] Re: Web Security Context: User Interface Guidelines (from: timeless@gmail.com) ( LC-2058)

From: <mzurko@us.ibm.com>
Date: Fri, 09 Jan 2009 20:03:03 +0000
To: timeless <timeless@gmail.com>
Cc: public-usable-authentication@w3.org,timeless@gmail.com
Message-Id: <E1LLNZP-0000Fk-J0@farnsworth.w3.org>


 Dear timeless ,

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/20080806163050.GX4194@iCoaster.does-not-exist.org
 2. http://www.w3.org/TR/2008/WD-wsc-ui-20080724/


=====

Your comment on :
> http://www.w3.org/TR/2008/WD-wsc-ui-20080724/
> 
> > user agents, such as plugins, extensions, and others; they are
> summarily called
> > plug-ins, extensions, call outs to external systems which render
> particular document
> 
> plugins/plug-ins (English favors the latter, coders are lazy and use
> the former, please pick one :))
> 
> > behavior might be determined by scripting, stylesheets, and other
> mechanisms.
> 
> and => or
> 
> > anchor is authoritative. Relying parties use trust anchors to
> determine if digitally
> 
> is "Relying parties" a _defined_ term? it seems awkward otherwise....
> 
> > Trust anchor installation is typically handled by Web user agent
> vendors ,systems
> 
> the , is on the wrong side of the space
> 
> > trust anchor update is therefore often handled as part of Web user
> agent or operating system software update.
> 
> update => updates
> 
> > for a single session, sometimes for all future sessions involving
> that certificate.
> 
> Firefox 3 ties a certificate to a host+port.
> 
> > some process that adheres to the requirements of an augmented
> asurance specification
> 
> assurance
> 
> > user agents MUST NOT consider the certificate as an augmented
> assurance certificate,
> 
> is there some reason not to write AAC or Augmented Assurance
> Certificate?
> 
> > [Definition: An HTTP transaction is strongly TLS-protected if it is
> TLS-protected, an https URL was used, strong TLS algorithms were
> negotiated for both confidentiality and integrity protection, and one
> of the following conditions are true:]
> 
> the transaction is not the result of a transaction which is not
> strongly TLS-protected.
> 
> > warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger
> Messages) MUST be used.
> 
>  above? you're in 5.4.2...
> I think you mean "higher" or "greater". Above in a document to me
> means printed document order (closer to top) and not some more
> abstract thing.
> 
> > 5.4.3 Redirection chains
> 
> > a user agent such as a smart phone, air plane seatback or TV set
> which has a usage
> 
> individual LCD screens on airplanes
> 
> >       Subject logotypes derived from certificates SHOULD NOT be
> rendered, unless the certificate used is an augmented assurance
> certificate.
> 
> why is this a should not instead of a must not?
> 
> (i ran out of energy and am sending this now, hopefully it's useful)


Working Group Resolution (LC-2058):
Thank you. The proposed editorial changes have been accepted and made in
the current editor's draft, with a few exceptions:

- "relying party" is a common term of art, so we do not need to define it
here

- concerning "for a single session", added the following in the end of
that sentence: "...	sometimes for all future sessions involving that
certificate, possibly scoped to specific host and port combinations."

- concerning "the transaction is not the result of a transaction which is
not strongly TLS-protected": The text contains the definition of that very
term; it's not clear what additional changes your comment aims at.

- concerning the airplane example: changed to "individual entertainment
screen in an airplane seatback"

- Concerning the SHOULD vs MUST question about logotypes, we'll respond to
that one separately, and it is being tracked as a separate issue.

----
Received on Friday, 9 January 2009 20:03:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:15 GMT