<HTML>
<HEAD>
<TITLE>Re: The underlying user identifier</TITLE>
</HEAD>
<BODY>
<FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>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: <BR>
<BR>
</SPAN></FONT><SPAN STYLE='font-size:11pt'><FONT FACE="Courier New"><a href="https://login.salesforce.com">https://login.salesforce.com</a></FONT></SPAN><FONT FACE="Courier New"><FONT SIZE="2"><SPAN STYLE='font-size:10pt'>/id/{orgid}/{userid}<BR>
</SPAN></FONT></FONT><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
For example<BR>
<BR>
</SPAN></FONT><SPAN STYLE='font-size:11pt'><FONT FACE="Courier New"><a href="https://login.salesforce.com">https://login.salesforce.com</a></FONT></SPAN><FONT FACE="Courier New"><FONT SIZE="2"><SPAN STYLE='font-size:10pt'>/id/00DD0000000FH8l/005D0000001Az1u<BR>
</SPAN></FONT></FONT><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
Main difference is they our tenants usually aren’t directly DNS addressable. <BR>
<BR>
-cmort<BR>
<BR>
<BR>
<BR>
On 8/24/10 3:45 PM, "David Recordon" <<a href="recordond@gmail.com">recordond@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>A little over a week ago I wrote (<a href="http://davidrecordon.com/2010/08/the-three-types-of-openid-connect-identifiers.html">http://davidrecordon.com/2010/08/the-three-types-of-openid-connect-identifiers.html</a>) 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.<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>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 <a href="`recordond@gmail.com`">`recordond@gmail.com`</a> is that it tells a site that my identity is hosted on gmail.com <<a href="http://gmail.com">http://gmail.com</a>> . The same holds true for `davidrecordon.com <<a href="http://davidrecordon.com">http://davidrecordon.com</a>> ` or just clicking a Facebook button.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
I believe that #1 and #3 are not contentious. A provider is identified by a domain (google.com <<a href="http://google.com">http://google.com</a>> , openid.aol.com <<a href="http://openid.aol.com">http://openid.aol.com</a>> , etc) and a user's profile is a full on URL. Disagree?<BR>
<BR>
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.<BR>
<BR>
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 `<a href="https://www.google.com/accounts/o8/id?id=AItOawmP6awF76I-CromhOw__yakkw0SCM6nzjM`">https://www.google.com/accounts/o8/id?id=AItOawmP6awF76I-CromhOw__yakkw0SCM6nzjM`</a>. 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.<BR>
<BR>
Thus a user identifier for Facebook might look like <a href="`24400320@facebook.com`">`24400320@facebook.com`</a>, `acct:<a href="24400320@facebook.com">24400320@facebook.com</a> <<a href="mailto:acct%3A24400320@facebook.com">mailto:acct%3A24400320@facebook.com</a>> `, 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.<BR>
<BR>
This decision is a bit orthogonal to the discussion around allowing the server hosted at myopenid.com <<a href="http://myopenid.com">http://myopenid.com</a>> to issue an assertion about a user on davidrecordon.com <<a href="http://davidrecordon.com">http://davidrecordon.com</a>> . 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.<BR>
<BR>
Thoughts?<BR>
<BR>
--David<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>