W3C

Widgets 1.0: Requirements

W3C Working Draft 14 April 2008

This version:
http://www.w3.org/TR/2008/WD-widgets-reqs-20080414/
Latest published version:
http://www.w3.org/TR/widgets-reqs/
Previous versions:
http://www.w3.org/TR/2007/WD-widgets-reqs-20070705/
http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
http://www.w3.org/TR/2006/WD-WAPF-REQ-20061109/
http://www.w3.org/TR/2006/WD-WAPF-REQ-20060821/
Latest editor's draft
http://dev.w3.org/2006/waf/widgets-reqs/
Version history:
Twitter messages (non-editorial changes only): http://twitter.com/widgetspecs (RSS)
Editor:
Marcos Caceres, Invited Expert

Abstract

Widgets are small client-side Web applications for displaying and updating remote data, that are packaged in a way to allow a single download and installation on a client machine, mobile phone, or mobile Internet device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and those that make use of Web services, like weather forecasters, news readers, email checkers, photo albums and currency converters.

This document lists the design goals and requirements that specification would need to address in order to standardize various aspects of widgets.

Status of this Document

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

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. 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. It is expected that this document will progress along the W3C's Recommendation Track Process.

This document is produced by the Web Application Formats (WAF) 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 WAF Working Group's public mailing list public-appformats@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.

Table of Contents

1. Introduction

This document lists the design goals and requirements that specifications need to address in order to standardize how widgets are authored, 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 (known also as widget engines) and existing Web browsers.

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), or may be embedded into a Web document. In this document, the runtime environment on which a widget is run is referred to as a widget user agent and a running widget is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource. For more information about widgets, see the Widget Landscape document.

To be clear, this specification describes the requirements for desktop style widgets (akin to Dashboard, Opera Widgets, and Yahoo! Widgets). This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets.

As shown by the Widget Landscape document, there is currently no formally standardized way to author, package, digitally sign and 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.

2. Conformance

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this document.

This specification only applies to one class of product: W3C Technical Reports. Inputs that attempt to standardize widgets as described in this document must conform to the requirements listed in this document.

A conforming specification is one that addresses all the requirements (particularly those that contain the words must or must not) listed in this document. A conforming specification must attempt to address all should and may requirements unless there is a technically valid reason not to do so. The validity of technical reasons for not addressing should or may requirements will be determined by the working group members, and through communication with vendors and the public on the Working Group's public mailing list public-appformats@w3.org (archive).

3. Design Goals

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.

Accessibility:
A conforming specification needs to support relevant accessibility guidelines.
Compatibility with other standards:
A conforming specification needs to maintain compatibility with, or directly make use of, other standards where possible.
Current development practice or industry best-practices:
A conforming specification needs to consider the development practices currently used by the widget development communities and promote relevant industry best-practices.
Device independence:
A conforming specification needs to support relevant device independence guidelines.
Ease of use:
A conforming specification needs to specify solutions that are easy to use and avoid unnecessary complexity, meaning that a widget resource should be easy for authors to create without requiring special software, and easy for end-users to acquire and install/run.
Internationalization and localization:
A conforming specification needs to support relevant internationalization and localization guidelines, as well as consider current practical internationalization solutions used by the widget development community.
Interoperability:
A conforming specification needs to attempt to be as interoperable as possible with existing market-leading widget user agents.
Longevity:
A conforming specification needs to be specified in such a way that it ensures that a widget resource can still be processed well into the future (eg. 100 years from date of the a specification reaching Recommendation Status W3C Process).
Security:
A conforming specification needs to address the security concerns of end-users and vendors by recommending appropriate security policies and programming behavior. A conforming specification must also consider the distribution and deployment security requirements as they relate to authors and vendors.
Web and offline distribution:
A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth or a Multimedia Message Service.

4. Requirements

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.

4.1 Packaging

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:

R1. Packaging Format

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.

