W3C

List of comments on “Widgets 1.0: Access Requests Policy” (dated 4 August 2009)

Quick access to

There are 7 comments (sorted by their types, and the section they are about).

substantive comments

Comment LC-2259: marcin-01
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: Document as a whole
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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2264
Commenter: Dominique Hazael-Massieux <dom@w3.org> (archived message)
Context: 3 The access Element
Hi,

The attribute "uri" on the <access> element in WARP is somewhat
misleading - what it takes is more a URL pattern than a URI. I would
suggest renaming it in "urlpattern" or just "pattern" (unless there are
already many implementations that rely on that attribute name).

There may be lessons to be taken in designing these patterns from POWDER
http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect
the POWDER expressivity needs are much greater than what is needed here.

Dom
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2258: marcos-01
Commenter: Marcos Caceres <marcosc@opera.com> (archived message)
Context: Document as a whole
Hi Robin,
Thanks for putting this spec together... I copy/pasted the spec below
and added inline comments.

Enjoy! :)

On Thu, Aug 6, 2009 at 9:53 PM, Marcos Caceres<marcosc@opera.com> wrote:
> 1 Introduction
>
> User agents running widgets are expected to provide access to
> potentially sensitive APIs (phone book, calendar, file system, etc.)
> that expose data which should not be leaked to arbitrary network
> locations without the user's consent.
>

The above is all true. But this specification does not protect
against "API leakage"; I find the above overstretching a bit. I think
the scope of this specification with regards to <feature> is
underspecified. Either we say nothing about feature, or we need to
talk about this some more in the WG.

> The purpose of this specification is precisely to define the security

maybe "is to precisely define", though I think precisely is redundant.

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

The above paragraph is a single sentence that conveys multiple ideas.
Please break it up into multiple sentences.

> 1.1 Definitions
>
> An access request is a request made by an author in the configuration
> file

configuration file > configuration document (check globally)

> for the ability to retrieve one or more network resources
> identified via the access element's uri and subdomains attributes.
>

I would rewrite as:

An access request is a request made by an author to the user agent for
the ability to retrieve one or more network resources. The network
resources and author requests to access are identified via the access
element's URI and subdomain attribute, within the widget's
configuration document.

> To grant access means that the user agent authorises widget execution
> scopes to retrieve one or more network resources via the user agent.

"Widget execution scope" is <dfn>'d but not actually defined in this
definition. I can only assume this means stylesheets, script elements,
etc. However, implementers that have not been taking part in the
discussion may incorrectly assume that the HTML5 "inline content"
rules still apply (i.e., cross-origin is allowed for images, iframe,
scripts, etc. is allowed in widgets, as it is on the Web.... which is
not the case for Widgets).


> Note that some schemes (e.g. mailto:) may be handled by third-party
> applications and are therefore not controlled by the access mechanism
> defined in this specification.

This note is marked up to use RFC2119 terminology (please remove MAY).
Also, the note is not marked up as a Note:.

> To deny access is to refuse to grant access.

Please rewrite as: To deny access means that the user agent rejects an
author's request to grant access.

> A network resource is a retrievable resource of any type that is

Maybe say "any content type" or mime type?

