The underlying user identifier

Thu Aug 26 20:56:49 UTC 2010

This positioning is very much aligned with Google's thinking on
identifiers, except that because we're an existing provider, we are
interested in the 'identifier migration' issue. I don't want to
distract this higher-level conversation with Google-specific technical
details, but I thought it was worth documenting the status quo here
for reference.

Today, Google supports four types of OpenID identifiers:

1. Realm-specific URLs of the form
https://www.google.com/accounts/o8/id?id=<random number>

2. Global opaque URLs that are generally not discoverable, of the form
http://[hosted-domain]/id?id=<random number>, where [hosted-domain] is
a Google Apps domain, such as Google.com; t

3. Profile Ids, of the form
http(s)://www.google.com/profiles/[username or random id]; These are
both OpenIDs and profile URLs

4. Any URL that delegates to the Google OpenID provider using the
Google user's profile id as the local id.

This situation is probably somewhat unusual among providers in terms
of complexity, but I suspect many of the existing providers will have
to deal with the issue of 'upgrading' current OpenID 2.0 usage to
OpenIDConnect (link new identifier with old one).

On Thu, Aug 26, 2010 at 12:07, Chuck Mortimore
<cmortimore at salesforce.com> wrote:
>
>
>
> 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
>
>
>
>
> _______________________________________________
> openid-specs-connect mailing list
> openid-specs-connect at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-connect
>
>

-- 
--Breno