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 Friday, 6 July 2007 15:15:14 UTC