This area defines in detail how applications are authenticated, signed and certified. It also defines how the runtime constraints placed on applications and how they communicate securely with the PZP and external services.
Because webinos allows for applications running within different renderers and with different levels of certification, we define the following types of application.
|Type||Runs in||Local / hosted||Widget Manifest?||Delivered over||Installed?||Authentication|
|B-A||Browser||Hosted (+ app cache)||Yes||HTTPS||Yes||TLS certificate, root trusted by browser|
|W-R||Widget renderer||Combination||Yes||File + HTTPS||Yes||Signed widget authenticated by widget processor. 'Recognised' as per (WAC). HTTPS traffic only from recognised origin.|
|W-U||Widget renderer||Combination||Yes||File + HTTPS||Yes||Signed widget, but unrecognised identity (WAC). HTTPS traffic only from recognised origin. HTTPS traffic authenticated by widget runtime OR connected to same entity as the widget signature.|
There is no distinction between hosted applications and local applications. This is because webinos supports widgets that are mixture of both.
All applications must have a configuration file corresponding to the webinos specifications, even hosted applications viewed in a web browser.
Applications may be installed by users, by device manufacturers shipping webinos, or as part of the webinos installation as bundled by webinos developers. "Installation" refers to the registration of a web application with the client-side webinos framework. In this section we describe only installation by users after the platform has been installed. This specification does not describe where applications may come from.
The installation of an application is the time when a trust decision must be made. If the application is not trusted at all, it should not be installed. If there is doubt about the provenance of the application - whether it is from the right source and has the right name - it should also not be installed. The following steps are taken from WAC (WAC) and modified for the webinos install process:
An example UI is shown below. This is not implemented but explains the expectation for how an install screen might look.
The above image is not normative: it describes a potential UI but conforming implementations of this specification may have different UIs.
The install screen UI shall by default only display features being requested by applications.
The default setting for permission requests shall be set based on a configuration file on the local platform -
This configuration file will have the same format as the access
control policies, but is only processed to set defaults for the
installation screen. If there is a conflict between the
@<feature>@s requested by an application and the default
permissions, defined as where default permissions state 'denied' but the
feature is requested, this shall be flagged visually by the
installation GUI. The installer may set the default (in this
instance) to an ask-at-runtime prompt. The aim is that, should user
'click through' without changing anything on this form, the application
will receive the default permissions defined by the platform rather than
those requested by the application.
The result of the install screen UI will be additional XACML policies stored in the policy.xml file.
All applications must have signed manifests, but they may be signed by keys with self-signed certificates. User policies will dictate whether this is supported by the runtime. The PZP must store the association between the application and its certificate, and a different self-signed certificate cannot be used for subsequent versions of the application.
Browser-based applications can access webinos IF they are served from an origin with scheme HTTPS and IF the user 'installs' them. The installation process will be triggered by the web application attempting to use webinos APIs for the first time. When this happens, the application will create a WebSocket request to the PZP and pass with it the origin of the application. This is in accordance with the WebSocket specifications. The origin is the identity of the application and must be stored by the webinos runtime and used in webinos policies.
If the user does not install the web application, subsequent attempts to use webinos will be ignored. The decision to not install a web application therefore effectively blacklists it. This decision must be revocable through a PZP-provided UI.
When the PZP receives the origin of the application it MAY attempt to check the validity of the certificate of that domain to check that the certificate is trusted by a set of root authorities installed in the PZP, which are likely to mirror those in the browser.
Upon installation, the webinos platform shall create a new set of policies based on the recommendations outlined in the Security Framework for the application type. A prompt shall appear showing this information to the end user, as defined in the policy specification (Policy). This prompt will allow such a policy to be edited in some respects.
Installing and application - based on a browser or widget runtime - implies that the entire personal zone may be aware that the application has been installed. As per the policy specifications, installation of an application will result in the synchronisation of application manifests and policies to all personal zone devices.
Widgets can be updated by following proposals described in the W3C Widget Update Working Draft (WidgetUpdates). Remotely hosted content loaded by a widget and browser-based applications require no special mechanism to be updated.
The webinos application security framework relies upon valid certificates being used and the webinos runtime containing a set of trusted certificates, much like a web browser. Webinos must periodically (as well as when the certificate is first installed) check each certificate is valid, and use OCSP to check that it has not been revoked. This task should be performed to the PZH, which can make the necessary updates and synchronise them between all user devices.
Webinos applications will communicate with the PZP in different ways depending on the application type and the platform.
|Android||Web socket||Android IPC|
|Windows||Web socket||Web socket|
All platforms will inject the webinos.js script in some way to allow applications to access webinos APIs.
The PZP will create a secure WebSocket server on localhost which should only accept connections from local entities.
The secure websocket server SHALL use the certificates defined in the Personal Zone Key Infrastructure documentation.
WebSockets SHALL request client certificates and SHALL reject unauthenticated connections. Each widget renderer SHALL therefore contain a valid certificate issued by the PZP. Installation of this certificate is a platform and renderer specific process.
A widget renderer may communicate with the PZP through either the Web Socket mechanism given above, or through a native IPC mechanism. The IPC mechanism SHALL protect the integrity and confidentiality of communications and SHALL provide a means to authenticate the PZP and renderer.
Outside of webinos, application can communicate with external entities in a number of ways, including:
To avoid the security and privacy implications of some of these mechanisms, the following policies are used in widget renderers.
As described in the Widget Runtime section, widgets shall use the WARP specification to define the origins that a widget may access.
The webinos platform will follow most of the recommendations defined by Google Chrome Extensions (ChromeCSP) but dictate how this must be implemented.
External pages (from origins not mentioned in the application's WARP configuration) may not be embedded in an iframe within the application. Images, video and audio may be referenced from any origin as normal.
A valid widget render will not enable extensions while webinos applications are running.
Google Chrome Extensions - Content Security Policy
Unknown author, Google
Fetched: August 2012
Section 4: Security and Privacy
30 April 2012
XML Digital Signatures for Widgets
W3C Proposed Recommendation 11 August 2011
W3C Working Draft 22 March 2012