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.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.