This section describes how authentication works in webinos. There are three types of authentication available in webinos, device authentication, user authentication and authentication with third party services (e.g. oAuth for Twitter). Support for the first two are specified in this section. Third part authentication in the case of OAuth 1.0 is described in the informative section of this specification.

User authentication

OpenID user credentials

Users are primarily authenticated through their OpenID credentials. This involves them connecting to their PZH web interface and logging in with whatever account they used to register the PZH in the first place. This process is described in more details in the PZH section.

Authenticating with OpenID is a pre-requisite for many sensitive operations, but is not sufficient in its own right for accessing webinos APIs or other device features. It only allows a user to connect through the PZH web interface. Applications do not have access to any enhanced privileges through this.

Alternatively, on some devices users may log into the PZH web interface using just client-side X509 certificates. This is possible only when that device has been configured within the personal zone (based on a configuration file at the personal zone hub) to support this.

OpenID login MUST be requested using the PAPE extension and set max_auth_age=0 in order to prevent authentication caching.

Sequence diagram OpenID Authentication

Device authentication

Devices are authenticated through the possession and use of an RSA private key. Having this key is a pre-requisite for a PZP connecting to a personal zone and sharing data with other devices, since it can be used to sign and to prove device identity. More details as to the keys and certificate present on webinos devices can be found in the Personal Zone Key Infrastructure section

Sequence diagram - device held private key authentication

This credential can be used peer-to-peer as well as when connected to the personal zone hub. When used peer-to-peer, there is a risk of the key having been revoked but the other device not being aware of this because it has not been connected online and synchronised. When used via the personal zone hub, this is not an issue, as the PZH will know if the credential has been revoked. More details on the use, management and distribution of keys and certificates within a personal zone can be found in Personal Zone Key infrastructure section

The device-held private key is not strictly a user authenticator, but a device authenticator. However, for many situations it can be considered another factor. E.g., for a device with generally a single owner (a mobile phone) then it is a reasonable authenticator for many things. The key can also be considered a useful authenticator when the device is not being currently operated by the end user. E.g. a home PC being accessed remotely.

In order to make sure that a private key is used appropriately -- e.g. it cannot be used by a frequently shared device as user identity -- it must be integrated with the policy system and with the local device's authentication. For instance, the private key will be held in a key storage (key storage interface , key storage implementation ), which requires the user to prove their presence by unlocking it. Furthermore, it can interact with the authentication API, such that an application can work out whether the user is still present or not.

Presence - authenticating to the local device

Devices have different modes of interaction with users. Sometimes presence is assumed (smartphones) and sometimes it is not (shared TVs, home servers).

Authentication state machine

The following state diagram shows the permitted states a user (or rather, their user agent) can be in. This does not include 'presence' via local authentication.

The PZP will not be aware of which state they are necessarily in. For example, the PZP will know whether it is in "DeviceKey" or "Unauthenticated" state, but will not know whether the user has logged in with OpenID to the hub.

Actions requiring authentication

The following actions must require user authorisation, which will require authentication of the current user.

Local authentication refers to an invocation of the authentication API. Remote authentication refers either to OpenID login to the PZH or use of a PZP private key in situations where that is sufficient to

This table considers the potential threat of an unknown user performing this action on a shared device (e.g., a "friend" on a shared TV).

Action   Unauthenticated (virgin mode) State   Device Key State   OpenID State   OpenID and Device Key State  
Installing an application Local authentication if specified in policy Local authentication if specified in policy Authorisation prompt Authorisation prompt
Removing an application Local authentication if specified in policy Local authentication if specified in policy Authorisation prompt Authorisation prompt
Local API Access Local authentication if specified in policy Local authentication if specified in policy Authorisation prompt Authorisation prompt
Remote API Access Remote authentication if specified in policy Remote authentication if specified in policy Authorisation prompt Authorisation prompt
Updating local policies Local authentication Local authentication Authorisation prompt Authorisation prompt
Updating zone-wide policies Remote authentication Remote authentication Authorisation prompt Authorisation prompt
Viewing the PZH web interface Remote authentication Remote authentication None None
Adding a device to the zone Remote authentication Remote authentication Authorisation prompt Authorisation prompt
Revoking a device Remote authentication Remote authentication Authorisation prompt Authorisation prompt
First-time connection to another user (peer-to-peer) Local authentication Local authentication Authorisation prompt Authorisation prompt
First-time connection to another user (online) Remote authentication Remote authentication Authorisation prompt Authorisation prompt
Subsequent connection to another user None None None None
Synchronising data None None None None

Initiating OpenID authentication from the PZP

Because the PZP does not know whether the user is logged into the PZH with OpenID or not, the PZH will provide an interface for authorising requests initiated by the PZP. The following sequence diagram describes the process:

Note that the PZH is used as a web server in this diagram. This sequence diagram can be described in text in the following way:

  1. The user attempts to perform the privileged action on the PZP
  2. The PZP forwards this request to the PZH
  3. The PZH replies: "authentication required" + URL
  4. The PZP opens a web browser and directs the user to the provided URL
  5. The user must log in to this URL
  6. The page presents an authorisation prompt explaining the action requested and the impact of the action on the personal zone
  7. The user approves or rejects the prompt
  8. The action is carried out or not, depending on the decision made.

