Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document lists the design goals and requirements that specifications would need to address in order to standardize various aspects of widgets. A Widget is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and widgets that make use of Web services, like weather forecasters, news readers, e-mail checkers, photo albums and currency converters.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
You can always find the latest Editor's Draft of this document in the W3C's CVS repository; it is updated on a fairly regular basis.
This is the 15 September 2008 Second Last Call Working Draft version of the "Widgets 1.0: Requirements" document (formerly "Widgets 1.0: Requirements"). The Last Call period ends on 13 October 2008. This version reflects over two years of gathering and refining requirements for the Widgets 1.0 family of specifications. The requirements were gathered by extensive consultation with W3C members and the public, via the Working Group's mailing lists (WAF archive, WebApps archive). The purpose of this Last Call is to give external interested parties a final opportunity to publicly comment on the list of requirements. The Working Group's goal is to make sure that vendor's requirements for Widgets are complete and have been effectively captured. The Widgets 1.0 family of specifications will set out to address as many requirements as possible (particularly the ones marked with the keywords must and should).
This document is produced by the Web Applications (WebApps) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain. The public is encouraged to send comments to the WebApps Working Group's public mailing list public-webapps@w3.org (archive). See W3C mailing list and archive usage guidelines.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
A widget is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. A widget may run as a stand-alone application (meaning it can run outside of a Web browser), and it is envisioned that the kind of widgets being standardized by this effort will one day be embedded into Web documents. In this document, the runtime environment in which a widget is run is referred to as a widget user agent. Note that running widgets may be the specific purpose of a widget user agent, or it may be a mode of operation of a more genetic user agent (eg. a Web browser). A widget running on a widget user agent is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource. For more information and definitions related to widgets, see the Widget Landscape document.
As argued by the Widget Landscape document, there is currently no formally standardized way to author, package, digitally sign or internationalize a widget resource for distribution and deployment on the Web. In the widget space, although many successful widget user agents are now on the market, widgets built for one widget user agent are generally not able to run on any other widget user agent.
This document lists the design goals and requirements that specifications need to address in order to standardize how widgets are authored/scripted, digitally signed, secured, packaged and deployed in a way that is device independent, follows W3C principles, and is as interoperable as possible with existing market-leading user agents and existing Web browsers.
To be clear, this specification describes the requirements for installable/desktop or mobile widgets (akin to Apple's Dashboard, Opera Widgets, Opera Mobile Widgets. or Yahoo!'s Konfabulator Widgets). This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets, which are being specified by the Open Ajax Alliance's IDE Working Group. Please see the Widget Landscape document for a discussion on the differences between widgets and web widgets.
This section is normative.
The key words MUST, MUST NOT, required, not required, SHOULD, should not, recommended, MAY, and optional in the normative parts of this document are to be interpreted as described in RFC2119.
This specification only applies to one class of product: W3C Technical Reports. The working group will attempt to standardize widgets by addressing the requirements listed in this document through the Widgets 1.0 family of specifications, which include:
Note: Only normative statements marked with the keywords MUST and SHOULD are required to be standardized by the Widgets 1.0 family of specifications. The Working Group will publish an informative Working Group Note at the end of the standardization process listing any requirements that were not formally addressed by the Widgets 1.0 family of specifications.
Although a number of specifications will be created to address the requirements enumerated in this document, in some instances, it will be the amalgamation of multiple parts of individual specifications that address a single requirement. Never the less, this document speaks only of a conforming specification (defined below). The Working Group's choice to have multiple specifications address the following requirements, as opposed to having a monolithic specification (e.g. HTML5), was made for the following reasons:
A conforming specification is one that
addresses one or more requirements listed in this document. A conforming
specification SHOULD attempt to address requirements
marked with the keywords should
or may
unless there is a technically valid reason not
to do so. The validity of technical reasons for not addressing any
requirements will be determined by Working Group members, and through
communication with vendors and the public on the Working Group's public
mailing list public-webapps@w3.org (archive).
This section is informative.
This section lists the design goals that the working group recommends a conforming specification adopt when attempting to standardize the various standardizable aspects of widgets identified in the Widget Landscape document. The requirements are directly motivated by the following design goals. The design goals are listed in alphabetical order.
Recommendation StatusW3C Process).
This section is normative.
This section enumerates the requirements that a conforming specification would need to address to standardize widgets. These requirements are directly motivated by the design goals and are based on an iterative process of feedback from the public, discussions with various vendors, and a survey of market-leading widget user agents.
This section enumerates the requirements that a conforming specification needs to address to standardize the packaging format of a widget. The objective of this section is to ensure that a conforming specification recommends a general packaging format that is, amongst other things:
A conforming specification MUST recommend a packaging format that is royalty free, open, and widely implemented across market-leading widget user agents and compatible with mobile devices. In addition, a conforming specification MUST specify exactly which aspects of the packaging format are to be supported by conforming widget user agents.
A conforming specification MUST recommend that a conforming widget resource be sent over HTTP with a formally registered MIME Type that is specific to the Widgets 1.0 Family of specifications. The Working Group MUST formally register the MIME type with the Internet Assigned Numbers Authority (IANA). A conforming specification MUST specify how a widget user agent will process a widget resource that was served with an unsupported MIME type or when the MIME type is unspecified.
A conforming specification MUST specify a file extension for widget resources not intended to be sent over HTTP. In addition, a conforming specification SHOULD recommend that a widget resource always contains a file extension, even when being sent over HTTP.
A conforming specification MUST recommend a packaging format that supports structuring resources into collections such as files and directories (understood in this document in a broader sense than in some popular file systems, namely as forms of generic logical containers). In addition, the packaging format SHOULD allow authors to add and remove resources of a widget resource without needing to recreate the widget resource.
A conforming specification MUST indicate if any resources (files or directories or similar logical containers) are mandatory or reserved and what specific function they serve in the widget resource. A conforming specification SHOULD specify graceful error handling/recovery procedures if those resources are used erroneously or missing.
resources
'
directory located at the root of the widget resource.A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system (if any) to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed.
<img
src="images/bg.png'/>
where the src
attribute
resolves to something akin to "widget://myWidget/images/bg.png
"). To disable
access by widget instances to the underlying file system (if any) or
other resources which are not instances of the same widget or resources
contained in the widget resource used to create the current set of widget
instances.A conforming specification MUST recommend a packaging format that allows for non-ASCII characters in file and directory names, allowing authors to create widgets suitable for various cultures and languages, as well as multilingual contexts. The packaging format MUST either provide for a declaration of the character encoding used or specify what it is. The UTF-8 character encoding SHOULD be either the default (if multiple encodings are allowed) or sole encoding used.
A conforming specification MUST provide guidelines that explain to authors how resources need to be structured for the purpose of internationalization.
'resources/en/
' for all English content, and
'resources/en-au/
' for further localized Australian-English
content, and so on).A conforming specification SHOULD specify a processing model that automatically localizes content when authors follow the localization guidelines.
A conforming specification MUST recommend a packaging format that is suitable for delivery to many devices, particularly Web-enabled mobile devices.
A conforming specification MUST recommend a packaging format that supports both uncompressed data and OPTIONAL data compression. A conforming specification SHOULD also recommend at least one royalty-free default compression/decompression algorithm that is compatible with market-leading widget user agents and implementations of the packaging format on mobile devices.
This section enumerates the requirements that a conforming specification needs to address to standardize the configuration document. The objective of this section is to ensure that a conforming specification specifies a configuration document format that defines:
A conforming specification MUST specify the configuration document language using a common data interchange format, as well as the rules for processing the configuration document language and any micro-syntaxes represented as character data. A conforming specification SHOULD specify a formal schema for the language, as well as define any configuration defaults. The schema SHOULD NOT be a normative part of the conforming specification, but MUST be suitable for use by conformance checkers. A conforming specification MUST recommend that configuration documents be encoded in Unicode's UTF-8. A conforming specification MAY specify the configuration document language using alternative standardized data interchange formats (e.g. JSON) and schema.
A conforming specification MUST specify the structure and semantics of XML elements that represent metadata about a widget. The conforming specification MUST describe a model for how that metadata is to be processed by a widget user agent. A conforming specification MUST specify graceful error handling procedures for all metadata elements for when values are in error, or contradictory to the system, or declared erroneously by an author. The metadata MUST be extractable, processable and reusable in other contexts (for instance, to create an online gallery). In addition, a conforming specification SHOULD make it clear to authors which elements are optional and which elements are mandatory.
A conforming specification MUST specify the structure and semantics of elements that represent data about the authorship of a widget, including an author's name, e-mail, and organization. In addition, a conforming specification MUST specify the structure and semantics of elements that represent data about the widget, including the name, version number, a unique identifier, and a description of what a widget does.
A conforming specification MUST specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice. In addition, A conforming specification MUST provide a means to declare who holds the copyright for the widget, as well as a model for how this data must be processed by a widget user agent.
For widgets that make use of a rendering context, a conforming specification SHOULD specify an OPTIONAL means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). A conforming specification MUST specify that styling by the author takes precedence over dimensional values declared in the configuration document or any dimensional values implicitly computed by the widget user agent.
A conforming specification MUST specify a declarative bootstrap mechanism that addresses the start file that is to be initially instantiated at runtime (the instantiated widget). The bootstrap mechanism MUST NOT be able to address or instantiate local resources outside the scope of the widget resource. However, the bootstrapping mechanism MAY be able to address a resource on the Internet, but only of a MIME type allowed by the automated bootstrap requirement (below) or resources that are of media types supported by a widget user agent. A conforming specification MAY also allow authors to declaratively bootstrap proprietary resources within the widget resource, so long as they are able to be processed or instantiated by the widget user agent. If a bootstrap has not been declared by an author, then automated bootstrapping MUST occur as described in the automated bootstrap requirement.
/ui/clock.svg
'). Alternatively, resource might be a HTML
document that when combined with the visual rendering
dimensions requirement displays at the appropriate size.A conforming specification Should specify an automated model for finding the start file of the widget in the absence of a declarative bootstrap. The automated bootstrap model MUST NOT be able to address resources outside the scope of the widget resource and MUST NOT address resources on the Web over HTTP or any other protocol. The widget user agent SHOULD be allowed to select its preferred format for the start file, and then it should locate that resource first before attempting to locate other resources.
index.htm
, index.html
, index.svg
, etc.) firstly within
localized directory names, as required by automatic localization, and
then within the directories of the widget resource. If that search fails,
then the widget user agent could try finding files with extensions
".html, .svg, etc." starting from the root directory.A conforming specification MUST specify a means to declare iconic representations of the widget for use as alternate or fallback content, standby indicator or in a non-running context. The conforming specification should not limit iconic representations to static images and it SHOULD provide support for alternative text representations of an icon where possible. A conforming specification SHOULD also recommend a default icon MIME type and file name.
A conforming specification MUST specify a means to for authors to declare values of custom and predefined configuration parameters, all of which would be applied as a widget is instantiated. A conforming specification MUST specify the default values for specification-defined parameters in case a parameter is missing or the value supplied by the author is invalid. A conforming specification SHOULD allow a widget user agent to override author defined parameters in circumstances where it might be beneficial for users or has the potential to improve performance or stability of the widget user agent.
width
= 50
indicating the 50
as the value for visual width. Or, in the absence of an
author-declared width, the widget user agent will automatically set the width
to some standardized value (eg. 300
).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. A conforming specification SHOULD also make it possible to externalize and associate security declarations with a particular widget resource (e.g., by allowing security declarations to be acquired from an external trusted authority over HTTP(S)). 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 resource (e.g. by using Digital Signatures).
A conforming specification MUST specify the configuration document in such a way that it can be used independently of the widget resource that contains it. A conforming specification MAY provide guidelines for how the configuration document can be used separately from a widget resource.
This section enumerates the requirements that a conforming specification needs to address to standardize an API for widgets. The objective of this section is to ensure that a conforming specification specifies an API that allows authors to, amongst other things:
A conforming specification MUST specify a set of interfaces that expose properties, methods, and events of an instantiated widget. These interfaces MUST be encapsulated as a self-contained object, or some similar data structure, in a non-object-oriented programming environment.
widget
Object described in
the Dashboard Reference and
Microsoft's System.Gadget
Object described in the Sidebar Reference.A conforming specification MUST specify the APIs in this section in Web IDL or a similar standardized interface definition language.
A conforming specification SHOULD specify a set of interfaces that expose relevant properties and methods of the widget user agent.
A conforming specification MUST specify a set of interfaces for dynamically getting and setting preferences for the widget instance.
A conforming specification must define a set of states in the lifecycle of the instantiated widget as well as how and when an instantiated widget enters each state. Changes in states must have associated events which can be consumed by event handlers, such as scripts. Additionally the API must expose the current state. A conforming specification MUST NOT require the widget user agent to send events to the widget immediately, and should allow the widget user agent to dispatch the events at its convenience.
A conforming specification MUST specify a means that allows authors to check if the widget instance is connected to the network. A conforming specification MUST define the scope of the term network and MUST specify a means by which connection and disconnection events can be captured by an author through script. A conforming specification MUST NOT guarantee event delivery, as there may be cases where a device is running low on power and can not afford to deliver them.
A conforming specification SHOULD specify how an instantiated widget (or any of its presentation contexts) should classify itself to the widget user agent as critical, floating, output-only, etc.. Some of these mode changes may require the end-user's attention, in which a case conforming specification SHOULD recommend that widget user agent find a suitable way to draw the end-user's attention.
A conforming specification SHOULD specify a mechanism, either through an API or through the configuration document, which allows instantiated widgets to bind to third-party APIs that allow access to device-specific resources and services. A conforming specification is not required to specify any APIs to device specific resources or services, but SHOULD provide some means of binding to those APIs if they are available and the user agrees. A conforming specification SHOULD specify that bindings MUST NOT occur without consulting the user or a policy which exists to represent the end user (or the owner of the device).
Note: There are other WGs working on this requirements such as the Ubiquitous Web Applications Working Group (UWA-WG), and the Open Mobile Alliance (OMA) Device Capabilities Working Group.
A conforming specification MUST recommend that a widget user agent implement the XMLHttpRequest object specification.
A conforming specification MAY specify a model and
API to allow multiple instantiated widgets to securely communicate with
each other. A conforming specification attempting to address cross-widget
communication SHOULD provide a way for users to be aware of widget
dependencies and to introduce widgets to each other ("pairing"
and "unparing").
A conforming specification SHOULD specify a means that allows authors to control the iconic representation of a widget resource at runtime.
A conforming specification SHOULD specify a means that allows authors to access data they declared in the configuration document for the widget resource.
A conforming specification SHOULD specify a means that allows authors to open IRIs in a browsing context outside the widget user agent.
This section enumerates the requirements that a conforming specification needs to address to standardize a user interface language for widgets. The objective of this section is to ensure that a conforming specification mandates an accessible language that is well-suited for creating user interfaces.
A conforming specification MUST specify that the language used to declare the user interface of a widget be either HTML or a language that is accessible at the various levels specified by the WCAG 2.0 (perceivable, operable, understandable, and robust): specifically, the language MUST provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through a non-graphical UI. For the user interface language, the role and state of all interface elements MUST be available to screen readers and other assistive technologies, to allow relevant sections of text and functionality to be accessed.
This section enumerates the requirements that a conforming specification needs to address to standardize certain aspects of widget user agents. The objective of this section is to ensure that a conforming specification recommends features that will make widget user agents interoperate more effectively with each other and with Web services.
A conforming specification MUST specify a model to allow widget user agents to automatically check if a new version of a widget resource has become available online or from local storage. A conforming specification MUST recommend that an updated widget is downloaded only with the user's consent and that users be able to cancel or defer updates. An automatic update MUST preserve the identity of a widget, meaning that that preferences previously set by the user are retained after the update process. A conforming specification SHOULD recommend that, when possible, automatic updates be conducted over a secure communication channel. In addition, a conforming specification SHOULD specify a means for updates to be authenticated. A conforming specification should also define a mechanism to protect against downgrade attacks using ancient versions of widgets. A conforming specification SHOULD specify that signature verification policies be applied to updates in a manner that is consistent with those applied upon original installation of the widget.
A conforming specification MUST recommend that a widget user agent allow multiple instances of a widget resource to be instantiated. A conforming specification MAY recommend that implementations which have sufficient resources (CPU, memory, etc.) run widgets concurrently as separate processes.
A conforming specification MUST recommend that a widget user agent implement a means to persistently store user preferences for each widget. A widget user agent MUST persistently retain a widget's preference in the case where a widget is re-instantiated or the widget user agent is restarted.
A conforming specification MUST specify runtime exceptions for when a widget's script attempts to perform an action it's not authorized to perform.
This section enumerates the requirements that a conforming specification needs to address to standardize industry standard signing and an adequate security model for widgets. The objective of this section is to ensure that a conforming specification specifies a security model that:
A conforming specification MUST specify a means to verify the authenticity and data integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification (e.g. the digital signature file itself). A conforming specification MUST provide these capabilities by specifying or recommending a processing model for generating and verifying a digital signature associated with a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509v3.
A conforming specification SHOULD recommend that it should be possible for a widget resource to contain multiple independent digital signatures (i.e. it be possible to include multiple signatures and associated certificate chains). A conforming specification MUST specify the expected behavior when multiple signatures and certificate chains are provided. A conforming specification MUST specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHOULD be treated as unsigned (meaning that widget is treated as if it had no digital signature).
A conforming specification MUST recommend a digital signature format that allows for the signature value(s) and associated certificate chain(s) (if any) associated to the widget resource to be used independently of the widget resource. A conforming specification SHOULD provide guidelines for how any digital signature can be used separately from a widget resource.
A conforming specification MUST recommend that where the integrity of data is protected using a message digest, it MUST be possible to use the SHA-1 message digest algorithm or the SHA-256 message digest algorithm. Due to known weaknesses in the SHA-1 algorithm and the expected lifetime of implementations, a conforming specification MUST strongly recommend the use of SHA-256 to ensure that the overall security of the solution is maintained.
A conforming specification MUST recommend that where a widget resource is digitally signed, either the DSA Signature algorithm and the RSA Signature algorithm be used. A conforming specification MUST recommend that widget user agents support processing of digital signatures created with the DSA signature algorithm or the RSA signature algorithm.
A conforming specification MUST recommend that widget user agents support processing RSA Signature with key lengths up to at least 2048 bits. In addition, a conforming specification MUST recommend support for DSA Signature with key lengths up to at least 2048 bits. A conforming specification MUST recommend to authors that widget packages be signed with RSA with key lengths of at least 2048 bits or be signed with DSA with key lengths of at least 2048 bits.
A conforming specification MUST specify the expected use of valid key
usage extensions and when present (in end entity certificates) MUST
specify that implementations verify that the extension has the digitalSignature
bit set (as defined in X.509v3). A conforming specification MUST
specify that implementations recognize the extended key usage extension
and when present (in end entity certificates) verify that the extension
contains the id-kp-codeSigning
object identifier.
A conforming specification SHOULD specify a means of packaging up-to-date revocation information with digital signature and associated certificate chain (e.g. a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) response stating that certificate has not been revoked). In addition, a conforming specification SHOULD specify the behavior in the case that the revocation information is not included or not complete. A conforming specification SHOULD specify that if the revocation information is present the widget processing environment MUST attempt to verify the revocation information. A conforming specification SHOULD specify the behavior if revocation information is out of date or otherwise invalid.
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).
A conforming specification MAY specify a mechanism that allows a remote trusted authority to update black and/or white lists and the security policy related to widget packages installed on the widget user agent.
The editor would like to thank to the following people who have contributed to this document (ordered by first name):