The underlying user identifier

[Joseph Smarr]

I would argue that salesforce.com still is the authoritative database for
all of their tenants, and so they should just be using opaque IDs that
internally can be broken out into orgID/userID. This is also how things work
for Google Apps--every Apps user has a normal Google Accounts ID (e.g. my
jsmarr at google.com account ID is just as flat and normal and opaque as my
jsmarr at gmail.com account ID), but internally we know that the former is part
of the google.com apps domain.

On Thu, Aug 26, 2010 at 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. Are you planning to have more than one OpenID Server
> endpoint on a tenant by tenant basis?
>
> --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> 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> . The
>> same holds true for `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> , 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 <mailto:acct%3A24400320 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 <http://myopenid.com>  to issue an
>> assertion about a user on 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-connect/attachments/20100826/fdb3294a/attachment-0001.html>