The underlying user identifier

[David Recordon]

A little over a week ago I wrote (
http://davidrecordon.com/2010/08/the-three-types-of-openid-connect-identifiers.html)
about how I really see there being three different types of identifiers that
OpenID need to care about. This is important background for the following
discussion.

1) Identify the provider. Much of the recent work around WebFinger is based
> on the idea that people more commonly identify with email addresses than
> URLs. From an OpenID perspective, the most important part of `
> recordond at gmail.com` is that it tells a site that my identity is hosted on
> gmail.com. The same holds true for `davidrecordon.com` or just clicking a
> Facebook button.


> 2) Identify the user. In order for OpenID Connect to be secure, user
> identifiers must be HTTPS URLs and never recycled. This type of identifier
> does not need to be human friendly and ideally will never be shown to the
> user. It is the basis of all identity assertions and is ultimately the
> unique identifier of the OpenID account. It is easy to never recycle these
> URLs because they are not human friendly and thus don't take up the valuable
> part of a service provider's namespace.


> 3) Link to the user's profile. OpenID 1.0 was originally designed in an
> environment where the OpenID URL was also a homepage or a blog. It's clear
> that the profile URL is an important part of online identity, but should be
> separated from the underlying user identifier. There are times when the
> profile URL will also be used to identify the provider, but I think that the
> vast majority of users will instead enter an email address to sign in.


I believe that #1 and #3 are not contentious. A provider is identified by a
domain (google.com, openid.aol.com, etc) and a user's profile is a full on
URL. Disagree?

I don't believe that we have consensus around the form of the underlying
user identifier. Unlike prior versions of OpenID, this isn't an identifier
which the user needs to know, type, or really ever see. The provider
identifier is what gets used for discovery (the user typing in their email
address or clicking a button) and the profile URL is the human-friendly
identifier.

The user identifier really has two components: 1) the domain and 2) a unique
and non-reassignable identifier on that domain. OpenID previously used the
URL to try and encode this information which is how we ended up with
identifiers like `
https://www.google.com/accounts/o8/id?id=AItOawmP6awF76I-CromhOw__yakkw0SCM6nzjM`.
I've seen a number of arguments around no longer treating the user
identifier as a URL and instead having it be just the pair of domain and
user.

Thus a user identifier for Facebook might look like `24400320 at facebook.com`,
`acct:24400320 at facebook.com <acct%3A24400320 at facebook.com>`, or
`facebook.com:24400320` if we didn't want them to become confused with
actual email addresses. One of the benefits of doing this is that storing
`24400320` as a key in your database is quite a bit easier than storing a
URL as a key. Even Six Apart's user identifiers are relatively short
alphanumeric strings which are easier to store and index compared to URLs.

This decision is a bit orthogonal to the discussion around allowing the
server hosted at myopenid.com to issue an assertion about a user on
davidrecordon.com. I feel really strongly that we must retain account
portability between providers, but am actually pretty convinced that it
isn't necessary to use a URL as the underlying user identifier to achieve
that.

Thoughts?

--David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-connect/attachments/20100824/b822f77b/attachment.html>