- From: Arribas, Laura, VF-Group <Laura.Arribas@vodafone.com>
- Date: Thu, 29 Oct 2009 11:33:07 +0100
- 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: Definitions API 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? feature 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 (http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0160.htm l): "A *Feature* is a defined way of accessing certain specified device capabilities using an associated API." Policy Definition Requirements * 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 Rationale ... 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. Identification 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. Thanks, Laura 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 http://dev.w3.org/2009/dap/policy-reqs/ 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 Nokia
Received on Thursday, 29 October 2009 10:33:47 UTC