RE: [Policy] identifying APIs

Hi Frederick,

>>Don't all events/callbacks result effectively in a method invocation,
>>to which access control can be applied,
If one wants to explicitly register for an event programmatically, one uses addEventListener.
Event reception could then be prevented by prohibiting the registration, ok.

However, there are default event handlers, specified in HTML4/5, e.g. onkeydown [1].
We may want it to depend on the security policy whether those handlers (or other handler defined e.g. in DAP or by vendors) are triggered.
Therefore we could assume that "all events [/callbacks] result effectively in a method invocation", but we override here the term method.
In this specific case it is not a method, but a handler that points to some code/method [2].

>>are you saying the event
>>could result in some generic javascript execution that might not be
>>appropriate?
Yes. I mean it specifically for some new events and handlers that would be defined in DAP, like input events etc.

Thanks,
Marcin

[1] http://dev.w3.org/html5/spec/Overview.html#event-handlers-on-elements-document-objects-and-window-objects
[2] http://dev.w3.org/html5/spec/Overview.html#event-handlers

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:16 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; W3C Device APIs and Policy WG
Subject: Re: [Policy] identifying APIs

Marcin

Don't all events/callbacks result effectively in a method invocation,
to which access control can be applied, or are you saying the event
could result in some generic javascript execution that might not be
appropriate?

regards, Frederick

Frederick Hirsch
Nokia



On Oct 7, 2009, at 5:45 AM, ext Marcin Hanclik wrote:

> Hi again,
>
> I think that events/callbacks should be added to the term API.
> They are another side (pushing the data in the contrary to the usual
> methods that pull the data) of the API and are abstracted a bit
> differently in WebIDL.
> So we may need some security aspects considered as well.
> Assuming that some events just arrive (without explicit
> specification of the EventListener etc.), we may want to restrict it
> in the security policy.
> I.e. we may want to distinguish between eligibility to call methods
> and retrieve data from an attribute from getting some event.
>
> I think this relates to ISSUE-14.
>
> 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: Marcin Hanclik
> Sent: Tuesday, October 06, 2009 11:01 PM
> To: Marcin Hanclik; Frederick Hirsch; W3C Device APIs and Policy WG
> Subject: 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.


________________________________________

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:36:22 UTC