Messages - Username claim

[Former user]

There's no claim in the userinfo endpoint for a user's preferred username on a service. This is semantically distinct from "name", which is meant to be the full display name of the user, "nickname", which is meant to be a shortened form of the first name for display purposes, or "user_id", which is meant to be a server-issued unique identifier. This is intended to be a traditional "username", something user-displayable with no spaces that is generally chosen by the user. While they are often unique within a given IdP's domain, their uniqueness MUST NOT be relied upon, and an RP that supports usernames can make no guarantees for a user to be granted their preferred username locally.

Facebook defines the "username" claim on their graph API's user endpoint:

https://developers.facebook.com/docs/reference/api/user/

Portable Contacts defines a "preferredUsername" claim in their schema:

http://portablecontacts.net/draft-spec.html#entry-schema

I suggest that we use the Facebook form to keep it in line with the rest of the UserInfo schema.

[John Bradley]

Can the user change the value and what must the RP do in that case?

Ignore would be my guess, but we need to be clear or someone will use it as the user_id and then have trouble with IdP that treat it as self asserted.

[Former user]

User might be able to change the value, just like any other asserted fields in the UIE like name or anything else. The RP can choose to try and sync, ignore, or whatever it wants.

We should probably have normative language that says it MUST NOT be used for a unique identifier. That's why I actually prefer the term "preferredUsername" from PoCo as it gives the right weight to it, but that doesn't match the rest of the schema's roots and documentation can probably smooth over potential issues.

[Michael Jones]

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 acocunts. 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.

[John Bradley]

I could probably by into a optional claim from the IdP

local_user_handle , A local alias that the user is known by at the IdP.

That way twitter could send the twitter id.

and Facebook the page identifier etc.

[Former user]

I think there needs to be something along the lines of username somewhere. Looking at the discovery protocol what is the first part of <id>@<idP> suppose to be? Nobody is going to remember or want to use something like [e-mail] , that IMO is just unusable. If the discovery protocol makes use of something like a username then it needs to be a first class citizen as far as the claims are concerned.

[Former user]

I can understand Mike's argument, but I don't think the ideal world maps to reality of today or the near future. Many, many applications have a convenient slot for a "username", even for federated logins. And in hybrid systems that have both local and federated accounts, there's often a need to cram *something* into the username field for basic applicaiton functionality. Aditionally, there's a difference between a unique federated identity (tuple of the issuer and user_id field) that's used for inbound authentication and global disambiguation and a local short-form name that's used for display and local disambiguation. The latter is user facing, user memorizable, and is a long-standard part of human computer interaction.

It should definitely be an optional claim, like nearly everything else, and there should be normative text that tells people not to use it as a unique identifier (like email should probably have, too).

Our deployed system *will* have a username claim field, and our in-house RPs *will* depend on it when talking to our IdP. I would imagine that many other IdPs will do the same. Facebook's graph API already does, as shown above. I'd rather see this standardized in the right place.

[Former user]

I have to say that I do not like the idea of calling it prefered username. Even though there will be language that dictates that it should not be used to uniquely identify a user the term preferred makes it sound as if the user would have more than 1 username , or even possibly that there would be multiple users with the same username at an idP.

I think ideally the constaints on this attributes should be a username MUST be unique to an idP at a given point in time and that a user MUST only have 1 username at an idP at a given point in time.

I dont see why an idP cannot make user_id and username synonymous as long as they dictate that a username will be a unique and enduring attribute the user. You will also need to think about this as to how it plays with pairwise user_id's too. If the goal of pairwise is to prevent tracking of users than username contradicts that goal.

[Former user]

The two fields are very different in both intent and use: Usernames might be reassigned over time, user_ids shouldn't be. Usernames might change for a particular user over time, their user_id won't change. My company does recycle and change usernames, for instance, but our identity systems generate a unique identifier for each person that is stable regardless of the state of their username. This value is a long string on numbers and dashes that you don't ever want a person to have to deal with directly, but it's guaranteed unique.

