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

Re: ACTION 63 - Review policy reqs document

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Fri, 11 Dec 2009 16:46:16 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-Id: <FDE90774-E513-4C27-8B61-DCC5C8D19440@nokia.com>
To: "ext Arribas, Laura, VF-Group" <Laura.Arribas@vodafone.com>
comments inline, thanks for the review Laura.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 11, 2009, at 10:16 AM, ext Arribas, Laura, VF-Group wrote:

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


another way to say this is, an API may require access to  all needed  
capabilities to be fully functional.

However couldn't some aspects of an API be usable even if not all  
capabilities are available, e.g a monolithic file API could include  
methods for both read and write yet only have permission for read?  
Thus the last sentence is "Device API interface"?



>
> 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)."

do we need to say this? Don't we expect a v2 to be likely anyway? Not  
against it, just not sure it is needed.

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

ok

> -----------
> 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".)


I agree, let's remove it - it is confusing and unnecessary. If we ned  
to justify policy, we should do it elsewhere.


> - Regarding the issues in this section, I think the CRUD approach to
> define features is OK.

Not sure this belongs in the policy requirements document. Isn't this  
an API definition concern on a per API basis? For example, what does  
it mean to create or update battery status?

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

thanks

> -----------
> Section 7. Identification
> - Would it make sense to move the 3rd, 4th and 6th requirements of  
> this
> section to section 8. Access control ?

to be specific

	 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 device features (one or more capabilities bound to a device API).
	 The security framework must support sufficient granularity for  
sensible access control decisions.

yes

> - Small comment on the 4th requirement: I would remove *device* before
> features.

yes


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

yes, lets remove the sentence.


> -----------
> Section 8. Access Control
> Issue: Is access control at feature level required or is access  
> control
> at a device capability level adequate?

remove the issue if the wg has resolved it. Need to check.

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

We should be clear on the problem. Is the problem that without feature  
access control it would be implementation dependent what happens in  
this case?
And that it could be the user is prompted to take the picture but then  
not be able to save it?
Is an alternative to not have policy for saving the picture but a file  
chooser showing what is possible?

>
> So, IMO, both access control at a feature and a device capability  
> level
> is necessary.
>
>
> Thanks,
> Laura
>
>

Thanks for the review.

comments from others?

> 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 21:47:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT