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