Contents

1 Introduction

This document defines the core requirements that a widget runtime ( WRT ) must exhibit in order to be considered a WAC certified runtime. Areas covered in this document include:

• Web standards that are used to create widgets.

• Security, application life cycle, user interface requirements, and device integration.

The hardware target for the widgets are typically mobile phones or other mobile devices, these are generally referred to as "devices" and were often previously known as "terminals". Other types of devices may also be WAC-certified. WRTs are addressed here specifically and distinctly from the device or OS in which they are hosted, although WRTs are dependent in various ways upon the host device, e.g. in mapping APIs to device/OS resources or idle-screen presentation capabilities.

It is expected that there will be various ways in which WRTs are deployed, for example:

• embedded in devices as manufactured
• installed by Operators at their stores as part of device customization at sale, or through subsequent device management actions (e.g. when a user signs up for a widget-enabled service)
• downloaded/installed by users.

It is intended that these deployment options are not constrained by this specification, and therefore the specification allows flexibility in implementation.

WAC is taking the following approach to the types of devices considered in scope for support of WAC widgets :

• WAC is starting from the assumption of no principle limitation, (i.e. hardware or operating system in the devices considered targeted for WAC support.

• WAC has the ambition to support WAC widgets on mass market and feature phones. The lower end of the market is set at those that currently do not feature a WRT or any other technology to run Web applications.

• Overall, devices on which WAC widgets can be used should deliver a good user experience. WAC does not expect to support devices on which WAC widgets cannot provide a meaningful user experience due to hardware limitations.

• Through the requirements in this document and the WAC compliance program, WAC will define an acceptable variation of capabilities and performance criteria for WAC-compliant devices.

1.1 Conventions

The requirements within this document are uniquely identified using the following format aa-nnnn, where:

• aa is a 2 letter acronym identifying the chapter of the document:
  • WS: Web Standards
  • SP: Widget Security and Privacy
  • WL: Widget Life cycle
  • WR: Widget Runtime
• nnnn is a 4-digit number that identifies the requirement (e.g. 0020) and is unique within that document.

1.2 Definitions

The following terms are used throughout the specification. This list is not exhaustive :

App store

An overall set of client and/or server functions that may enable various capabilities of the user related to the application life cycle, e.g. widget discovery, selection, preview, payment, Authorization checks, update, etc.

App store client

A device client that supports client-side functions of an App store.

App store server

A network server that supports server-side functions of an App store.

Certification authority (CA)

An infrastructure that issues certificates signed by or chained to a root certificate owned by the organisation operating the CA infrastructure. CA operating organisations typically own multiple root certificates, and apply various certification practices, e.g. level of business or domain validation required for issuing certificates signed by a particular root certificate.

Certificate Revocation List (CRL)

In the operation of some cryptosystems, usually public key infrastructures (PKIs), a certificate revocation list (CRL) is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked, and therefore should not be relied upon.

Device capability

A specific resource, or functionality of a device, that can be accessed, manipulated or exploited by a WAC application. Device Capabilities are defined and identified in a portable way, without a dependency on any specific JavaScript API , or on any underlying software platform or platform-specific API.

Digital Rights Management (DRM)

Digital rights management (DRM) is a term for access control technologies that can be used by hardware manufacturers, publishers, copyright holders and individuals to limit the use of digital content and devices. The term is used to describe any technology that inhibits uses of digital content not desired or intended by the content provider.

Distributor Signed

Having a Verified Distributor Signature. Note that if a widget is WAC-signed then it is distributor signed, but not vice versa.

Download Manager

A device client that supports client-side functions enabling secure download of WAC widgets from WAC App stores.

Exactly matches

A comparison performed in a case-sensitive manner.

Extended Validation(EV)

EV Certificates are intended for establishing Web-based data communication conduits via TLS/SSL protocols with a greater level of trust than is provided by typical "domain validation" certificates.

International Mobile Equipment Identity (IMEI)

The International Mobile Equipment Identity (IMEI) is a number that identifies mobile devices.

Mobile Equipment Identifier (MEID)

A Mobile Equipment Identifier (MEID) is a globally unique number identifying a physical piece of mobile station equipment.

Multipurpose Internet Mail Extensions (MIME)

A file format label used by various protocols on the Internet.

Revoked Signature

A Widget Signature determined to be revoked based on the rules for determining the revocation status of a widget signature.

Security Manager

Device software which provides support for various aspects of security policy management and enforcement.

Side-loading

Importation of a Widget package, that has been downloaded via means other than through WAC-certified clients, e.g. the Web Runtime or an App store Client securely integrated with the Web Runtime. Side-loading includes cases in which widget packages are received via browser download, reception in a message (email, MMS), reception via some other file transfer protocol (e.g. Bluetooth), and importing from a device or removable memory location.

Subscriber Identity Module( SIM )

A Subscriber Identity Module (SIM) on a removable card securely stores the service-subscriber key used to identify a subscriber on mobile telephony devices (such as mobile device).

Test Signature

A distributor signature that contains a Target Restriction.

Trusted Application

An application which has been assigned a specific level of trust, which can be based upon a variety of application attributes and installation context attributes, as defined by a security policy.

Untrusted Application

An application which has not been assigned any specific level of trust, and is thus assigned to a default level of trust.

Verified Signature

A Widget Signature determined to be verified based on the rules for determining the status of a widget signature.

WAC Certification authority (CA)

A CA operated by WAC.

WAC-certified

Having been verified by WAC as compliant with all related WAC requirements.

WAC root certificate

A root certificate issued by a WAC CA.

WAC-signed

A Widget package that contains at least one Verified Distributor Signature that is not a Test Signature and which chains to a WAC root certificate.

WAC test widget

A widget having one or more Test Signatures.

1.3 Conformance

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

Only one class of product can claim conformance to WAC specifications: a widget runtime.

User agents MUST inmplement the WebIDL in the WAC specification in a manner that conforms to the ECMAScript Bindings defined in the Web IDL specification.

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

2 Widget Runtime

The following section and subsections define the general requirements for WAC -certified web runtime ( WRT).

The widget runtime as referred to here is a logical collection of functions that can be deployed as various components, e.g. a hypothetical collection including an App store Client (enabling widget discovery, purchase, download etc.), Download Manager (enabling secure widget download), Widget Manager (enabling widget installation and preferences), Security Manager (enabling security policy), and Widget Engine (enabling runtime support for core Web features and WAC API s). Although WAC does not mandate a particular set of components or deployment model, any component implementing WAC-specified functions is expected to be WAC-certified for specification conformance.

2.1 User expectations

Users expect the WRT to provide a means for the user to determine which widgets are running, including those that are running in background. Users also expect the WRT to provide a means for the user to terminate any running widgets. Furthermore, users will expect the WRT to install widgets in such way that the user can find and launch the widgets as any other application on the device, e.g. by clicking on an icon.

2.2 Web Standards

In terms of Web standards, a widget runtime( WRT ) is an implementation of the conformance requirements of this specification, which also supports the following specifications:

• [HTML]
• [CSS 2.1]
• [ECMAScript]
• [JSON]
• [CSS3]
• [DOM4]
• [CSSOM View]
• [Selectors API]
• [XHR]
• [SVG Tiny]
• [Widget Packaging]
• [Widgets-APIs]
• [Widgets-URI]
• [Widgets-DigSigs]
• [WARP]
• [CSS Device Adaptation]
• [View Mode Media Feature] (see requirements in View Modes section)

2.3 URI Schemes

A widget runtime supports the following URI Schemes:

• tel: URI scheme [RFC3966]
• sms: URI scheme [RFC5724].
• mailto: and mmsto: URI scheme [OMA URI Schemes].
• data: URI scheme [RFC2397].
• http: and https: URI schemes as described in [RFC2616] , [RFC2817] , and [RFC2818]

2.4 WRT Identification

WR-4200 The WRT MUST include a User Agent header identifying the following information in each HTTP request, including:

• Web layout engine and version.

• Host device vendor, model, and version (vendor-specific string).

• WRT vendor, name, and version (vendor-specific string).

User-Agent header example:

2.5 WRT Installation and Updates

To the extent that the device supports over-the-air software update, the WRT SHOULD support an update over-the-air.

2.6 Multitasking

To the extent that the device supports execution of multiple applications concurrently, the WRT needs to support execution of multiple widgets simultaneously.

To the extent that the device supports execution of applications in background mode, the WRT needs to support execution of widgets in the background.

The WRT needs to allow native system events/clients to take the foreground/focus.

2.7 Debug Functions

When operating in developer mode , developers will expect support for a debug protocol with at least the following debug functions ;

• execution control operations of set/clear/change breakpoints, start/continue, stop/break and step,
• enumeration and retrieval of JavaScript source code,
• inspection of the current JavaScript state at any available stack frame, expression, local and global variable,
• logging capability (e.g. console JavaScript object).

The WRT MUST enable debug functions only for WAC test widgets , i.e. the functions must not be usable for normal WAC widgets, even when a WAC test widget is executing.

The WRT SHOULD support use of the debug protocol via an IP transport independent of the connectivity framework provided.

2.8 Compliance Mode

The WRTneed to support a Compliance Mode which, for compliance testing purposes only, enables the following additional functionality:

• permit Side Loading of WAC-signed widgets;
• permit configuration of the security policy of the Security Manager ;
• permit configuration of the root certificates recognised by the Security Manager ;
• permit configuration of a mock device identity ( IMEI or MEID ) for the purposes of allowing target restriction conditions for compliance test widgets to be satisfied;
• permit installation of a widget containing a revoked signature.

The WRTshouldn't allow the user to enable Compliance Mode.

2.9 Developer Mode

The WRT MUST provide a means to enable a developer mode under which WAC test widgets can be installed and executed by the developer.

The mechanism of enabling developer mode is not within the scope of this specification.

The WRT MUST NOT install or run a WAC Test Widget when the developer mode is disabled.

WR-4630 When a WAC Test Widget is started, the WRT MUST verify that the identity of the device ( IMEI or MEID ) is contained within the list of identities embedded in the widget signature.

WAC-specific XML elements for inclusion in a Widget digital signature document are defined in the following namespace:

http://wacapps.net/ns/digsig  

The <wac:TargetRestriction> element is defined as follows:

<!ELEMENT TargetRestriction EMPTY> 
<!ATTLIST TargetRestriction
 IMEI CDATA #IMPLIED MEID CDATA #IMPLIED> 
                                                                

Other attributes may be defined for device types that have other identifying serial or identification numbers.

WR-4640 The WRT MUST treat the <wac:TargetRestriction> element as optional in WAC widget signatures.

WR-4650 The WRT MUST consider WAC widget signatures with a <wac:TargetRestriction> element as valid only if all of the following target restriction conditions are met:

• the <Signature> element contains exactly one <ds:Object> element containing zero or more <wac:TargetRestriction> child elements.
• at least one of the TargetRestrictions is satisfied on the device in question; and:
  • there is a same-document <ds:Reference> to the enclosing <ds:Object>
  • the TargetRestriction contains exactly one attribute (IMEI or MEID)
  • the TargetRestriction is satisfied on the device in question

Therefore, the collection of all TargetRestrictions acts as a disjunction of conditions.

An example of the structure of the signature would be:

<xml version="1.0" encoding="UTF-8"?> 
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
 xmlns:wac="http://wacapps.net/ns/digsig"> 
<SignedInfo> 
<CanonicalizationMethod... /> 
<SignatureMethod ... /> 
<!-- other references here ...--> 
<!-- 
same-document reference to the element enclosing the TargetRestriction
elements 
--> 

<Reference URI="#target-restriction">
 <Transforms>
   <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> 
 </Transforms>
 <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
 <DigestValue>lt;/DigestValue> 
</Reference> 
</SignedInfo>
<SignatureValue> ... </SignatureValue> 
<KeyInfo> ... </KeyInfo> 
<!-- TargetRestriction details --> 
<Object Id="target-restriction">
 <wac:TargetRestriction IMEI="012345678901234" />
 <wac:TargetRestriction
 IMEI="012345678901235" /> 
 <wac:TargetRestriction IMEI="012345678901236"/> 
 </Object>
</Signature>

WR-4660 When a WAC Test Widget is started, the WRT MUST display a disclaimer that clearly states the widget is a developer widget under test, with appropriate accompanying text to describe the potential dangers of running a widget signed with a test signature.

2.10 View Modes

WR-4000 WAC devices MUST support the "maximized" view mode per [View Mode Media Feature]. It is OPTIONAL for user agents to support other view modes.

For widgets displayed on an mobile idle screen, the RECOMMENDED view mode is the floating view mode.

WR-4022 The widget object MUST implement the EventTarget [DOM4] interface.

Widget implements EventTarget;

If the WRT supports multiple view modes AND supports switching between view-modes in a running instance, then if a change in the view-mode of the widget occurs the WRT MUST fire a 'ViewmodeChangeEvent' at the widget object. The event name is " viewmodechange ", it does not bubble, is not cancelable, has no default action. The oldViewmode is set to the value previous view-mode. The newViewmode is set to the value new view-mode.

[NoInterfaceObject] 
interface ViewmodeChangeEvent: Event {
 readonly attribute DOMString oldViewmode;
 readonly attribute DOMString newViewmode;
}

2.11 Roaming Data Usage Control

WR-4500 Unless roaming data usage control is provided by the underlying platform, the WRT MUST provide users with the ability to control online behaviour of devices separately for home and roaming Public Land Mobile Networks ( PLMN ). The requirements WS-4510 to WS-4570 below apply if roaming data usage control functionality is provided by the WRT.

Note: 'roaming' as used here includes national and international roaming. "Network connection" as used below refers to connections to the PLMN.

WR-4510 The WRT MUST provide the following home and roaming options for data usage;

• never connect,
• always ask (conditional connection),
• connect automatically.

WR-4520 The WRT MUST provide a warning to the user when a setting is changed to 'connect automatically', and allow the user to cancel the change, e.g. "You changed to 'connect automatically'. Be aware that data charges might apply! You like to continue? Yes/No".

Note: Operators should pre-define the default for home and roaming as a security policy permission, using the XMLHttpRequest ( XHR ) and "external network access" device capabilities with environment qualifier "roaming status".

WR-4530 When a network connection is requested for any purpose while the related setting is 'always ask' the WRT MUST notify the user of the pending network usage, and allow the user to allow or deny the network connection.

WR-4540 When a network connection is requested for any purpose while the related setting is 'connect automatically' the WRT MUST establish the connection without notification.

WR-4550 The WRT MUST consider user confirmation of network connections as valid for the current session only.

WR-4560 If the user moves into a roaming network while a connection is established and the roaming setting is 'never connect', the WRT MUST terminate the network connection.

WR-4570 If the user moves into a roaming network while a connection is established and the roaming setting is 'always ask', the WRT MUST notify the user of the pending network usage, and allow the user to retain or terminate the network connection, e.g. with the notification "You are now roaming and you are online. Caution! Data charges may apply. Do you want to continue? Yes/No".

3 Common APIs

This specification provides the basic definitions that are used in all other WAC APIs. These include generic error and success callbacks.

Additionally, this API also specifies the location in the   [ECMAScript] global environment in which the WAC APIs are instantiated, as well as mechanisms to retrieve the list of supported and activated features.

3.1 Disabled methods

A method can be disabledthrough the use of particular features strings. When a method is disabled, the method is still exposed on an object implementing an affected interface. However, when it is invoked, it does nothing.

3.2 Callbacks

The following IDL fragments define callbacks that are generally used throughout WAC specifications.

callback  Function = void  (any  ... arguments);
callback  ErrorCB  = void (DOMException  e);

3.3 Algorithms

These algorithms are used throughout the WAC specifications.

General invocation checks

The general invocation checks algorithmis as follows:

1. Perform WebIDL's ECMAScript type mappings for each of the arguments of the invoked method. If no WebIDL predefined exceptions are thrown from performing the type mappings, continue.

2. If the algorithm that invoked this algorithm has an errorCallback argument, and if errorCallback is not callable , termiminate this algorithm.

3. Otherwise, if the method that invoked this algorithm is disabled (via a feature declaration) or the user agent's security policy does not allow invocation of the method that invoked this algorithm:

   1. Let exception be a new DOMException of type " SecurityError " with message "Method invocation blocked by security policy." (or similar).

   2. Queue a task to invoke the errorCallback with exception as the argument.

   3. Terminate this algorithm and the algorithm that invoked this algorithm.

4. If the user agent does not support the functionality specified for the method that invoked this algorithm (e.g., because of a platform/hardware limitation):

   1. Let exception be a new DOMException of type " NotSupportedError " with message "Method invocation failed because of a platform limitation." (or similar).

   2. Queue a task to invoke errorCallback with exception as the first argument.

   3. Terminate this algorithm and the algorithm that invoked this algorithm.

3.4 WindowDeviceapis interface

[NoInterfaceObject]
interface WindowDeviceapis{
            readonly  attribute  WACDeviceapis deviceapis;
};
Window  implements WindowDeviceapis ;

3.5 The deviceapis attribute

The deviceapis attribute provides a point of access for the WAC Device APIs.

3.6 WACDeviceapis interface

[NoInterfaceObject]
interface WACDeviceapis{ 
       Feature [] listAvailableFeatures (); 
       Feature [] listActivatedFeatures (); 
};

3.7 The listAvailableFeatures() method

The listAvailableFeatures() method retrieves a list with all the features available in the Web Runtime (WRT). For features not requested in the widget's configuration document, the attributes required and parameters in the feature instance MUST be null. For those features requested in the widget configuration document, the attributes required and parameters MUST contain the values provided in the widget configuration document.

Javascript example

var features = deviceapis.listAvailableFeatures(); 
for (var i=0; i<features.length; i++) { 
    alert("The Feature " + features[i].uri + " is supported"); 
}

3.8 The listActivatedFeatures() method

This method MUST provide a list with all the features that have been activated for the widget in the WRT. For every feature, the required and params attributes MUST contain the values provided in the widget configuration document.

Javascript example

var features = deviceapis.listActivatedFeatures();
for (var i=0; i<features.length; i++) { 
     alert("The Feature " + features[i].uri + " has been activated");
}

3.9 PendingOperation interface (DEPRECATED)

[NoInterfaceObject] interface PendingOperation{ 
      boolean cancel(); 
};

The PendingOperation interface interface provides a means to cancel an asynchronous action, refered to as a pending operation, by removing a given task from a specific task queue .

3.10 The cancel() method

The cancel()method attempts to stop an associated task from being run by removing it from a given task queue (which task queue to remove the task from is given in prose when the pending operation is constructed). The method returns true if invoking it was able remove the task from a task queue. Otherwise, it returns false : meaning that remoal did not succeed either because:

• the task has already run (and, hence, removed from from the task queue )
• or because the cancellation cannot occur due to some other limitations beyond the implementation (e.g., the operation was passed to some other sub-system of the device over which the user agent has no control).

When the cancel() method invoked, the user agent MUST run the steps to cancel a pending operation.

The steps to cancel a pending operationare given by the following algorithm. The algorithm always returns a boolean.

1. Let task be the task associated with this pending operation.
2. If the given task queue contains task , attempt to remove task from the task queue. If the task was successfully removed, return true and terminate this algorithm.
3. Otherwise, return false.

3.11 Feature interface

Provides all the information about a feature.

[NoInterfaceObject] 
interface Feature{ 
    attribute DOMString uri; 
    attribute boolean required; 
    attribute Param[] params; 
};

This interface is used to provide the details about a feature.

3.12 The uri attribute

The uri attribute represents the unique identifier of a feature.

3.13 The required attribute

The required attribute is set to true if the feature has been tagged as required in the widget configuration document (config.xml).

3.14 The params attribute

This attribute contains an array with all the parameters included for that feature in the widget configuration document (config.xml).

3.15 Param interface

Represents a parameter linked to a feature.

[NoInterfaceObject] 
interface Param{ 
  attribute DOMString name; 
  attribute DOMString value; 
};

3.16 The name attribute

The name attribute represents the value of a name attribute of a param element.

3.17 The value attribute

The value attribute represents the value of a value attribute of a param element.

3.18 WatchOptions dictionary

dictionary WatchOptions{ 
   unsigned long  maxNotificationInterval = 0; 
   unsigned long  maxNotificationInterval = 0;
   octet  minChangePercent ; 
};

The WatchOptions dictionary is used to set the how often the user agent needs to report the device's acceleration to the application.

Example

// Receives acceleration changes 
function watcher(acceleration){
   alert("The acceleration has changed");
} 

// registers to be notified when acceleration changes 
// (minimum time between notifications is 10 secs)
 deviceapis.accelerometer.watchAcceleration( 
        watcher, 
        null, 
        {minNotificationInterval:10000});

3.19 The minNotificationInterval member

The minNotificationInterval member represents a minimum length of time (expressed in milliseconds) between some running a task in a given task queue.

3.20 The maxNotificationInterval member

The maxNotificationInterval member represents a maximum length of time (expressed in milliseconds) between some running a task in a given task queue. That is, if the time is exceeded, the interval is ignored.

3.21 The minChangePercent member

The minChangePercent member represents the minimum change expressed as a percent that needs to occur before a callback is invoked.

3.22 DeviceApisPim and Pim Interface

interface Pim{}; 
[NoInterfaceObject  ] 
interface DeviceapisPim{
  readonly  attribute  Pim  pim; 
};
Deviceapis  implements DeviceapisPim ;

4 Security and Privacy

WS-1501 The WRT MUST NOT allow the top-level browsing context of a widget to be navigated to URI s outside the widget. When navigation to a URI outside the widget is attempted, if there is a URI scheme handler for the given URI the WRT MUST trigger the platform's handler with the given URI (e.g. a Web browser for http: or https:, the SMS application for sms:, the email client for mailto:, etc). For avoidance of doubt, this applies also to HTML anchor elements, meta refresh tag, window.location , and any other method via which a new document can be loaded into the top-level browsing context.

WS-1502 When a user agent receives a request to navigate to a protocol other than widget, the WRT MUST dispatch that link to an appropirate protocol handler (e.g., lower level in the stack, like the native SMS handler or opening the default Web Browser).

The requirements in this chapter are based partly upon the BONDI Architecture and Security specification [BONDI A&S]. The BONDI specification can be read in parallel with this document. The overall set of functions required by WAC have been simplified and the following BONDI features and specific requirements are not included and have been deferred to a future release:

• Some signature attributes, as specified for use in security policies.
• Use of API feature URIs in policies: instead, the more generic "device capability" identifiers will be used, in order to simplify policies and enable a single policy to be used for multiple API versions and APIs defined by different organisations (e.g. BONDI, JIL, others).
• AS-0290: provisioning mechanism that supports prior download of widget metadata, which can include a signed hash of the widget to provide additional assurance (e.g. authenticity check) prior to full download.
• AS-0460: Feature Sets.
• AS-0471, AS-0472, AS-0480, AS-0491: Programmatic dependencies (requestFeature() API) supporting the browser use-case.
• AS-0510 - AS-0540: Signed Security Policy format (used in policy provisioning).
• AS-0550 - AS-0640: Policy provisioning.
• AS-0650 - AS-0740: Remote Policy management.
• AS-0750 - AS-0790: User Settings (note: there is some overlap with functions specified here).
• AS-0800 - AS-0820: Extensions (note: there is some overlap with functions specified here).

4.1 Authentication

This section addresses authentication of the various software components involved in network interfaces, including the WRT and its logical components as described in the introduction , WAC-certified App stores , and other WAC-specified network services as described below:

• WAC-certified App stores: Verified authenticity of the App store helps ensure that widgets can be trusted.
• WAC-certified App store Client : Verified authenticity of the App store Client helps ensure that widgets delivered to a user device will be handled in compliance with WAC.
• WAC-certified WRT: Verified authenticity of the WRT helps ensure compliance with WAC security and privacy requirements for security/privacy-sensitive APIs and data.

4.2 App store Authentication

In the requirements described below, please note that the device client that interfaces with a WAC-certified App store is referred to as the "App store Client", which may be a function of the WRT or a discrete, integrated client in the device.

SP-2010 All communication between an App store Server and an App store Client that involves the transmission of security and/or privacy-sensitive information or content MUST occur over an SSL -secured HTTP connection, using an SSL client and server certificates for authentication of the secure connection endpoints.

SP-2020 For communication over secure connections, the App store Client MUST require that the App store Server present an Extended Validation ( EV ) Certificate [EV Certificate] , and validate the server domain name in the certificate.

SP-2040 The App store Client MUST securely store client certificates and root certificates (for server certificate validation) used for mutual authentication with App store Servers.

Requiring widget download over a secure HTTP connection with EV server certificate validation ensures integrity of the widget package (as obtained from the server). Requiring a client certificate ensures that WAC-certified App stores do not provide widgets to non-WAC-certified clients where they would be vulnerable to attack.

4.3 Digital Signatures

Widget signatures ensure that a widget has not been altered in any way, and that its identity can be relied upon in the determination of content access authorization, e.g. as accessed via network and device APIs. In particular for unsigned widgets, authenticity assurance is not possible. Side-loaded widgets can be authenticated if signed by a trusted CA.

Processing Widget Signatures

A widget signature is valid if it satisfies the following conditions:

• It is verified by the user agent as a valid [Widgets-DigSig] digital signature.
• It contains embedded certificate data satisfying the following conditions:
  • each embedded certificate is a base64-encoded X.509 v3 certificate represented as an <X509Certificate> element;
  • each certificate is included, in certificate path order, from the end-entity certificate up to, and optionally including, the root certificate.

A widget signature associated with a widget is verified if, when processed by a WRT , it satisfies the following conditions:

• it is valid ;
• if it is a Distributor Signature :
  • the certificate path is terminated by a root certificate that the WRT recognizes as a valid root for a Distributor Signature ; and
  • each certificate in the certificate path is unexpired; and
  • each certificate in the certificate path other than the root has a determined OCSP Status of "good" or "unknown";
• if it is a author Signature :
  • the certificate path is terminated by a root certificate that the WRT recognizes as a valid root for a author Signature.

The set of DNS Identities of a certificate is obtained as:

• the set of all valid RFC1034 domain names encoded as a Subject Alternative Name extension of type dnsName; or, if no such extensions are present
• the singleton comprising the first CN component of the Subject Distinguished Name, if that represents an RFC1034 domain name.

A widget id matches a DNS identity if the scheme of the id is http or https and the host component of the id is identical to the DNS identity.

A widget is recognizedif:

• it contains a Verified Distributor Signature ; and
• it contains an id attribute; and
• the widget id matches a DNS Identity of the end-entity certificate of the Distributor Signature.

An unrecognizedwidget one that is not recognized.

The recognized originof a widget is determined based on the widget's id attribute, and is defined only when there is assurance of that origin, that is the widget is recognized.

For widget ids whose URI scheme is http or https, the Recognized Origin is the combination of scheme, domain, and port of the widget id. WAC may define the Recognized Origin for other URI schemes.

5 Processing Widget Signature

SP-2060 The WRT MUST support widget signature processing as specified in Widgets Digital Signature [Widgets-DigSig]. This includes the algorithm specifying the numerical order for processing distributor signatures.

SP-2061 The WRT MUST reject a widget as invalid and process no further signatures once it encounters an invalid signature.

SP-2063 The WRT MUST treat a widget as distributor signed once it encounters a verified distributor Signature.

SP-2064 The WRT MUST reject a widget as invalid and process no further signatures once it encounters a valid distributor signature which contains any expired or Revoked certificate.

SP-2065 The WRT MUST NOT display author information to the user when confirming that the user wishes to install a widget, unless

• the widget has a verified distributor signature ; or

• the widget has a verified author signature.

author information includes:

• information identifying the author of the widget contained in the widget's Configuration Document (see the <author> element);

• if the widget is recognized , the matching DNS Identity.

SP-2066 The WRT MUST allow installation of widgets with an expired author signature , if installation is not blocked by other conditions (e.g. SP-2067 ).

Note that the assignment of the widget to a trust domain under the applicable security policy is independent of whether the author signature is expired

SP-2067 The WRT MUST provide a user-configurable 'secure-by-default' preference to enable installation of widgets that are not distributor-signed , with the default value set to "No". If the user selects "Yes", they MUST be shown a warning explaining the potential dangers of installing unsigned widgets.

SP-2068 The WRT MAY further enhance the functionality in SP-2067 by supporting a latch function to reset the user preference once they have installed an unsigned widget. The options pop-up for this sub-functionality could be as follows: "only for one application", "for 15 minutes", "forever".

SP-2090 The WRT MAY support use of widget author signature attributes in the security model as specified in [BONDI A&S] AS-0280. The WRT MUST NOT associate the corresponding subject attributes with the widget unless the author signature is Verified.

SP-2110 If a Widget Resource has multiple distributor signatures that can be verified , the WRT MUST use the first distributor signature that is verified (based on the order of processing of distributor signatures defined in [Widgets-DigSig] ) and present the associated distributor signature Subject Attributes in the security model.

SP-2120 The WRT MUST support processing of certificates that conform to the PKIX Certificate and CRL Profile [RFC2459] , with the following addition:p>

• The WRT MUST support processing of certificates using the sha256WithRSAEncryption algorithm, as specified in [RFC4055] , with an RSA key length of up to 2048 bits.

5.1 Signature Revocation

The OCSP Status of a certificate at the time of processing by a WRT is determined as:

• one of "good", "revoked", or "unknown", corresponding to the value of the most recent, unexpired, OCSP response obtained for that certificate (if any);
• "good" if the certificate does not have an OCSP AIA extension.

The OCSP Status of a certificate is "undetermined" if it does not have a determined status (e.g. if the WRT has not yet obtained a response, or a cached response has expired).

A Widget Signature is Revoked if:

• it is valid ;
• the certificate path is terminated by a root certificate that the WRT recognizes as a valid root for that type of signature; and
• each certificate in the certificate path is unexpired; and
• any of its certificates has an OCSP Status of "revoked".

SP-2151 For each certificate except the root, of each verified Distributor Signature , the WRT MUST attempt to determine the OCSP Status at the time the widget is installed, without relying on any cached OCSP responses, and take action determined by the OCSP status as follows:

• if the status is "good", the WRT MUST proceed with installation
• if the status is "revoked", the WRT MUST reject the widget
• if the status is "unknown" or is undetermined because it was not possible to obtain a valid response from the server, then the WRT MUST disregard that Distributor Signature. If as a result there is no remaining verified Distributor Signature, the WRT MUST continue processing the widget as an Untrusted Application, or cancel or defer installation.

For the avoidance of doubt, installation as an Untrusted Application MUST still be subject to the requirements and constraints that would normally apply to Untrusted Applications, such as SP-2067.

SP-2152 For the end-entity certificate of each Distributor Signature , the WRT MUST attempt to determine the OCSP Status at the time the widget is instantiated (i.e. launched). The WRT MAY use an unexpired cached OCSP response for the purposes of this check. If the status is "revoked" then the WRT MUST issue a suitable error message, cancel instantiation of the widget and block it from being instantiated at any later time.

SP-2162 The WRT MUST use SHA-256 hash algorithm [SHA2] when calculating Cert ID value.

SP-2163 The WRT MUST be capable of verifying OCSP response signatures computed with the sha256WithRSAEncryption signature algorithm (see [RSA Algorithms] ).

SP-2164 The WRT MUST support SHA-256 algorithm for KeyHash of ResponderID in OCSP Response.

SP-2165 The WRT SHOULD support Certificate Revocation List ( CRL ) retrieval and processing as described in [Widgets-DigSig].

6 Widget Protection

SP-2180 To prevent unauthorized access and modification, the WRT MUST securely store copy-protected widget resources, including preventing the widget resources from being viewed, exported, modified, or otherwise accessed in any way by other applications on the device, or by the user.

SP-2185 If the WRT supports the installation of widgets on removable memory or in device file system locations that are generally accessible, the WRT MUST encrypt copy-protected widget resources stored in those locations, using strong encryption methods.

WAC may extend this widget sharing model with support of Digital Rights Management ( DRM ) in the future. The terms under which the widget can be obtained through URI sharing will be determined by the App store. This can for example, enable widget super-distribution through the App store recording widget sales and downloads. The user can then re-download or re-distribute widgets, e.g. for family use in cases where locales that require this. Note: It is also expected that for customer service e.g. as a result of full device reset or refurbishment, the user will be able to re-download widgets to their device from the App store.

SP-2196 The WRT MUST NOT allow side-loading of copy-protected widgets.

7 Security Framework

SP-2200 The WRT MUST include a policy-based access control mechanism that mediates all access by web applications to device capabilities and network resources.

7.1 Trust Domains

SP-2240 The WRT MUST support the definition of trust domains based upon the following policy subject attributes related to widget identities and website identities:

• id: widget identifier from the widget package
• version: widget version from the widget package
• distributor-key-cn: common name from the distributor signature
• distributor-key-fingerprint: fingerprint of the distributor signature
• distributor-key-root-cn: common name of the root key of the distributor signature
• distributor-key-root-fingerprint: fingerprint of the root key of the distributor signature

7.2 Policy Rules

SP-2250 The WRT MUST support the following options for policy rule effects :

If a user decision has been remembered for a rule, that decision takes effect for all subsequent policy queries for that application that resolve to the same rule.

7.3 Policy Structure

SP-2290 The WRT MUST support the following policy resource attributes , as specified in [BONDI A&S Appendices] :

• device-cap
• param:name.

SP-2310 The WRT MUST support representation of a policy structured according to the model specified in [BONDI A&S Appendices] Appendix B with at least the following policy constructs :

• Subject Attributes (B.4), supporting at least the attributes listed above
• Resource Attributes (B.5), supporting at least the attributes listed above
• Attribute Match (B.7)
• Subject Specification (B.8)
• Target (B.9)
• Rule (B.11)
• Condition (B.12)
• Policy (B.13)
• Policy Set (B.14)
• String Equality Matching Function (B.17.1)
• Globing Matching Function (B.17.2)
• Modifier Function (B.18)
• Deny-Overrides Combining Algorithm (B.12)
• First-Applicable Rule Combining Algorithm (B.14)
• First-Matching-Target Policy Combining Algorithm (B.15)
• Effect (B.20).

For more user options related to prompts and permissions, see 3.4.4. User Prompting and Preferences.

7.4 Sensitive Capabilities

The WRT MUST support identification of sensitive capabilities using Device Capabilities derived from the feature string of device APIs.

SP-2281 The WRT MUST support controlled access to network resources through the definition of network access conditions in the policy, using the following network access device capabilities :

7.5 Security Parameters

SP-2282 The WRT MUST support the following environment attributes and device capability request parameters in policy rules:

A rule for param:uri in XMLHttpRequest or externalNetworkAccess can be used to restrict access to resources by URI scheme, allowing network resource controls not currently supported by the Widget Access Request Policy ( WARP ) [WARP]. For example, this may be used to deny access to a specific URI scheme. The following policy expression can be used, and is based upon the policy schema defined in BONDI A&S Appendices:

<rule effect="deny"> 
<condition> 
<resource-match attr="device-cap">XMLHttpRequest</resource-match>
<resource-match attr="param:uri" func="equal">market</resource-match>
</condition> 
</rule>

To deny access to any URI scheme other than http(s):

<policy combine="first-applicable"> 
<rule effect="permit">
 <condition> 
  <condition combine="or"> 
   <resource-match attr="device-cap" 
              func="equal">XMLHttpRequest</resource-match> 
   <resource-match attr="device-cap" 
              func="equal">externalNetworkAccess</resource-match>
  </condition>
  <resource-match attr="param:uri.scheme" 
                  func="glob">http*</resource-match>
</condition> 
</rule> 
<rule effect="deny"> 
  <condition>
    <condition combine="or"> 
    <resource-match attr="device-cap" 
                func="equal">XMLHttpRequest</resource-match>
    <resource-match attr="device-cap" 
                func="equal">externalNetworkAccess</resource-match>                                     
     </condition> 
    <resource-match attr="param:uri.scheme" 
                    func="glob">*</resource-match>                                      
   </condition> 
 </rule>
</policy-set>

7.6 Policy Deployment

The WRT needs to securely store security policies and certificates used to validate widget signatures.

The WRT MUST NOT have any hidden mechanisms to allow subversion of the WAC security framework (for example a hidden menu that disables policy checking).

The WRT MUST support the customisation of policies by individual Operators. This does not imply a requirement for specific WRT UI capabilities for policy customisation. Specific methods of Operator customisation of policies are undefined in this release. It is assumed that Operators will specify the policy to the WRT vendor prior to deployment of the WRT in devices supported by the Operator. This will be either as pre-loaded or downloadable, Operator-signed, (i.e. trusted) software client. Policy updates as supported in BONDI (via delivery of a signed policy file) are not in scope for this release but may become an Operator-specific requirement. Furthermore, related UI-requirements to such policy updates (which are not in scope for this release as above) are to be determined.

Upon SIM swap, the WRT MUST continue to apply installed security policies and widget permissions, unless the WRT supports the association of policies to individual Operators, e.g. through policy signatures.

The WRT MUST be capable of being configured to implement the default access control policy as specified in 3.10. Default Policy.

The WRT MAY be capable of applying different policies depending upon device configuration or user identity/role, e.g. for application of enterprise policies or parental control policies.

The WRT MAY provide a password control option for policy switching and editing, e.g. to allow the switching-on or customisation of a parental policy.

7.7 Policy Enforcement

SP-2360 The WRT MUST take the following device capability mediation actions prior to launching widgets, as specified in [BONDI A&S] :

• As part of the resolution of each statically referenced Feature, the WRT MUST evaluate an access control Query that determines whether or not the Web Application is authorized to access each device-capability that is accessed by any of the methods made available by the requested Feature. If the evaluated Decision of that Query is Deny, and the dependency is marked as required, the WRT MUST abort installation and it MUST not be possible to instantiate that Widget.
• If permission is not granted for that Widget to access that Feature, and the dependency is marked as optional, the WRT MUST continue installation. The WRT MUST fail access to any associated JavaScript API at runtime if the dependency remains unsatisfied at the time the Widget is instantiated.

SP-2380 The WRT MUST take the following device capability mediation actions for attempted accesses by widgets to device capabilities, (based in [BONDI A&S] requirements which are referred for information purposes only):

• The WRT MUST only enable a Web Application to use a JavaScript API if a dependency has been explicitly expressed on the corresponding Feature and access to the Feature has been granted (based in [BONDI A&S] Requirement AS-0351).

• The WRT MUST resolve Feature dependencies of a Web Application to already-available Features (based in [BONDI A&S] Requirement AS-0352).

• In the resolution of each Feature request, the WRT MUST deny access to the requested Feature upon a failure to resolve and satisfy any dependency (based in [BONDI A&S] Requirement AS-0354).

• The WRT MUST return a non-fatal run-time error each time an operation is attempted that calls the JavaScript API associated with (or that otherwise depends on) a Feature that could not be resolved (based in [BONDI A&S] Requirement AS-0355).

• The WRT MUST use a configured Security Policy as the sole basis on which access control decisions are made when a Web Application attempts to make use of a Feature on which it has previously expressed a dependency(based in [BONDI A&S] Requirement AS-0500).

• The WRT MUST verify that each use of each API method made available by a Feature is permitted by evaluating an access control query that determines whether or not the Web Application is authorized to access each device-capability that is accessed by the given API method.

Note that widget-external documents loaded into iframe elements (ie iframes whose document has a remote origin) will be given no access to WAC-defined device APIs, since Web domains are not supported in this release as subjects of security policies. Thus in the event that the external document did contain code invoking WAC-defined APIs, the checks required in SP-2380 would result in a security exception.

7.8 User Prompting and Preferences

Note: specific user interface or presentation methods are not mandated by these requirements. However, the requirement is that WRTs use effective methods to convey the specific information described below, and provide the user with effective controls for managing their preferences.

SP-2390 Upon user request, the WRT MUST display the expressed dependencies ( API s related to <feature> element statements in the widget configuration document) of a widget prior to granting permission for the widget resource to be installed.

SP-2400 The WRT MUST allow the user to restrict permission for any device capability to be accessed by a given web application, or for all web applications, even if the configured access control policy permits access without prompting.

Requirement SP-2400 would for example, enable the user to specify that a previously configured prompt-session permission be changed to prompt-oneshot. This however, can impact on the user experience and potentially cause problems with the applications. The potential dangers associated with this action should be made clear to the user in the UI provided for such policy preferences management.

SP-2405 The WRT MUST NOT allow the user to elevate permissions beyond the level specified in the Operator's deployed policy.

SP-2406 The WRT SHOULD allow the user to reduce permissions to below the level specified in the Operator's deployed policy.

SP-2420 The WRT MUST provide the user with the ability to review, and selectively remove, permissions previously granted by the user in responses to explicit prompts.

SP-2421 The WRT MUST provide the user with a password-protected facility to review, and selectively remove, permissions previously granted by the user through configuration options, e.g. via a security/privacy preferences menu.

SP-2422 For user-managed policies, e.g. a parental control policy, the WRT MAY require user password verification for actions that elevate permissions within the scope of what is permitted within the user-controlled policy domain.

8 Security Features of Web Technologies

9 Non-WAC APIs

The WRT MUST support protection of WAC -defined Device Capabilities under the WAC security framework, for all non-WAC API s and supported WAC-legacy APIs (i.e. those defined in earlier WAC versions).

The intent of this requirement is to prevent non-WAC APIs from enabling widgets to circumvent the objectives of this specification, or the specific applicable policies. All APIs must be capable of being protected under the WAC security framework. However this should not impact backward compatibility of supported legacy APIs.

The WRT MUST NOT allow installation of 3rd-party plugins.

"3rd-party" refers to any extension other than those provided by the device OEM , Operator, or WRT vendor. The purpose of this requirement is to prevent untrusted functionality from being added to the WRT, and weakening the overall security model. It does not prevent the device OEM, Operator, or WRT vendor from bundling WAC-certified extensions in a WRT product, or from supporting downloadable extensions that are WAC-certified. In these cases however, such extensions are considered part of the WAC-certified product.

10 Privacy

The WRT should do its best to protect any user private information used for its internal purposes, i.e. not expose the information through the device filesystem or WRT features (e.g. storage or JavaScript objects).

10.1 Privacy Considerations for Device Property Access

Device properties have been grouped so that the exposure of those properties through the Device Status API can be controlled without users and policy writers being faced with an overwhelmingly complex set of choices. The groups are defined in the specifications below:

The property group "deviceinfo" includes data points that describe features or technical limits of the user's device, and are generally considered not privacy sensitive. However, a policy control option for this group of properties addresses concern about potential misuse of this information for fingerprinting, identification or tracking purposes.

The WRT MUST control access to these device information properties as a group, through the Device Capability "devicestatus.deviceinfo":

• Battery
• Device
• Display
• MemoryUnit
• OperatingSystem
• WebRuntime.

The property group "networkinfo" includes data points that describe features or technical limits of the network connection or connections that are available to the device. These properties are considered privacy sensitive. These properties in particular, may be more likely to be misused for fingerprinting, identification or tracking purposes.

SP-2620 The WRT MUST control access to the network information through the Device Capability "devicestatus.networkinfo" that groups the following aspects as defined in the Device Status Vocabulary :

• CellularHardware
• CellularNetwork
• WiFiHardware
• WiFiNetwork.
• mcc, mnc.

10.2 Parental Mode

Security of users of the WRT is important and this specification details a WAC security policy which provides a mechanism for restriction of content and access to device capabilities at the capability level. This approach allows fine-tuning of specific security requirements and also the ability for the widget to be used in alternative locales with differing national security requirements. A parental mode is specified in this section to provide blanket control of the access to many device capabilities allowing young device users to use widgets safely. Once activated, parental mode overrides any widget settings and the WAC security policy and the specifications below come into force.

The support for an explicit, user-activated Parental Mode avoids limitations of automatically detecting that a child is using the device. However, in addition, while it is not technically possible to perform an age verification on a device yet (this may be possible in later versions of WAC), there are specific categories that can be used to help parents make decisions about the policy they want to apply. In different countries, criteria determining a "child" or "minor" vary considerably. However, there are some global standards. A child must be 13 before they can access Facebook for example. It is therefore possible to define "cutoffs" to differentiate between different age groups and what they could access.

This specification focuses on capabilities that can be access controlled and which are defined by the user of a device when the Parental Mode is activated. The flexibility of the WAC security policy framework allows creation of policies that prevent access to features which a parent may not want their child to use. Because the policy is flexible, it means a recommendation can be made to a parent, but it is up to them to decide whether their child can use certain features and at what level of permissions. There are many cases where a parent is likely to want their child to use advanced device API features and trust the service very well. For example, a parent may allow their child to use the Google Maps service as useful tool and having prior knowledge of the service knows how the service uses personal information (such as location in this case).

SP-2700 The WRT MAY provide a password-controlled "Parental Mode" which can be activated and deactivated by the user.

SP-2710 When Parental Mode is active, the WRT MAY apply the Parental Mode restrictions as defined in this section.

SP-2720 The WRT MAY provide a password-controlled facility for a user-managed list of restricted URI s.

SP-2730 The WRT MAY provide a password-controlled facility for a user-managed list of restricted content and application types, per the WAC-defined content categorisation vocabulary.

The user-managed lists may be embedded within the WRT itself or supplementary to the policy on the device. The WAC-defined content categorisation vocabulary may be extended in a subsequent version of this document.

SP-2740 When Parental Mode is active, the WRT MAY restrict access to the sites, content types, and application types in the restricted-access lists defined above.

It is recommended that Operators, WRT vendors, and other policy providers work to deploy a default list of restricted-access URIs, content types, and application types. These should cover prevention of access to:

• "socially location enabled" services
• "unmoderated chat forums" services
• "social networking applications"
• generalised content categories, e.g. ADULT, SEXUAL, VIOLENT.

SP-2750 When Parental Mode is active, the WRT MAY require one-shot prompt confirmation for camera, video, and audio capture operations.

The potential for fun child-centred widgets which use the camera and microphone are endless, for example voice distorting apps or wacky picture creators. However there is a potential risk that access to these capabilities could allow surveillance of a child. Requiring a one-shot prompt when in Parental Mode will prevent surveillance concerns by restricting automatic media capture by widgets, and allowing the child to be in control of when the device is able to capture such data.

SP-2760 When Parental Mode is active, the WRT MAY block widget access to geolocation information.

Under certain ages, it is recommended that no location information is accessible (this is closely related to the "social location" comment above). It is further recommended that "high accuracy" location be restricted to users in certain age ranges (e.g. between 13 and 18 years old), but the above-mentioned limitation on age verification limits the feasibility of this restriction. The fall back is a global restriction on access to location information when Parental Mode is on.

SP-2770 When Parental Mode is active, the WRT MAY block user access to widgets that list advertising as a primary or secondary use of user information.

This requirement fulfils the WAC objective of preventing "advertising targeted at children".

SP-2780 When Parental Mode is active, the WRT MAY require entry of the Parental Mode password for installation of widgets.

SP-2781 When Parental Mode is active, the WRT MAY block side-loading of widgets.

11 Default Policy

WAC specifies a BONDI-like security framework with a flexible policy at the device capability level. Some device capabilities also have independent security parameters that allow a finer resolution to the security policy rules. JIL however, defined a fixed policy on the API method and property level. The WAC flexible approach allows the operator to adapt the security policy to national laws, legal guidelines or requirements and company security and privacy policies.

In addition, the WAC security framework gives the possibility to define network access conditions in the policy.

The disadvantage of a flexible policy is the possible fragmentation of the user experience, however, this is mitigated by a clear system response to API calls where the policy prevents access to a feature. Developers should ensure that they follow guidelines for application development to ensure a consistent and reliable user experience.

The default policy should:

• help to limit policy fragmentation
• give operators a basis for the definition of their own policy
• be used by operators who decide not to specify their own policy
• help developers better understand how applications will behave on runtime.

11.1 Trust Domains

Three trust domains are defined for the default policy.

11.2 Permissions

12 Widget Lifecycle

This chapter of the WAC Core Specificationdefines the requirements for WAC -certified web runtime ( WRT ) processing of widgets throughout the widget lifecycle. The widget lifecycle is defined as all stages and steps through which the user manages their widgets, including:

• discovery
• selection
• download
• installation
• update
• sharing
• preferences management
• uninstallation.

The widget lifecycle up to the point of installation may be fulfilled by different mechanisms. This specification does not mandate any of these mechanisms but defines the expected behaviour in some of them.

Application Store Client (" App store Client ") triggered installation

An App store Client which is integrated with the WRT (either as part of the WRT or otherwise securely integrated with the WRT), enables the user to obtain widgets from an App store Server. Through the App store Client, the user may be able to perform various steps, leading to the download of a widget to the user's device, which triggers installation of the widget.

Installation triggered by browser download of widget package

The user may use the device browser to download widgets directly. Upon the completion of widget package download, the browser hands the widget package off to the device's registered handler for widget packages. This is typically the WRT as Widget Manager (a logical component of an integrated WRT software suite on the device), thus triggering installation. Note that this installation option is considered side-loading , and cannot be used for direct download and installation of copy-protected widgets.

Installation triggered by browser download of widget sharing file

The user may be able to use the device browser to initiate widget download through the "kicker file" approach described in Widgets Sharing. This process can be initiated either by one user sharing a widget with another, or a browser-based widget AppStore which uses the widget sharing file approach to initiate widget download. As the WRT or its integrated AppStore Client is responsible for download of the widget package, this process therefore can be used for download and installation of copy-protected widgets.

Installation triggered by file explorer

The user may be also able to browse the device filesystem to select a widget package available in the memory of the device or any removable storage. Upon selection of an "open" function on a widget package file, the device invokes the Widget Manager Client which is configured as the device handler for widget packages (e.g. by file extension or MIME type if available as filesystem metadata), thus triggering installation. Note that this installation option is considered side-loading, and cannot be used for installation of copy-protected widgets.

12.1 Discovery

This section is a placeholder for future requirements related to the user's ability to discover available widgets for their device.

No specific requirements are defined, however, in the current release, support for the discovery phase of the widget lifecycle is limited to the requirements in the sections specified below:

• WRT disclosure of its capabilities and those of the host device, as described in 5.2. User Agent Identification. This information can be used by App stores to preselect widgets that are compatible with the user's device.
• Widget metadata describing widgets and the API features they intend to use, as described in 2.7.1. Widget Packaging and Configuration. This information can be used by App stores to preselect widgets that are compatible with the user's device and user preferences.
• Widget metadata that may be presented to the user or used in filtering of available widgets by user preferences, including content categorisation metadata as described in 3.7. Description Resources and privacy-related metadata as described in 3.8. Privacy.

All other functionality and capabilities supporting widget discovery are out of scope for this release. These must be defined as necessary by each App store, and implemented by the related App store Client (if any) on the device. App store support for browser-based widget discovery is also an option, and avoids any device requirements during this lifecycle phase.

12.2 Selection

This section is a placeholder for future requirements related to the user's ability to select specific widgets for use on their device, e.g. using an App store Client or browser. The selection process can include such functions as advice of charges, disclosure of terms and conditions of use, and user acceptance of presented charges and disclosures as applicable. These functions must be defined as necessary by each App store, and implemented by the related App store Client (if any) on the device. App store support for browser-based widget selection is also an option for the operator, and avoids any device requirements during this lifecycle phase.

No specific requirements are defined in support of this lifecycle phase in the current release.

12.3 Download

This section is a placeholder for future requirements related to the user's ability to obtain the widgets that have been selected for installation on their device(s). The download process can include such functions as direct and indirect delivery (such as where a trusted client is invoked for reception of the widget package), re-download to the same or other devices, download verification etc.

No specific requirements are defined, however, in the current release, support for the download phase of the widget lifecycle is limited to:

• Widget download through the "kicker file" approach as described in 4.6 Widget Sharing

The Widget Sharing feature can be used by App stores to invoke the download of a widget package, as referenced by the <downloadUrl> element of the widget sharing file. Since the actual download of the widget package occurs through the WRT or its integrated App store Client, the widget package is securely handled, and thus the browser-based download initiation option can be supported. In the <downloadUrl> element, the App store can include additional parameters such as a download ticket, for example by use-limited or time-limited tickets. An example flow description:

• The user browses the App store, selects a widget, and purchases it (if applicable). The store returns a kicker file with the download URL containing a token for download, and determines that this user (typically identified by MSISDN) is entitled to download the widget.
• The browser invokes the WRT as the registered kicker file handler. The WRT retrieves the widget from the App store using the download URL from the kicker file. Using the valid ticket, the App store delivers the widget.
• The WRT installs the widget, and the widget is securely stored.

All other functionality and capabilities supporting widget download are out of scope for this release. These functions must be defined as necessary by each App store, and implemented by the WRT or its integrated App store Client on the device.

12.4 Installation

This section addresses the handling of widget packages once they have been received by the device.

WL-3210 The WRT MUST inform the user if a widget cannot be installed because one or more required features are not supported.

WL-3230 The wac:min-version attribute is a string attribute defined in the "http://wacapps.net/ns/widgets" namespace that identifies the minimum WAC platform version required by the widget to run. When the attribute is missing, or in error, the WRT assumes the widget supports any version of the WAC platform.

If the value of the wac:min-version attribute does not conform to the rec-version-tag as defined in [Widget Packaging] , then the wac:min-version attribute is in error and the WRT MUST ignore it (i.e., behave as if it had not been declared by the developer).

WL-3240 If the WAC version supported by the WRT is less than the required min-version , the WRT MUST inform the user of the potential for incompatibility with the WRT version, and offer the user the option to cancel installation.

12.5 Widgets Installed from an AppStore Client

The capability to update a widget to the latest available version is essential for end-users to ensure the latest updated widget version is installed, and for developers to enhance widget functionality or to fix bugs post-distribution. This capability is important, however, the method of implementation or use may differ depending the method of installation of the widget.

WL-3300 For widgets that have been installed through an App store Client , the App store Client MUST be able to check for updates from the App store Server.

WL-3310 The user MUST have the option to perform an update check for a specified widget installed by the App store Client.

WL-3320 The user MUST have the option to perform an update check for all the widgets installed by the App store Client.

WL-3330 The user MUST be able to choose to install all or a subset of the available updates.

WL-3340 The App store Client SHOULD be capable of periodically checking for widget updates.

WL-3350 The time between periodic update checks SHOULD be customisable by the Operator or user.

WL-3360 The App store Client MAY provide the user with an option to download and apply any updates automatically, or to require confirmation prior to applying widget updates.

WL-3370 The WRT MUST process widget packages as an update when received under the following conditions :

• the received Widget Id matches the Widget Id of an installed widget
• the received Widget version number is greater (as a compared string) than that of the installed widget, or no version information was provided for the installed widget.

To ensure that a string comparison of widget versions can reliably determine which version is an updated widget, WAC will mandate a specific version string format for WAC widgets. All widgets coming through the WAC channel will be required to have version strings in this specified format. Side-loaded widgets may have any format and, in this case, there is no requirement that the WRT support version detection for update of these widgets.

The widget version format is the rec-version-tag grammar as described in [Widget Packaging] :

• rec-version-tag = 1*DIGIT "." 1*DIGIT [ "." 1*DIGIT]
• *[ 1*ALPHA / SP / 1*DIGIT ]

Examples of rec-version-tag:

• 1.0
• 1.10.1 beta1
• 1.02.12 RC1

WL-3371 The WRT MUST use the following widget version comparison algorithm to compare WAC widget version strings:

• prepare the version strings for comparison:
  • all leading zeros are discarded
  • the optional *[ 1*ALPHA / SP / 1*DIGIT ] part, if present, is discarded
  • the resulting numbers are then in the format major.minor[.micro]
• Version A = Amajor.Aminor[.Amicro] is equal to Version B = Bmajor.Bminor[.Bmicro] if and only if:
  • Amajor == Bmajor AND
  • Aminor == Bminor AND
  • ((Amicro == Bmicro) OR (Amicro==Bmicro==absent)).
• Version A = Amajor.Aminor[.Amicro] is greater than Version B = Bmajor.Bminor[.Bmicro] if and only if:
  • Amajor > Bmajor; or
  • Amajor Bmajor && Aminor > Bminor; or
  • Amajor Bmajor && Aminor == Bminor && both Amicro and Bmicro are present and Amicro > Bmicro; or Bmicro is absent.

WL-3380 If an update has been received for a running widget , the WRT MUST wait until the widget exits before installing the update.

WL-3390 The WRT MUST preserve widget preferences and other widget-specific storage data when applying an update.

Note: the migration of data as necessary during widget updates (e.g. changes in local stored data) is an application concern that the widget developer will need to take into consideration when planning an update.

12.6 Side-Loaded Widgets

Side-Loading is the term used for widgets installed by all means other than an App store Client.

WL-3400 The WRT MAY support processing of the widget configuration document update-description element as specified by the W3C Widget Updates [Widgets Updates] specification.

WRT support for the Widgets Updates specification is optional, and is intended, for example, to handle widgets obtained by side-loading. The following requirements relate to processing of widget updates, independent of whether the WRT supports the Widgets Updates specification. In WAC , the general process for discovery and delivery of available widget updates is assumed to be Operator or App store specific, and is not dependent upon the Widgets Updates specification.

12.7 Uninstallation

WL-3600 The WRT MUST remove any personal and configuration data linked to a widget when the widget is uninstalled, including data relating to:

• the widget package
• any internal data of the WRT created in support of the widget package installation or widget operation
• WRT-internal persistent storage specific to the widget
• WRT-external private storage specific to the widget.

WL-3610 The WRT MUST NOT automatically remove any data downloaded or created through the widget which is not specifically associated with the widget. Such data may include for example:

• media files created or downloaded and stored in open areas of the device filesystem, or in a media gallery
• other types of files created or downloaded and stored in open areas of the device filesystem
• other data created by the widget and stored in specific locations not directly associated with the widget, e.g. contacts, tasks, calendar entries etc.

WL-3620 The WRT SHOULD provide the user with the opportunity to give feedback on why they are uninstalling the widget , including if they believe the widget to be malware. This feedback must be delivered to the App store from which the widget was installed.

A specific method of feedback delivery to the App store is not specified in this release. Feedback collected however, is expected to be delivered by the App store to WAC.

13 Widget Sharing

13.1 Generation of web app sharing messages

WL-3500 The WRT MAY provide the user with an option to share any Distributor-signed widget (as an application sharing feature) using standard mechanisms as supported by the platform, e.g. SMS, email, Bluetooth, etc.

If WL-3500 is implemented then WL-3510 and WL-3520 MUST be implemented.

WL-3510 If WL-3500 is implemented the WRT MUST use the widget sharing URI format <scheme>://<domain>[/<location>]/<Widget Id>[/<version>] , where:

• The <scheme> MUST be either http or https.
• The <domain> is defined by the Operator and SHOULD be a configurable value on the device. The <domain> represents the domain of the resolution server that is used by the Operator. The default domain is the WAC domain or, typically, the Operator's own domain to which the Operator's resolution server is assigned.
• The <location> is an optional URI field defined by the Operator or WAC and SHOULD be a configurable value on the device. The <location> represents a path on the resolution server that is used by the Operator or WAC.
• The <Widget Id> MUST be the Widget Id located in the widget configuration document and MUST be escaped as necessary for any characters that are reserved as specified by [RFC2396].
• The <version> MUST be the version value (if any) located in the widget configuration document and MUST be escaped as necessary for any characters that are reserved as specified by [RFC2396].

Note that the Widget Id is mandatory in the widget sharing URI. Presence of a Widget Id in distributor-signed widgets is assumed to be enforced by the distributor, e.g. in the widget testing process.

WL-3520 If WL-3500 is implemented the WRT MUST ensure that the widget sharing URI plus any additional text message requested by the user or inserted by default is in total less than 140 characters. This is in order to be compatible with SMS delivery in networks or to devices that do not support SMS concatenation.

The link in the widget sharing message, when selected by the receiving user, will invoke the user's browser which will request the resource from the widget sharing URI. The Operator of the widget sharing resolution server is expected to resolve the included widget hash to the correct Widget Id. Resolving of Widget Ids is recommended to be optimised on the server to minimise the response time.

The resolution server will respond with a "kicker file", which is a WAC-defined document with a WAC-registered MIME media type application/vnd.wac.widget-sharing . The MIME type will be registered on the device thus when the browser receives the resolution server response, the WRT or its integrated App store Client will be invoked for further handling of the widget sharing request.

13.2 Browser based App Stores and Web App Sharing

WL-3530 If the WRT is integrated with an App store Client , the WRT's App store Client SHOULD be registered as the media type handler on the device for the MIME media type application/vnd.wac.widget-sharing , so that when browsers receive the widget sharing kicker file, the App store Client is invoked as the handler of the kicker file.

WL-3535 If the device does not have a dedicated App store Client , the WRT SHOULD support enough functionality as a " Download Manager " to facilitate secure download and installation of widgets obtained from a WAC authenticated, browser based App store.

If WL-3535 is implemented then WL-3540 , WL-3541 , WL-3542 , WL-3543 and WL-3550 MUST be implemented.

WL-3540 If WL-3535 is implemented and in the case that the WRT serves as a Download Manager , the WRT MUST be registered as the media type handler on the device for the MIME media type application/vnd.wac.widget-sharing , so that when browsers receive the widget sharing kicker file, the WRT is invoked as the handler of the kicker file.

WL-3541 If WL-3535 is implemented and if the Download Manager is configured to use a default App store domain and the downloadUrl field in the kicker file is either not present or has no value, the Download Manager MUST use the default App store domain as the <domain> field of a widget sharing request URI (see WL-3510) and launch the default browser with the subsequent URL.

WL-3542 If WL-3535 is implemented and if the Download Manager is not configured to use a default App store domain and the downloadUrl field in the kicker file is either not present or has no value, the Download Manager MUST construct an App store request URL in the following format: <scheme>://<domain>/<request>/<Widget Id>[/<version>] where <request> is the string " App store " e.g.: http://wacapps.com/App store/... , and launch the default browser with this URL.

WL-3543 If WL-3535 is implemented and if the downloadUrl field is present in the kicker file, the Download Manager MUST initiate a widget download by issuing a GET request to the URL in the downloadUrl field.

WL-3550 If WL-3535 is implemented the WRT or its integrated App store Client MUST recognise the following widget sharing "kicker file" elements defined in the WAC namespace "http://wacapps.net/ns/wacshare":

Example kicker files:

<wacshare xmlns="http://wacapps.net/ns/wacshare"> 
<widget id="http://widgets.example.com/geotweet"
version="1.0"> 
</widget> 
</wacshare> 
<wacshare xmlns="http://wacapps.net/ns/wacshare">                                                     
<widget id="http://widgets.example.net/geotweet"> 
<download src="http://ddprdm.net/wac/widgets/geotweet.wgt"/> 
</widget> 
</wacshare> 
<wacshare xmlns="http://wacapps.net/ns/wacshare">
<widget id="http://widgets.example.net/geotweet" version="1.0"> 
<download src="http://ddprdm.net/wac/widgets/geotweet.wgt" />
</widget>
<widget id="http://widgets.example.net/geotweet" version="1.0"> 
<download src="http://ddprdm.net/wac/widgets/geotweet.wgt" /> 
</widget>
</wacshare>

Further handling of the widget sharing request, e.g. processing by the WRT or App store Client and interaction with the App store Server, is not specified in this WAC specification release.

14 SIM Swapping

If a user served by another Operator puts their SIM into a device not configured for use with that Operator's widgets or App store, it is likely that the user will experience errors in the widget and or App store operation. However the types of errors that may occur and what the WRT does in response to better the user experience are out of scope for WAC specifications.

If a user served by the same Operator puts their SIM into a device, widgets and App store services may operate as expected, but problems may be encountered with any personalised services dependent upon the user identity. The types of errors that may occur and what the WRT does in response to better the user experience are out of scope for WAC specifications.

Overall there are no special actions to be taken in WAC by the WRT when a SIM swap occurs.

15 References

All references are normative unless marked "Non-normative". For W3C specifications that are "Work in progress", the latest published drafts (as of the publication date of this specification) are referenced. Later published drafts or final released versions of these specifications supersede any prior versions shown below, and developers are encouraged to refer to the latest editor's drafts for works in progress.

[BONDI]

BONDI 1.1.Approved Release. OMTP .

[BONDI A&S]

BONDI 1.1.Architecture and Security Requirements. OMTP .

[BONDI A&S Appendices]

BONDI 1.1.Architecture and Security Requirements (Appendices). OMTP.

[CSS 2.1]

Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification . W3C.

[CSS Device Adaptation]

CSS Device Adaptation (Work in progress). W3C.

[CSS3]

CSS3 Modules. W3C.

[CSSOM View]

CSSOM View Module . (Work in progress). W3C.

[Selectors API]

Selectors API . (Work in progress). W3C.

[DOM4]

DOM4 . (Work in progress). W3C.

[ECMAScript]

ECMAScript Language Specification. ECMA.

[Extended Validation (EV) Certificate]

Extended Validation (EV) Certificate . CA / Browser Forum.

[HTML]

HTML Standard , (Work in progress). WHATWG.

[JSON]

JavaScript Object Notation. IEFT.

[OCSP]

RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. IETF.

[OCSP-MP]

Online Certificate Status Protocol Mobile Profile specification. OMA.

[OMA TLS Profile]

OMA TLS Profile. OMA.

[OMA URI Schemes]

URI Schemes for the Mobile Applications Environment. OMA.

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. IETF.

[RFC2396]

Uniform Resource Identifiers (URI): Generic Syntax. IETF.

[RFC2397]

The "data" URL scheme. IETF.

[RFC2459]

Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF.

[RFC2616]

Hypertext Transfer Protocol -- HTTP/1.1. IETF.

[RFC2817]

Upgrading to TLS Within HTTP/1.1. IETF.

[RFC2818]

HTTP Over TLS. IETF.

[RFC3966]

The tel URI for Telephone Numbers. IETF.

[RFC4055]

Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF.

[RFC5724]

URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS). IETF.

