[Openid-specs-ab] Username

Justin Richer jricher at mitre.org
Tue May 22 21:12:38 UTC 2012


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.

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.

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.

  -- Justin

On 05/22/2012 04:16 PM, Nat Sakimura wrote:
> Well, let me counter this from another angle.
>
> 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.
>
> Traditional way to deal with it were:
>
>  1. Client uses email to look up an existing account and authenticate
>     with existing credential (password)
>  2. If no existing username was found:
>      1. Let the user choose a desired one.
>          1. If the username exists, then authenticate with password.
>          2. else, go ahead and create an account.
>      2. OR Client plug-in generates whatever the string it deems
>         suitable.
>      3. OR just use verified claimed_id in case of OpenID 2.0 (<- this
>         is bad in terms of user experience.)
>
> Even in the case 2-2, often this string is used for "greeting" message 
> on the site.
> So, it is better to have a user friendly name than a random string, 
> preferably, a string that the user usually uses.
>
> 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.
>
> I guess that is what people are wanting in this thread.
>
> Nat
>
> On Fri, May 18, 2012 at 7:40 AM, Mike Jones 
> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
>     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.
>
>     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.
>
>     (Also added the comments above to the ticket.)
>
>                                    -- Mike
>
>     -----Original Message-----
>     From: openid-specs-ab-bounces at lists.openid.net
>     <mailto:openid-specs-ab-bounces at lists.openid.net>
>     [mailto:openid-specs-ab-bounces at lists.openid.net
>     <mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of
>     Justin Richer
>     Sent: Wednesday, May 16, 2012 10:08 AM
>     To: openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     Subject: Re: [Openid-specs-ab] Username
>
>     Issue reported:
>
>     https://bitbucket.org/openid/connect/issue/584/messages-username-claim
>
>      -- Justin
>
>     On 05/16/2012 12:04 PM, Justin Richer wrote:
>     > Yes, that's exactly what I'm after. For my own facebook account, it
>     > returns "zeronine", which is what I would expect for a "username" on
>     > that service. Since we plan to implement both the OpenID (aka
>     > "facebook") schema and the PoCo schema on our endpoints, I wanted to
>     > make sure we had sufficient overlap in the data model. Plus,
>     from our
>     > IdP, all of our users *do* have unique usernames in addition to (and
>     > separate from) the user IDs we'll be presenting.
>     >
>     >  -- Justin
>     >
>     > On 05/16/2012 11:52 AM, John Bradley wrote:
>     >> In the Facebook case they are exposing the Facebook username.  Is
>     >> that what thou want or an indication of what username they
>     would like?
>     >>
>     >> I am not against the idea, just wanting to clarify the proposed
>     >> semantics.
>     >>
>     >> John
>     >> On 2012-05-16, at 11:27 AM, Justin Richer wrote:
>     >>
>     >>> Whether or not we want to encourage them, we have systems that
>     will
>     >>> use them. Facebook also has "username" now:
>     >>>
>     >>> https://developers.facebook.com/docs/reference/api/user/
>     >>>
>     >>> So I say we just grab that and be done with it. PoCo has
>     >>> "preferredUsername" for the same purpose. This makes a lot more
>     >>> sense than "nickname", which really has a different (and
>     potentially
>     >>> useful in parallel) semantic behind it.
>     >>>
>     >>> -- Justin
>     >>>
>     >>> On 05/16/2012 11:16 AM, John Bradley wrote:
>     >>>> That is not part of the basic set of attributes Facebook
>     uses, That
>     >>>> was where the list originally came from.
>     >>>>
>     >>>> I thought that nickname was used by RP for that.
>     >>>>
>     >>>> looking at the spec the example of shorting Michael to Mike
>     may be
>     >>>> slightly misleading, In my case my nickname is "ve7jtb".  The
>     other
>     >>>> potential issue is that we don't preclude spaces.
>     >>>>
>     >>>> Is there a need for a separate claim that is a single string not
>     >>>> including spaces to be used as a local user name.
>     >>>>
>     >>>> There is also the question of encouraging local user names.
>     >>>>
>     >>>> John B.
>     >>>> On 2012-05-16, at 10:45 AM, Justin Richer wrote:
>     >>>>
>     >>>>> I might be missing it, but it seems that there's a gap for
>     >>>>> specifying a user's preferred local username in the User Info
>     >>>>> schema. This is distinct from "user_id" which is a guaranteed
>     >>>>> unique identifier, "name" which is the actual name of the
>     person,
>     >>>>> "nickname" which is a shortened first name, or anything else
>     that
>     >>>>> I can see.
>     >>>>>
>     >>>>> Is there a specific reason for this omission? If not, I'd
>     like us
>     >>>>> to add in a standard claim for this information.
>     >>>>>
>     >>>>> -- Justin
>     >>>>> _______________________________________________
>     >>>>> Openid-specs-ab mailing list
>     >>>>> Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     >>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>     >
>     > _______________________________________________
>     > Openid-specs-ab mailing list
>     > Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>     >
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/e3a16683/attachment.html>


More information about the Openid-specs-ab mailing list