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 all of her signin preferences (which web sites to automatically log into, etc.) are present in this new device.

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.

Pluggable 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: the user's selected services identities. A BCP is a BrowserID IdP with additional properties to enable the service discovery portion. 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-attached Services

An ID-attached service is a web-based service that takes a BrowserID assertion for login, then provides a particular service whose semantics are defined for that service category. The interface to that ID-attached service is via JavaScript MessageChannel: the user-agent loads the ID-attached-service endpoint URL in an (invisible) IFRAME and makes API calls to it using standard postMessage mechanics. The specifics of the MessageChannel calls are defined by the type of service.

For example, an ID-attached Bookmarks Service implementation, be it from Mozilla or Delicious, provides a URL endpoint that expects certain bookmarks-specific calls over the MessageChannel.

(Why not REST? Because want to allow the service to do its own authentication and caching.)