Identity/Architecture/SignIntoBrowser: Difference between revisions

Jump to navigation Jump to search
Line 42: Line 42:


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.
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 ===


== Flow ==
== Flow ==
668

edits

Navigation menu