Re: What Is A Secure Page - Templateified

> 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 
used 
> 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 
SCI 
> 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 
represent). 

> 
> I have added a defintions section at the top of the overview. Please 
take 
> 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? 
http://www.w3.org/2006/WSC/wiki/WhatIsASecurePage
Why isn't there a link to that at the bottom of
http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
Where Shawn is tracking templatized proposals to put into the rec track 
document?

"
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 
communcation. 
"
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 
by
> > direct links, and not redirects. If unsecure->secure redirects are 
needed
> > then the redirect SHOULD be immediate, and not multistep. This lets 
the
> > user know where he or she is headed before intiating the transition. "
> >
> > This reasoning seems wrong to me. Users don't really know where 
they're
> > 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 
SCIs.
> 
> This requirement encourages transparency to interested users, and it 
also 
> 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 
SCI 
> 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 
not 
> 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 
cases 
> 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?