If you're doing a pairwise user_id and you're allowing *any* personally identifying claims out the door, including your full name and email address, you're doing it wrong.

It comes down to managing usability. At the end of the day, no matter how you get in the front door, in the vast majority of applications you're going to map that session to *some* record in a database somewhere local to the application that says "this is the user that I'm talking to". What the "username" field says to an RP is "If you have a place to put a 'username', this is the value that I'd like to have in it." If I'm logging in to StackOverflow, I don't want to be id-239423-gfa-321-fasd, I want to be jricher. If I can't be 'jricher' at StackOverflow because there's already one there, that's fine, I have to pick another username. Passing this field over doesn't guarantee anything, it's just another name that I'd *like* to fill out my profile on a system. But my username there does not affect my ability to log in using id-239423-gfa-321-fasd from my IdP, since I don't use it as a unique federation identifier and changing it at my IdP doesn't change what I'm showing up to the RP to authenticate with.

I haven't seen the same arguments being leveled against passing an email address claim, even though some systems have a unique email address requirement for their user accounts, emails may be unstable over time, and there's probably just as much of a draw for developers to use this as their primary key as a username does.

[Casper Biering]

I completely agree with Justin on this issue.

[Former user]

I would greatly prefer to reuse either the PoCo "preferredUsername" or the Facebook "username" claims instead of an openid-specific "local_user_handle" for this. In the PoCo case, it's telling the RP "this is what the user prefers to be known as". In the Facebook case, it's saying "this is the username of this user here at the IdP". Both of these are valid interpretations of the claim, and the RP should treat it like any other claim on the UserInfo Endpoint.

[Michael Jones]

The working group believes that, if we add something like this, it should be the local_user_handle proposal by John - not a preferred username. This has the advantage of likely already being present at the IdP, rather than requiring that users fill in one more field that they are likely to not understand at the IdP. The working group would like comments on that approach.

Also, the syntax restrictions would have to be defined. For instance, ASCII-only? Printable characters only? No slashes or backslashes? Letters, numbers, underscores, dots, dashes? Pluses? This matters for interop. Specific proposals requested.

[Former user]

I think there may have been some confusion about my arguments for this field above. I think we should treat "username" just like "name", "nickname", and similar fields. It should be an optional field with reasonably defined semantics that has no guarantees of uniqueness, stability, or fitness for use in the RP.

I strongly disagree with the above assessment that "local_user_handle" is the right name. Both John and I are talking about the exact same data being put in this field -- something that's likely already present at most IdPs. From the IdP's perspective, it is the "username". As far as the profile of the user at the IdP is concerned, which is what the UserInfo Endpoint is expressing, this value is the "username". From the RP's perspective, it's a "preferredUsername", since the RP may have a different idea of what a username can be, if it even has one. This latter example was largely given since this is what PortableContacts calls the field. Since we're copying facebook with everything else in the schema, and the claim name makes sense, call it "username".

Not all IdPs will fill this in, and that's fine. Not all IdPs will have "name" filled in either, and RPs need be be OK with that.

I believe it's a mistake to call it something new when we already have a label for this piece of information that's in standard use outside of the OpenID Connect world.

I think the syntax restriction is a red herring: since this field is NOT to be used for unique identification of the user and is simply there as a standard place to put a common piece of information, there is no real interop issue with not restricting its format. I would restrict the syntax of the username field only in the same way that other fields, like "name", are restricted: all valid JSON strings are fine. No one restriction set is going to be sufficient to allow all RPs to automatically reuse this value, in the same way that some limited RPs will only be able to properly display someone's full name if it's in ASCII. Some RPs will have tighter or looser character restrictions, such as a minimum or maximum length. We can provide guidance and best practices, but anything we put into the specification is either going to be insufficient, overly restrictive, or otherwise ignored.

