RE: Updated Security, Privacy and Policy Requirements Editors Draft

Hi Frederic,
I have reviewed the current version and have these suggestions and
comments:

Add to 2. Definitions
Explicit Consent
A user action directly related to a query for the user's consent, for an
action to be taken by the application, or for an application lifecycle
action. An example of explicit consent for an application action is a
positive user response to a query by the web runtime, asking whether an
application should be allowed to take a photograph. Examples of explicit
consent for an application lifecycle action include a positive user
response to a query by:
*	a positive user response to a query by the web runtime upon
application installation, asking whether an explicitly disclosed set of
API requests by the application should be allowed
*	a positive user response to a query by the application
storefront upon application selection and download, asking whether an
explicitly disclosed set of API requests by the application should be
allowed.

4. Privacy Areas
The first paragraph sets the tone but is perhaps too explicit, and I
recommend to delete the sentence "When privacy concerns are not
appropriately met, legal remedies in the courts may be required after
the fact." We should avoid discussing or referring to legal issues or
potential liabilities in this document.

Change paragraph in 5.1 User Control Principle (added text in [],
deleted in{})
Many existing ecosystems for mobile applications are based on a trust
model in which a particular distributor (such as a network operator)
certifies an application as trustworthy, eliminating run-time user
prompts[ in some cases]. This approach avoids the disadvantages of
prompts, but at the expense of taking {legitimate}[real-time] control
away from the user[ in those cases]. Other approaches, such as BONDI, do
not hard-code this type of trust model, but nonetheless provide for a
policy authority to determine an access control policy, and this policy
can require that certain decisions are made without reference to the
user.

Change paragraph in 5.1 User Control Principle (added text in [],
deleted in{})
DAP should not presuppose that an approach involving blanket permissions
only (e.g. implicit granting of blanket permission by allowing
installation to occur, or an explicit blanket permission given when the
application is first run) is the right answer. {Both
approaches}[Different permission granularities] have advantages for
different use cases and we should {try to define}[require] a system that
supports all use cases effectively. [DAP should follow industry practice
in these cases, and provide permission granularities consistent with
those widely deployed in the mobile market.]

8.2 Security Framework Requirements
It's unclear what these mean, more explanation would be helpful:
*	The Security Framework MUST be application language independent
*	The Security Framework MUST be Javascript capable and define a
Javascript binding

The document should provided a reference to the "HTML 5 security model".
It's unclear what that is in general.
*	The DAP security model SHOULD be compatible with the HTML 5
security model.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Monday, March 15, 2010 8:08 PM
To: W3C Device APIs and Policy WG
Cc: Frederick Hirsch; John Morris
Subject: Updated Security, Privacy and Policy Requirements Editors Draft

I have updated the Editors Draft for "Security, Privacy and Policy  
Requirements" to incorporate new material from John Morris [1] and  
also to restructure it.

I delineated definitions and principles,  conformance targets, use  
cases and requirements.

http://dev.w3.org/2009/dap/policy-reqs/ (reload might be needed)

I believe the material we had on "types of privacy requirements" can  
be better viewed as different conformance targets, so moved that to a  
new conformance target section before a section on privacy areas  
(previously called aspects).

User control is a principle, so noted it as such.

Added a new section on privacy use cases, reformatting the material  
from John's recent message [1].

Created a new requirements section, moving user control requirements  
and other requirements here.

We still have missing material and issues noted in the document, but I  
think these changes will help. Thank you John for providing privacy  
use cases.

I propose we use this version of the document in our discussion  
tomorrow.

regards, Frederick

Frederick Hirsch
Nokia


[1]
http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0140.html

Received on Tuesday, 16 March 2010 08:02:48 UTC