identity 1.0 documentation

Backplane

«  Simple Web Discovery (SWD)   ::   Contents   ::   LRDD: Link-based Resource Descriptor Discovery  »

Backplane

http://developers.janrain.com/documentation/backplane-protocol/

Backplane

Protocol

Overview

The Backplane Protocol is an open source protocol, developed to simplify communications between multiple web widgets and applications on the same web page.

Instead of each widget or application using their own scheme to access user data, Backplane-enabled widgets listen to a single, common Backplane Server for updates.

The Backplane Protocol can publish different types of messages, alerting widgets when users have authenticated, or activities the user is sharing with social network.

Publishing Authentication Data on Backplane

  1. User is authenticated with a Backplane-enabled sign-in widget, such as Janrain Engage.
  2. The widget publishes a message on a Backplane Server channel.
  3. Widgets on the web page listening to the Backplane are updated.

Audiences

Two audiences:

  • Website Owners — Add Backplane functionality to a website.
  • Product Developers — Add Backplane support to a product, such as a widget.

Version

The Backplane Protocol is an open source, cross-company initiative aimed at advancing web app technology. There are currently two versions:

  • Backplane Protocol 1.2 – The first public implementation of Backplane Protocol. Supports publishing Identity messages.
  • Backplane Protocol 2.0 – Uses OAuth2 for the authorization process. Supports an Identity Scenario , and will support an Activity Streams Scenario when implemented. Messages also have been re-engineered to send only header information to browser or anonymous clients, the payload is sent to authenticated clients as specified in the protocol.

Protocol Flow

Backplane Protocol

Figure 1 shows an example of the Backplane Protocol identity message flow using Janrain as the authenticating service.

images/bpp-tech-diagram-1.png

Figure 1

[A] Message Posting with the Backplane Protocol

A1) User signs in to website.

A2) Identity connector publishes Identity/Login events to the Backplane Server.

[B] Message Notification

B1) A Backplane-compliant application polls the Backplane Server for messages .

B2) The Backplane Server delivers the message to the clients running in the browser, absent the payload.

B3) The Backplane JavaScript distributes the message to apps that are registered for the message.

[C] Message Retrieval

C1) Widgets make JSONP calls to their servers.

C2) Widget Server calls Backplane Server for full message and payload.

C3) Widget Server securely receives payload.

C4) Widget Server returns subset of payload to application on website.

Messages

Senarios

The Backplane Server can retrieve different types of messages and send them on to the widgets.

In Backplane Protocol terms, a Scenario is an a protocol extension that defines one or more message types and specifies their semantics, use, and so on. Currently, the Scenarios in development on the Backplane Protocol are:

Identity Scenario

Updates all widgets with user data once a login widget publishes to a Backplane channel.

Activity Streams Scenario

Coming soon: When a user shares activities on a social network, widgets will be informed as well.

Messages in Backplane Protocol v1.2 versus messages in Backplane Protocol 2.0

One of the improvements in the newer version is that Backplane 1.2 always delivers the entire data payload, while Backplane 2.0 delivers only the header information to browser or anonymous clients, and sends the full the data payload to authenticated clients according to the protocol. While on the surface this may appear to be a step backwards in the evolution of the Backplane protocol, it was done for two important reasons.

The first is the security principle of “ least privilege,” which states that applications should only have access to data that directly concerns them, rather than a firehose of sensitive data that may or not be directly consumed by the subscriber of the content.

Secondly, it was desirable to conserve bandwidth. As payloads become more data rich, they may contain several hundred kilobytes of data each. Pumping the entire payload to the JavaScript client library would be wasteful.

Because the client implementing the Backplane 2.0 JavaScript library receives only the message header, each application subscribing to the message needs to use an API to contact their server-based applications, which then send the relevant information.

Backplane 2.0 allows server-side applications ( as authenticated clients) to consume the entire message content, including the payload portion.

Add to Your Website

Note

The Backplane Protocol, and Janrain’s implementation of the Backplane Server, are new. We anticipate that given user feedback we will modify the documentation, so check back frequently for updates.

This section explains how to integrate the Backplane Protocol into your website. When you are finished, your site will publish messages to a channel on a Backplane Server using the Janrain Capture or Engage widget.

There is no need for any further configuration if your website is already using Backplane-compliant widgets and web apps. See our list of supported technologies for more information.

Note

You must have access to a working Backplane Server. You can build your own with the open source version , or Janrain can provide access to one.

Technologies used:

  • HTML markup and DOM
  • Javascript XMLHTTP and asynchronous events
  • JSON/JSONP

The main steps to integrating Backplane Protocol on a website are:

  1. Obtain bus name and credentials from Capture Dashboard .
  2. Add backplane.js .
  3. Initialize the Backplane object .
  4. Configure Backplane channel for Engage or Capture .

We recommend that you implement the latest 2.0 version of the Backplane Protocol. Directions for version 1.2 are provided for organizations that have already installed version 1.2.

None

Obtain Bus Name and Credentials from Capture Dashboard

In the Capture Dashboard, this value is listed as backplane_bus. Copy this value to a text file, or write it down. You will need this later. For Engage credentials, please contact your Janrain support representative.

The Bus Owner credential is used by the website operator or Bus Owner to authenticate with the Backplane Server before authorizing OAuth clients (widgets) to post to their bus.

The OAuth token is used by widgets to post messages on a bus. (Widgets that do not use OAuth2 can still use the Backplane 1.2 authorization procedure.)

Add backplane.js

Place this code in the <head> section of the webpage hosting the widgets. This script adds the library to your web page that the Backplane Server uses. Any Backplane-enabled widgets on this web page, regardless of who made them, will have access to the Backplane bus.

<script type="text/javascript"
src="http://d134l0cdryxgwa.cloudfront.net/backplane.js" ></script>

Initialize the Backplane Object

Add the code below to the <body> section of the web page, replacing the busName value with the one obtained at Step 1.

<script type="text/javascript">
function setup_bp() {
//
//  Initialize Backplane:
// This creates a channel and adds a cookie for the channel.
// It also sets the function to call when this is complete.
//
    Backplane(bp_ready);
    Backplane.init({
        serverBaseURL: "http://backplane1.janrainbackplane.com/v2.0",
        busName: "janraindemo.com"
    });
}

