RE: [Policy] identifying APIs

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