668
edits
Identity/Architecture/SignIntoBrowser: Difference between revisions
Identity/Architecture/SignIntoBrowser (view source)
Revision as of 04:06, 23 April 2012
, 23 April 2012→Working with an ID-attached service
No edit summary |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 24: | Line 24: | ||
== Components == | == Components == | ||
[[Image:SigninToFirefoxComponents.png| | [[Image:SigninToFirefoxComponents.png|800px]] | ||
=== Browsing Context Provider (BCP) === | === Browsing Context Provider (BCP) === | ||
A Browsing Context Provider is the service that, upon user login, provides the context for the user's Web experience | 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 public key that is the root of trust for that domain | ||
| Line 37: | Line 37: | ||
* a directory service that indicates the user's personalized services. | * a directory service that indicates the user's personalized services. | ||
=== ID- | === ID-connected Services === | ||
An ID- | 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 [[https://wiki.mozilla.org/Identity/BrowserIDSync#BrowserID_.2B_REST|BrowserID+REST]]. 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 <tt>postMessage</tt> 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 <tt>MessageChannel</tt>. This may be done by having the user-agent introduce a new property, e.g. <tt>window.channel</tt>, that serves as the <tt>MessageChannel</tt> between the user-agent and the service whose endpoint is loaded within the user-agent. | |||
The current preference is for the latter model, <tt>MessageChannel</tt>, 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 === | === 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 == | == Flow == | ||
This flow assumes the <tt>MessageChannel</tt> 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 <tt>alice@example.com</tt> | |||
* Based on this email and on internal configuration, User Agent discovers the appropriate BCP, and finds its <tt>login_url</tt> (as advertised in BrowserID parameters). This <tt>login_url</tt> is loaded into a content IFRAME displayed by the User Agent with some trust indicator. It makes use of the <tt>navigator.id</tt> 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 <tt>provision_url</tt> (as advertised in BrowserID parameters). Using the <tt>navigator.id</tt> API again, the BCP causes the User Agent to generate a BrowserID keypair and certifies the public key as belonging to <tt>alice@example.com</tt>. | |||
* Upon completion of this protocol, the User Agent holds (1) a certificate for <tt>alice@example.com</tt>, (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. <tt>https://bookmarks.example.com/endpoint.html</tt> | |||
* set up, in that IFRAME, a <tt>window.channel</tt> field, which is a standard HTML5 <tt>MessageChannel</tt> 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 <tt>.emit()</tt> calls to the MessageChannel. | |||