Lucas Adamski [:ladamski] Reporter
	Description • 12 years ago

We will use a Persona ID (with modifications) to track purchase history and the user's corresponding payment provider ID.  This is necessary to support the new payment provider flow (see 794530).

	Jason Smith [:jsmith]
	Comment 1 • 12 years ago

This is a meta bug - we don't block on metabugs. Please nom the individual implementation bugs to block.

	Ben Adida [:benadida]
	Comment 2 • 12 years ago

We will support the navigator.id API (the Observer API, the latest), as specified in:

  https://developer.mozilla.org/en-US/docs/DOM/navigator.id

This DOM API is already implemented in Gecko, toolkit/identity and dom/identity.

We'll build a B2G specific UI in b2g/components/SignInToWebsite.jsm, which parallels the existing desktop browser/modules/SignInToWebsite.jsm.

Because of the short timeframe and the need for new server-side features and flows, we will serve the identity selector from the Persona servers live, rather than have them locally in B2G. Thus, SignInToWebsite.jsm will, much like mozPay, message Gaia and Gaia will open a trusted popup to the Persona servers.

In order to message back via the DOM API, the dialog frame will be injected with client-side JavaScript that hooks the server-provided content into chrome callbacks, exactly like mozPay does with payment providers.

In addition, time permitting, the native crypto functions already built into Gecko (IdentityCryptoService) will be exposed to the server-provided dialog via additional injected JS APIs.

	Jason Smith [:jsmith]
	Comment 3 • 11 years ago

Closing for v1 tracking. I've moved all bugs over post v1 work for payments and identity over to bug 846517. So let's use that any post v1 tracking needed for client-side work.