W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

Re: What Is A Secure Page - Templateified

From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Thu, 5 Jul 2007 08:58:25 -0400
Cc: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Message-ID: <OFF6BE440B.E7B990D6-ON8525730F.00443C45-8525730F.0047443C@LocalDomain>
To: yngve@opera.com
> In this discussion my primary concerns are end-to-end protection of the 
> data, the strength of the methods used to protect the data, and how to 
> present (to the user) a summary of the information about the methods 
> to download the content presented to the user.

Well stated. If there's not already something like that near the beginning 
of the proposal, I encourage you to add this. 

> Another major concern is how to handle or present this information when 
> part of the presented content is not protected by such methods.
> A third major concern is how to handle a transition from unprotected to 
> protected mode when the user provided data to be transmitted in the 
> protected mode was entered into the client via content (aka forms) that 
> was not received in the protected mode.

Perhaps this too. I found it helpful. 

> With respect to the term "padlock" I am using that as the name of the 
> as it is the most commonly used indicator.

Since the rec track doc will have a section on the Primary SCI (right 
Shawn?), I think it will be useful for us to refer to that when we can, 
when our proposals will apply to any primary SCI. Or perhaps in this case, 
any primary SCI that includes protocol protection of data (a pure identity 
based primary SCI would not include that). The idea is to abstract as much 
as makes sense so that the scope of our proposals is clear. Does each one 
only apply to the padlock today, or does it apply to a class of SCIs (in 
this case, primary SCIs that include protocol protection in what they 

> I have added a defintions section at the top of the overview. Please 
> a look, and see if that resolves the definition problem, or if we should 
> find some other phrasing. If new phrasing is in order I am open to 
> suggestions. I am not sure that "protected" is better than "secure" as a 
> description here.

You mean here? 
Why isn't there a link to that at the bottom of
Where Shawn is tracking templatized proposals to put into the rec track 

A secure website is, for the purpose of this proposal, defined as a 
website hosted on a SSL/TLS HTTPS server, or a similar protocol offering 
end-to-end (client-server) authentication, integrity and privacy of the 
I don't remember the authentication aspect of SSL being critical when I 
read your proposal. And if it is, it would only be the server 
authentication, not the optional client authentication. You might want to 
clarify that part. 

On the "padlock" definition, I'll want the text rewritten at some point to 
use the abstraction instead. We'll have a lot of work to do to bring 
together all our proposals to be using a consistent set of terminology. 

> > " Change from and unsecure to secure parts of a service SHOULD be done 
> > direct links, and not redirects. If unsecure->secure redirects are 
> > then the redirect SHOULD be immediate, and not multistep. This lets 
> > user know where he or she is headed before intiating the transition. "
> >
> > This reasoning seems wrong to me. Users don't really know where 
> > going, and we're not encouraging the use of URLs to figure out where
> > you're going and where you are, since they're not secure and usable 
> This requirement encourages transparency to interested users, and it 
> makes for easier logic when implementing the SCI.

It will be easier to align this when everything is organized in the rec 
track document. But it sounds like you're talking about secondary SCI 
transparency ("interested users"), not primary SCI. 

> Just want to be sure: Do I understand this to mean that we should use 
> exclusively instead of "security level indicator", "padlock", etc?

I would like us to develop consistent terminology. Security Context 
Indicator (SCI) seems like the right one to me (unless we're referring to 
more specific instances of SCIs). If I use the "concensus" word, then 
anyone who disagrees should speak up :-). And it can/should be a term in 
the Glossary or Definitions section (which we'll need, OK Shawn?). 

> With respect to the onsubmit aspect of the post you referenced, the 


It would be great if you'd reply directly to the tag list with your 
responses on that thread. 

>   2. Server-only selfsigned certificates, or an broken chain that does 
> link to a known root. In this case you do not generally know who is 
> running the server, and it may even be a man-in-the-middle. In such 
> accepting the connection offers little, if any, better protection than 
> clear text HTTP (i.e., none). This type of sites is the target for the 
> above proposal.

Sure I do, it's IBM. I don't mean to be dense; how is it that, 
hypothetically, I don't know that a self signed cert for, say, 
shakespeare.notesdev.ibm.com isn't run by IBM? 
Received on Thursday, 5 July 2007 12:58:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC