Identity/Architecture/SignIntoBrowser

Use Cases

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 immediately use that identity to log into web sites. She should not be limited to that identity alone, however, and she should have her other preferred identities immediately at her disposal without having to retype them on each device.

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 a BrowserID IdP with additional properties. This means a BCP provides the basic BrowserID IdP items:

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

and, in addition to this:

• a discovery ID-attached-service URL that provides the user's set of personalized service endpoints.

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.

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

For example, an ID-attached Bookmarks Service implementation, be it from Mozilla or Delicious, provides a URL endpoint that responds