There is no immutable reference to users in the LP API

[Stuart Metcalfe]

There's no immutable unique reference to users available through the API. This means that external systems which want to do something regularly based on a user (with the reference stored locally) will break if the user changes their username on LP.

[Gary Poster (gary)]

Curtis and I talked about this a bit yesterday. Here's a summary.

- We have several use cases for an immutable identity reference to a person.
  * AIUI, Stuart M.'s interest in the original bug description is that he wants to be able to store these references in a database for applications like SSO, and then be able to reliably get a person back from the identifier, no matter what has happened.
  * We sometimes need to send out emails to people about other users--such as emails to team owners about users who want to join. We have had recent experiences of a user changing their identity causing the links in the email to break.
  * When PPAs change their names or disappear, their users can experience significant annoyance.
- We have a variety of possible definitions of identity based on external values, such as GPG key, SSH key, email, and openid.
  * These values can be compromised, changed, mistakenly assigned, and have been in the past.
  * Only openid and email are required to exist initially for LP users, and only email will exist for people added to LP because of code imports.
  * All of them are managed by external services or tools; openid is currently managed by a "local" service, Canonical's SSO, but that will not be the case when we become a general OpenID consumer (https://dev.launchpad.net/LEP/OpenIdRoadmap). These external services may have their own foibles and security issues.
  * Because of the above challenges, we don't believe they are good choices for an immutable identity.
- The primary key of the person table would be a reasonable candidate from at least some perspectives, as long as you handled a few things.
  * merged people records know the "destination" of the merge; therefore, asking for a merged record would need to support a redirection of sorts. For instance, if you asked for person 12345, your code would need to be able to handle getting person 67890, if 12345 had been merged into 67890.
  * people who have been suspended or otherwise disabled would need to be handled somehow, either by not returning a result or by returning a result that clarified the situation.
- There are some concerns about using the primary key of the person table (bug numbers welcome). Depending on what the concerns are, we could instead have a unique value in the person cell which was effectively another key to the person. This is what the original Launchpad openid implementation provided, before we let the openid (alias) be mutable. The reason it was discarded was because people wanted their primary external Launchpad identifier to be human-readable. From that experience, it seems as if an opaque immutable identifier like this would be good for Stuart Metcalfe's use case, probably sufficient for the use case of sending team moderation request emails, and probably poor for the use case of PPAs. However, I don't see another answer.

In conclusion, I currently believe we should create an opaque, immutable identifier for a person, with support for merges and suspensions. It is the only solution yet identified that answers at least some of the use cases well.

[Gary Poster (gary)]

Stuart Bishop asks:

Do you want to be able to link to Launchpad people? Accounts? What concept of "identity" do we need?

He suggests using email addresses even though they can be retired, if that works. If that doesn't work, that's a data point in helping us define what identity means here.

[Stuart Metcalfe (stuartmetcalfe)]

On further investigation, I think the lplib.me entry will work for our use cases.

[Robert Collins (lifeless)]

This possibly should be closed, but I think we need another planning session with ISD around the microservices / SOA concepts and how it will tie into SSO.