reviewing our Note,

 
Section 3.2
3.2 Non-HTTP Web interactions 
 
I am trying to come to grips with how a secure HTTP(s) session
interacts with other applications/protocols within the bounds of our
charter.  If the user is presented with information that the browser
session is secure, but security only exists until the HTTP(s) data is
handed off to something like an insecure SIP session is the user given
a false impression on the amount of security that they have. 
 
Other protocols are out of scope but can we provide some architecture
guidance or other guidance that security presented to the user must be
provided by all software services at a level that is consistent with
the security context that is presented to the user. 
 
Bill D.
 



________________________________

	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Mary Ellen Zurko
	Sent: Friday, March 02, 2007 2:13 PM
	To: public-wsc-wg@w3.org
	Subject: reviewing our Note, part 2
	
	

	I've done a better run through the wiki to find contributors to
the Note. In addition to the text below for the Acknowledgements,
include Bill Doyle, Maritza Johnson, Phill Hallam-Baker, Hal Lockhart
and Brad Porter. Again, if I've missed anyone, let me know. (you people
are way too modest)
	
	7.6 is missing passwords submitted via basic authentication
(since that doesn't use a form). I propose adding "submitted passwords"
as the first or second bullet item. 
	
	9.1.2 should mention color blindness. I propose adding the
following to the end of the first paragraph - "In addition, color only
cues often do not work for users who are color blind." Does anyone know
if there are any standards that point that out? For instance, do
accessibility standards mention that? 
	
	9.2.3 might be a little subtle for folks who haven't been in
our discussions. Or maybe it's even too subtle for me. At least part of
what I think it should be talking about is that the URL also represents
choices made by the site/service. That's not always the creator of the
referring hyperlink, though perhaps it always is when its an attack
(not when it's search results?). I propose changing the first sentence
to "The current web page's URL is chosen in tandem by the creator of
the referring hyperlink and the owner of the web site." I further
propose adding to the end of the second paragraph " While the hostname
has to be registered and cannot be directly redundant with existing
hostnames, there are a number of tricks that can be played to make
hostnames look like something that will fool users. See the Hostname
section for additional discussion." 
	
	9.2.4 - sites can also redirect to an ssl protected url. I
propose adding the following: "The web site itself can also choose to
redirect access to an SSL protected URL." 
	
	10.1.11 - I propose substituting "web user agents" for
"browsers". 
	
	That's it from me; I've done a full review pass. 
	Has anyone else? 
	
	          Mez
	
	Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l
333-6389)
	Lotus/WPLC Security Strategy and Patent Innovation Architect
	
	----- Forwarded by Mary Ellen Zurko/Westford/IBM on 03/02/2007
08:35 AM -----
	
Mary Ellen Zurko/Westford/IBM 

02/20/2007 06:21 PM

To
cc
Subject
reviewing Note

	



	Comments on the Feb 16th draft (from the start through Section
6). 
	
	
	The email list to send comments to needs to change to a list
that's truly public. Thomas will specify. 
	
	Does the Patent stuff stay? The link to the public list of any
patent disclosures made in connection with this group is broken. 
	
	First paragraph of overview. I'd like to see an extra sentence
being more explicit about addressing both the usability and assurance
of those mechanisms. I'd also like to see a ref/link to the charter in
the overview as well, since certain restrictions come straight from it.
I propose adding:
	"Those recommendations will address both the usability  of
those mechanisms and their robustness against spoofing attempts by web
sites, as specified in the Web Security Context Working Group charter
<http://www.w3.org/2005/Security/wsc-charter> " 
	
	I'd like us to add some text to the Goals section before
beginning to list them. I propose:
	"This section outlines the goals that the working group will
focus its efforts on."
	
	Section 2.4 - I propose removing the last line ("Presenting
security information..."). I don't think the goal needs it, and it
detracts from the goal. 
	
	Section 4, "In Scope", I'd like to see a bit of introductory
text. I propose:
	"This section outlines in broad form what aspects of web
security experience, indicators and trust are within the scope of this
working group." 
	
	Section 4.2 - there is some redundancy there. I propose
striking the third sentence as wholey redundant ("This range
includes..."). 
	
	And Chuck, here is a good place for you to make specific
recommendations if you believe we are not adequately addressing the
range of user agents in scope. They can at least be called out here. 
	
	Section 6 - I'd like to have a bit more motivation and
expectation framing for the use cases. I propose adding this text
before the line that's there:
	"Use cases will ground and guide our recommendations." 
	
	It seems an odd gap that 6.2 does not explicitly call out
following a link provided by a person through some collaboration
application, such as email, blogs, or other social networking. That
case does not seem to be precisely covered by any of what is currently
there. Assuming I am right, I propose the following rewording for the
second sentence:
	"He might have followed a web link from a known site's web
pages, from web application data provided by other users, or from a
search engine."
	
	Section 6.3 - the implication that the user is fully aware of
the implications of downloading software seems wrong to me. I propose
striking the full final clause, starting with ", fully aware that...". 
	
	We need an acknowlegements section. Here's the first draft of
it. Please let me know who I've missed: 
	
	Acknowledgments
	This note is based on based on input from Tyler Close, Thomas
Roessler, Mary Ellen Zurko, and the members of the Web Security Context
Working Group.