function bp_ready() {
//
// This function is called when Backplane.init is complete.
//
    if (Backplane.getChannelID() != undefined) {
        demo_bp();
        return false;
    }
}

setup_bp();
</script>

This script requests a channel on the server and initializes the Backplane object and associated cookies. The process is asynchronous and does not affect web page load times.

Configure Backplane Channel for Engage or Capture

In order for the Capture or Engage widget to publish messages, it retrieves a Backplane channel from the Backplane Server.

Because Backplane 2.0 is OAuth2 compliant, access to the Backplane Server should be through an OAuth2 access token. (You can still use the “manual” access of Backplane 1.2 if your widget is not OAuth2 compliant.)

This access token is issued by the Backplane Server and is essentially a “valet key” that allows the user to access resources “owned” by a particular bus owner (in this case, your Janrain application).

To initialize the Engage widget, add the following code to the <body> of the web page:

function doBackplaneStuff() {
    janrain.engage.signin.setBackplaneChannel(Backplane.getChannelID());
    bpListen();
}

To initialize the Capture widget, add the following code to the <body> of the web page:

function doBackplaneStuff() {
 document.getElementById('capture-signin').href +
 '&bp_channel='+encodeURIComponent(Backplane.getChannelID());
 bpListen();
}

When a visitor authenticates with a Backplane-enabled service like Capture or Engage, that service will publish an event to the specified Backplane channel.

Add to Your Application

Note

The Backplane Protocol , and Janrain’s implementation of the Backplane Server , are new. We anticipate that given user feedback we will modify the documentation, so check back frequently for updates.

These directions are for application developers adding Backplane functionality to a standalone application or a web application (as opposed to a website).

Once implemented, your widget or web app will be configured to listen to a Backplane Server , and will be able to be deployed in any Backplane-enabled site.

Integration Steps

  1. Obtain authentication credentials for your specific bus.
  2. Set up the application to listen for Backplane messages.
  3. Implement a logout.

We recommend that you implement the latest 2.0 version of the Backplane Protocol. Directions for version 1.2 are provided for legacy purposes.

Flow

The following steps describe the Backplane Protocol 2.0 Flow (see Figure 1), and how to integrate your application or web app with each step:

None

Before Proceeding

In the Capture Dashboard, you need the values listed as backplane_password and backplane_bus. Copy these values to a text file, or write them down. You will need these later.

For Engage credentials, please contact your Janrain support representative.

1. Register for Callback

One of the notable differences in Backplane Protocol v2.0 from Backplane Protocol v1.2 is that the message payload (that portion of the message containing personally identifiable content) is removed from the message arriving at the non-credentialled client.

The Backplane 2.0 widget listens for a message, and then requests the data to go along with the message from another server. For more information on this change in procedure, refer to Messages.

The following is sample code used to listen to the Backplane channel for ‘identity/login’ messages. Once this message type is received, this code will make a call to its server-side component, using JSONP, to fetch the portion of the payload that is important for their function.

See Step 4 for details.

function fetchPersonalData(messageId) {
var oldScript;
// Cleanup old script if it exists to prevent memory leak
// This will also prevent more than one server side request from pending
// at any point - which may or may not be desirable
while (oldScript = document.getElementById('fetchSingleMessage')) {
oldScript.parentNode.removeChild(oldScript);
for (var prop in oldScript) {
delete oldScript[prop];
}
}
var script = document.createElement("script");
script.type = "text/javascript";
script.id = 'fetchSingleMessage';
script.src = "getsinglemessage.php?"
+ "v=" + new Date().getTime() // to prevent browser caching
+ "&amp;callback=fetchCallback" // the user-defined callback
+ "&amp;messageid=" + encodeURIComponent(messageId);

var firstScript = document.getElementsByTagName("script")[0];
firstScript.parentNode.insertBefore(script, firstScript);
}
function bpListen() {
window.escSubscription = Backplane.subscribe(function(backplaneMessage) {

//
//This enclosed function runs when any message is received.
//Sign in if the message type is correct.
//

if (backplaneMessage.type == 'identity/login') {
fetchPersonalData(backplaneMessage.messageURL);
}

});

// Expecting a message type will increase the polling for that type
//until it is received.
//

Backplane.expectMessages('identity/login');
}
// script block continues

2. Identity/Login Published on Backplane Server Channel

The user signs in to the website, and an Identity/Login message is published onto the Backplane Server channel.

The Engage or Capture widgets must be configured to publish this message.

Engage Widget

To initialize the Engage widget, add the following code to the <body> of the web page:

function doBackplaneStuff() {
 janrain.engage.signin.setBackplaneChannel(Backplane.getChannelID());
 bpListen();
}

Capture Widget

To initialize the Capture widget, add the following code to the <body> of the web page:

function doBackplaneStuff() {
 document.getElementById('capture-signin').href +
 '&bp_channel='+encodeURIComponent(Backplane.getChannelID());
 bpListen();
}

When a visitor authenticates with a Backplane-enabled service like Capture or Engage, that service will publish an event to the specified Backplane channel.

3. Poll for Messages on Website

Place this code in the section of the webpage hosting the widgets. This script adds the Backplane Server library to your webpage. Any Backplane-enabled widgets on this web page, regardless of who made them, will have access to the Backplane bus.

Once included, the library facilitates the client side code for pulling, fetching, and getting tokens.

<script type="text/javascript"
src="http://d134l0cdryxgwa.cloudfront.net/backplane2.js" ></script>

4. Request Payload from Backplane Server

Once the widget or web app on the site receives the message, it will request more information from its Widget Server through a JSONP call. The Widget Server then requests the payload from the Backplane Server.

The following is an example request in PHP:

<?php

// getdisplayname.php

// The config.ini file contains Backplane host information
// along with the access_token required for this server based
// client to interact with the Backplane server.
$settings = parse_ini_file('config.ini');

define('CLIENT_TOKEN', $settings['access_token']);
define('CALLBACK', $_GET['callback']);
define('CHANNEL', $_GET['channel_name']);
define('BP_POST_SSL', false);
define('BP_POST_JSON', true);
define('BP_CURL_ERROR', 'CURL-ERROR');
define('BP_ELABEL_DEBUG', 'debug');
define('BP_ELABEL_ERROR', 'error');

