Add username attribute to profile response

reiterate-app commented 2 years ago

There are many contexts where a short, memorable username is appropriate, and a full legal name or long profile URL won't work for either privacy reasons, length, or memorability. More than one user has become confused seeing their Profile URL used to display their identity on an IndieWeb site.

I propose that in addition to the existing name, url, email, and photo fields, a username field is returned by the authentication endpoint as part of the user profile. The client would then be free to use this username for display purposes, while still keeping a record of the profile URL as the actual, unique identifier for that particular user.

The username response is actually already a part of rfc7662 and seeing as the recent IndieAuth discussions have been moving towards compliance with that spec, this would bring it a little closer.

aaronpk commented 2 years ago

I would prefer to use the name nickname rather than username for two reasons:

nickname is in the h-card vocabulary which is actually where the current name, url, photo properties came from
username implies that it is unique, since most websites will not let two people use the same username. Since this property would not at all be something guaranteed to be unique, I wouldn't want people to accidentally assume it is, and then create problems for them down the road when using it. nickname on the other hand is more clear that two people may use the same nickname.

It is of course up to the consuming website how to use this value, but I would guess that more people would naively treat username as a user identifier in their internal system. Instead it needs to be clear that this value is for display purposes and is not guaranteed to be unique and should not be used as a user ID.

reiterate-app commented 2 years ago

I would be fine with nickname. I mainly picked username to match rfc7662.

as far as uniqueness goes, I feel like it would be nice if nickname/username were unique for each endpoint, although of course there’s no way to guarantee uniqueness on the client side. I don’t have a strong case for that, just an intuition that it would be a nice constraint to have.

reiterate-app commented 2 years ago

Here is an argument for requiring uniqueness on the authenticating endpoint: if the client wishes to display a unique username, but that username is already registered with that particular client, the the client can use “username@example.com” as a guaranteed unique identifier to display.

dshanske commented 2 years ago

@aaronpk I thought we also modeled the profile scope on OpenID, which I think also uses nickname. https://openid.net/specs/openid-connect-basic-1_0.html#StandardClaims

Zegnat commented 2 years ago

Was this not what name in the profile was supposed to be? To quote @aaronpk’s answer from #31 where I mentioned using nickname instead of name:

The mf2 (and jf2) property "name" is already a display name. No need to change it to "displayname", […]_

As I understood it then, the unique identity for the user should be their URL, and the “memorable username” should be the name field provided by their endpoint. Has something changed in how people are implementing it that now warrants adding another field? How is the use-case different?

reiterate-app commented 2 years ago

Has something changed in how people are implementing it that now warrants adding another field? How is the use-case different?

What changed was that someone (me) actually implemented the spec. I wrote Authorio, an IndieAuth endpoint implementation, and I believe it was the first in-the-wild implementation that returned actual profile data.

When I did so, I tried to use the spec to determine what sort of "name" to return. As it is now, the spec is very vague on what the name attribute represents. It gives no definition for it at all, and the only example data looks like this:

  "profile": {
    "name": "Example User",
    "url": "https://user.example.net/",
    "photo": "https://user.example.net/photo.jpg",
    "email": "user@example.net"
  }

Based on that example, I assumed that name was meant to be a full, legal name. This turned out to be problematic for other reasons, so I raised this issue.

At the very least, there is a great deal of confusion here (not just from the IndieAuth spec, but about names in general).

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

What we are attempting to do here is not just naming something, but naming a name, so we are at a meta-level of hard problems 🙄

I've attempted a short survey of the various specs out there and how they deal with user names, and names of names.

OpenID Connect

This defines many different types of names. That's nice because you know exactly what you're supposed to put in each name, at the expense of being somewhat cluttered.

attribute	value
name	end-user's full name in displayable form including all parts
given_name	given or first name
family_name	surname or last name
nickname	Casual name that may or may not be the same as given_name. For example, `Mike`
preferred_username	Shorthand name by which the End-User wishes to be referred to at the RP, such as `janedoe`

Of note here. name is used for legal name. And nickname is used to mean a shortened form of the legal name, not a login or display name.

Also, OpenID also makes very clear how the client (RP) is meant to use these values:

Claims such as email, phone_number, and preferred_username and MUST NOT be used as unique identifiers for the End-User.

OAuth 2.0 Token Introspection

attribute	value
username	Human-readable identifier for the resource owner who authorized this token.

This is a little vague, but the spec goes on to give an example which puts it in line with preferred_username of OpenID:

{
      "active": true,
      "client_id": "l238j323ds-23ij4",
      "username": "jdoe",
      "scope": "read write dolphin",
      "sub": "Z5O3upPC88QrAjx00dis",
      "aud": "https://protected.example.net/resource",
      "iss": "https://server.example.com/",
      "exp": 1419356238,
      "iat": 1419350238,
      "extension_field": "twenty-seven"
     }

Microformats 2

attribute	value	example
p-name	The full/formatted name of the person	Sally Ride
p-given-name	given (often first) name	Sally
p-family-name	Family (often last) name	Ride
p-nickname	nickname/alias/handle	sallykride

Of note, name is used consistently with OpenID and OAuth 2.0, but nickname here is used not as a shortened form of the legal name, but more like the preferred_username of OpenID and username of OAuth 2.0

There's a lot of confusion here. Aaron's reply on #31 said

The mf2 (and jf2) property "name" is already a display name.

But in fact it's not, if we're saying that what we want as a display name is in fact what mf2 calls p-nickname. Mf2 seems to be the "odd man out" with regards to username naming so that makes me a little hesitant to align IndieAuth there instead of with OpenID / OAuth. It's going to be impossible to align IndieAuth with everything, we have to break something somewhere. I would argue with breaking the least amount of existing specs.

Regardless of how this issue is ultimately resolved, I think we can all agree that the spec needs much more clarification with regards to user names / display names, in particular:

What the display name parameter should be called
If there should be multiple name-related parameters
Give clearer definitions for all name parameters
Give good examples for all name parameters, and ensure the examples align with the definitions
Give instructions to the client as to how it should interpret and deal with each name-related parameter

dshanske commented 2 years ago

Decision to address by defining name, url, photo in a PR

dshanske commented 2 years ago

@reiterate-app I believe the recent changes to spec clarifying the definition of the parameters should address your issue. If they do not, please reopen.

indieweb / indieauth