Wholesale Application Community Device API Specifications 2.1

Core Specification

The WAC Core Specification defines the core requirements and base APIs for a widget engine.

Contents

  1. 1 Introduction
    1. 1.1 Conventions
    2. 1.2 Definitions
    3. 1.3 Conformance
  2. 2 Widget Runtime
    1. 2.1 User expectations
    2. 2.2 Web Standards
    3. 2.3 URI Schemes
    4. 2.4 WRT Identification
    5. 2.5 WRT Installation and Updates
    6. 2.6 Multitasking
    7. 2.7 Debug Functions
    8. 2.8 Compliance Mode
    9. 2.9 Developer Mode
    10. 2.10 View Modes
    11. 2.11 Roaming Data Usage Control
  3. 3 Common APIs
    1. 3.1 Disabled methods
    2. 3.2 Callbacks
    3. 3.3 Algorithms
    4. 3.4 WindowDeviceapis interface
    5. 3.5 The deviceapis attribute
    6. 3.6 WACDeviceapis interface
    7. 3.7 The listAvailableFeatures() method
    8. 3.8 The listActivatedFeatures() method
    9. 3.9 PendingOperation interface (DEPRECATED)
    10. 3.10 The cancel() method
    11. 3.11 Feature interface
    12. 3.12 The uri attribute
    13. 3.13 The required attribute
    14. 3.14 The params attribute
    15. 3.15 Param interface
    16. 3.16 The name attribute
    17. 3.17 The value attribute
    18. 3.18 WatchOptions dictionary
    19. 3.19 The minNotificationInterval member
    20. 3.20 The maxNotificationInterval member
    21. 3.21 The minChangePercent member
    22. 3.22 DeviceApisPim and Pim Interface
  4. 4 Security and Privacy
    1. 4.1 Authentication
    2. 4.2 App store Authentication
    3. 4.3 Digital Signatures
  5. 5 Processing Widget Signature
    1. 5.1 Signature Revocation
  6. 6 Widget Protection
  7. 7 Security Framework
    1. 7.1 Trust Domains
    2. 7.2 Policy Rules
    3. 7.3 Policy Structure
    4. 7.4 Sensitive Capabilities
    5. 7.5 Security Parameters
    6. 7.6 Policy Deployment
    7. 7.7 Policy Enforcement
    8. 7.8 User Prompting and Preferences
  8. 8 Security Features of Web Technologies
  9. 9 Non-WAC APIs
  10. 10 Privacy
    1. 10.1 Privacy Considerations for Device Property Access
    2. 10.2 Parental Mode
  11. 11 Default Policy
    1. 11.1 Trust Domains
    2. 11.2 Permissions
  12. 12 Widget Lifecycle
    1. 12.1 Discovery
    2. 12.2 Selection
    3. 12.3 Download
    4. 12.4 Installation
    5. 12.5 Widgets Installed from an AppStore Client
    6. 12.6 Side-Loaded Widgets
    7. 12.7 Uninstallation
  13. 13 Widget Sharing
    1. 13.1 Generation of web app sharing messages
    2. 13.2 Browser based App Stores and Web App Sharing
  14. 14 SIM Swapping
  15. 15 References
  16. Change Log

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:

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:

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 :

1.1 Conventions

This section is normative.

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

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:

2.3 URI Schemes

A widget runtime supports the following URI Schemes:

2.4 WRT Identification

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

User-Agent header example:

User-Agent: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; MegaOEM-MegaPhone/1.0) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 WidgetsRus-MyWRT/1.0

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 ;

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:

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:

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;

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:

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:

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:

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:

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

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

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:

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

author information includes:

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>

This table needs to be made accessible.
This figure describes the use of author and distributor signatures for the purposes of determining trust (association of the widget to a trust domain) and recognition (association of the widget to a specific author):

5.1 Signature Revocation

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

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:

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:

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:

7.2 Policy Rules

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

Rule Effect Meaning
prompt-blanket Interactive confirmation is required before access to the resource is permitted. The WRT MUST offer the option that the user's decision is remembered indefinitely.
prompt-session Interactive confirmation is required before access to the resource is permitted. The WRT MUST offer the option that the user's decision is remembered for the duration of the application's session. The user's decision MUST NOT allow access to the resource without further interactive confirmation after the end of the application's session.
prompt-oneshot Interactive confirmation is required before access to the resource is permitted. The user's decision MUST NOT allow access to the resource on any subsequent attempt without further interactive confirmation.
permit Use of the device capability is always permitted, without asking the user.
deny Use of the device capability is always denied.

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] :

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 :

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 :

Network Access Device Capabilities
Network access mechanism Device capability Description
XMLHttpRequest XMLHttpRequest Access via the XMLHttpRequest API [XHR].
HTML elements externalNetworkAccess Access via resource references in elements.

7.5 Security Parameters

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

Environment Attributes
Device Capability Condition Attribute Values Description
XMLHttpRequest, externalNetworkAccess environment-match roaming true | false Permission to use network services is conditioned upon the status of roaming.
messaging.send environment-match roaming true | false Permission to use the messaging service is conditioned upon the status of roaming.
Request Parameters
Device Capability Condition Values Description
devicestatus.deviceinfo
devicestatus.networkinfo
param:component
param:aspect
param:property
components, aspects, and properties as defined in [DeviceStatus API] Permission is conditioned upon the specific device property being accessed, as a combination of the parameters component, aspect and property.
filesystem.read
filesystem.write
param:location filesystem location as defined in [Filesystem API]. Permission is conditioned upon the filesystem location being accessed. Widgets always have access to the wgt-private , wgt-package and wgt-private-tmp virtual root locations.
geolocation.position param:enableHighAccuracy true (option requested) Permission is conditioned upon whether high position accuracy is requested.
messaging.send param:recipient pattern Permission is conditioned upon the target address pattern, e.g. for premium-rate numbers.
param:messageType SMS, MMS, email Permission is conditioned upon the type of message service being accessed.
XMLHttpRequest, externalNetworkAccess param:uri xsd:anyURI Permission to use network services is conditioned upon the status of roaming.

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] :

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):

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":

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 :

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:

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:

