- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Tue, 6 Oct 2009 23:00:48 +0200
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Correnction for the below text: s/ECMAScript/WebIDL/ I assume we will use WebIDL to express APIs. Thanks, Marcin ________________________________________ From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik [Marcin.Hanclik@access-company.com] Sent: Tuesday, October 06, 2009 10:12 PM To: Frederick Hirsch; W3C Device APIs and Policy WG Subject: RE: [Policy] identifying APIs Hi Frederick, I think it is importantto define the term API, so that we could establish a concrete level of detail in our discussions. In ECMAScript we have basically the following terms that seem important from API scope identification point of view: a) module b) interface c) method d) attribute (=constant) Modules do not have runtime implications, since they are not instantiated. They are important from the namespace point of view. Thus we may want modules to be part of the URI. Interfaces may be instantiated, they may also be reflected in the URI. Modules and interfaces are means for functional grouping of methods and attributes (thus could be welcome in URI). Methods, attributes and constants are the core of the functionality behind "API". All or part of the above items could go into URI. However, the question is why all those items should be put into URI. The most visible goal is to enable the security policy to restrict access to the API (i.e. to method and/or attribute). Then, we should consider whether we need such level of detail in security policy and URI. Usually just some part of the interface/module is about the actual access to sensitive information, the rest are helpers. E.g. in a hypothetical file API, just file.read operation gets access to the sensitive data, file.open, file.close, file.seek may be considered as helpers. Therefore we may want the URI to stop on the module or interface level on one hand, and define some USE CASE on the other hand. This is the principle behind BONDI API. E.g. http://..../filesystem.read URI (for feature/API) is "responsible" for file-reading use cases. On the contrary, imagine how many URIs would need to be enabled to realize file reading if the URIs would match APIs 1:1 (we would need at least access to open, read, close methods; additionally probably some constants). Another comments: do we limit features to be only API [2]? P&C says that feature is a runtime component, this does not necessarily limit the features to API. We may, however, have some specific namespace for "API features". >>10. Able to identify an API by URI >>13. Able to identify a feature by URI It seems that if we limit features to be about APIs only, then points 10 and 13 from your list are identical. Otherwise point 10 would be also about a definition of the specific URI namespace for point 13. Thus, we may need a DAP interpretation of the term "feature". BTW: I would consider my above comments as partial fulfillment of the action-25 [1]. I will try to provide more comments tomorrow. Thanks, Marcin [1] http://www.w3.org/2009/dap/track/actions/25 [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0022.html ________________________________________ From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Frederick Hirsch [frederick.hirsch@nokia.com] Sent: Tuesday, October 06, 2009 7:42 PM To: W3C Device APIs and Policy WG Cc: Frederick Hirsch Subject: [Policy] identifying APIs 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 ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Tuesday, 6 October 2009 21:02:21 UTC