668
edits
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 == |
edits