%ents; ]>
Shared BOSH This specification defines an extension to BOSH that allows multiple clients to share the same underlying XMPP connection. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council XMPP Core XEP-0124 XEP-0206 NOT_YET_ASSIGNED Jack Moffitt jack@metajack.im metajack@gmail.com 0.0.1 2009-05-13 Jack

First draft.

XMPP-powered applications which run inside of Web browsers typically use &xep0124; to create a link to an XMPP server. Unfortunately Web applications do not have control over some interactions, such as a user opening a link in a new tab. This means that an application can end up with multiple simultaneous BOSH connections, each of which is a fully addressable XMPP endpoint. Complex applications often need to share some state, and managing this over an arbitrary number of individual connections can be problematic.

This specification defines a mechanism for a connection manager to allow multiple clients to share the same underlying XMPP connection. Additionally, the connection manager will notify all clients of inbound stanzas. Similar functionality exists in specific areas of the XMPP protocol; for example, roster changes are broadcast to all connected resources so each resource can keep roster state synchronized.

As an example, consider an application which is open in two tabs (or two windows) in a Web browser. In the first tab, the application subscribes to some pubsub node it is interested in. The BOSH connection manager would send this subscription request to the other connected clients (in this case, just the second tab) so that they are aware that a subscription has been requested. When the subscription acknowledgement is received by the connection manager, it will broadcast it to all clients.

Shared BOSH must meet the following requirements:

In addition to these, the intention is for this extension to be easy to implement in current BOSH implementations.

In order to establish a sharable connection which is then shared across two clients, the following steps take place. The mechanism for sharing the secret below is just one possible mechanism.

  1. Client A initiates a BOSH session and indicates that this session is sharable via the 'shared:key' attribute.
  2. Client A authenticates with the XMPP server and publishes the secret key to a private PEP node.
  3. Client B initiates a BOSH sesion and indicates that this session is sharable via the 'shared:key' attribute.
  4. Client B authenticates with the XMPP server and discovers Client A's existing secret key in the PEP node.
  5. Client B terminates the BOSH connection and initiates a new one, using the discovered secret key as the value of the 'shared:key' attribute in the initial <body/> tag.
  6. The connection manager verifies the key and allows Client B to share Client A's XMPP connection.

A client can create a sharable BOSH connection by providing the 'shared:key' attribue to the connection manager in the initial <body/> element.

]]>

If the connection manager supports sharable connections, it will include the 'shared:result' attribute in its response. Since this is a new sharable connection and not an attachment to an existing sharable connection, the value of the 'shared:result' attribute is 'created'.

]]>

If the connection manager does not support this extension, it will ignore the 'shared:key' attribute and will not include one in its response.

Attaching to a connection is performed in the same manner as creating a sharable connection. The client provides the secret key of an existing connection as the value of the 'shared:key' attribute. If the key matches, the connection manager will respond with a 'shared:result' attribute with a value of 'attached'.

]]>

In order to easily maintain state across shared BOSH clients, the connection manager must deliver inbound traffic to the server from one client to all the other clients sharing the connection. Applications which use shared connections must be written so that they can deal with this extra traffic; they cannot assume that all stanzas received are outbound.

In order to protect against unauthorized or unintended connection sharing, this specification uses a shared secret. It is important that this secret be hard to guess and long enough that it is resistant to brute force attack.

It is necessary for a client to communicate the shared secret to the other clients. Since Web browser security policy prevents most ways of achieving this, it is necessary to store the secret somewhere the other clients can find this. Implementors must be care that this storage is robust to attack.

Two options are recommended for secret storage:

  1. Generate the secret on the server side (for example, in the Web application framework that generates your HTML pages). Please note that the secret should not be transmitted alongside the HTML as this would allow anyone reading the HTML to share the connection. Instead, the BOSH connection should be bootstrapped before page delivery.

  2. Generate the secret on the client side, and store it within the XMPP server using some available mechanism. For example, a client could use &xep0049; or a private &xep0163; node.

This document requires no interaction with &IANA;.

This XEP proposes the namespace 'urn:xmpp:tmp:shared-bosh:0' be added to the registry.

To follow.