- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Tue, 6 Oct 2009 13:42:02 -0400
- To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Earlier I listed some of the higher level requirements and goals to consider for DAP API Policy [1]. One of these was: "10. Able to identify an API by URI" I should note that URI need not be the only approach, though my inclination was to start with URI. An example of the first approach, using a URI, is BONDI 1.01 which defines IRIs for the various APIs (section 4.2 BONDI architecture and security [2]). A second approach is to use class names, as Marcin noted in the Access workshop position paper [3] - APIs could be identified by Javascript class name and optional property attribute (see the table in 3.3). A third approach is to not name APIs at all, but pass material in the API invocation to enable use, passing a capability. But for an enforcement engine to evaluate declarative policy it would still need to be able to name APIs, I would think. This raises a couple of questions: is the DAP API work restricted solely to Javascript or should the model support other languages (degree of language independence needed), and does declarative policy require the ability to name an API (regardless of whether feature access control is included). It seems to me we need naming and that URIs offer more flexibility. Is this a decision easily made, or is discussion required? regards, Frederick Frederick Hirsch Nokia [1] http://lists.w3.org/Archives/Public/public-device-apis/2009Sep/0126.html [2] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf [3] http://www.w3.org/2008/security-ws/papers/ACCESSPositionPaper_W3CSecurityWorkshop.pdf
Received on Tuesday, 6 October 2009 17:42:53 UTC