W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

[Policy] Draft policy requirements comments

From: Arribas, Laura, VF-Group <Laura.Arribas@vodafone.com>
Date: Thu, 29 Oct 2009 11:33:07 +0100
Message-ID: <E71B6B341C8C3D47AA1288D9E719D1C502F1BD93@VF-MBX12.internal.vodafone.com>
To: <public-device-apis@w3.org>

Hi All,

As suggested in yesterday's call, and after a first review of the policy
requirements draft, these are a few comments to start with:

Collection of interfaces structured in terms of methods and properties
used by applications to access device functionality. 
[LA] The term device functionality refers to device capability, right?
In my opinion, "capability" instead of "functionality" would work better
in order to be consistent with the rest of the text.

device capability
Note that a given API may require different capabilities, as in this
JavaME example: Connector.open("file://sdcard/my_dog.jpg"); would use a
"local filesystem" feature, whereas Connector.open("btspp://:"); would
use a "Bluetooth serial port profile" feature. 
[LA] I agree that we need to define the mapping and relation between
APIs / device capabilities / features. However, since the definition of
feature comes right after the definition of device capabilities, it is
confusing to understand the feature concept here. I would suggest to
describe this mapping in a separate paragraph after the definitions.
What do you think? 

is ability to use capability for a specific API [LA] "ability to use
capability" is a little bit confusing. In my opinion a clearer
definition would be the one from Paddy's e-mail
l): "A *Feature* is a defined way of  accessing certain specified device
capabilities using an associated API."

Policy Definition
*	The DAP security framework MUST allow a flexible choice of
policy decisions for device capability and feature access. 
[LA] Question: Is it related to the granularity of access control
(ISSUE-26 API Identification
http://www.w3.org/2009/dap/track/issues/26)? Meaning that both device
capability and feature level must be supported?

User Control over Decisions
If a sensitive operation requires some user interaction to initiate it
(such as choosing a file to upload, or pressing the shutter on a
camera), then this interaction can be arranged so that it is an implicit
user authorization. Whether or not this is possible depends on the
operation or API in question. 
[LA] Question: could anyone give an example on how this ("interaction
arranged so that it is an implicit user authorization") would work?

Open Issues for Resolution
*	User authorization vs other policy authority
Support for trust models other than user security decisions needed? 
[LA] I would go for BONDI's approach, that provides for a policy
authority to determine an access control policy that can make certain
decisions without reference to the user.
*	Granularity of user decisions
What is the correct granularity of security decisions presented to user?
[LA] As it is stated in the text, I agree that DAP should not presuppose
that an approach involving blanket permissions only and that both
approaches have advantages for different use cases and we should try to
define a system that supports all use cases effectively.
*	Application control vs user agent control
Does application or user agent or both determine which prompts are
presented to user? 
[LA] IMO, the example given in the document shows that it is important
that the application itself is also involved in the prompting decision.
However, I'm not sure how this could be implemented - I need to look
deeper at this issue.

Open Issues for Resolution
Is access control at the feature level required or is access control at
the device capability level adequate? 
[LA] IMO, both feature and device capability access control levels
should be required.


Laura Arribas
Vodafone Group R&D
Tel: +44 (0) 7775411861

Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN Registered in England No 3802001.

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Frederick Hirsch
Sent: 27 October 2009 00:10
To: W3C Device APIs and Policy WG
Cc: Frederick Hirsch
Subject: Draft policy requirements

I've created an initial  Policy Requirements editors draft, see

Please review and propose additions or changes.

I used material that we've discussed to date on the teleconferences,
including  proposals from Paddy and myself.

This draft is to give us something concrete to improve - it does not
assume consensus on the material (at this point).

regards, Frederick

Frederick Hirsch
Received on Thursday, 29 October 2009 10:33:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:12 UTC