RE: What we're trying to protect...

Why wouldn't it be in scope?  Just asking.  The padlock today tells as
much (actually more) about confidentiality than it says about
authentication.  And our project is about web security content, not just
web authentication context.  Cheers Mike

  _____  

From: Brad Porter [mailto:brad@tellme.com] 
Sent: Monday, February 12, 2007 4:51 PM
To: McCormick, Mike
Cc: stephen.farrell@cs.tcd.ie; public-wsc-wg@w3.org
Subject: Re: What we're trying to protect...


Are "confidentiality clues" something we need to add to our use
cases/requirements?   Would we consider it in-scope?

--Brad

michael.mccormick@wellsfargo.com wrote: 

	I agree confidentiality cues are a user requirement.  People
trust their
	doctor or their banker more than they trust their ISP or phone
company.
	
	An example when confidentiality is required without
authentication might
	be if my clinic or bank e-mails me some very personal
information.
	Because of the private nature of the data I'm confident it came
from the
	trusted party.  What I'm more worried about is busy-bodies
trying to
	read it along the way.
	
	-----Original Message-----
	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org]
	On Behalf Of Stephen Farrell
	Sent: Monday, February 12, 2007 12:00 PM
	To: Brad Porter
	Cc: W3C Security (Public)
	Subject: Re: What we're trying to protect...
	
	
	
	What I mean is that users and sites sometimes also have an
interest in
	data they send being kept confidential; a site may separately
have a
	requirement that the data it sends be kept confidential (at
least while
	in transit).
	
	Can't think of an important case where only confidentiality is
needed
	offhand, so I guess confid. is perhaps only required in
conjunction with
	some kind(s) of peer-entity-authentication.
	
	Use case: medical worker accesses patient records. Regardless of
what
	authentication requirements are, there is a requirement that we
can
	basically only really meet by encrypting. And I would guess that
	everyone involved would have this requirement, the site, the
medical
	worker and the patient (and regulators).
	
	S.
	
	Brad Porter wrote:
	  

		Everything we're talking about thus far is browser
making statements 
		to the user about a site.  So I'm not sure
confidentiality applies, 
		but perhaps you can expand?
		
		--Brad
		
		Stephen Farrell wrote:
		    

			Doesn't that ignore confidentiality
requirements? (Although I like 
			the line of thinking.)
			
			Brad Porter wrote:
			      

				In general, with the web, the goal of
security is to transparently 
				protect the user.  Browsers that support
sandboxing are trying to
				transparently protect the user from
malicious applications.   The 
				only two cases where the browser needs
to make any assertions to the
				        

	
	  

				user are the following:
				
				1) Establishing the veracity of the
information on a site
				2) Establishing that you are submitting
your information to the 
				party you intended
				
				I would argue that people are generally
aware of the veracity of any
				        

	
	  

				information on the web is questionable.
So the question becomes, 
				are we trying to make any statements
about the veracity of 
				information on a site?  If not, then we
can punt on #1 and focus
				        

	instead on #2.
	  

				Number two only occurs when submitting
information and is a very 
				active instead of passive act.  (I'm
intentionally ignoring 
				click-stream type data leaks as they
could be handled by proper 
				sandbox restrictions.)  This suggests
that for 98% of what people 
				do, they don't need any security
indicators from the browser.  They 
				only need to verity the security when
submitting their data.  This 
				suggests that presentation of security
context information could be 
				late-binding instead of omnipresent and
integrated into the 
				task-flow instead of passive, which
might help address a number of 
				the problems with the current
mechanisms.
				
				--Brad