> identified by a URI that has a DNS or IP as its authority.
>
> A feature-enabled API is an API that is for one reason or another
> considered to be sensitive (typically because it has access to the

missing "is" ("is considered")

> user's private data). It may be that this API can also be activated in
> a broader web context (e.g. through user interaction, prompting,
> etc.);

> but here we are considering the case where it was activated
> based on processing the <feature> element in the widget's
> configuration file as per the Widgets 1.0: Packaging and Configuration
> specification [Widgets-PC]

"We" is weird above. .Also, configuration file > configuration document.

I kinda get the above, but not really. The text needs to be tightened
up a little bit.

> The widget execution scope is the scope (or set of scopes, seen as a
> single one for simplicity's sake) being the execution context for code
> running from documents that are part of the widget package.

Oh, ok. The first dfn of widget execution scopes should be a link to
this one. Still, this definition does not cover style sheets and
inline context. Is that correct?

> The web execution scope is the scope (or set thereof) being the
> execution context for code running from documents that have been
> loaded off the web.

Maybe leech some HTML5 terminology here?

> 1.2 The Widget Family of Specifications
>
> This section is non-normative.
>
> This specification is part of the Widgets 1.0 family of
> specifications, which together standardise widgets as a whole. The
> Widgets 1.0: APIs and Events [Widgets-APIs] specification defines APIs
> to store preferences and capture events. The Widgets 1.0: Digital
> Signature [Widgets-DigSig] specification defines a means for widgets
> to be digitally signed using a custom profile of the XML-Signature
> Syntax and Processing Specification. The Widgets: 1.0: Automatic
> Updates [Widgets-Updates] specification defines a version control
> model that allows widgets to be kept up-to-date over [HTTP].

I rewrote this boilerplate for the P&C spec. Now uses a nice list,
etc. Please use that one.

> 1.3 Design Goals and Requirements
>
> This section is non-normative.
>
> The design goals and requirements for this specification are captured
> in the Widgets 1.0 Requirements [Widgets-Reqs] document. This document
> addresses the following requirements:

During the teleconf with the Director to progress P&C to CR, Ralf
asked me to tighten up the above text indicating precisely which date
version of the requirements are being met by this draft. Please copy
the text from P&C for the above.

>    * Default Security Policy: see Security model.
>    * Security Declarations: see the access element.
>
> Additionally, the following requirements are taken into account:
> Restricted access to remote web resources
>
> Motivation:
>    Security, Current development practice or industry best- practice,
> Interoperability.
> Rationale:
>
>    A Widget may need to make use of external web services in order to
> function, for example using AJAX to obtain information.
>
>    A User Agent may wish to restrict access to external web services
> from Widgets based on white lists or black lists, for example using a
> proxy server or firewall.
>
>    This raises the possibility for users installing Widgets that are
> unable to function due to access restrictions on remote web services.
>
>    By providing a mechanism for declaring a Widget's access
> requirements, the usability and interoperability of Widgets can be
> improved.

This statement is unfounded/speculation without a citation.

>    For example, when a user attempts to install a Widget in a User
> Agent, and the Widget Configuration Document declares that it requires
> access to currently blocked services in order to function, the User
> Agent may prompt the user to choose to:
>
>       1. enable access to the service (for example, adding the
> service to a proxy server or firewall white list),
>       2. cancel installing the Widget, or
>       3. proceed with installation, with the user now aware that
> there may be problems with the Widget due to restricted access to
> services.
>
> Additional considerations guiding this specification are maximal
> compatibility with existing web technology (including not breaking
> linking to JS libraries, embedded media, ads, etc.); and not
> restricting the platform in such a way that would make it less
> powerful than the web platform.

All this should be moved out of this spec and into the requirements
document. The requirements document can then be republished at the
same time as this spec.

> 2 Policy
>
> A widget runs in its own widget execution scope. Communication between
> that execution scope and the network is prohibited by default, but may
> be turned on selectively using the access element.

The above needs to be in active voice. Also, the user agent is doing
this in operation, so I would recommend adding a MUST in there:

A user agent must prohibit communication between that execution scope
and the network is prohibited by default,. A user agent may grant
access requests selectively using the access element.

The word "selectively" bothers me, as it implies some kind of
artificial intelligence.

> This prohibition
> must apply equally to access through APIs (e.g. XMLHttpRequest) or
> through inlined content (e.g. iframe, script, img).

"This prohibition" doesn't make sense there, which prohibition. Make
the above either a statement of fact (drop the must), or convert it to
a testable assertion (A user agent must..).

> Scripts executing in that widget execution scope have access to
> feature-enabled APIs. Note that other mechanisms may provide access to
> the same APIs in other contexts, but that that is outside the scope of
> this specification.

Again, an untestable assertion and you use the word Note where it is
not marked up as a "note". This note also uses RFC2119 terminology
yet does not apply to a product. I suggest dropping "may" (use "can")
instead and making this into an actual note.

Whoa! I just realized that this spec lacks a Conformance section.
Wooopsy! :) We don't have any products defined that can conform to
this spec?

> When permission is selectively turned on to access a given set of
> network resources, it must be granted equally to APIs and inlined
> content.

How is a permission selectively turned on? via a authorized grant request?

The above is in passive voice, please rewrite in active voice.

Inline content should be formally defined (or reference HTML5).

> The exact rules defining which execution scope applies to network
> resources loaded into a document running in the widget execution scope
> depend on the language that is being used inside the the widget.

Break here. Mark up the following as an example:

> For
> instance, in HTML 5 [HTML5] a script loaded off the network into a
> document running in the widget execution scope is itself in the same
> scope,

Full stop.

> whereas a document loaded off the network in an iframe will be
> in the web execution scope.

I probably already said this, but web execution scope should just be
defined in terms of HTML5.

> 3 The access Element
>
> The access element allows authors to request permission from the user
> agent to retrieve a set of network resources.

You should mention the configuration document here.

> A user agent must prevent the widget execution scope from retrieving
> network resources, using any method (API, linking, etc.) and for any
> operation, unless the user agent has granted access to an explicitly
> declared access request.

The above is nice, but it is out of context here.

> However, a user agent may grant access to certain URI schemes (e.g.,
> mailto:) without the need of an access request if its security policy
> considers those schemes benign.

Ok.

> A user agent may deny access requests
> made via the access element (e.g. based on a security policy, user
> prompting, etc.).

"deny access requests" links to access requests, link deny to "deny
access" too.

> The access element is in the http://www.w3.org/ns/widgets namespace.

"... as defined in the P&C spec".

> Context in which this element may be used:
>    As a child of the widget element.
> Content model:
>    Empty.
> Occurrences:
>    Zero or more.
> Expected children:
>    none.
> Localizable via xml:lang:
>    No.

All good.

> Attributes
>
> uri
>    Required.

Required what? :) Change to authoring guideline, as per P&C please.

