Improve account creation workflow

[Anthony Lenton]

(forwarded from a mail from Martin Albisetti)
Hello everyone,

Reviewing the SSO registration process with Anthony, I bumped into an issue I'd like us to consider solving before rolling out.
The current workflow is roughly as follows:

1) User clicks on "create account" on a "random" website
2) They get sent to a page where you're presented with a log in and a registration form
3) The user clicks on registration
4) The form asks them for their email address (and a captcha verification)
5) Email is sent with a verification URL
6) User clicks on the URL, get sent to back to the SSO page
7) SSO asks them for their name and password, user fills them in, submits
8) We present the user with a page that tells them what information will be sent to the site that sent them here, and ask them to explicitly submit it
9) User continues their flow on the site they started on

Besides this being too many steps, we split our the information gathering into 2 places, making the process even more confusing, especially if the email verification is done a long time after the process got started.

I spent quite a bit of time discussing this with James Henstridge and Steve Alexander a while back and we had found a better solution for this (and hopefully simple enough to implement now), without getting into creating accounts without verified email addresses, which is a complex and uncertain change.
It goes something roughly like this:

1) User clicks on "create account" on a "random" website
2) They get sent to a page where you're presented with a log in and a registration form
3) The user clicks on registration
4) The form asks for *all* the information (gets saves on a cookie, like the redirect URL)
5) Email is sent with a verification URL
6) User clicks on the URL, get sent to back to *the original site they came from* (we create the SSO account in the back, and don't ask them to verify the information they want to send, as they have already entered it into the system, prompted by the other site)

While this shouldn't block on testing the SSO service with Canonical sites, where everyone already has an SSO account, I feel it's important to do before it's rolled out to a public site, like Ubuntu One.

[Stuart Metcalfe (stuartmetcalfe)]

It'd be good to implement asynchronous email verification where it's not immediately required to return a verified email. Of course, we don't want to go sending unverified emails to relying parties because they might not realise they're unverified and start sending actual emails to them.

[Stuart Metcalfe (stuartmetcalfe)]

Also, see the gdoc spec "Ubuntu SSO UX Specification" (ask Stu for the URL if it's not already in your available list)

[Anthony Lenton (elachuni)]

Moved to 2.9.0 to make space in 2.8 for Ubuntu 10.10 critical tasks

[David Owen (dsowen)]

This should have a mock-up to review before we start on the code, if possible.

[David Owen (dsowen)]

QA instructions:

This changes e-mails that are sent for account creation, but old e-mails will still be out there and supported. To test *that* aspect (support for older e-mails), do this:

Create an old-format e-mail:

 1. From the login screen, click "New account"
 2. Append a parameter named "old" the the URL

For example, for http://.../+new_account, add "?old" to the end. For http://.../+new_account?email=..., add "&old" to the end.

This part doesn't need testing, and will have a poorly styled form, but will create an old-format e-mail. Once you have that e-mail, try both the confirmation code and the link and ensure the account is properly created.

[Julien Funk (jaboing)]

Pass in staging.