E-mail
When the standalone UF was implemented, we had to implement a different way to link CiviCRM accounts with UF accounts (which, in the case of standalone, are OpenIDs). The traditional approach was to use e-mail addresses as the linking value, but since we didn't necessarily have that information in standalone, we couldn't do that.
Lobo also said at the time that the e-mail address linking was less than ideal anyway because it broke down whenever more than one person shared the same e-mail address, for example. So in an attempt to kill two birds with one stone, I proposed a new concept for all CiviCRM <-> UF account linking.
My proposal was to generate a uniq_id that was similar to an OpenID in format (i.e. a domain name, dot-separated components) composed of the UF username and the website domain of the UF. So if you're running a Drupal site at http://mysite.org/ and your login is wmorgan, then your uniq_id is wmorgan.mysite.org.
This has a number of benefits:
- It unifies the CiviCRM <-> UF account link format because standalone uses OpenIDs which are essentially the same format (they should be full URLs technically, but that just requires the addition of http:// on the front and at least a trailing slash on the end, which can be easily added and subtracted when needed).
- It allows disambiguation of which UF instance the account belongs to which will be required when using the Drupal or Joomla! UFs where n sites point at 1 CiviCRM instance.
- It can be easily converted to an OpenID down the road by running a provider at mysite.org and/or by creating a CiviCRM-backed OpenID provider (which would also allow local installations of CiviCRM standalone to function without a connection to the Internet).
- It allows multiple people to share the same e-mail address as long as they have different logins for the UF, which is a much more reasonable assumption.
This concept was never fully implemented, but it's being brought up again due to the impending multiple Drupal sites point at 1 CiviCRM project / multi-org project. Point #2 above is especially relevant to this.