> A URI attribute that defines the specifics of the access

What's a uri attribute ? (missing link to P&C)

> request that is requested. Additionally, the special value of U+002A
> ASTERISK (*) may be used.

Passive voice and use of RFC2119 for a non-testable assertion. Change
to a statement of fact and add an authoring guideline about "*".
Actually, just remove the last sentence and change the following.

> This special value provides a means for an

This special value > The reserved value of U+002A ASTERISK (*)

> author to request from the user agent unrestricted access to resources
> through any and all schemes and protocols supported by the user agent.

Maybe add a note here saying that user agents are under no obligation
to grant such preposterous requests :)

> subdomains
>    Optional. A boolean attribute that indicates whether or not the

What's a boolean attr? missing link to P&C for external reference.

> host component part of the access request applies to subdomains of
> domain in the uri attribute. The default value when this attribute is
> absent is false, meaning that access to subdomains is not requested.
>
> Usage example
>
> This example shows the expected usage of the access element.
>
> <widget
>  xmlns ="http://www.w3.org/ns/widgets"
>  width ="400"
>  height="500">
>  <name>Flight Tracker</name>
>  <access uri="http://example.com/api/"/>
>  <access uri="https://example.net"/>
>  <access uri="http://example.org" subdomains="true"/>
>  <access uri="http://example.com/dahut?bar"/>

Phew! I was about to say that mentioning a "dahut" would make this
example vastly more comprehensible. Thankfully, it is there.

>  <access uri="*"/>
> </widget>
>
> 4 Processing model

Here you need to say that this happens as part of Step 7's algorithm
to process a configuration document, in P&C.

> Let access-request list be an empty list of objects that represent the
> author's access requests to network resources.
>
> Note: The following sequence of steps relies on terminology that is
> defined in RFC 3987 [RFC3987] and in the URI [URI] specification. The
> particular the terms derived from the IRIs specification include:
> ifragment , ipath, iuser info, and iquery.

You also use terminology from P&C, e.g., ignore. rule for getting a
single attribute value, etc.

> For each access element that is a direct child of the widget element:
>
> If the uri attribute is absent, then this element is in error and the
> user agent must ignore it.
>
> Let uri be result of applying the rule for getting a single attribute
> value to the value of the uri attribute. If the result is a single
> U+002A ASTERISK (*) character, then prepend the a U+002A ASTERISK to
> the access-request list and skip all steps below.

Would it not be better to collect all, as the UA might choose to
ignore this access request, but grant more granular ones?

> If uri is not a valid URI, if it has no host component, or if it has a
> iuser info component, then this element is in error and the user agent
> must ignore it.


> Let sub domains be the result of applying the rule for getting a
> single attribute value to the value of the subdomains attribute. If
> the value of sub domains is not a valid boolean value, then this
> element is in error and the user agent must ignore it.

