Identity/Architecture/SignIntoBrowser

Use Case

Check out the Feature Page.

Brief version: Alice signs into her Firefox with Persona credentials, and her Firefox is immediately customized with her theme, bookmarks, passwords, history, add-ons, apps, and identities. She can use her identities to sign into websites, and her signin preferences (which web sites to automatically log into, etc.) are present in this new device.

Technical Goals

Reusable but Flexible Identity

If Alice logs into her browser as alice@example.com, she should be able to easily use that identity to log into web sites. She should also be able to use her other preferred identities.

Pluggable Services

Alice should be able to use the services of her choice, e.g. store her bookmarks with Google, her passwords and apps with Mozilla, and her contacts with her cell phone operator.

User-Selectable Browsing Context Provider

Alice should be able to select the server that performs the initial signin-to-the-browser authentication and setup of her preferred services. E.g., this may be a corporate directory server.

Components

Browsing Context Provider (BCP)

A Browsing Context Provider is the service that, upon user login, provides the context for the user's Web experience, specifically the user's set of identities and additional ID-connected services. A BCP is implemented as a BrowserID IdP with an additional discovery service. Thus, a BCP provides BrowserID parameters:

• a public key that is the root of trust for that domain
• a login content page where users authenticate in whatever way the BCP chooses
• a provisioning content page where authenticated users receive a certificate of their identity

In addition, to this, the BCP provides:

• a directory service that indicates the user's personalized services.

ID-connected Services

An ID-connected service is a web service that provides data and/or functions based on the user's identity. A service that stores a user's bookmarks (or passwords, or apps, or contacts) is one example of an ID-connected service.

ID-connected services may authenticate users via Persona or any other authentication mechanism. Persona-authenticated services are easier to integrate into browser functionality, given the standard presentation of a Persona login assertion.

Two potential interfaces to ID-connected services should be considered:

• REST: the semantics of a given service type, e.g. bookmarks or contacts, define a given REST API. Authentication can be done via [[1]]. The service endpoint is then the base URL off which hangs the REST API.

• MessageChannel: the semantics of a given service type, e.g. bookmarks or contacts, define a given postMessage API. Authentication can be done by passing appropriate BrowserID assertions at the beginning of the message exchange. The service endpoint is then the single URL to which the user-agent connects over a MessageChannel. This may be done by having the user-agent introduce a new property, e.g. window.channel, that serves as the MessageChannel between the user-agent and the service whose endpoint is loaded within the user-agent.

The current preference is for the latter model, MessageChannel, which allows a particular service implementation to define its client caching/batching behavior in a custom fashion. This model also enables more flexible protocols than request-response.

User-Agent

The User Agent is simply a browser, e.g. Firefox, which is the user's interface to the Web. The User Agent is assumed to understand the semantics of certain service types, but not necessarily all. For example, if a user has two ID-attached services, bookmarks and contacts, and one User Agent understands both (because it's a phone) while another User Agent understands only one (because it can't make calls), then that's just fine. The User Agent is expected to know, when it encounters an ID-connected service whose semantics it understands, when and how to make each API call for that service. The User Agent is expected to ignore ID-connected services it doesn't understand.

Flow

This flow assumes the MessageChannel architecture indicated above.

Signin

Alice wishes to sign into her browser and selects the appropriate menu item in her User Agent to begin this flow.

• User Agent prompts Alice for her email, she enters alice@example.com

• Based on this email and on internal configuration, User Agent discovers the appropriate BCP, and finds its login_url (as advertised in BrowserID parameters). This login_url is loaded into a content IFRAME displayed by the User Agent with some trust indicator. It makes use of the navigator.id provisioning API (which the User Agent specifically makes available to this IFRAME) to indicate successful or failed login, and, if successful, to communicate to the User Agent Alice's list of other identities and the set of her ID-connected services.

• Upon successful login, the User Agent loads, in a hidden content IFRAME, the BCP's provision_url (as advertised in BrowserID parameters). Using the navigator.id API again, the BCP causes the User Agent to generate a BrowserID keypair and certifies the public key as belonging to alice@example.com.

• Upon completion of this protocol, the User Agent holds (1) a certificate for alice@example.com, (2) the list of other email addresses that Alice uses to log into web sites, and (3) the set of ID-connected services that Alice uses, e.g. her bookmarks and contacts services.

Working with an ID-attached service

When the User Agent needs to interact with an ID-attached service, e.g. because it needs to upload a new bookmark, or download the latest set of contacts, it performs the following actions:

• load, in an invisible IFRAME, Alice's preferred endpoint for that service type, e.g. https://bookmarks.example.com/endpoint.html

• set up, in that IFRAME, a window.channel field, which is a standard HTML5 MessageChannel on which the endpoint can listen for messages and send messages back to the User Agent.

• perform a simple message-passing handshake over that MessageChannel to determine if the service needs a BrowserID assertion or if it needs to prompt the user for a login using custom authentication.

• make the service-type specific calls over simple .emit() calls to the MessageChannel.