[Casper Biering]

Again, I think Justin and Nat (on the mailing list) sums up my perspective/opinion correctly.

[John Bradley]

Facebook as defined it as an alternate user handle that can be used as a ID in the graph API

Alternatively, people and pages with usernames can be accessed using their username as an ID. Since "platform" is the username for the page above, https://graph.facebook.com/platform will return what you expect. All responses are JSON objects.

We should attempt to keep the usage constant with the current use if we are going to re-use the name.

An alternate userid that may be provided by the IdP, it should have some constraints like no spaces etc. I think Facebook limits it to the semantics of a valid path subsegment, as it is also used for profile pages.

John

[Former user]

I'm not vehemently opposed to some of the restrictions, but on the same token I'm not comfortable putting that much weight onto the username claim, and I don't think it should be placed in a special category apart from the other claims about a user.

Here's why: I would consider the Facebook implementation a kind of set of optional restrictions at the IdP side. That is to say, any IdP is free to say that usernames will be unique within their system. They can also say that they match certain character constraints. Other IdPs might disagree what those constraints ought to be. Any RP might still balk at a Facebook username value for a variety of reasons (local conflict, length restrictions, absence) and not be able to use it interchangeably with the (issuer,user_id) tuple that remains the only defined method of globally unique user identification.

If we don't limit the "name" field or give it special precedence, I don't think we should limit the "username" field. This *allows* an IdP like facebook to set its rules up, but doesn't force others to comply and I don't see RP's really losing anything in functionality either.

For instance, our IdP will deploy with a username that's the local part of people's email addresses. This will be unique per user ID, but they will potentially be recycled and assigned to other user IDs in the future (as people leave the company and new hires come on). The username might also change for a particular user ID. Therefore they're temporarily interchangeable but not permanently, and our character restriction is actually based on the email URI syntax not the URL path syntax. But I'm not going to say that these same restrictions should be relied upon elsewhere. Username should be a convenience field for carrying a common piece of information and not elevated to a special status. user_id should be the only claim given such special status.

Summary of my stance on proposed restrictions:

1. character set: the same as "name" (no promises beyond valid JSON string)
2. string length: the same as "name" (no promises beyond valid JSON string)
3. uniqueness: might be OK to guarantee temporary uniqueness per IdP, but if IdP recycles than uniqueness is a race condition (like email addresses are today)
4. recycling (new user_id for given username): must be allowed
5. remapping (new username for given user_id): must be allowed

[Michael Jones]

Relying parties could just use the part of the e-mail address before the @ to achieve approximately the same thing. The consensus on the call was that this field is adding more confusion than value.

[Former user]

In list discussions, there was a general consensus to adopt this as a "preferred_username" claim. This is my suggested text taken from that thread:

    preferred_username     string    Shorthand name that the End-User wishes to be referred to at the RP, such as 
                                         "janedoe" or "j.doe". This value MAY
                                         be any valid JSON string including special characters such as "@", "/", or whitespace. This
                                         value MUST NOT
                                         be relied upon to be unique by the RP. (See § 2.3.2.2)
    email             string    The End-User's preferred email address. This value MUST NOT be relied upon to be unique by
                                      the RP. (See § 2.3.2.2)


    == 2.3.2.2 Claim Stability and Uniqueness

    The user_id claim is the only claim which a client can rely upon to be stable, since user_id claim MUST be locally unique and never reassigned within the Issuer for a particular End-User as described in § 2.1.1. Therefore, the only guaranteed unique identifier for a given End-User is a combination of the Issuer's identifier and the user_id claim, and other fields such as preferred_username and email MUST NOT be used as unique identifiers for a given End-User.

    All other claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use a given preferred_username or email address claim across different different End-Users at different points in time, and the claimed preferred_username or email address for a given End-User MAY change over time.

[Former user]

Oops, didn't see that Nat had opened #603 to capture this, closing again.