This is inconsistent with the behavior of boolean attributes, but I
can live with this. It is inconsistent as it should default to "false"
if the value of subdomain is in error.

> If uri has an ifragment component, remove it from uri. Let scheme be
> the scheme component of uri. Let host be the host component of uri.
> Let port be the port component of uri or if there is no port component
> the default value for the protocol that corresponds to scheme. Let
> path be the ipath component of uri concatenated to the iquery
> component of uri.
>
> If scheme is unsupported by the user agent, then this element is in
> error and the user agent must ignore it.
>
> If scheme is "http" or "https", then the value of host must be
> processed

Convert to active voice.

> using the ToASCII algorithm as per [RFC3490], then decode,
> as per [URI], all percent-encoded parts of path that are unreserved
> characters.

Then store all these access requests in the configuration defaults
table, please.

> Rule for Granting Access to a URI identifiable Resources

This rule is never applied during processing. Maybe it should be
applied to derive the overall access scope?

> When multiple access elements are used, the set of network connections
> that are allowed is the union of all the access requests that were
> granted by the user agent. The following rules are applied to

Applied by who? When? where? why? how?

> determine what each access element is requesting access to.

I don't think you should talk about access elements here, talk about
access requests. Access requests being the data derived by the user
agent from processing the XML serialization of a request for access by
the author.

>   1. The request for access made by the access element is for network
> resources that have:
>          * a scheme equal to scheme; and
>          * if subdomains is false, a host exactly equal to host; and
>          * if subdomains is true, a host either exactly equal to
> host, or that is a subdomain of host; and
>          * a port equal to port; and
>          * a path and query concatenation that is equal to path or
> begins with it.

what is "it"? The above is redundant. You already determined this in
the processing step.

> At runtime, when a network request is made from within the widget
> execution scope, the user agent matches it against the rules defined
> above, accepting it if it matches and blocking it if it doesn't.

Break. You have another note...

> Note
> that if scheme is "http" or "https", host comparisons must be
> performed in a case-insensitive manner.

You use the word must as part of a note and don't identify the product
to which it applies. Please make this a statement of fact or a
testable assertion.

> As a special case, the uri attribute may hold the value *.

As above, wrt "may"

>In that
> case, the access element is considered

Considered by who?

> to request access to all
> network resources without limitation (e.g. retrieve RSS feeds from
> anywhere). If access is granted

Granted by who?

> to such a request, then all other
> network access requests must be granted.

By who? please identify.

> Acknowledgements
>
> The editor would like to thank (in no particular order): the OMTP
> BONDI effort, Jere Kapyaho, Thomas Roessler, Art Barstow, Mohamed
> Zergaoui, Arve Bersvendsen, and Batman Caceres.

heh, nanananaaaa Batman! :)

> Normative References
>
> [RFC3987]
>    Internationalized Resource Identifiers (IRIs). RFC3987, M. Duerst,
> M. Suignard. January 2005.
> [URI]
>    Uniform Resource Identifier (URI): Generic Syntax. RFC 3986, T.
> Berners-Lee, R. Fielding and L. Masinter. January 2005.
> [RFC3490]
>    Internationalizing Domain Names in Applications (IDNA). RFC 3490,
> P. Faltstrom, et al. March 2003.
> [Widgets-PC]
>    Widgets 1.0: Packaging and Configuration, M. Caceres. W3C, December 2008.
>
> Informative References
>
> [Widgets-Reqs]
>    Widgets 1.0 Requirements, M. Caceres. W3C, April 2009.
> [Widgets-DigSig]
>    Widgets 1.0: Digital Signature. M. Caceres, . W3C, W3C Working
> Draft April 2009.
> [Widgets-Updates]
>    Widgets 1.0: Updates. M. Caceres. W3C Working Draft October 2008.
> [Widgets-APIs]
>    Widgets 1.0: APIs and Events. Arve Bersvendsen et al. W3C Working
> Draft 23 April 2009.
> [HTML5]
>    HTML 5. Ian Hickson et al. W3C Working Draft 23 April 2009.
> [HTTP]
>    Hypertext Transfer Protocol -- HTTP/1.1. RFC 2616, R. Fielding, et
> al. June 1999.
> [HTTPS]
>    HTTP Over TLS. RFC 2818, E. Rescorla. May 2000.
>