// begin bp_post
function bp_post($url, $parameters, $ssl = BP_POST_SSL, $json = BP_POST_JSON)
{
    $curl = curl_init();
    if ($curl == false) {
        return false;
    }
    if ($json === true) {
        curl_setopt($curl, CURLOPT_HTTPHEADER, array(
            'Content-type: application/json',
            'Authorization: Bearer ' . CLIENT_TOKEN
        ));
    }
    curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
    curl_setopt($curl, CURLOPT_POSTFIELDS, $parameters);
    curl_setopt($curl, CURLOPT_POST, false);
    curl_setopt($curl, CURLOPT_HEADER, false);
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($curl, CURLOPT_FAILONERROR, true);
    curl_setopt($curl, CURLOPT_URL, $url);
    return curl_exec($curl);
}
// end bp_post

$url         = $settings['backplane_server'] . '/' . $settings['backplane_version'] . '/message/' . $_GET['messageid'];
$post_result = bp_post($url, $post);

if ($post_result) {
    $json = json_decode($post_result);
    if ($json->channel != CHANNEL) {
        $arr = array(
            'stat' => 'fail',
            'message' => 'Channel mismatch.  Not authorized.'
        );
    } else {
        $name = $json->payload->identities->entry->displayName;
        $arr  = array(
            'stat' => 'ok',
            'displayName' => $name,
            'messageURL' => $json->messageURL
        );
        if (empty($name)) {
            $arr = array(
                'stat' => 'fail',
                'message' => 'server side component failed to retrieve message payload'
            );
        }
    }
} else {
    $arr = array(
        'stat' => 'fail',
        'message' => 'server side component failed to retrieve message payload'
    );
}

header('Content-Type: text/javascript');
echo CALLBACK . "(" . json_encode($arr) . ")";

?>

5. Process Payload

The Backplane Server delivers the payload to the Widget Server as a JSON file.

The Widget Server must parse and then store data from this file. Not all data needs to be preserved. The storage and format is completely up to the Widget Server. All that matters is that the server can send a JSON payload to a widget.

6. Widget Server Subset of Payload to Widget

Finally, in response to the widget’s or web app’s JSONP call, the Widget Server returns only the data required to update the state of the widget. For example: some Widgets may only want to update the User Name to welcome the user.

Terms

Activity Message
The message published on the Backplane Server channel that alerts widgets that a user has shared and activity.
Activity Scenario

An implementation of Backplane Protocol that publishes Activity Message to update widgets on a website.

When a user shares an activity, such as a video, or image, on a social network, all widgets listening will know as well.

Application Vendors
Product developers who are making their web apps, or widgets Backplane compliant, and able to listen for Backplane Messages.
Backplane JavaScript
(TBD)
Backplane Protocol
The Backplane Protocol is an open source, cross company initiative aimed at advancing web app communication technology.
Backplane Server
The server set up to relay messages to and from widgets. The purpose of the Backplane Server is to create a channel. Widgets publish messages to this channel, and widgets listening to this channel are delivered the message.
Bus Owner
The authenticated user that accesses a channel on a Backplane Server.
Capture
Social Data Storage. http://janrain.com/products/capture/
CORS
Cross-Origin Resource Sharing ( http://www.w3.org/TR/cors/ )
Engage
Janrain Engage enables sites to provide a convenient and secure way to sign up and sign in. `Formerly known as RPX <http://en.wikipedia.org/wiki/Janrain> `_. ( http://developers.janrain.com/documentation/engage/ )
Identity Message
The message published on the Backplane Server channel that alerts widgets that a user has been authenticated.
Identity Connector
(TBD)
Identity Scenario
An implementation of Backplane Protocol that publishes Identity Messages to update widgets on a website. These widgets then can collect current user data.
Janrain
JSONP
JSON with padding ( http://ja.wikipedia.org/wiki/JSONP ) See CORS
OAuth2
A community-based specification providing a much needed solution for security web APIs without requiring users to share their usernames and passwords.
Payload

The data indicated by the message.

In version 1.2, the payload is included with the message.

In version 2.0, the payload is requested by the widget separately, after it receives a message.

Scenario
Protocol extension that defines one or more message types and specifies their semantics, use, and so on.
Site Owner
The individual adding the Backplane Protocol to a website, namely adding code to enable a Backplane Server.
Widget Server
Relying Party (TBD)

Backplane 2.0

Abstract

Backplane is a framework that facilitates message exchanges and event notifications between third-party JavaScript components within a web page.

(draft 08 )

1. Introduction

Web pages have evolved from being loaded from a single resource to being able to reference third-party, external components that get loaded, run and rendered by the web browser within the same web page.

These components can be active and continue to run after the web page completed loading and are generally decoupled — not under the control of a single entity.

Interactions between the end user, the web page, and its features provided through such components can greatly benefit when all parties involved can exchange information with each other, and can do it in a standardized way.

The Backplane framework facilitates such interactions by providing an open standard API that is secure in the context of the assumed trust relationships between the parties involved. Messages are delivered reliably and in order. The framework may be used in different scenarios which build on top of the transport-level semantics described in this document.

(draft 08)

2. Definitions

Web Page
Document obtained from a web resource and loaded by the end user’s web browser.
Widget
Widgets
Third-party JavaScript component referenced from the Web Page that is loaded and run in the end user’s browser.
Backplane Client
Backplane Clients
Entity that uses the Backplane framework to exchange information.
Backplane Message
Backplane Messages
A JSON object representing the unit of communication between Backplane Clients.
Message Identifier
Unique string assigned by Backplane Servers to each incoming Backplane Messages for the purpose of identifying and referencing them via the “since” retrieval mechanism.
Backplane Header
A Backplane Message without the payload field.
Backplane JavaScript API
JavaScript API used by Widgets to initialize and subscribe to Backplane Messages.
Backplane JavaScript Library
Backplane JavaScript API implementation.
Backplane Server API
Server API through which Backplane Clients send and retrieve Backplane Messages.
Backplane Server
Backplane Server API implementation.
Bus
Buses
Logical grouping of Backplane Clients that need to interact with each other, typically belonging to one organization.
Channel
Subset of Backplane Messages that belong to a Bus and are addressed to the Backplane Clients interacting with the end user through a single session and Web Page.
Message Sequence
A set of Backplane Messages that meet a certain filter criteria, in the same order as they have been received by a Backplane Server.
Message Age
The length of time since the Message was received by the Backplane Server.

(draft 08)

3. Overview

An operational Backplane framework consists of the following components:

Note

  • Widgets are Backplane Clients
  • Widget Servers are also Backplane Clients

A Backplane Server is an independent orchestrator of the message interchange between Backplane Clients and may serve multiple independent Buses.

A Backplane framework instance needs to be configured prior to use: all Backplane Clients and the Server have to share the same Bus. Backplane Clients operating at the Privileged Access Level (Privileged Access) need a password to authenticate themselves to the Server. It is outside the scope of this document how such configuration is performed.

(draft 08)

4. Trust

The Backplane framework is intended to be used and operate under the following trust relationships. Any number of security issues can arise if any of these assumptions do not hold.

The end user trusts the Web Page owner (and indirectly all Widget owners) that the Web Page will not attack or exploit their web browser.

The Web Page owner (and indirectly the end user) trusts all Widget owners that the Widgets will not abuse the Backplane framework by trying to impersonate other Widgets’ behavior in order to obtain and access information that is not directed to them, such as end user account information addressed to other Widgets.

The Web Page owner (and indirectly the end user), and Widget owners trust the Backplane Server API and Backplane JavaScript API implementations that they will comply with this specification.

The Web Page owner (and indirectly the end user) trusts all content on the Web Page to not attack the widgets or the Backplane framework. This must explicitly include all JavaScript loaded for any purpose, including JavaScript that is not part of any of the Widgets on the Web Page.

Backplane Clients trust the Bus owner and the authenticity of Backplane Messages received through a Bus, i.e all Backplane Clients that were granted permission to post on the Bus by its owner.

(draft 08)

5. Access Levels

Considering the significantly different security enforcement capabilities of applications running in a web browser versus the ones running on a web server, two access levels are defined for Backplane Clients: Regular and Privileged.

Each access level is exercised for retrieving messages from the Get Messages (Get Messages) endpoint by presenting either a regular or a privileged access token obtained from the token (Access Token Request) endpoint. The access token MUST be presented as described in section 2.1 (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.) [OAuth2.token.bearer].

Backplane Servers MUST validate the access token presented with all requests received at the Get Messages (Get Messages) endpoint and determine the access level associated with it.

(draft 08)

5.1. Regular Access

Regular access level is given to Backplane Clients running in the web browser (Widgets and the Backplane JavaScript Library) and are obtained through anonymous calls to the token (Access Token Request) endpoint.

Bus owners and Backplane Servers acting on their behalf MUST NOT give authorization credentials for Privileged access level to Backplane Clients running in the web browser.

Backplane Servers MUST only make Backplane Message Headers (not full Backplane Messages) available to Clients having Regular access level.

(draft 08)

5.2. Privileged Access

Privileged access level is given to Backplane Clients that are not running in a web browser (typically the Widgets’ server-side components) and are obtained through authenticated calls to the token (Access Token Request) endpoint.

Backplane Clients having Privileged access level can perform the following operations on a Bus for which they have obtained authorization (Authorization) credentials from the Bus owner:

  • retrieve all Backplane Messages sent to the Bus [[[ xref ]]]
  • post Backplane Messages to a Channel [[[ xref ]]]

(draft 08)

5.2.1. Authorization

Registered (Backplane Client Registration) Backplane Clients must be authorized with Privilged Access Level. This can be done in one of the following ways:

  • By Backplane Server administrators. It is outside of the scope of this specification how the administrators learn from their customers, the Bus Owners, the Buses and Backplane Clients to be authorized with Privileged Access.
  • By Bus Owners, through an administrative interface provided by the Backplane Server. The interactions between a Backplane Server and its Bus Owner customers (e.g. registration, authentication, Bus allocation) remain outside of the scope of this specification.

(draft 08)

6. Discovery, Registration and Authorization

For a functional setup, the Bus Owners, Backplane Servers and Backplane Clients needing Privileged Access have to perform the following preliminary interactions:

(draft 08)

6.1. Backplane Server Discovery

6.1.1. Dynamic Discovery

It is RECOMMENDED that Backplane Servers support dynamic discovery, as described in [OAuth.Dynamic.Client.Registration] (Hardjono, T., Machulak, M., Maler, E., and C. Scholz, “OAuth Dynamic Client Registration Protocol,” Oct 2011.) section 5. Discovery of Server’s Client Registration Endpoint. [[[ doesn’t cover authorization/token endpoints, it probably should ]]]

(draft 08)

6.1.2. Static Discovery

When dynamic discovery is not available, Backplane Clients must independently acquire and keep configuration entries for the registration, authorization, token and message endpoints of the Backplane Servers they wish to interact with.

(draft 08)

6.2. Backplane Client Registration

Backplane Clients need to be registered with the Backplane Server in order to be authorized with Privileged Access (Privileged Access).

Backplane Servers SHOULD provide one of the following registation methods, listed in decreasing order of preference.

(draft08)

6.2.1. Dynamic Client Registration

It is RECOMMENDED that Backplane Servers and Backplane Clients employ [OAuth.Dynamic.Client.Registration] (Hardjono, T., Machulak, M., Maler, E., and C. Scholz, “OAuth Dynamic Client Registration Protocol,” Oct 2011.) as described in sections “6. Client Registration with Pushed Metadata” and “7. Client Registration with Pushed URL and Pulled Metadata”.

(draft 08)

6.2.2. Static Client Registration

Backplane Servers MAY provide an administrative interface through which Bus Owners can register Backplane Clients. The interactions between a Backplane Server and its Bus Owner customers (e.g. registration, authentication, Bus allocation) remain outside of the scope of this specification.

Note

Buses seems to have to be allocated at Backplane Server

For the purpose of Privileged Access Level authorization a server-side Backplane Client needs to be identified by a URL that corresponds to the Redirection URI defined in section 2.1.1 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] and used in the authorization step in section 4 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2].

The redirection URI MUST be obtained and approved by the Bus Owner administrator. Backplane Servers may assist Bus Owner administrators by providing the redirection URIs of well known Backplane Clients (such as popular Widget providers) in their administration user interface.

When completing a Backplane Server Initiated Authorization (Backplane Server Initiated Authorization) if the previously unregistered Backplane Client opted to also send client credentials, the Backplane Server MAY register (Static Client Registration) the Backplane Client.

The Backplane Server MUST verify all of the following:

  • The grant_type is “code”.
  • The code is present and the value is recognized as a previously issued, one-time use, valid code.
  • The redirect_uri is present and matches the redirect_uri for which the supplied code was issued.
  • The client_id is present and is different than “anonymous” or any other already registered client_id.

Note

  • OAuth code flow
  • “anonymouse” is special client_id for Wiget

After a successful registration the Backplane Server MUST continue processing the Authenticated Access Token Request (Authenticated Access Token Request)

(draft 08)

6.2.3. Manual Client Registration

As a last resort, Backplane Server administrators MAY manually register Backplane Clients and make them available to Bus Owners for Privileged Access authorization.

(draft 08)

6.3. Authorization

6.3.1. Backplane Client Initiated Authorization

A Bus Owner MAY initiate standard OAuth 2.0 authorization code flow from the Backplane Client as described in section 4.1 Authorization Code (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2], if supported by the Backplane Client. Backplane Servers SHOULD support the standard OAuth Authorization Code flow.

(draft 08)

6.3.2. Backplane Server Initiated Authorization

Backplane Servers MAY provide an administrative interface through which Bus Owners can initiate the authorization of registered (Backplane Client Registration) Backplane Clients using a slightly modified OAuth Authorization Code flow described in this section.

Once the Backplane Client has been identified and the Bus Owner has selected the Buses for authorization, the Backplane Server persists the authorization grant, generates an OAuth code for it and sends it with an unsolicited OAuth Authorization Response to the Backplane Client’s redirection URI. The successful authorization response SHOULD contain a space sperated list with the authorized Bus names in the scope field.

Since an unsolicited OAuth Authorization Response is issued, the Backplane Server‘s token (Access Token Request) endpoint MUST be identified in the Redirection URI using a query parameter named bp_token_endpoint.

The Backplane Client continues by following the OAuth Authorization Code flow from this point, and exchanges the authorization code for an access token at the Backplane Server’s token endpoint, as described in sections 4.1.3 and 4.1.4 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] and Access Token Request (Access Token Request).

