RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

Thanks Dom, for putting this together. It looks good to me!
I wonder if there should be identifiers at the API level e.g. 'file' would indicate access to the entire File API i.e. read and write, 'contacts' would indicate access to the entire Contacts API and so on, in addition to the granular per operation access identifiers similar to 'geolocation' where it provides access to both getCurrentPosition() and watchPosition() methods. This to me would make sense if one wanted to provide blanket-type of access to the entire API without worrying too much about the detail operations inside a particular API.

Since the <feature> element is linked into this document, would it make sense to also bring in the WARP <access> element to address the domain aspect? I think so.

Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Dominique Hazael-Massieux
Sent: Monday, September 20, 2010 10:44 AM
To: public-device-apis
Subject: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

Hi,

Following the discussions on the list [1], on the call last week [2] and
per my ACTION-263, I've taken a stab at what used to be called "Device
API Features and Capabilities" and is now available under the title
"Permissions for Device API access":
http://dev.w3.org/2009/dap/features/


It defines identifiers for permissions of 5 APIs: geolocation, contacts,
media capture, file, and sysinfo. I've tried to define those based on
current implementations of the APIs (when available) or based on the
security models described in the said APIs.

I've left out on purpose APIs for which our permissions model is not
clearly defined yet (messaging, calendaring, contacts writer to name a
few).

For each of these APIs, I've defined one or more strings (that can be
trivially turned into a URI) that match (in general) permissions to
access a set of methods. I've also described quickly how that permission
is currently implemented (or meant to be implemented) in Web browsers.
These descriptions might benefit from being a bit more formalized, esp.
in the context of describing how these permissions map to widget
features.

I've moved the mapping to BONDI and Android in an appendix, and limited
the mapping to features/permissions that indeed seem to match roughly
what we are proposing.

Things that I have not included but would be logical additions:
* permissions for off-line storage through the manifest attribute in
HTML5
* permissions for IndexedDB

There are probably more APIs that should be added; Web notifications
should also be part of that list at some point.

I had originally thought that I would also add to the description of
these permissions their meaning in the widgets context (e.g.
"geolocation" means the widget can access getCurrentPosition() without
user prompting). But it looks like the meaning of the <feature> element
in the widgets P&C is not strongly bound to the notion of permissions
("allowed to access") has much as to the notion of capability ("device
provides said API"):
        a feature that is needed by the widget at runtime"
        http://www.w3.org/TR/widgets/#the-feature-element


The impact of requesting a given feature on the permissions is
apparently left user-agent dependent. So it probably doesn't make much
sense to add much more on widgets in this document at this sage?

[In Android, there is a distinction made between using a feature
(declared with <uses-feature>) and requesting permission for some of
these features (declared with <uses-permission>):
http://developer.android.com/guide/topics/manifest/uses-feature-element.html

]

Anyway, I think the document is now much closer to be in a state for a
FPWD; comments, corrections and suggestions are welcome.

Dom

1.
http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0016.html

2.
http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0079/minutes-2010-09-15.html#item04





---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 20 September 2010 22:15:31 UTC