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

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
>>>
>>>
>>
>

Received on Monday, 12 February 2007 22:37:39 UTC