RE: [WARP] Last Call comments (1)

Hi Frederick,

I do not think they are so different.
<feature> points to anything, we can still build the interpretation.
We can build new "worlds" on top of <feature> and <param> elements, independently of any spec IMHO.
<feature> does not necessarily have to point to the same category of components, we can define the categories in any way, e.g. by various IRI namespaces.

I think it can be disputable what <access> is for.
WARP says:
" 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."

Then, how to fit e.g. sms: or tel: schemes into this context?
@subdomains makes also little sense for those schemes.
Apart from DNS/IP issues, I assume that some Web "resources" are not meant to be retrievable, e.g. POSTing a form uses URI to send information to, and not to retrieve a resource.
If we would like the spec to be future-/scheme-proof, we could prepare the model based on actual schemes, as e.g. suggested in my below email. Experience from CORS could also help.

>>if so, doesn't feature imply both the loading and permission to access
>>a library, whereas access is about accessing a resource.
E.g. generic network access (not to specific resource, but just to the information whether the WUA is online/connected) may be regarded as runtime component of the WUA or its environment.

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: Thursday, September 10, 2009 3:01 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; public-webapps@w3.org
Subject: 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.
>


________________________________________

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 Tuesday, 15 September 2009 19:13:24 UTC