(draft 08)

7. Padded Responses

For API requests made by the Javascript Library, the response is formatted specially.

The response body begins with the value of the callback parameter from the request. That value is followed by a “(” (opening parenthesis), then the JSON-encoded result value, then a ”)” (closing parenthesis).

Note

JSONP

(draft 08)

8. Buses

A Bus is a logical grouping of Backplane Clients that need to interact with each other, typically belonging to one organization. Buses allow a Backplane Server to service multiple customers. Bus names are short strings referencing the Bus owner‘s name (e.g. “customer.com”, “organization.org”). Backplane Clients must know the identifiers for the Buses through which they wish to exchange Backplane Messages.

It is assumed that a relationship of trust exists between all clients granted permission to post messages to a specific Bus (see Trust (Trust)).

(draft 08)

9. Channels

A Channel is a subset of Backplane Messages that belong to a Bus and are addressed to the Backplane Clients interacting with the end user through a single session and Web Page.

A Channel is similar to a session identifier for the user but is shared by multiple Backplane Clients.

Channels are:

Channel identifiers are used by Backplane Clients for message retrieval. All Backplane Clients that know a given Channel identifier can receive Backplane Messages posted to that Channel.

Channel identifiers MUST only contain characters from the base64url (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648.section5] character set and be at least 32 characters long. New channels are generated only on anonymous access token requests (Anonymous Access Token Request).

The channel name MUST NOT be guessable given knowledge of the algorithms in use or any details of the request being made (RFC 4086 (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) [RFC4086] discusses the requirements and pitfalls of generating unguessable values in great detail).

There can be at most one channel active on a Web Page at a given time.

(draft 08)

10. Backplane Messages

A Backplane message is a JSON object with the following fields:

messageURL
(string) a URL that a client can use to retrieve the message
source
(string) an arbitrary URL identifying the client which posted the message [[[ who/how/when/where? ]]]
type
(string) opaque to the core Backplane specification; value, semantic and associated payload format is defined in application scenario specifications
bus
(string) the name of the Bus the message was posted to
channel
(string) the identifier of Channel the message was posted to
sticky
(boolean) sticky flag. See Sticky Messages (Sticky Messages)
payload
(object) arbitrary data specific to the particular message type

The presence of certain fields in a Backplane message depends on the context it appears in.

A downstream (server-to-client) Backplane message MUST contain all the fields listed above. If the client receiving the message has regular access, the server MUST omit the “payload” field.

An upstream (client-to-server) Backplane message MUST only contain the following fields: “bus”, “channel”, “payload”, “type”.

Example downstream Backplane Message:

{
    "bus": "customer.com",
    "channel": "67dc880cc265b0dbc755ea959b257118",
    "messageURL": "https://bp.example.com/v2/message/097a5cc401001f95b45d37aca32a3bd2",
    "source": "http://aboutecho.com",
    "payload": {
            "role": "administrator"
    },
    "type": "identity/ack"
}

(draft 08)

11. Message Retention

Note

  • Message retained at Backplane Server has TTL.
  • “TTL=5(min)” is recommendation.

Backplane Servers MUST maintain a buffer of messages received from all their clients until messages become older than a certain threshold.

Such threshold MUST be no less than 1 minute. It is RECOMMENDED that Backplane Servers set the threshold to at least 5 minutes. A message is considered obsolete once its age reaches the threshold.

It is RECOMMENDED that Backplane Servers make messages available for retrieval as soon as possible after they are posted.

Backplane Clients that require reliable message delivery MUST poll their Backplane Servers with an interval of 30 seconds or less in order to avoid omissions.

(draft 08)

11.1. Sticky Messages

Some Backplane application scenarios may require longer lived Backplane Messages, such as for keeping a shared state about a end user’s logged-in identity or profile data.

