Abstract

This specification defines a process and a document format to allow a user agent to update an installed widget package with
a different version of a widget package. A widget cannot automatically update itself; instead, a widget relies on the user agent to manage the
update process.

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

Note: The working group reached consensus to stop work on this specification. It is being published for archival reasons and is no longer being progressed along the W3C's Recommendation Track.

User agents that wish to extend this specification in any way are encouraged to discuss their extensions on a public forum, such as
public-webapps so their extensions can be considered for standardization.

Publication as a Working Group Note 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.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
and notes in this specification are non-normative. Everything else in this specification is
normative.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY,
and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

This specification defines conformance requirements for a single class of product: user agents.

3.
Definitions

The concepts of a widget package, a configuration document, a valid IRI, a version attribute, user agent locales, global attributes and the definition that one element is allowed per language are defined in the [WIDGETS] specification.

A user agent is an implementation of this specification that also implements the [WIDGETS] specification and its
dependencies.

6.
Acquiring an Update Description Document

It is expected that user agents will perform a widget update process asynchronously and periodically check for any available
updates. The timing of any widget update process is an implementation detail left to the discretion of the implementer (e.g.
once a day or once a week).

On receiving HTTP response codes in the 2xx range, other than HTTP 200 OK, the user agentMUSTterminate the widget update. They are, however, likely to indicate an error
has occurred somewhere and may cause the user agent to emit a warning.

On receiving HTTP 301 Moved Permanently, 302 Found, 303 See Other, and 307 Temporary Redirect responses, the user agentMUST reconnect using the new server
specified URL instead of the previously specified URL.

The user agentSHOULD treated HTTP 305 Use Proxy, 401 Unauthorized, and 407 Proxy Authentication Required responses transparently as for any other
subresource.

Any other HTTP response code not listed here, and any network error that prevents the HTTP connection from being established in the
first place (e.g. DNS errors), must cause the user agent to terminate the widget update.

The following processing model is written with more concern for clarity over efficiency. As such, a user agent can optimize
the processing model so long as the end result is indistinguishable from the result that would be obtained by following the
specification.

The term in error, typically used on an element or attribute, means that the element, attribute, or other construct
does not conform to the rules of this specification. Rules for exactly how a user agent needs to treat the erroneous construct are
always given when the term is used.

Let digSigsMatch be the result of comparing the dsp:Identifier value [WIDGETS-DIGSIG] from update_signature with the same
value obtained from the associated incumbent_signature within incumbent_digsigs.

9.
Security Considerations

Because an update description document is not self-contained, it is conceivable that the update model could be subject to a
man-in-the-middle attack, as with any unencrypted requests performed over [HTTP11]. For this reason, it is RECOMMENDED that, for
widgets that have not been digitally signed, updates are always performed over [HTTP-TLS].

Another means of protection is for authors to always digitally sign their widget resources. During an update, the user agent
will then validate the signature before installation, ensuring that a widget resource's identity and integrity was maintained
over the network.