RE: ACTION-15, ACTION-25

Hi Frederick,

>>I assume you mean that  the access control policy  enforcement point
>>must know which API is mapped to which feature, since access to
>>features is what is specified in the policy.
Yes.

>>Perhaps  this mapping can
>>be expressed declaratively in the policy itself - since hardcoding
>>this might not be optimal?
I meant the fact that the mapping of features to API and of features to device capabilities may be UA dependent.
Then the policy writer may have problem with interoperability, i.e. the design principle behind device capabilities.
The UA knows the mapping.
If the mapping is repeated in the policy itself, I am not sure whether the situation would be simpler.

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 3:51 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; public-device-apis@w3.org
Subject: Re: ACTION-15, ACTION-25

Marcin

> The IMPORTANT requirement is, however, that the mapping between
> APIs, features and device capabilities is of crucial importance to
> the actual security. I.e. the UA must know which API is mapped to
> which feature and to which device capability. This in turn means
> that only part of the security policy is actually portable.

I assume you mean that  the access control policy  enforcement point
must know which API is mapped to which feature, since access to
features is what is specified in the policy. Perhaps  this mapping can
be expressed declaratively in the policy itself - since hardcoding
this might not be optimal?

regards, Frederick

Frederick Hirsch
Nokia



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

> Hi All,
>
> This are my comments to the actions 15 and 25 [A15], [A25], i.e.
> about features and capabilities.
> Yesterday I provided the info about features [1], those
> consideration reflect the topics we discussed in BONDI.
>
> Here are some thoughts on features and capabilities and how they
> (could) play together.
> The initial note is that BONDI defines APIs (methods, attributes)
> based on WebIDL and those APIs are grouped as WebIDL modules.
> Modules are to be kept independent (i.e. you can use API from one
> module without requiring other modules) for simplicity (this is a
> short-term goal, probably not realistic in the long run).
>
> BONDI defines the device capability and feature as follows [2]
> (section 7):
>
> DEVICE CAPABILITY
> A Device Capability is a specific capability of a device that may be
> exposed via a JavaScript API. From the point of view of a Web
> Runtime, a Device Capability would typically be exposed via an API
> of the underlying platform. However, Device Capabilities are defined
> and identified in a portable way, without a dependency on any
> specific software platform or platform-specific API.
> FEATURE
> A Feature is a specific set of functionality provided by a Web
> Runtime, as made available by a defined set of JavaScript interfaces
> and behaviours. Features are hierarchical, in that one feature may
> itself be made up of a number of sub-features. A Feature is
> identified uniquely by IRI, and is the unit of expression of
> dependencies by BONDI Web Applications.
> "
>
> P&C defines the feature as follows [3]:
> " A feature is a runtime component (e.g. an Application Programming
> Interface or video decoder)..."
>
> The definition of a feature in BONDI matches the corresponding
> definition in P&C, it restricts it to formally JavaScript
> interfaces, but we also have other features (e.g. "http://bondi.omtp.org/meta/ui?background=true&hidden=false
> " in [4], section A.2.1).
> Therefore we realize that features are not only APIs.
>
> Device Capabilities are exposed via APIs and Features are made
> available by JavaScript interfaces.
> So, as for me, they are very similar.
> The basic difference is that Device Capabilities are to be defined
> in a portable way.
> Therefore BONDI assumes that APIs may change (across devices,
> platforms etc), but Device Capabilities will not.
> Device Capabilities have abstract definitions [4], not tightly
> related to APIs.
>
> Section B.5 of [5] - about resource attributes - requires that a
> feature is always specified in a corresponding query, whereas a
> device capability is optional.
> This means that each device capability is related to some feature,
> but not each feature must be related to a device capability.
> It allows e.g. only "authenticated" APIs to access some resources
> (depending on the security policy).
>
> On the BONDI API level, we may build another picture based on [6].
> The APIs (methods, attributes) are covered by features.
> The scope of a feature (i.e. the methods and attributes it covers)
> is limited to the module (in WebIDL sense), so are the use cases I
> mentioned in [1].
> We could perceive the feature as a selector (pointer etc) to some
> set of APIs.
>
> On the other hand, one device capability is mapped to (or by,
> depending on the mapping direction) multiple features and those
> features are not limited to stem from one module (in WebIDL sense).
> Therefore we could perceive the device capability as a selector
> (pointer etc as above) to some cross-module set of API.
>
> To sum up:
> a) we need device capabilities to make a distinction between
> architecture and APIs. I.e. if we want the DAP architectural part to
> be extensible and e.g. to be used without the DAP APIs.
> b) device capability is about portability, i.e. the security policy
> based on device capabilities shall be portable. The IMPORTANT
> requirement is, however, that the mapping between APIs, features and
> device capabilities is of crucial importance to the actual security.
> I.e. the UA must know which API is mapped to which feature and to
> which device capability. This in turn means that only part of the
> security policy is actually portable.
>
> I hope this helps.
>
> Thanks,
> Marcin
>
> [A15] http://www.w3.org/2009/dap/track/actions/15
> [A25] http://www.w3.org/2009/dap/track/actions/25
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0068.html
> [2] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf
> [3] http://www.w3.org/TR/widgets/#feature0
> [4] http://bondi.omtp.org/1.01/apis/devcaps.html
> [5] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_Appendices_v1_01.pdf
> [6] http://bondi.omtp.org/1.01/apis/apifeatures.html
>
> 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
>
>
> ________________________________________
>
> 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 14:08:40 UTC