11.1 Trust Domains

Three trust domains are defined for the default policy.

Trust Domains
Trust Domain Signature
Untrusted Unsigned or signed with unknown certificate (signature can't be validated by a root certificate)
WAC Widget is signed by WAC (signature can be validated by the WAC root certificate)
WAC operator Widget signed with the operator (signature can be validated by the operator root certificate)

11.2 Permissions

Default Policy Legend
Permission Description
See table in section 3.4.1.2 Policy Rules for details
Default Policy
Device Capability Untrusted WAC WAC operator Rationale ("textual interpretation")
accelerometer prompt-blanket permit permit Abuse case: Privacy threat, as a widget can know if a device is moving, and expose that information though other APIs.
pim.calendar.read prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
pim.calendar.write prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
camera.show permit permit permit camera.show only adds the ability to attach the viewfinder to a window object, thus is not sensitive.
camera.capture prompt-oneshot prompt-blanket permit Abuse case: audio and camera surveillance
pim.contact.read prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
pim.contact.write prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
deviceinteraction permit permit permit No significant abuse cases: at most an annoyance could be created by a widget that beeps the phone etc continuously or at inopportune times.
devicestatus.deviceinfo prompt-session prompt-blanket permit No significant abuse cases: the information exposed in this device capability is not sensitive from a security point of view.
devicestatus.networkinfo prompt-session prompt-blanket permit No significant abuse cases: the information exposed in this device capability is not sensitive from a security point of view.
filesystem.read Permit conditionally with Deny fall back Permit conditionally with prompt-blanket fall back permit Uncontrolled access to the device filesystem can lead to a variety of abuse cases.
Widgets are always permitted to access their private storage areas in the filesystem. "Permit conditionally" means that if the widget is accessing its private storage, access is permitted. Otherwise the fall back action applies, e.g. access to other areas is denied for untrusted widgets.
filesystem.write Permit conditionally with Deny fall back Permit conditionally with prompt-blanket fall back permit Uncontrolled access to the device filesystem can lead to a variety of abuse cases.
Widgets are always permitted to access their private storage areas in the filesystem. "Permit conditionally" means that if the widget is accessing its private storage, access is permitted. Otherwise the fall back action applies, e.g. access to other areas is denied for untrusted widgets.
messaging.write prompt-oneshot prompt-blanket permit Abuse case: excessive messaging, malware spreading, premium rate fraud
messaging.send prompt-oneshot prompt-blanket permit Abuse case: excessive messaging, malware spreading, premium rate fraud
messaging.find prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
messaging.subscribe prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
geolocation prompt-oneshot prompt-blanket permit User experience (avoiding multiple prompts for the watch position operation) is a more significant concern than allowing access to location data by untrusted widgets, for which WAC is applying other generally restrictive requirements (e.g. untrusted widget use is disabled by default).
orientation prompt-blanket permit permit Abuse case: Privacy threat, as a widget can know if a device is moving, and expose that information though other APIs.
pim.task.read prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
pim.task.write prompt-oneshot prompt-blanket permit Applications in untrusted domain should not be offered with the opportunity to access these features without appropriate prompts. If developers want to enhance the user experience they can sign the widgets through WAC.
XMLHttpRequest prompt-session prompt-blanket permit Abuse case: Excessive network usage, or WARP-declared domains acting as a bridge to malware. prompt-session is necessary since WAC has no control over the WARP declarations of untrusted widgets.
externalNetworkAccess prompt-session prompt-blanket permit Abuse case: Excessive network usage, or WARP-declared domains acting as a bridge to malware. prompt-session is necessary since WAC has no control over the WARP declarations of untrusted widgets.
Default Policy Parameter Rules
Device Capability Security Parameter Value Untrusted WAC WAC operator Rationale (textual interpretation)
network access
messaging.send
environment-match roaming deny prompt-session prompt-blanket Applied to device capabilities that result in network usage ( Network Access and the Messaging API ) as network usage is sensitive to extra roaming costs.
devicestatus.info param:property IMEI deny prompt-blanket permit Applied to the Device Status API , as the IMEI number can be used for tracking, or stolen for purposes of spoofing on another device.
filesystem.read
filesystem.write
param:location wgt-private, wgt-private-tmp, or wgt-package permit permit permit Applied to device capabilities which use filesystem-based resources ( Filesystem API and Messaging API ), as widgets should always have access to their private data stored on the device filesystem.

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:

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:

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:

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:

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 :

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] :

Examples of rec-version-tag:

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

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:

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:

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:

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":

WAC Widget Sharing Document Elements
Element Attribute Description
widget Parent element of widget detail including child elements:
widget id Widget ID: The id of the widget being shared
widget version Widget version: The version number of the widget being shared (Optional)
download Child element of the widget element. Indicates the location where the widget can be downloaded from. (Optional)
download src Widget Source: URL pointing towards the widget download.

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.