Support for such scenarios is accomplished by flagging messages as “sticky” when they are posted (see Post Messages To A Channel (Post Messages)). Backplane Servers MUST retain sticky messages for at least X minutes. It is RECOMMENDED that Backplane Servers retain sticky messages for Y minutes.

Backplane Clients can request retrieval of Backplane Frames that only encapsulate sticky messages by using the “sticky” Access Scope (Access Scopes) filter. See also Message Retrieval Conventions (Message Sequences and Retrieval) below.

Application scenario protocols MUST specify the criteria for posting sticky messages, if any, such as defining certain message types or operations as sticky.

Application scenario protocols SHOULD define `sticky messages`_ in such a way as to minimize the number of sticky messages that may be retained by the Backplane Server at any one time for a channel, in order to reduce complexity of retrieval and processing by the Backplane Clients that rely on them.

(draft 08)

12. Message Sequences and Retrieval

Backplane Clients may wish to retrieve a subset of all the messages they have access to, such as belonging to certain Buses or Channels, having a certain type, source, or other attributes such as sticky.

A Message Sequence is the subset of the entire stream of Backplane Messages that match a filter criteria, in the same order as they have been received by a Backplane server.

The token (Access Token Request) endpoint is used to obtain an access token tailored to the filter criteria desired by the client. The access token is used at the Get Messages (Get Messages) endpoint to retrieve the messages in the current buffer that belong to the associated Message Sequence.

The Message Identifier of the last Backplane Message in a retrieved batch of messages is returned as the value of the “since” query parameter of the nextURL response field, such that the nextURL value will point to the messages that will immediately follow in the buffer and will not retrieve any of the messages that were already retrieved.

If a Message Identifier points to a message that is no longer in the buffer, the associated filter criteria is evaluated against the entire current buffer.

(draft 08)

12.1. Access Scopes

The filter criteria for defining a Message Sequence are passed to the token endpoint when requesting access tokens (Access Token Request) as a space-delimited list of access scopes in the following format:

Access Scope Format:
    <message_field_name>:<message_field_value>

where message_field_name is any of the defined message field names (Backplane Messages), and message_field_value is the expected field’s value.

An access scope is evaluated by performing a case-sensitive string comparison between the expected field’s value in the access scope, and the field value from the Backplane Message.

A list of access scopes is evaluated as follows:

  • a logical OR operation is performed for all access scopes having the same field name
  • a logical AND operation is performed among all access scopes having different field names

Example access scopes: all sticky messages of type “identity/ack” posted by “http://aboutecho.com” to any channel belonging to the “customer.com” bus.

bus:customer.com source:http://aboutecho.com type:identity/ack sticky:true

Example access scopes: all messages (belonging to bus A OR bus B) AND (having type C OR type D)

bus:A bus:B type:C type:D

When issuing or verifying the scope of an access token, Backplane Servers MUST enforce that the requester is authorized with Privileged Access (Privileged Access) for all “bus:” access scopes.

Application scenario protocol extensions MAY define additional authorization requirements against other scope type and Backplane Message fields.

(draft 08)

13. Backplane Server API

(draft 08)

13.1. Access Token Request

The OAuth “Token Endpoint” as defined in section 2.2 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] is used to obtain an access token to be used for retrieving messages from the Get Messages (Get Messages) endpoint.

Endpoint
/v2/token
HTTP mehod
POST
Security
HTTPS
Parameters

The parameters constitute an access token request as defined in either section 4.1.3 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] ( “code” grant type) or section 4.4.2 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] (“client credentials” grant type).

The parameters MUST be passed in the request body using the “application/x-www-form-urlencoded” format:

  • client_id (string, REQUIRED)
  • client_secret (string, OPTIONAL)
  • grant_type: MUST be “client_credentials” or “code”
  • code (string): REQUIRED if and only if grant_type is “code”
  • redirect_uri (string): REQUIRED if and only if grant_type is “code”
  • scope (string, OPTIONAL): a list of space-delimited filter criteria (Access Scopes) for the messages the client is interested in.
Returns

On success, a JSON object is returned per section 5.1 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] with the following fields:

  • token_type: MUST be “Bearer” [OAuth2.token.bearer] (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.)
  • access_token: the issued bearer access token
  • expires_in: the server MUST include the “expires_in” parameter if the issued token is set to expire.
  • backplane_channel (optional): the Channel name, if one was generated as a result of an anonymous request

The server MUST NOT include the “refresh_token” into the response.

Response example

{
  "access_token": "465203f03680f59b7ddd5e1e5d851461",
  "token_type": "Bearer",
  "backplane_channel": "0a92d76f54f7877a68abe19c5b3ffcf8"
}

(draft 08)

13.1.1. Anonymous Access Token Request

anonymous access tokne request
  • grant_type = client_credentials
  • client_id =”anonymous”

If the “grant_type” parameter is “client_credentials” and the “client_id” parameter is set to “anonymous”, the request is an anonymous access token request. The client MUST omit the “client_secret” parameter in this case. The server MUST ignore the value of the “scope” parameter.

In response to a anonymous access token request the Backplane Server allocates a new channel (Channels) and issues a regular access token (Regular Access) to the client (no message payloads) for the channel. New channels are generated only anonymous access token requests. The channel is not bound to a bus until the first message is posted to the channel (see Post Messages (Post Messages)).

Regular access tokens issued in response to anonymous access token requests MUST expire. It is RECOMMENDED that such tokens expire within 1 hour after having been issued.

As an operational note, this API call SHOULD NOT be implemented in a way that makes it capable of blocking and use of one of the mechanisms in section 7 of RFC 4086 (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) [RFC4086] is RECOMMENDED.

(draft 08)

13.1.2. Authenticated Access Token Request

If the “grant_type” parameter is “code” and both “client_id” and “client_secret” are present, the server MAY attempt Static Client Registration (Static Client Registration).

The server MUST check the credentials of the client. If the credentials are valid, the request is a authenticated access token request; otherwise the server MUST return error per section 5.2 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] (error “unautorized_client”).

The server MUST check that the client making the request is authorized for the requested scopes. If the client is not authorized for any of the requested scopes the server MUST return error per section 5.2 (Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.) [OAuth2] (error “invalid_scope”).

