RE: Section 7 - Security context ACTION-263 Review list of security information this week

Hi Thomas,

I've made a pass at section 7 based on your feedback. See:

http://www.w3.org/2006/WSC/drafts/note/#available

I found a couple meta-issues in your comments...

Confusion between 'provided by' versus 'defined by':

The sub-sections are organized according the family of specifications
that define the semantics of the listed information, and not by who
actually provides the information at runtime, since that always bottoms
out at the user agent. For example, DNS defines what a hostname is,
though hostnames are acquired at runtime in many ways.

Intent of section:

The session we had at our first f2f, and subsequent conversations about
this section, have merely attempted to list information that is
relevant. We haven't tried to capture why information is relevant and
how. You seem to wish we had done this more complete analysis. I agree
it is a worthwhile thing to do, but it is a major undertaking and I'm
not going to do it alone. We've got what we've got. I filled out some
points a little more during this latest pass, and I think what we've got
is a good enumeration, but not analysis.

Most of the rest seem to be wording issues, that I've tried to correct.

I just spent 3 hours on this. It's probably not a good idea for me to
spend more time on this section, given the other tasks on my plate.
Please only point out remaining issues that you find truly embarrassing.

Thanks,
Tyler

> -----Original Message-----
> From: public-wsc-wg-request@w3.org 
> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Thomas Roessler
> Sent: Friday, July 06, 2007 8:15 AM
> To: Close, Tyler J.
> Cc: public-wsc-wg@w3.org
> Subject: Re: Section 7 - Security context ACTION-263 Review 
> list of security information this week
> 
> 
> I think I also still owe a review of that section, by way of a deal
> with Tyler that he might address issues I raise.  So, here we go...
> 
> - HTTP-Auth handshake is strictly speaking not "context
>   information."  The information in that handshake is, as is the
>   fact whether or not it was successful, as are the various
>   variables that feed into the protocol.
> 
>   (Did we supply the HTTP authentication information spontaneously?
>   How many retries?  When did we first authenticate here?)
> 
> - Similar for Cookies.  There is information both in and about the
>   cookies that might contribute to the user's security context. Some
>   of that information is actually user agent or server state, and
>   not usefully "provided by HTTP."
> 
> - "Has the page completed loading successfully" is a statement
>   that's undecidable when Javascript code is involved.  It also
>   depends on, among other things, content and stylesheet
>   information, and is therefore not provided by HTTP.  It's possible
>   to trigger further network requests interactively from
>   stylesheets.
> 
> - Referring page is, strictly speaking, client state.  The client
>   uses HTTP to transfer this information to the server.
> 
> - Redirection path is, strictly speaking, client state.
> 
> - The HTTP content-type header is probably security context
>   information.  More importantly, though, it feeds (together with
>   the "MIME type of the content" in the next section) into a complex
>   decision process that happens inside the browser.  That decision
>   process leads to what I'll call the effective media type.  
> 
>   To make it all funnier, that media type (for the same protocol
>   exchange and actual content) might be different for
>   representations displayed in a standards-compliant Web browser,
>   for representations displayed in an actual Web browser, and for
>   representations stored locally and then fed to some local
>   application.
>   
>   Aren't file extensions joy?
> 
> - The target URI for a hyperlink or form submission isn't
>   necessarily provided by web content, since it might be constructed
>   based on both content and user input.  Indeed, if a form is
>   submitted through HTTP GET, that's regularly the case.
>   
> - "Presence of client-side dynamic content" sounds confusing, though
>   it's indeed an important point.  The discussion that follows is
>   most closely related to the "has the page completed loading" point
>   further up.  Also, the statement about the rendered view remaining
>   constant isn't completely true:
>   
>   * stylesheets can cause network interactions based on a user,
>     e.g., hovering over a link
>   * a refresh tag can cause navigation away from a view without
>     explicit user interaction
>   
>   There's probably more.
> 
> - "Does the content come from multiple domains?" -- "come from" is a
>   bit unspecific; domain needs a definition.
> 
> - "Is the rendered view composed from multiple content sources, such
>   as referenced images or stylesheets?" -- Yes.  But, more
>   importantly, what's meant by "content sources"?  I suspect that
>   this is meant to be a variation over the "multiple domains" item
>   above.
> 
> - "Was the content transmitted using SSL" is, strictly speaking, not
>   a piece of information that is "provided by SSL".
> 
> - CRL and OCSP can use expansions in the context of this docment
> 
> - "Provided by IP or DNS" mixes layers.  DNS is a directory service,
>   IP is a network layer protocol.
> 
> - The server hostname is actually provided by neither IP nor DNS,
>   but instead a function of whatever the client chose, and whatever
>   redirect path the client followed.
> 
> - The server IP address is either discovered through DNS, based on
>   the server hostname, or has been directly part of a URI or
>   redirect path.
> 
> - "DNSSEC" is, in its brevity, almost meaningless for the purposes
>   of this enumeration.
> 
> - "network diagnostic information, such as ping or traceroute" mixes
>   network diagnostic information (kind of good) with the names of
>   programs used to derive such information.  I'd suggest to phrase
>   this in a slightly more elaborate way.
> 
> - "Provided by user agent" -- is this supposed to mean "client
>   state", or rather "client state before the user started using it"?
> 
> - "installed certificate authorities" -- do we mean "trusted"?
> 
> - "installed search engines" -- what does it mean to install a
>   search engine on a client?  Do we mean "known"?
> 
> - "default window layout" -- I have a slight clue what we mean by
>   this, and why its relevant, but it's probably worth explaining
>   that more.
> 
> - "Has the user agent completed rendering of the page" is the one
>   item that doesn't fit into the collection here.
> 
> - "Provided by user" -- this seems to be "client state that was
>   acquired through use"
>   
> - submitted passwords -- there's also user names, and the conditions
>   under which they were submitted (TLS or not, field names, URI of
>   form, ...)
> 
> - "installed {client|server} certificates" means the ones that the
>   user accepted interactively?  Or something else?
> 
> - "user's understanding of his task" is something that the user
>   typically doesn't provide us with.
> 
> - "user agent customization" may also be something that is a
>   function of, e.g., the malware that the user most recently ran.
>   I'm not sure it's really "provided by user".  (It is client state
>   that was accumulated during interactive use, though.)
> 
> - I'm not sure how "hyperlinks on visited web pages" fit into the
>   "Provided by third-party" section.
> 
> Cheers,
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>
> 
> 
> 
> 
> 
> 
> 
> On 2007-07-02 14:52:39 -0400, Doyle, Bill wrote:
> > From: "Doyle, Bill" <wdoyle@mitre.org>
> > To: Thomas Roessler <tlr@w3.org>, public-wsc-wg@w3.org, 
> tyler.close@hp.com
> > Date: Mon, 2 Jul 2007 14:52:39 -0400
> > Subject: Section  7 - Security context ACTION-263 Review 
> list of security information this week
> > X-Spam-Level: 
> > X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> > 
> > A quick review of section 7 - 
> > 
> > 7.1 Does HTTP provide info on page loading or is this more 
> http status
> > and user agent processing that provides loading status?
> > 
> > 7.3 How about HTTPs instead of SSL?
> > 	Provided by HTTPs
> > 	Use of SSL/TLS protocol that enables other security services
> > 
> > 	SSL Server Certificate - 
> > 	How about PKIX Certificate, it is not an SSL Cert but an X.509
> > cert that SSL uses. Can also be server cert or client cert.
> > 
> > 7.3 OSCP - should be OCSP, typo
> > 
> > 7.6 user's understanding of his task - 
> > 
> > Have to help me on this one.
> > 
> > 	It has been a long day so - Do we hook something like a
> > breathalyzer to the user agent so we can determine user 
> state, at least
> > try to determine if they drunk? WSWIt proposal - Web Surfing While
> > Intoxicated test, disable credit card transactions if 
> reading is 2.0 or
> > greater and at 3.0 or greater user is now blind, can't see 
> the monitor
> > so and mouse and keyboard are turned off?  In thinking of 
> this, maybe I
> > could use this. 
> > 
> > I do not believe that the WSC can ask anything about users 
> ability. If
> > user agent needs to be in safe mode, restricted mode, 
> granny mode or my
> > favorite "Nanny Mode" that is one thing. That is a user agent
> > configuration determined by an authority that owns the system and
> > configures the user agent to operate in a specific way. 
> > 
> > Help information could support the user identify tasks and 
> things that
> > they could be doing, this is a user agent item.
> > 
> > Bill D.
> > 
> > 
> 
> 
>

Received on Wednesday, 25 July 2007 01:03:09 UTC