I didn't check the references, but I assume they are ok.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2260
Commenter: Breitschwerdt, Christian, VF-Group <christian.breitschwerdt@vodafone.com> (archived message)
Context: the example is unclear in
Hi,

Wrt the latest draft of WARP, I noticed that the usage example of the access element is actually not very meaningful as the last access element with uri="*" allows access to practically everywhere, thus turning the earlier more restrictive permissions pointless.

Regards,
Christian
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2261: art-01
Commenter: Arthur Barstow <art.barstow@nokia.com> (archived message)
Context: Document as a whole
Below are some comments regarding the 4-August-2009 Last Call Working
Draft of the WARP spec:

<http://www.w3.org/TR/2009/WD-widgets-access-20090804/>

-Regards, Art Barstow


1. This spec is missing a statement about which sections are
normative and which are non-normative as well as the RFC2119
boilerplate re keywords

2. Section 1.1 - Network Resource - since this section is presumably
normative, this definition should cite the relevant spec that defines
URI and the authority components

3. Section 1.1 - Web Execution Scope - instead of "have been loaded
off the web", I think the important point (to contrast this
definition with Widget Execution Scope"), would be to say "are
external to the widget package".

4. Section 1.2 - replace the text in this section with a reference to
the Widgets Family of Specs wiki:

<http://www.w3.org/2008/webapps/wiki/WidgetSpecs>

5. Section 1.3 - the "Restricted access to remote web resources"
requirement (including Motivation and Rationale) should be moved to
[Widgets-Reqs] and a pointer to this requirement should be added to
the list of requirements addressed by this spec. BTW, I think the
title of this requirement should use "Restrict" [verb] and not
"Restricted" [adjective]; NB "A UA may wish to Restrict access ...".

6. Section 1.3 - I don't understand the following statement. For
starters, what is "This"?

[[
This raises the possibility for users installing Widgets that are
unable to function due to access restrictions on remote web services.
]]

Given the statement that follows the above ("By providing ...") and
the ensuing "For example ...", perhaps the statement quoted above
should be deleted or concatenated with its previous statement/paragraph.

7. Section 2 - a few items:

a. the term Policy is not defined and it should it be (perhaps in
Section 1.1)

b. This section is titled "Policy" yet the section itself never uses
that term. This section's focus seems to be "widget execution scope".

c. First paragraph - the use of "MAY" should be changed to "may"
since its usage is non-normative (that sentence is informative). The
use of "MUST apply" should be changed to "applies" since that
sentence is also informative.

d. 2nd para - change MAY to "may" since this sentence is non-
normative [NB the sentence starts with "Note".]

e. 3rd para - it seems like the essence of this paragraph is stated
in the first paragraph thus this paragraph should be deleted

f. I think this Section should be marked as non-normative

8. Section 3:

a. The "MAY" in ... this element MAY be used" should be "may"

b. The "MAY" in the definition of the uri attribute should be "may"

c. To be consistent with the P&C spec, the valid boolean values
should be explicit as is done in that spec:

http://www.w3.org/TR/2009/CR-widgets-20090723/#attribute-types

Alternatively, tighten up the following part of Section 4 such that
the valid boolean values are well-defined:

[[
Let sub domains be the result of applying the rule for getting a
single attribute value to the value of the subdomains attribute. If
the value of sub domains is not a valid boolean value, then this
element is in error and the user agent must ignore it.
]]

9. Section 4:

a. The "rule for getting a single attribute value" should be defined

b. Typo: "then prepend the a U+..." should be "then prepend U+..."

c. The following text has a bug since the

10. Informative Refs - update A&E spec to its new title
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2262: marcin-02
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: Document as a whole
What is the relation of <access> element to openURL from Widget interface specification?

openURL examples use sms: and tel:.



As discussed in another mail thread [1], the scope of WARP in terms of programmatic usage of URIs focuses on XHR.

Should then openURL be incorporated there as well?



Thanks,

Marcin



[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2263
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: Document as a whole
In section 1.3 [1] (non-normative) I suggest changing all the instances of word "service" to "resource".
Service could mean e.g. mail, telephony, messaging service etc. and WARP is about access to retrievable network resources.

Thanks,
Marcin

[1] http://dev.w3.org/2006/waf/widgets-access/#design-goals-and-requirements


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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org