The underlying user identifier

Thu Aug 26 19:07:44 UTC 2010

On 8/26/10 10:38 AM, "David Recordon" <recordond at gmail.com> wrote:

hmm, interesting. Would be useful to hear from the Google folks if this is similar to how they think about Apps for Your Domain.

In theory this could be expressed as user "{orgid}/{userid}" on the domain login.salesforce.com <http://login.salesforce.com> . Are you planning to have more than one OpenID Server endpoint on a tenant by tenant basis?

Nope - we ended up going with one global service for all tenants.

-cmort

--David

On Thu, Aug 26, 2010 at 6:37 AM, Chuck Mortimore <cmortimore at salesforce.com> wrote:
Our identifiers are similar, but subtlety different.   Rather than "domain + userid", we're really "tenant + userid".   Here's an example of the URLs we're issuing in our initial implementation:

https://login.salesforce.com/id/{orgid}/{userid}

For example

https://login.salesforce.com/id/00DD0000000FH8l/005D0000001Az1u

Main difference is they our tenants usually aren't directly DNS addressable.

-cmort

On 8/24/10 3:45 PM, "David Recordon" <recordond at gmail.com <http://recordond@gmail.com> > wrote:

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` <http://recordond@gmail.com>  is that it tells a site that my identity is hosted on gmail.com <http://gmail.com>  <http://gmail.com> . The same holds true for `davidrecordon.com <http://davidrecordon.com>  <http://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 <http://google.com>  <http://google.com> , openid.aol.com <http://openid.aol.com>  <http://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` <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` <http://24400320@facebook.com> , `acct:24400320 at facebook.com <http://24400320@facebook.com>  <mailto: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 <http://myopenid.com>  <http://myopenid.com>  to issue an assertion about a user on davidrecordon.com <http://davidrecordon.com>  <http://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

_______________________________________________
openid-specs-connect mailing list
openid-specs-connect at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-connect

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-connect/attachments/20100826/8a4b5e72/attachment.html>