RE: [Policy] identifying APIs

Hi Frederick,

My comments inline below.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Frederick Hirsch [mailto:Frederick.Hirsch@nokia.com]
Sent: Wednesday, October 07, 2009 2:38 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; W3C Device APIs and Policy WG
Subject: Re: [Policy] identifying APIs

Marcin

I'd like to repeat what I think you are saying, to be clear on whether
we agree.  Much thanks for your work to clarify these issues.

First, one aspect is granularity of access control.

It seems clear that it would be useful to have access control at the
level of methods. It also seems that one might want to have access
control at the level of the class/module, in effect disallowing all
access to all methods if denied, but if allowed then the method
control applies. If this were the case, I'd expect access to
attributes/constants to be covered by the module level access.

Logically this could be enforced -  so I think module level access
would be possible, despite how it is implemented.

What I think you indicated in this email is that BONDI has grouped
APIs into sets called features, such as read including various APIs.
This  avoids an explosion of policy rules, probably a good thing.
Essentially logical APIs including various methods. (Hierarchical
features makes it a bit more complicated however)

[MH] There is no hierarchy in features (i.e. the text in 1.01 may be misleading).
In BONDI 1.1 we consider feature-set that just group features and serve mainly the convenience of the developer.


If there is no module level access control, how would one deal with
attribute/constant access, or is that a non-issue?

[MH] attributes and constants are to be put under features. I.e. each method/attribute maps to one or more feature.
(This is coming in 1.1.)

Second is the issue of naming, referring to API "items", presumably by
URI.

Here I assume (perhaps incorrectly) that such URIs could be generated
from the WebIDL and a base URI; presumably the URI would correspond
very closely to the method name or module name, eg baseuri/module or
baseuri/module/methodname

[MH] Your assumption is correct, we would like to refer to WebIDL as much as possible for simplicity.
In BONDI only module is in the URI, after the dot we have a component that I perceive as use case, thus
http://bondi.omtp.org/api/filesystem.read
contains:
"http://bondi.omtp.org/api/" as the namespace,
"filesystem" as the module and
"read" as the "use case" component.

I wonder if it would be clearer to name a feature so that it is clear
it is a group, e.g. read-feature or something like that, since some
individual APIs will also require access control (without being a
feature set). Perhaps not -  I think you are suggesting that features/
APIs be named in one way so it is uniform and treated uniformly, there
is elegance to that.

[MH] "read-feature" could probably have too many possible connotations.
Also we may have several namespaces for various features (API, hardware-related etc).
That is why we have a few components in IRI: namespace, module and use case.
It seems practical and seems to be elegant :)

Did I understand correctly what you are saying?

[MH] I think yes.
regards, Frederick

Frederick Hirsch
Nokia



On Oct 6, 2009, at 4:12 PM, ext Marcin Hanclik wrote:

> 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 Wednesday, 7 October 2009 12:58:42 UTC