In response to a authenticated access token request the Backplane Server issues an privileged access token (Privileged Access) to the client for the requested scope. If no “scope” parameter was specified in the request, the client is granted access to all buses it is authorized to per the server configuration.

(draft 08)

13.2. Get Messages

Retrieve messages from the server.

Endpoint
/v2/messages
HTTP mehod
GET
Security
HTTPS
Authorization

The client MUST present the access token obtained from a Access Token Request (Access Token Request) as described in section 2.1 (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.) [OAuth2.token.bearer].

The server MUST retrieve the Access Scopes (Access Scopes) associated with the presented access token, determine the Message Sequence (Message Sequences and Retrieval) filter and access level (Access Levels), and respond accordingly.

Parameters

  • block (integer, default 0): if no messages are available for immediate retrieval, this parameter communicates how long (in seconds) the server should wait before returning an empty response
  • callback (string, optional): callback function to pad the response with (see Padded Responses (Padded Responses)); MUST only contain alphanumeric characters (a-zA-Z0-9)
  • since (optional, string): the Message Identifier representing the starting point of the requested Message Sequence. See Message Sequences and Retrieval (Message Sequences and Retrieval).
Returns

On success, a JSON object is returned with the following fields:

  • nextURL (string): a complete URL pointing to the Get Messages endpoint that the client can invoke to retrieve subsequent messages from the server. The URL MUST contain a Message Identifier in the since query parameter.
  • messages[]: an array of messages in the order they were originally received by the server. Each message within the array is represented as a JSON object of the same structure as returned by the Get Single Message (Get Single Message) API method.

Response example

{
  "nextURL": "https://bp.example.com/v2/messages?since=958bfa2dd8aed82c86afbd54b4a314a5",
  "messages": [
    {
      "bus": "customer.com",
      "channel": "67dc880cc265b0dbc755ea959b257118",
      "messageURL": "https://bp.example.com/v2/message/097a5cc401001f95b45d37aca32a3bd2",
      "payload": {
        "role": "administrator"
      },
      "source": "http://aboutecho.com",
      "type": "identity/ack"
    }
  ]
}

(draft 08)

13.3. Get Single Message

Retrieve a single message from the server.

Endpoint
/v2/message/<msg_id>: The full endpoint URL constitutes the messageURL obtained from a Get Messages (Get Messages) response.
HTTP mehod
GET
Security
HTTPS
Authorization
The client MUST present the access token obtained from a Access Token Request (Access Token Request) as described in section 2.1 (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.) [OAuth2.token.bearer], to prove that it has access to the message. The server MUST retrieve the Access Scopes (Access Scopes) associated with the presented access token, determine its access level (Access Levels) and respond accordingly with either a Backplane Header, a Backplane Message (including payload), or error.

Query parameter

callback (string, optional): callback function to pad the response with (see Padded Responses (Padded Responses)); MUST only contain alphanumeric characters (a-zA-Z0-9)

Returns

  • HTTP status code 404 (“Not Found”) if the message is no longer available.

  • HTTP status code 403 (“Forbidden”) if the client is not authorized to retrieve messages from the Bus the message belongs to.

  • On success, a HTTP status code 200 (“OK”) is returned, with the response body containing a Backplane Message JSON object, with the following fields:

    • messageURL (string): the URL of the message, see Get Single Message (Get Single Message)
    • source (string): an arbitrary URL identifying the client which has posted the message.
    • type (string): message type (arbitrary string).
    • bus (string): the bus name the message was posted to
    • channel (string): the channel name the message was posted do.
    • payload (object, optional): message payload. Only available to privileged access clients.

Response example:

{
  "messageURL": "https://bp.example.com/v2/message/097a5cc401001f95b45d37aca32a3bd2",
  "source": "http://aboutecho.com",
  "type": "identity/ack"
  "bus": "customer.com",
  "channel": "67dc880cc265b0dbc755ea959b257118",
  "payload": {
    "role": "administrator"
  },
}

(draft 08)

13.4. Post Messages

Publish messages to the Backplane.

Endpoint
/v2/messages
HTTP mehod
POST
Security
HTTPS
Authorization

The client MUST present the access token obtained from a Access Token Request (Access Token Request) as described in section 2.1 (Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.) [OAuth2.token.bearer].

The server MUST retrieve the Access Scopes (Access Scopes) associated with the presented access token and determine that it has Privileged Access Level (Privileged Access) for each of the Buses referenced in the request body.

Request body

The body of the request is a JSON object of the following structure:

  • messages[]: an array of messages to be posted, represented as JSON objects of the following structure:

    • source (string): an arbitrary URL identifying the client which has posted the message
    • type (string): message type (arbitrary string)
    • bus (string): the name of the bus to post the message to
    • channel (string): the name of the channel to post the message to
    • payload (object): the message payload

Returns

  • HTTP status code 201 (“Created”) upon success.
  • HTTP status code 403 (“Forbidden”) if the client is not authorized to post messages to any of the referenced Buses. The server processes the messages in the request one by one; if a message can’t be posted for any reason, the whole request fails and none of the messages get posted.

The server MUST check that the channel in a message was previously allocated as a result of a Access Token Request (Access Token Request).

If the channel is not yet bound to a bus, the server MUST bind it to the bus specified in the same message object from the request.

If the channel is already bound to a different bus than the one specified in the same message object in the request, the entire request is considered invalid and is aborted.

Request example:

{
  "messages": [
    {
      "source": "http://aboutecho.com",
      "type": "identity/ack"
      "bus": "customer.com",
      "channel": "67dc880cc265b0dbc755ea959b257118",
      "payload": {
        "role": "administrator"
      },
    },
    {
      "source": "http://aboutecho.com",
      "type": "identity/ack"
      "bus": "organization.org",
      "channel": "d7a592b31fbbc2baf5f9476884b9acd5",
      "payload": {
        "role": "moderator"
      },
    }
  ]
}

(draft 08)

14. Backplane JavaScript API

Note

  • Backplane.init
  • Backplane.subscribe
  • Backplane.unsubscribe
  • Backplane.getChannelID
  • Backplane.expectMessagesWithin

A Backplane JavaScript Library runs in an end user’s browser and mediates communication between Backplane-enabled Widgets on the page and the Backplane Server.

