Launchpad itself

Bug #655565
Comment #1

Comment 1 for bug 655565

Revision history for this message

Gary Poster (gary) wrote on 2010-10-07: Re: Immutable reference to users in API

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.

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.