An example for authorising a zone-wide policy change is given below:

  1. The user changes XACML policies, this updates the local copy of policy.xml
  2. The PZP attempts to synchronise the new policy by pushing changes to the PZH
  3. The PZH sends a message to the PZP requiring authentication at[session id]
  4. webinos opens a new browser window pointed at this page
  5. The user must log in to access this page using their openid credentials
  6. The page then presents a prompt showing the user what their policies changes mean
  7. The user approves or rejects the changes
    1. On success, the new policy is synchronized and updated on the hub.
    2. On failure, the new policy is overwritten.

The following messages are exchanged between PZP and PZH. We do not show the messages relating to the initial action request as this is activity-specific.

Request for authentication

  "type": "prop",
  "to":   "pzp_id", 
  "from": "pzh_id",
  "payload": {
    "reply-to:"" // action message
    "url": "" // URL to PZH web interface, containing session identifiers

Successful authentication

  "type": "prop",
  "to":   "pzp_id", 
  "from": "pzh_id",
  "payload": {
    "reply-to:"" // action message

Unsuccessful authentication

  "type": "prop",
  "to":   "pzp_id", 
  "from": "pzh_id",
  "payload": {
    "reply-to:"" // action message

Entity authentication tables

This section outlines how the different entities (defined in Entity Definitions) are authenticated.


Entity   Authenticates a user by  
User Out of band channel or via PZHs (see certificate exchange documentation)
Application Not specified
Devices Authentication API or own user account
Personal Zone Hub Requesting an OpenID login on the PZH web interface
Personal Zone Proxy Authentication API, possession of the PZP device key, or through OpenID login at the PZH
Personal Zone Hub provider Through OpenID and the creation of a persistent account with the provider.


Entity   Authenticates an application by  
User By lieu of the browser / widget renderer displaying the name and a padlock or indicator of authenticity
Application For communication through webinos - trust in the PZP. Through communication via XHR / online, through the widget runtime
Device N/A
Personal Zone Hub N/A - communication from Applications is assumed to be trustworthy because it has been proxied by the PZP.
Personal Zone Proxy The PZP contains a widget processor which checks the signatures attached to an application, as defined in WAC and widget signature standards. Subsequent communication relies on the browser or widget renderer to reauthenticate and reidentify the application
Personal Zone Hub provider N/A
Widget Renderer Identifying the .wgt package and checking the integrity against signature files
Browser Checking the HTTPS certificate is trusted and corresponds to the domain


Entity   Authenticates a device by  
User Visually for the current device, or by relying on the PZH to authenticate remote devices via their PZP. On enrolment through physical posession.
Application Applications don't authenticate devices.
Device As PZPs
Personal Zone Hub As PZPs
Personal Zone Proxy See "Devices".
Personal Zone Hub provider
Widget Renderer Widget renderers don't authenticate devices
Browser Browsers don't authenticate devices

Widget renderers

Entity   Authenticates a widget renderer by  
User N/A. Out of scope for webinos. The OS might provide a mechanism.
Application N/A. Applications remain renderer-agnostic.
Device N/A.
Personal Zone Hub PZHs SHOULD authenticate the renderer (and indirectly the user) through requesting a client key through the web browser.
Personal Zone Proxy Proxies MAY authenticate the renderer by issuing them with a private, client key for web socket connections.
Personal Zone Hub provider
Widget Renderer N/A.
Browser N/A.


Entity   Authenticates a Personal Zone Hub by  
User Through authenticating the web interface for administering the personal zone hub, which may be hosted by the PZH provider. This authentication relies on the user noticing a URL 'padlock' indicator (or similar) and the underlying DNS and web PKI system
Application N/A
Device Through PZPs
Personal Zone Hub N/A
Personal Zone Proxy Through initial enrolment within the personal zone, a personal zone proxy will receive and store the certificates corresponding to keys held by the personal zone hub. These are used to authenticate the connection to the hub.
Personal Zone Hub provider Providers host hubs and therefore do not need to authenticate them. Each hub must belong to a registered user.
Widget Renderer N/A
Browser When rendering a PZH administration console, through the standard DNS and web PKI system


Entity   Authenticates a personal zone proxy by  
User Users do not authenticate their own proxies (they trust the device). Another user's proxy may be authenticated through authenticating the person (see the SHCBK protocol)
Application Applications do not authenticate PZPs
Device Out of scope. A device may provide an underlying native application framework to identify that a PZP is from a valid distributor.
Personal Zone Hub Through the TLS connection, the PZH will check that the PZP has the correct certificates issued by the PZH during enrolment. At time of enrolment, the PZP is authenticated through the use of a short code issued to the authenticated user via the PZH and web browser
Personal Zone Proxy PZPs may authenticate one another through the PKI infrastructure. If no prior trust relationship has been established, PZPs may use the SHCBK protocol to authenticate their users.
Personal Zone Hub provider Through the PZH.
Widget Renderer The widget renderer may authenticate the PZP through the secure websocket connection it establishes. This websocket connection shall be hosted by the PZP using a certificate installed into the widget renderer. If a non-websocket communication mechanism is used, the widget renderer may rely on the operating system to authenticate the PZP.
Browser See "widget renderer"