Only one instance of the Backplane JavaScript Library on a given page is possible. The library has to be the first to load on the page to make it possible for other scripts to use its subscription functionality.

The Backplane JavaScript Library provides the following API (all methods are static):

/**
 * Initializes the backplane library
 *
 * @param {Object} Params - hash with configuration parameters.
 *   Possible hash keys:
 *     serverBaseURL (required) - Base URL of Backplane Server
 *     busName (required) - Customer's backplane bus name
 */
Backplane.init(Params);

/**
 * Subscribes to messages from Backplane server
 *
 * @param {Function} Callback - Callback function which accepts backplane messages.
 * @returns Subscription ID which can be used later for unsubscribing.
 */
Backplane.subscribe(Callback);

/**
 * Removes specified subscription
 *
 * @param {Integer} Subscription ID
 */
Backplane.unsubscribe(SubscriptionID);

/**
 * Returns channel ID (like http://backplane.customer.com/v2/bus/customer.com/channel/8ec92f459fa70b0da1a40e8fe70a0bc8)
 *
 * @returns Backplane channel ID
 */
Backplane.getChannelID();

/**
 * Notifies backplane library about the fact that subscribers are going
 * to receive backplane messages within specified time interval.
 *
 * @param {Integer} TimeInterval - Time interval in seconds
 * @param {Array} MessageTypes (optional) - a list of expected message types
 */
Backplane.expectMessagesWithin(TimeInterval, MessageTypes);

(draft 08)

14.1. Initialization

Backplane is initialized using the Backplane.init method.

During initialization the library generates a random Channel Name unless information about one for the specified bus name already exists in the backplane-channel cookie. Since client-side generation of the channel name is non-secure, the library performs a request to obtain a channel name from the Backplane Server.

There can be at most one channel active on a Web Page at a given time.

After initialization the library stores the current Channel Name in the backplane-channel cookie set against the complete domain name of currently opened page. The cookie is set for 5 years in advance and keeps information about association of Bus names to Channel Names (to support possibility to use the library with several different Bus names on the same domain). The information about the association is stored in a serialized form.

Here is an example of cookie that stores association of Bus names example.com and example.org to the corresponding channel names 123 and 456:

backplane-channel=example.com:123|example.org:456

After the channel ID has been determined, the library performs a first reading of messages from a channel, discards all of them (remembering only the identifier of the very last one) and starts polling the Backplane Server for new messages since the latest Backplane Message. This way the library is guaranteed to push to subscribers only those Backplane Messages which arrived after the library had been fully initialized.

(draft 08)

14.2. Subscription Management

The library provides a method for Widgets to set up notification callbacks: Backplane.subscribe. The method returns a subscription id which can be later used for unsubscribing using the Backplane.unsubscribe method.

After the initialization the library starts polling the Backplane Server for new events. All incoming events are delivered to the Widgets that have registered callbacks with the library.

(draft 08)

14.3. Hints

For performance reasons the Backplane JavaScript Library polls the Backplane Server with a low frequency (e.g once a minute). Since Backplane events usually are initiated on the client side (e.g. the user clicking a button), Widgets on the page are in a position to hint the library that a Backplane message may be soon delivered. Upon the receipt of such hint (via expectMessagesWithin method), the library temporarily increases the polling frequency (e.g. to once a second) and then gradually decreases it to the default low value one.

The expectMessagesWithin method can accept an optional list of expected message types.

If the library accepts any message from the passed message types list, it gradually returns to the lower polling frequency mode;

If messages with only one type are expected, the second argument may be specified as a string;

Each call of the method adds passed message types to the list of expected message types. In other words, if a user calls the method with a message type “type1” and then performs one more call with a message type “type2”, the library will run in the fast polling mode until it received messages of all the types or until the libray reached the maximum allotted waiting time interval.

(draft 08)

14.4. Usage Example

Backplane.init({
    serverBaseURL: "http://backplane.customer.com/v2",
    busName: "customer.com"
});

var escSubscription = Backplane.subscribe(function(backplaneMessage) {
    alert(backplaneMessage.payload);
});

// We can ask the library to perform more frequent polling
// if a widget, for example, expects a message from Backplane pretty soon
// using the expectMessagesWithin method which accepts
// time interval of possible message arrival in seconds
Backplane.expectMessagesWithin(10);

// The method can accept an option list with expected message types.
// The library stops fast polling when it receives a message of
// either type.
Backplane.expectMessagesWithin(10, ["type1", "type2"]);

// Subsequent calls extend the list of expected message types.
// The library stops fast polling only after it has received
// a message of type1 or type2 AND a message of type3 or type4.
Backplane.expectMessagesWithin(10, ["type3", "type4"]);

Backplane.unsubscribe(escSubscription);

// If a widget needs Backplane channel ID it can get it using the
// getChannelID method
Backplane.getChannelID();

(draft 08)

15. Security Considerations

See Trust (Trust).

(draft 08)

15.1. Channel Name Sensitivity

The Channel Name acts as a session identifier shared among a group of trusted parties. Knowledge of a Channel Name offers Regular Access level to Backplane Server API.

It is therefore important that the Channel Name is not compromised, by either:

  • Trusting any third-party JavaScript source included in the Web Page without due verification, or
  • Disclosing Channel Names to untrusted parties.

(draft 08)

15.2. Message Payloads

Message payloads are only sent to Backplane Clients at Privileged Access Level (Privileged Access). This is in order to allow sensitive data to be exchanged among server-side Backplane Clients, while not allowing it to reach the less secure context of web browser.

It is therefore important that Privileged Access Level (Privileged Access) credentials are not provisioned to Backplane Clients that run in a web browser

(draft 08)

16. Normative References

[OAuth.Dynamic.Client.Registration]
Hardjono, T., Machulak, M., Maler, E., and C. Scholz, “OAuth Dynamic Client Registration Protocol,” Oct 2011.
[OAuth2]
Habber-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.
[OAuth2.token.bearer]
Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” Jun 2011.
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC2617]
Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[RFC4086]
Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” BCP 106, RFC 4086, June 2005 (TXT).
[RFC4627]
Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC4648.section5]
Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.

(draft 08)

«  Simple Web Discovery (SWD)   ::   Contents   ::   LRDD: Link-based Resource Descriptor Discovery  »