[RSA Algorithms]

Additional Algorithms and Identifiers for RSA Cryptography . IETF.

[SHA2]

FIPS 180-3: Secure Hash Standard. NIST.

[SVG Tiny]

Scalable Vector Graphics (SVG) Tiny 1.2.Specification . W3C.

[UAProf]

User Agent Profile 2.0 . OMA.

[View Mode Media Feature]

The 'view-mode' Media Feature. W3C.

[WARP]

Widget Access Request Policy. W3C.

[Widgets-APIs]

Widget Interface. W3C.

[Widgets-DigSig]

XML Digital Signature For Widgets. W3C.

[Widgets-Packaging]

Widget Packaging and XML Configuration , W3C.

[Widgets Updates]

Widget Updates (Work in progress). W3C.

[Widgets-URI]

Widget URIs. W3C.

[XHR]

XMLHttpRequest (Work in progress). W3C.

[XML]

Extensible Markup Language , W3C.

Change Log

This specification was last updated on 30 April 2012. A complete list of changes are kept on our GIT repository.

April 27, 2012

Moved some sections around to make the document a bit more logical.

April 26, 2012

Removed Widget Client Authentication section, as WAC has no plans to act as a CA ( member only bug ).

January 3, 2012

Reduce complexity of application signing: The WAC 2.0 specification required WRTs to recognise three types of signature (author signature, WAC distributor signature and operator distributor signature). Unfortunately, the requirement to support multiple signatures posed some challenges to the community. In the interests of ease of implementation and reducing complexity, the specification was simplified such that only a single signature needs to be present in a valid WAC 2.1 application, and only a single signature needs to be processed by compliant WAC 2.1 WRTs. WAC members can view the complete rationale and requirement for the change in the WAC Wiki.