attempting to create a new account with an existing team email address at login.ubuntu.com oopses

Original Ooops: Oops-Id: 1557carambola24
Oops from trying to log in after: Oops-Id: 1557canistel15

We're no longer able to restrict account creation so that emails related to team Persons from Launchpad aren't allowed to be used to create new Accounts, because we're not receiving updates for the emailaddress table.

Since we can't enforce this for every email address, the right thing to do is to not enforce it for *any* address, and let Launchpad refuse an account when it tries to sign in, it it notices it's related to a team Person.

So, we should a) check if an emailaddress already exists in the system when creating an account; then allow Emailaddresses that have a Person but not an Account create an Account, and b) ignore the Person's data when reporting sreg information to an RP if the Person is actually a team.

Moving to 2.10.0 so we can follow up with LP over the Maverick release when things are a little more sane

Yesterday, I spoke with Curtis Hovey about this, and in particular the parts of it that relate to Launchpad. Here's my understanding.

I largely agree with Anthony's comment (#2 above). To be precise:

1) CIP should not try to block any emails being assigned to SSO accounts.
2) Launchpad should be in charge of disallowing any SSO account from being associated with a team. As corollaries:
   * A new-to-LP SSO account that has an SSO preferred email address that is the same as a team's email address may not be associated with the team. (The workflow of this can be a separate discussion.)
   * An existing SSO account that is already associated with a (non-team) person but which has a SSO preferred email address that corresponds with a team (via changes in SSO or LP) will simply have its email address ignored: no errors or warnings should be raised.

Therefore, to address this bug, LP needs to verify that it enforces these constraints. CIP can definitely stop trying to block emails at that point. If the blocking is pointless now, maybe it can even be removed sooner, but that's more for ISD to determine, I think.

After some discussion with Curtis, the correct algorithm is probably thus:

    if openid is known:
        log in as openid's person
        if email is unknown:
            link email to openid's person
        elif email is owned by some other person or a team:
            warn user that things are confused
    else:
        if email and belongs to a person:
             log in as email's person
             link openid to email's person
        elif email belongs to a team:
             reject login
        else:
             create new person with email and openid

    if person is not active:
       # Do stuff, discussed below.

The main difference from the current implementation is the "warn user
that things are confused" bit. Currently we steal the email address from
its rightful owner and forcibly associate it with the OpenID
identifier's person. This is rather harmful if it steals a team's
contact address (changing how notifications work), a person's preferred
email address (making the person inactive), or even a person's last
remaining email address (making them largely unidentifiable and
difficult to recover).

The proposal puts a mismatch between identifier and email person into
one of four categories:

 - The identifier has no person. The email address is associated with a
   team. Launchpad explains that this is impossible, and rejects the
   login attempt.

 - The identifier has no person. The email address is associated with a
   person. Launchpad links the identifier to the email address' person.

 - The identifier has a person. The email address has a different person
   or a team. Launchpad displays a warning with a guide to resolution.

 - The identifier has a person. The email address has no person.
   Launchpad links the email address to the identifier's person.

Inactive profiles
-----------------

There is also the issue of unactivated, deactivated and suspended
profiles. All can be reached in the login process by having a
corresponding address in SSO, and deactivated/suspended can be reached
by OpenID identifier.

  - Unactivated profiles happen when eg. a Debian developer referenced
    in a package upload logs into Launchpad for the first time. They
    have an existing person without a preferredemail or active account.
    Given that we trust SSO to verify email addresses and we know the
    address is associated with this profile, we could continue to just
    activate the account and set the login address as preferred.

  - Deactivated profiles have no preferredemail, and currently get
    immediately reactivated with the login email address. While we could
    continue doing this, it upsets users as it looks as if the profile
    never went away. It's also a problem in the proposed algorithm,
    since we don't always have a usable email address (the login address
    may be occupied by a team).

  - Suspended profiles have no preferredemail, and login attempts are
    rejected. This probably doesn't change.

Since we don't always have a confirmed email address to set as
preferred, we can't always activate a profile automatically. Combined
with the confused email address warning, it looks like we have to ad...

n