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)

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

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

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.

Did I understand correctly what you are saying?

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.

Received on Wednesday, 7 October 2009 12:38:56 UTC