Re: [WARP] Last Call comments (1)

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

Received on Thursday, 10 September 2009 13:01:39 UTC