Is the fundamental difference of feature and access the following:
feature - API set expected to be possibly used
access - network resource to be accessed.
if so, doesn't feature imply both the loading and permission to access
a library, whereas access is about accessing a resource.
if this is correct, aren't these fundamentally different?
regards, Frederick
Frederick Hirsch
Nokia
On Aug 27, 2009, at 2:06 PM, ext Marcin Hanclik wrote:
Hi All,
Here are a couple of the Last Call comments to WARP LCWD [1].
They were already partially presented in my emails [2] and [3].
The comments below are more of architectural nature than just
editorial fixes.
That is why the arguments together with the derived understanding
are followed by the proposed changes to the specification. The
proposed changes below are incomplete.
MOTIVATION / ARGUMENTS
The main motivation for the changes proposed below is the syntax and
the underlying architecture related to the treatment of the network
access - from the widget's or web application's point of view - as
the resource to which access is to be controlled by some security
policy.
The specification that underlies the overall widgets ecosystem,
Widgets 1.0: Packaging and Configuration (further referred to as
P&C) [4], defines a method to express the dependency of the widget
on a resource/component, namely the <feature> element.
P&C in [5] - the definition of the <feature> element - states:
"A feature is a runtime component"
"The feature element serves as a standardized means to request the
binding of an (IRI) identifiable runtime component to a widget for
use at runtime."
"...a widget can attempt to access the feature identified by the
feature element's name attribute."
P&C [6] states non-normatively:
"The Widgets 1.0: Access Requests specification defines a means to
request access to URI-identifiable resources (e.g. resources on the
Web) (see [Widgets-Access])."
On the other hand, however, WARP states [7]:
" The purpose of this specification is precisely to define the
security model for network interactions from within a widget that
has access to sensitive information, and to provide means for a
widget to declare the need to access specific network resources so
that a policy may control it."
And [8]
"A network resource is a retrievable resource of any type that is
identified by a URI that has a DNS or IP as its authority."
WARP states that it addresses [9] the requirements [10] and [11].
[10] R52 Default Security Policy:
"A conforming specification MUST specify a default security policy
that limits the privileges afforded to a widget at runtime. The
default security policy MUST be specified in such a way that it
forces a widget package to explicitly request permission to use
particular device capabilities (see also the Security Declarations
requirement)."
[11] R54 Security Declarations:
"A conforming specification MUST specify or recommend a means for
declaring that an instantiated widget will require access to
resources or services that have the potential to introduce a
security risk for an end user. A conforming specification SHOULD
also make it possible to externalize and associate security
declarations with a particular widget package (e.g., by allowing
security declarations to be securely acquired from an external
trusted authority over HTTP). This MUST include a means of declaring
the APIs that a widget expects to access. When possible, a
conforming specification MUST specify a means to verify the
authenticity and integrity of security declarations included in the
widget package (e.g. by using Digital Signatures)."
One of the motivations against the @required attribute on <access>
element was prompting [12], and prompting is included the current
LCWD [9]. Therefore it is unclear what the argumentation against
@required attribute is (this is related to the semantics of the
<access> and <feature> elements as outlined below).
The above statements result in the following understanding:
1. WARP specification actually defines the syntax for expression of
dependency of a widget only on network resources. So here, the name
of the specification is misleading (taking into account only this
point, we could require it be named "Widgets 1.0: Network Access
Policy").
2. The dependency of a widget on network resources is atomic and
unconditional.
3. The resource is identifiable by URI.
4. The URI-identifiable resources are not necessarily truly remote
network resources.
5. Since network access introduces various risks (e.g. when roaming)
the requirement [11]:
" A conforming specification MUST specify or recommend a means for
declaring that an instantiated widget will require access to
resources or services that have to the potential to introduce a
security risk for an end user."
seems not to be fully satisfied, since the access to network
resources is unconditional in the WARP specification, whereas in
reality there may be other time- and/or location-dependent aspects
that could influence the decision of the WUA or its user regarding
the installation or instantiation of a widget.
From the above it is visible that the widgets family of
specifications defines two families of URI-identifiable resources,
one by means of <feature> element and secondly based on the
<access> element.
The basic semantic difference between both approaches is that the
expression of dependencies based on <feature> element is conditional
(e.g. a widget may install and run without a resource being
available or without the access to the resource), and based on
<access> element it is unconditional (e.g. a widget will not install
or run completely if the access to the network resource is not
granted/available).
It should be noted that from the historical perspective the <access>
element was earlier in the widget set of specifications than the
<feature> element. At first sight one may get an impression that
addition of the <feature> element and keeping the <access> element
are parts of an unaccomplished architecture-defining operation in
the widgets family of specifications.
The approach based on <feature> element seems to be more robust,
e.g. it allows expression of conditional dependencies.
It is not clear why - generically - we would need both approaches.
One approach, based on the <feature> element seems (as outlined as
proposed change below and in [2], [3]) to be fully capable of
handling the use cases that initially motivated the adoption of the
<access> element.
The Device API Working Group (DAP), chartered in [13], is to define:
"Security Policy Framework, to express security policies that govern
access of Web Applications and widgets to security-critical APIs".
From the architectural point of view and in order for W3C to define
a consistent set of specifications, it could be recommended to
define any security-related aspects in one place, currently this
work is planned in the DAP group.
The XMLHttpRequest APIs are currently excluded from the consistent
approach, since access to them (or to the results the call to that
API could deliver) is implicitly controlled by WARP specification.
The access to resources (also other than the network) - additionally
to the access to the security-critical APIs (XMLHttpRequest API
should be perceived as such) - should be governed consistently by
the set of rules and policies. From this perspective, WARP could
result in being an obstacle to having a clear model and architecture
in the near future, since the work in DAP WG has not fully started
yet and it is not clear from WARP whether the access to network or
other services that could be specified by URI is meant to be
programmatic (i.e. by a call to some API as planned in DAP) or is to
be realized by some other means (e.g. by User Agent's interaction
with some other applications).
Apart from the fact that the value of "*" is not a valid URI, the
requirement for the current @uri attribute to be just a valid URI
seems insufficient.
It is possible that in the future the @uri attribute or its
equivalent is used for other schemes. Then further or more refined
syntaxes may have to be imposed that could be incompatible with the
current model based on URI syntax and @subdomains attribute. See
e.g. the discussion about mailto [14] on WhatWG mailing list.
Starting with the principle "everything a widget may need from the
User Agent is expressible as a feature", the specification of the
dependencies based on the <feature> element seems to provide clarity
and consistency. The design based on <feature> element seems
naturally extensible, thus provides a good background for future work.
On the other hand the current design of <access> element and
@subdomains attribute is hardly expected to be extensible for other
protocols.
PROPOSED CHANGES
Given the semantic similarities (or equivalence) between:
<access uri="http://example.org" subdomains="true"/>
and e.g.:
<feature name="http://www.w3.org/widgetfeatures/networkaccess/http"
required="false">
<param name="uri" value="http://example.org"/>
<param name="subdomains" value="true"/> </feature>
I propose the following:
1. Change the name of the specification to "Widgets 1.0: Network
Access Feature" and focus on per-URI-scheme definition of the syntax
dependencies and functionality.
Examples:
a)
The following feature could replace the generic network access
(proposed in the LCWD as "*" for @uri attribute):
<feature name="http://www.w3.org/widgetfeatures/networkaccess"
required="true" />
b)
The following features could define the http and https access
<feature name="http://www.w3.org/widgetfeatures/networkaccess/http"
required="false">
<param name="uri" value="http://example.org"/>
<param name="subdomains" value="true"/>
<param name="ports" value="80, 8080"/> </feature>
<feature name="http://www.w3.org/widgetfeatures/networkaccess/https"
required="true">
<param name="uri" value="https://example.org"/>
<param name="subdomains" value="false"/>
<param name="interface" value="XMLHttpRequest"/>
<!-- port defaults to 443 -->
</feature>
c)
The following feature could define access to SMS feature:
<feature name="http://www.w3.org/widgetfeatures/networkaccess/sms"
required="true">
<param name="uri" value="sms:+16177166200"/> </feature>
<feature name="http://www.w3.org/widgetfeatures/networkaccess/sms"
required="true">
<param name="countrycallingcodes" value="1,48,49,34"/> </feature>
2. Rewrite parts of the specification - specifically section 3,
while keeping its majority as is - to adhere to the syntax of the
<feature> and <param> elements as outlined above.
3. Refrain from specifying the default policy; remove the word
security from the specification (since this is to be handled in DAP).
4. Focus in the specification text only on declarative aspects of
the intention of the author of the widget, leaving e.g. prompting
aspects for DAP. I.e. assuming that the network access is
conditional, what are the implications for the widget's code and
author in case the network access is not present or its presence is
dynamic? (e.g. provide a definition of the event mechanism).
5. In order to be able to define the IRI for network access feature,
another document should probably be prepared that would also define
the namespace for the further feature definitions (e.g. http://www.w3.org/widgetfeatures/)
.
6. Focus in the specification only on http and https. "subdomains"
attribute / value of the parameter is valid mainly for this protocol
family (also including e.g. rtsp, ftp etc.). Other schemes, like
sms, tel, mms (there is no RFC for some) have their own
specificities, e.g. country calling/dialing codes, shortcodes.
Thanks.
Kind regards,
Marcin
[1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html
[4] http://www.w3.org/TR/widgets
[5] http://www.w3.org/TR/widgets/#the-feature-element
[6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications
[7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction
[8] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#definitions
[9]
http://www.w3.org/TR/2009/WD-widgets-access-20090804/#design-goals-and-requirements
[10] http://www.w3.org/TR/widgets-reqs/#default-security-policy
[11] http://www.w3.org/TR/widgets-reqs/#security-declarations
[12] http://www.w3.org/2009/06/09-wam-minutes.html
[13] http://www.w3.org/2009/05/DeviceAPICharter
[14] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022264.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.hanc...@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.