ACTION 63 - Review policy reqs document

Hi All,

Sorry for the delay. Here a few comments on the current version of the
Policy Requirements.

Section 2. Definitions
Device Capability
- I'm OK with the definition for device capability. Maybe I would just
add the following text from the BONDI A&S doc to better understand this
concept:
"Although there will be simple Device APIs that provide access only to a
single Device Capability, it must be expected that there are also more
complex APIs that expose multiple Device Capabilities; examples might
include a camera API that provides the ability to geotag a photo with
the current location, or a messaging API that provides the ability to
access documents stored locally and attach them to outgoing messages.
Therefore, enabling or disabling access to a specific Device Capability
will not directly correspond to enabling or disabling access to a single
Device API."

Feature
- In order to complete the definition, would it be worth mentioning
something about feature addition? For example, from BONDI we could take:
"The set of Device APIs is not fixed, and is expected to be extended
over time, as new features become supportable (and perhaps also as
features become obsolete)."
-----------
Section 3. Use Cases
- A couple of use cases more the Widget example:
	* No widget can access evil.example.org
	* An unsigned widget cannot launch another application without
user consent
-----------
Section 5. Policy Definition
- I still don't understand completely what the second requirement means
("The DAP security framework MUST allow a flexible choice of policy
decisions for feature access to device capabilities".)
- Regarding the issues in this section, I think the CRUD approach to
define features is OK.
-----------
Section 6. User Control over Decisions
- Small typo in the 3rd paragraph of the Rationale sub-section: "The
semantics of some APIs are defined such that user interaction is
essential to *make* use of the API." *make* is missing.
-----------
Section 7. Identification
- Would it make sense to move the 3rd, 4th and 6th requirements of this
section to section 8. Access control ?
- Small comment on the 4th requirement: I would remove *device* before
features.
- In the Rationale sub-section the last sentence is: "Using IRIs to
identify capabilities and features allows the definition to be
decentralized, allowing extensibility." However, one of the requirements
says that device capabilities are identified by strings and not IRIs. 
-----------
Section 8. Access Control
Issue: Is access control at feature level required or is access control
at a device capability level adequate?
- I'm not sure I understand this issue. In section 7 of the doc
(Identification) it is already stated that:
	* The security framework MUST support access control decisions
based on device capabilities, independent of API.
	* The security framework MUST support access control decisions
based on features (one or more capabilities bound to a device API).
It is also explained how device capabilities such as "read local
filesystem" are API independent and, thus, specifying a rule which
denies access to this device capability means that local files won't be
acccessible for reading regardless of the API used.
I think this is a reason enough to define access controle a feature
level too.
Another practical example that I have found when defining a policy
document using BONDI:
In the Camera API, http://bondi.omtp.org/api/camera.capture feature maps
to 2 device capabilities: camera.capture and file.io.write.
Let's imagine that the intention of the policy writer is to allow the
camera to capture a picture after prompting the user. If access control
is only defined at a device capability level we could have the case
where one rule says that access to camera.capture is defined as
"prompt-blanket", whereas another rule says that access to file.io.write
is denied. In this case, defining access control at a feature level
would easily solve this problem.
 
So, IMO, both access control at a feature and a device capability level
is necessary. 


Thanks,
Laura


Laura Arribas

Security Technologies Researcher
Vodafone Group R&D
 
Tel: +44 (0) 7775411861
Fax: +44 (0) 1635231776
E-mail: laura.arribas@vodafone.com


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

Received on Friday, 11 December 2009 15:17:32 UTC