Identifiers and Usernames

This is a follow-up to my previous post Thoughts on IndieAuth Profile URLs where I objected to the use of Profile URLs in user-facing interfaces. I invented a distinction between what I termed user-facing identifiers and backend-facing identifiers, and claimed that Profile URLs belonged in the latter category and therefore shouldn’t be shown to users.

In Identifiers and Usernames, Ian Glazer makes a similar distinction, but his terms are internal and external identifiers. Internal identifiers are for systems, and they are how backend systems refer to digital identities. External identifiers, otherwise known as usernames, are for people.

Mr. Glazer feels even more strongly about usernames than I do. In particular he says:

Failing to consider identifiers, and especially usernames, can have direct, negative impacts on the projects and systems you are working on.

People feel strongly about their usernames. Which is why I feel IndieAuth should have strong support for usernames. If an endpoint returns a username to a client, that client should make the best effort to display that username anywhere it references the user in a UI, and not show the profile URL.

This depth of emotion works against my proposal as well, unfortunately. Because when IndieAuth was first written, it didn’t have profiles. Being geared towards people who felt at ease purchasing their own domains and setting up their own sites, IndieAuth took the approach that “you are your domain.” There’s a large subset of IndieWeb people who identify with their domain and feel that the domain name is the ultimate end point for IndieWeb identity.

I don’t want to take domain names away from people. If you associate with a domain, you should be able to continue to do so, by making your username your domain. My concern is for the people who don’t own their own website, who are using IndieAuth’s ability to authenticate multiple users per domain, and to give out profile information for the users it authenticates. Those people should be able to pick a username and not be saddled with a URL.

The Five Guiding Principles

Glazer then continues to expand upon usernames, and lists five principles that guide how good usernames are made. I feel it’s instructive to consider each of his principles in regards to IndieAuth.

Not Secret

A username can’t be secret. This seems obvious, but the best counter-example to this is the US Social Security Number. Originally designed as a means to track people’s wages, it grew to become default username. It’s less common now, but there are still some sites that ask you to login via your SSN. Since your SSN is linked to all sorts of personal data, this is a privacy disaster waiting to happen.

Internal identifiers often contain some sort of secret data. For example, Twitter’s snowflake contains a timestamp. The timestamp corresponds to when your user account was created. Do you care if people know when your account was created? I’m not sure, but it feels kind of iffy to me.

With respect to IndieAuth profile URLs, the secrecy of that identifier depends wholly on the endpoint’s implementation. It would be easy (and potentially time-saving) for an endpoint to encode secret data into its profile urls, making them more like secret data and not proper user names.

Public

In Mr. Glazer’s terminology, public data is data that is freely shared across organizational boundaries. I don’t see this as being a concern for IndieAuth, since the URLs which serve as identifiers are already shared with a well-known scheme. However, the structure of a URL does make it somewhat less convenient for sharing (at least, compared to the common username).

Memorable

Usernames need to be memorable. Profile URLs fail utterly in this regard.

People don’t like to took at URLs. They’re really designed more for machines than for humans. There’s been a trend in browser interfaces lately, where the URL at the top of the browser window has been slowly going away. I think that’s because it’s just screen clutter. No one really cares what the full URL of the site they’re current browsing is. And no one can certainly remember their browser history.

One key aspect of memorability is self-determination. If you create your own username, you’re much more likely to remember it. A username that is made for you, according to some proscribed format, is less memorable.

I would like to see a system that allowed any user to pick any username they wished. With IndieAuth, that’s possible, assuming that user names are respected by the clients. Additionally, there’s a potential conflict with the next Principle…

Uniqueness

User names must be unique. But Mr Glazer brings up a valuable point: unique with regards to what scope? Considering the scope brings the question of uniqueness into sharper focus.

A username could be unique to a service, to a namespace, or to a family of services. You can also try and make a username unique to the entire world (a la SSN).

IndieAuth usernames occupy an interesting space in regards to this principle. Their uniqueness is negotiated between the client and endpoint.

What I mean by that is that user name uniqueness can have the “best of both worlds.” Let’s say a user sets up an identity on an authentication endpoint. That identity comes with a username, and the user has complete control over that name. There’s no uniqueness constraint as far as the endpoint is concerned: having multiple profiles with the same username is not a problem, because their internal identifier is still the profile url.

When the user wishes to authenticate with some service, that service can and should impose some sort of uniqueness constraint on the username. As long as it’s easily recognizeable, I don’t see that as being a problem. User names are unique to whichever service the user authenticates with.

It would be nice if the IndieAuth spec had some suggestions as to how a client could uniquify and represent unique user names.

Recoverable

Glazer’s last property is that user names need to be recoverable. This is an issue with all authentication schemes and IndieAuth is no different. It’s interesting to look at the difference between domain-identity IndieAuth and URL-identity IndieAuth. For the multi user case (which is what I have been focusing on), an authentication endpoint will have all the recoverability issues that any typical authentication service would have to deal with. But if your identity is your domain, I think most of those problems would go away. For those who use a domain as their identity, it’s much more difficult for them to lose that domain. That’s a point in favor of domain identities.

Conclusions

I’d like to see IndieAuth evolve its thinking as far as user names goes. Currently, the spec only mentions them in passing, and there’s a fair bit of confusion as to how user names are meant to be used within IndieAuth. Some of this is just because it’s all new. As far as I know, my IndieAuth implementation Authorio was the very first implementation that actually served user names. Until then, user names were just domain names, or worse, profile URLs.

The spec continues to evolve, though, and I have hopes for its future direction.