Motivation:
Compatibility with other standards, Web and offline distribution, device independence, ease of use, current development practice or industry best-practices, internationalization and localization, longevity.
Rational:
To specify an interoperable and pervasive packaging format that is relatively easy for vendors to implement, and easy for authors to use/access on any platform.

R2. File Extension

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.

Motivation:
Device independence, ease of use, Web and offline distribution, longevity.
Rational:
When a MIME Type is not present, as is the case when a widget is instantiated locally from an end-user's storage device, the operating system will sometimes use the file extension to associate the widget resource with the appropriate widget user agent. However, when the widget is distributed over HTTP and a MIME type is present, a file extension may not be required. Note also that, in some cases, Web servers may also rely on a file extension to correctly set a widget resource's MIME type in the HTTP headers.

R3. Internal Abstract Structure

A conforming specification must recommend a packaging format that supports structuring resources into collections such as files and directories (or similar 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.

Motivation:
Ease of use, current development practice or industry best-practices.
Rational:
To provide authors with a format that is easy to use in a development process.

R4. Reserved Resources and Directory Names

A conforming specification must specify mandatory files or directories (or similar logical containers) that serve a specific function in the widget resource, as well as error handling procedures if those names are used erroneously or are missing.

Motivation:
Ease of use, Compatibility with other standards, current development practice or industry best-practices.
Rational:
To make it more efficient for widget user agents to locate the resources they require at runtime. For example, the packaging format may require authors to place all resources inside a 'resources' directory located at the root of the widget resource.

R5. Addressing Scheme

A conforming specification must specify or recommend a scheme to address the individual resources within the widget resource in a manner that authors are accustomed to.

Motivation:
Ease of use, Compatibility with other standards, current development practice or industry best-practices.
Rational:
To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI (eg. new Image('../images/pane.png')).

R6. Multilingual Resource Names

A conforming specification should recommend a packaging format that is suitable for multilingual contexts, giving authors the ability to name files and directories using characters from the Unicode character repertoire; in such a case, a conforming specification should recommend the UTF-8 encoding.

Motivation:
Internationalization and localization, current development practice or industry best-practices, ease of use, interoperability, longevity.
Rational:
To allow authors to create files and folders using characters beyond the ASCII character repertoire.

R7. Internationalization Guidelines

A conforming specification must provide guidelines that explain to authors how resources need be structured for the purpose of internationalization.

Motivation:
Internationalization and localization, current development practice or industry best-practices, ease of use, interoperability.
Rational:
To both guide and encourage authors to localize content. For example, the specification could mandate that authors place localized content into a strictly named directory structure that denotes localized content (eg. 'resources/en/' for all English content, 'resources/en-au/' for further localized Australian-English content, and so on).

R8. Automatic Localization

A conforming specification should specify a processing model that automatically localizes content when authors follow the Internationalization Guidelines.

Motivation:
Internationalization and localization, current development practice or industry best-practices, ease of use, interoperability.
Rational:
To define an internationalization model, complete with error handling, the reduces the amount of engineering work an author needs to do in order to localize a widget.

R9. Device Independence

A conforming specification must recommend a packaging format that is suitable for delivery onto many devices, particularly Web-enabled mobile devices.

Motivation:
Device independence, Web and offline distribution, interoperability.
Rational:
To recommend a packaging format that is interoperable with desktops and for mobile devices, where the widget space is currently growing.

R10. Data Compression

A conforming specification should recommend a packaging format that supports 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.

Motivation:
Web and offline distribution, device independence, current development practice or industry best-practices.
Rational:
To make a widget resource smaller for delivery over HTTP, where the cost of download data are sometimes expensive for end-users. Compressing might also help with transfer speed when a widget resource is sent over a communication channel with limited bandwidth, such as Bluetooth or infrared. Compressed widgets may also have a lesser impact on a device's battery during download.

R11. Digital Signature

A conforming specification must specify a means to digitally sign resources in a widget resource and a processing model for verifying the authenticity and the data integrity of the widget resource. The digital signature scheme must be compatible with existing Private Key Infrastructures (PKI), particularly X.509 digital certificates.

Motivation:
Security, current development practice or industry best-practices.
Rational:
To provide a means to verify authenticity, check data integrity, and provide a means of non-repudiation for users. Some vendors may choose to use digital certificates as a means of quality assurance, where by only widgets that meet a particular level of quality and security receive a digital signature.

R12. MIME Type

A conforming specification must recommend that a conforming widget resource be sent over HTTP with a formally registeredMIME Type. The Working Group must formally register the MIME type with the Internet Assigned Numbers Authority (IANA).

Motivation:
Compatibility with other standards, Web and offline distribution, ease of use.
Rational:
To provide a formal means for an authors to denote that a widget resource conforms to an appropriate specification when a widget resource is served over HTTP. In addition, the MIME type could potentially be used in conjunction with an auto-discovery mechanism, such as Atom Auto-Discovery, to facilitate deployment of a widget resource.

4.2 Configuration Document

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:

R13. Widget Metadata

A conforming specification must specify the structure and semantics of elements that represent metadata about the widget. The conforming specification must describe a model for how that metadata is to be processed by a widget user agent. 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.

Motivation:
Current development practice or industry best-practices, interoperability.
Rational:
To provide authors with a practical set of metadata elements that describe various aspects of the widget that may be used in various contexts.

R14. Authorship and Widget Metadata

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

Motivation:
Current development practice or industry best-practices, interoperability.
Rational:
To provide authors with a practical set of metadata elements that describe a widget and its authorship that may be utilized within an application context (such as a menu) or of importance to end-users.

R15. Copyright Notice and License Metadata

A conforming specification should specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice, and 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.

Motivation:
Current development practice or industry best-practices, interoperability.
Rational:
To provide authors with a means to legally declare how a widget and it's various resources can be used by end-users. For example, an author may include a GNU-style license that allows other to reuse any source code.

R16. Visual Rendering Dimensions and Initial Position

A conforming specification should specify a means for an author to declare the initial visual dimensions and initial position for an instantiated widget in a way that is device independent (eg. via CSS pixels).

Motivation:
Ease of use, device independence, current development practice or industry best-practices.
Rational:
To set up the rendering context for an instantiated widget in a way that scales on a range of devices.

R17. Declarative Bootstrap

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 it may be able to address a resource on the Web over HTTP but only of the MIME types 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 that are compatible with the widget user agent. If a bootstrap has not been declared by an author, then automated bootstrapping must occur as describe in the automated bootstrap requirement.

Motivation:
Ease of use, current development practice or industry best-practices, security.
Rational:
For example, bootstrapping could occur by referencing, via a relative IRI the, the initial resource to be run by a widget user agent (eg '/ui/clock.svg'). Alternatively, the bootstrap might be a Web page that when combined with the Visual Rendering Dimensions and Initial Position requirement displays at the appropriate size and screen position.

R18. Automated Bootstrap

A conforming specification may 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, then it should locate that resource first before attempting to locate other resources.

Motivation:
Ease of use, device independence, current development practice or industry best-practices, internationalization and localization.
Rational:
For example, the conforming specification could specify a model that searches for a default file name (index.htm, index.html, index.svg, etc) firstly within localized directory names, as required by automatic localization, 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 form the root directory.

R19. Iconic Representations

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, but should also support resources within the scope of the widget resource.

Motivation:
Ease of use, device independence, current development practice or industry best-practices, internationalization and localization.
Rational:
To provide authors with a visual means of representing widget to end-users prior to instantiation. The icon may also serve as visual means for end-users to associate an icon with a widget. For example, an a small graphic of a calendar may represent a calendar widget.

R20. Configuration Parameters

A conforming specification must specify a means to declare values of either custom or predefined configuration parameters, which would be applied as a widget is instantiated. A conforming specification must specify the default values for parameters in case a parameter is missing or the value supplied by the author is invalid.

Motivation:
Ease of use, current development practice or industry best-practices.
Rational:
To allow authors to declaratively control how a widget is configured during instantiation; and, in the absence of any declarations, allow the widget user agent to automatically configure a widget using default values. For example, the author might declare that the value for the parameter 'width = "50"', or in its absence, the widget user agent will automatically set the width to "300".

R21. Security Declarations

A conforming specification must specify a means for declaring that the instantiated widget will require access to resources or services that may introduce a security risk for an end user.

Motivation:
Security, current development practice or industry best-practices.
Rational:
To declare the security intentions of the widget, allowing the widget user agent to respond accordingly by adjusting its security policies and warning the end-user. Example of security sensitive services that could require access-control include accessing end-user's storage device, or performing a cross-domain request.

R22. XML, Micro-Syntaxes and Schema

A conforming specification must specify the configuration document language using XML syntax, as well as the rules for processing the configuration document language and any micro-syntaxes represented as character data or in XML attributes. A conforming specification should specify a formal schema for the language, as well as define any configuration defaults.

Motivation:
Compatibility with other standards, current development practice or industry best-practices, ease of use, internationalization and localization, longevity.
Rational:
To have a language in a format that is relatively easy for authors to read and write, and provides effective internationalization support. XML is generally accepted and understood by widget authors and parsed by all market-leading widget engines, and XML parsers generally have reasonable support for Unicode and other character encodings that are provide effective internationalization and localization.

R23. Configuration Document Independence

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.

Motivation:
Ease of use, Web and offline distribution, device independence.
Rational:
To allow the configuration document to be extracted and used by other applications (either on the server or on the client side) for different purposes. For example, a server may automatically extract the configuration document from a widget resource and serve it upon request. The independent configuration document may then be used, for instance, for checking information about the widget without needing to download the complete widget resource. This may be particularly useful for users of widgets on mobile devices, where the cost of downloading data can sometimes be expensive for end-users.

4.3 Scripting Interfaces

This section enumerates the requirements that a conforming specification needs to address to standardize a 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:

R24. Instantiated Widget API

A conforming specification must specify a set of interfaces that expose the 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.

Motivation:
Ease of use, compatibility with other standards, current development practice or industry best-practices.
Rational:
See for example Apple's widget Object described in the Dashboard Reference and Microsoft's System.Gadget Object described in the Sidebar Reference.

R25. Configuring Runtime Properties

A conforming specification should specify a set of interfaces that expose relevant properties and methods of the widget user agent.

Motivation:
Ease of use, compatibility with other standards, current development practice or industry best-practices.
Rational:
Such properties could include localization information, operating environment details, availability of network access, etc. See for example Microsoft's Sidebar Reference.

R26. Getting and Setting Preferences

A conforming specification must specify a set of interfaces for dynamically getting and setting preferences specific for an instantiated widget.

Motivation:
Ease of use, Compatibility with other standards, current development practice or industry best-practices.
Rational:
To provide a means for authors to allow end-users to dynamically change any preferences they have may have set in the past.

R27. Widget State Change Events

A conforming specification must define a set of states in the lifecycle of the instantiated widget that are able to be captured through script.

Motivation:
Current development practice or industry best-practices, ease of use.
Rational:
To allow authors to programmatically capture when a change has occurred in either the instantiated widget or possibly even the widget user agent.

R28. Modal Priority

A conforming specification should specify how an instantiated widget (or any of its windows) should to categorize 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 case the widget user agent should find a suitable and non-intrusive way to draw the end-user's attention.

Motivation:
Current development practice or industry best-practices, ease of use
Rational:
An example of this kind of behavior can be seen on Mac OS X, where a program's icon bounces in the dock when a program has a critical window to display.

R29. Accessing Resources, Services, and Applications

A conforming specification may specify APIs to access device-specific resources, services, and applications.

Motivation:
Compatibility with other standards, current development practice or industry best-practices, ease of use.
Rational:
Examples of device-specific services and resources that could be made available through script include cameras, SMS, and the address book. However, this requirement is beyond the scope of the working group charter. 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.

R30. ECMAScript Compatibility

A conforming specification must specify the APIs proposed in this section in such a way that they are implementable in ECMAScript.

Motivation:
Compatibility with other standards, current development practice or industry best-practices, internationalization and localization
Rational:
To support a lanaguage that is already widely used in widget user agents and to allow authors to use already existing ECMAScript code libraries.

R31. XMLHttpRequest

A conforming specification must recommend that a widget user agent implement the XMLHttpRequest object.

Motivation:
Current development practice or industry best-practices, interoperability.
Rational:
To allow the creation of Ajax-style applications.

R32. Cross-Widget Communication

A conforming specification may specify a model and API to allow multiple instantiated widgets to securely communicate with each other.

Motivation:
Current development practice or industry best-practices.
Rational:
To allow widget to communicate with each other.

4.4 User Interface Language

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 a language that is well-suited for creating user interfaces and is accessible.

R33. Language Accessibility

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 various levels: it should provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through an non-graphical UI. The declared interface may also be accessible to screen readers, allowing relevant sections of text and functionality to be accessed by non-visual means.

Motivation:
Compatibility with other standards, current development practice or industry best-practices, ease of use.
Rational:
To recommend a language, or a set of languages, that will allow authors to realize their designs, while at the same time remaining accessible to screen readers and similar assistive technologies.

4.5 User Agents

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.

R34. Additional Digital Certificates

A conforming specification may recommend that, aside from including standard root certificates, widget user agent allow the installation of digital certificates from other trusted sources.

Motivation:
Security, current development practice or industry best-practices, Web and offline distribution, interoperability.
Rational:
To allow authors and publisher to sign widgets.

R35. End-user Declared Proxy

A conforming specification should recommend that widget user agents allow end-users to explicitly input a proxy server through which all HTTP-based request are made.

Motivation:
Security, current development practice or industry best-practices, interoperability.
Rational:
For example, a widget user agent may be used behind a firewall or secure proxy.

R36. Automatic Updates

A conforming specification should specify a model to allow widget user agents to automatically check if a new version of a widget resource has become available online. Updating must preserve the identity of the widget and should be conducted over a secure communication channel.

Motivation:
Security, current development practice or industry best-practices, interoperability.
Rational:
To allow authors to provide updates for a widget resource online. For example, the author could declare in the configuration document an IRI for where the widget user agent can be check for updates. If an update to a widget resource becomes available, then the widget user agent could ask the end-user if they want to download the widget.

R37. Persistent Storage of Preferences

A conforming specification must recommend that a widget user agent implement a means to persistently store user preferences for each instantiated widget.

Motivation:
Current development practice or industry best-practices, Web and offline distribution, Security.
Rational:
To allow widgets to be closed and re-instantiated without the end-user having reset the preferences for an instantiated widget. For example, when using a weather widget, the end-user will want to store the preferred location for weather information, and not be asked to input that information again every time the widgets is re-instantiated.

R38. Multiple Widget Instances

A conforming specification must recommend that a widget user agent allow multiple instances of a widget resource to be instantiated and run concurrently as separate processes.

Motivation:
Current development practice or industry best-practices, interoperability.
Rational:
To allow multiples instances of the same widget to be run at the same time, but possibly be configured differently. For example, instantiating two clock widgets where one displays the time for Amsterdam and the other displays the time for Boston.

4.6 Security

This section enumerates the requirements that a conforming specification needs to address to standardize an adequate security model for widgets. The objective of this section is to ensure that a conforming specification specifies a security model that:

R39. 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 authors to explicitly request permission to use particular capabilities (see also Security Declarations).

Motivation:
Current development practice or industry best-practices, security.
Rational:
To make the default state of a widget as benign as possible. For example, the default security policy might be that a widget cannot access the network.

R40. Runtime Security Exceptions

A conforming specification must specify runtime exceptions for when the API attempts to perform an action it it not authorized to perform.

Motivation:
Current development practice or industry best-practices, security.
Rational:
To provide the API with an error recovery mechanism for when a script attempts to perform a disallowed security-sensitive action. For example, a security exception might be thrown if a widget attempts to access the network but has not been granted permission by the widget engine to do so.

References

Normative References

ECMAScript
ECMAScript Language Specification, Third Edition. ECMA, December 1999. Available at http://www.ecma-international.org/publications/standards/Ecma-262.htm
HTML
HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999. Available at http://www.w3.org/TR/html401/
HTTP
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt
MIME Type
Multipurpose Internet Mail Extensions (MIME) Part Two: media types, N. Freed and N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.
Unicode
The Unicode Standard, The Unicode Consortium, Version 5.
Widgets 1.0: Packaging and Configuration
Widget 1.0. M. Caceres. W3C Working Draft. 13 October 2007. Available at http://www.w3.org/TR/2007/WD-widgets-20071013/
XML
Extensible Markup Language (XML) 1.0 Specification (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October 2000. Available at http://www.w3.org/TR/REC-xml/
XMLHttpRequest
The XMLHttpRequest object. A. van Kesteren. 2006. W3C Working Draft, Available at http://www.w3.org/TR/XMLHttpRequest/
X.509
CCITT, Recommendation X.509: The Directory Authentication Framework, 1988.
IRI
Internationalized resource Identifiers (IRIs), M. Duerst, M. Suignard. IETF, January 2005. RFC3987 is Available at http://www.ietf.org/rfc/rfc3987
RFC2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt
XML Digital Signatures
XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation, February 2002. Available at http://www.w3.org/TR/xmldsig-core/
Zip
.ZIP File Format Specification. PKWare Inc., September 2007. Available at http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Informative References

Ajax
Ajax: A New Approach to Web Applications. J. J. Garrett. February 18, 2005. Adaptive Path. Available at http://www.adaptivepath.com/publications/essays/archives/000385.php
Atom Auto-Discovery
Atom Autodiscovery, M. Pilgrim, P. Ringnalda. ATOMPUB Working Group (Draft), May 2005-. Available at http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html
Bluetooth
Bluetooth Core Specification 2.1. Available at http://www.Bluetooth.com/NR/rdonlyres/F8E8276A-3898-4EC6-B7DA-E5535258B056/6545/Core_V21__EDR.zip
Charter
Web Application Formarts Working Group Charter. D. Jackson. November 15, 2005. Available at http://www.w3.org/2006/appformats/admin/charter.html
CSS
Cascading Style Sheets, level 2, revision 1, B. Bos, T. Çelik, I. Hickson, and H. Wium Lie. W3C Candidate Recommendation 19 July 2007. Available at http://www.w3.org/TR/CSS21
Dashboard Reference
Dashboard Reference, Apple Computer, Inc, May 2006. Available at http://developer.apple.com/documentation/AppleApplications/Reference/Dashboard_Ref/index.html
Google Gadgets
Google Desktop Sidebar Scripting API, Google Inc., 2006. Available at http://desktop.google.com/script.html
Sidebar Reference
Windows Sidebar Reference, Microsoft Corporation, 2006. Available at http://msdn2.microsoft.com/en-us/library/aa965853.aspx
Widget Landscape
Widgets 1.0: The Widget Landscape. M. Caceres. W3C Working Draft (Working Group Note). Available at http://www.w3.org/TR/widgets-land/
W3C Process
World Wide Web Consortium Process Document. I. Jacobs, W3C. 14 October 2005. Available at http://www.w3.org/2005/10/Process-20051014/
Yahoo! Widgets Reference
Yahoo! Widget Engine Reference 3.1 Reference Manual Yahoo! Inc., April 14, 2006. Available at http://Widgets.yahoo.com/gallery/dl_item.php?item=WidgetEngineReference_3.1.1.pdf

Acknowledgments

The editor would like to thank to the following people who have contributed to this document (ordered by first name):