<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yes: Nat has nailed the use case. The user's federated identity,
which will be the tuple of the user_id and the issuer, will still be
what gets them in the door; but this is bound to a local concept of
a "user" with some short "username" field.<br>
<br>
There's still the case where there's a conflict at the RP -- either
the name from the IdP is in use already at the RP, or it doesn't
match the local parameters. This falls under step 2-1 below, and a
smart RP will have to deal with this situation.<br>
<br>
That is to say: in the case of an RP that allows multiple IdPs and
does account creation on first login (very common case), if I come
in the front door with (user_id1,issuer1) and the claim "username",
I can bind that to the "username" field in the account creation
step, I get the "username" account on that system. If someone else
comes in with (user_id2,issuer2) with the same "username" claim,
they do *not* get bound to the "username" account on the system.
They can create an account with "username2" or anything else that's
valid, but just because their claim is of "username" doesn't mean
they can get to my account with that username. <br>
<br>
-- Justin<br>
<br>
On 05/22/2012 04:16 PM, Nat Sakimura wrote:
<blockquote
cite="mid:CABzCy2DDOOERgR5c4o+3qLOgy18v=NFOt+m4ZfM41NM=dLHTuQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Well, let me counter this from another angle.
<div><br>
</div>
<div>From my experience in integrating an existing sites (such as
Wordpress, Drupal, Xoops, etc.), they need local username,
simple because they were built that way. </div>
<div><br>
</div>
<div>Traditional way to deal with it were: </div>
<div><br>
</div>
<div>
<ol>
<li>Client uses email to look up an existing account and
authenticate with existing credential (password)</li>
<li>If no existing username was found: </li>
<ol>
<li>Let the user choose a desired one. </li>
<ol>
<li>If the username exists, then authenticate with
password. </li>
<li>else, go ahead and create an account. </li>
</ol>
<li>OR Client plug-in generates whatever the string it deems
suitable. </li>
<li>OR just use verified claimed_id in case of OpenID 2.0
(<- this is bad in terms of user experience.) </li>
</ol>
</ol>
<div>Even in the case 2-2, often this string is used for
"greeting" message on the site. </div>
</div>
<div>So, it is better to have a user friendly name than a random
string, preferably, a string that the user usually uses. </div>
<div><br>
</div>
<div>If the IdP can provide such a string (, which btw, is likely
to be equal to local username at IdP, I guess), the client can
use it in the step 2-1 to smooth out the user experience. </div>
<div><br>
</div>
<div>I guess that is what people are wanting in this thread. </div>
<div><br>
</div>
<div>Nat</div>
<div><br>
<div class="gmail_quote">On Fri, May 18, 2012 at 7:40 AM, Mike
Jones <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I have a
philosophical problem with including a "preferred username"
claim, as it is counter to our goals of having sites rely on
federated logins, rather than creating local accounts. Yes
it makes sense for SCIM, where the goal is provisioning of
local accounts. But the whole point of OpenID Connect is to
use third party identity - not to create local accounts.
Thus, we shouldn't knowingly facilitate local account
creation.<br>
<br>
Besides, this doesn't meet the "needed to enable 80% of
sites to accept OpenIDs without undue user interactions"
that we were informally using as the criteria to include a
claim in the basic UserInfo claim set.<br>
<br>
(Also added the comments above to the ticket.)<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Mike<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[mailto:<a moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>]
On Behalf Of Justin Richer<br>
Sent: Wednesday, May 16, 2012 10:08 AM<br>
To: <a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
Subject: Re: [Openid-specs-ab] Username<br>
<br>
Issue reported:<br>
<br>
<a moz-do-not-send="true"
href="https://bitbucket.org/openid/connect/issue/584/messages-username-claim"
target="_blank">https://bitbucket.org/openid/connect/issue/584/messages-username-claim</a><br>
<br>
-- Justin<br>
<br>
On 05/16/2012 12:04 PM, Justin Richer wrote:<br>
> Yes, that's exactly what I'm after. For my own
facebook account, it<br>
> returns "zeronine", which is what I would expect
for a "username" on<br>
> that service. Since we plan to implement both the
OpenID (aka<br>
> "facebook") schema and the PoCo schema on our
endpoints, I wanted to<br>
> make sure we had sufficient overlap in the data
model. Plus, from our<br>
> IdP, all of our users *do* have unique usernames in
addition to (and<br>
> separate from) the user IDs we'll be presenting.<br>
><br>
> -- Justin<br>
><br>
> On 05/16/2012 11:52 AM, John Bradley wrote:<br>
>> In the Facebook case they are exposing the
Facebook username. Is<br>
>> that what thou want or an indication of what
username they would like?<br>
>><br>
>> I am not against the idea, just wanting to
clarify the proposed<br>
>> semantics.<br>
>><br>
>> John<br>
>> On 2012-05-16, at 11:27 AM, Justin Richer
wrote:<br>
>><br>
>>> Whether or not we want to encourage them,
we have systems that will<br>
>>> use them. Facebook also has "username" now:<br>
>>><br>
>>> <a moz-do-not-send="true"
href="https://developers.facebook.com/docs/reference/api/user/"
target="_blank">https://developers.facebook.com/docs/reference/api/user/</a><br>
>>><br>
>>> So I say we just grab that and be done with
it. PoCo has<br>
>>> "preferredUsername" for the same purpose.
This makes a lot more<br>
>>> sense than "nickname", which really has a
different (and potentially<br>
>>> useful in parallel) semantic behind it.<br>
>>><br>
>>> -- Justin<br>
>>><br>
>>> On 05/16/2012 11:16 AM, John Bradley wrote:<br>
>>>> That is not part of the basic set of
attributes Facebook uses, That<br>
>>>> was where the list originally came
from.<br>
>>>><br>
>>>> I thought that nickname was used by RP
for that.<br>
>>>><br>
>>>> looking at the spec the example of
shorting Michael to Mike may be<br>
>>>> slightly misleading, In my case my
nickname is "ve7jtb". The other<br>
>>>> potential issue is that we don't
preclude spaces.<br>
>>>><br>
>>>> Is there a need for a separate claim
that is a single string not<br>
>>>> including spaces to be used as a local
user name.<br>
>>>><br>
>>>> There is also the question of
encouraging local user names.<br>
>>>><br>
>>>> John B.<br>
>>>> On 2012-05-16, at 10:45 AM, Justin
Richer wrote:<br>
>>>><br>
>>>>> I might be missing it, but it seems
that there's a gap for<br>
>>>>> specifying a user's preferred local
username in the User Info<br>
>>>>> schema. This is distinct from
"user_id" which is a guaranteed<br>
>>>>> unique identifier, "name" which is
the actual name of the person,<br>
>>>>> "nickname" which is a shortened
first name, or anything else that<br>
>>>>> I can see.<br>
>>>>><br>
>>>>> Is there a specific reason for this
omission? If not, I'd like us<br>
>>>>> to add in a standard claim for this
information.<br>
>>>>><br>
>>>>> -- Justin<br>
>>>>>
_______________________________________________<br>
>>>>> Openid-specs-ab mailing list<br>
>>>>> <a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>>>> <a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>