Comment 5 for bug 556680

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 add
extra steps to some login attempts:

  - If the profile is unactivated or deactivated and the SSO email is
    unusable, we need to ask for a new email address and fire off a
    logintoken to get it validated and set as preferred.

  - If the SSO email isn't associated with the same person as the OpenID
    identifier, we should warn and guide them through a fix (usually a
    profile merge)

We probably want to be more explicit around account reactivation anyway,
so the first case may want to happen even if the address is usable.

Generic OpenID consumption
--------------------------

This gets us remarkably close to a generic untrusted OpenID provider
profile creation workflow, where we basically just add a third case:

  - If the OpenID identifier is unknown and the email is untrusted,
    prompt the user to enter an address for profile creation. Use a
    logintoken to validate it, and continue profile creation as normal.

External interactions
---------------------

Now, Software Center Agent assumes that it can use
getOrCreateByOpenIDIdentifier to turn an SSO OpenID identifier into an
active Launchpad person without user interaction. But it does this
before payment processing, so it's not absolutely terrible if it fails
sometimes. It can be taught to ask the user to log into into Launchpad,
where they will be guided into making their account usable before
retrying their purchase.