I'm not 100% sure it should be config or just an attribute of the IdentityProvider (it should not be configurable for the JupyterHub class, for example), but the idea makes perfect sense.

There are implications around the display name, because if it's totally unrestricted, that means users will be able to impersonate each other. I guess that's okay for anonymous access, though.

Does it make sense for the IdentityProvider to specify which identity fields can be set? For example, color should probably ~always be settable, username never, display name and avatar_url will depend on the implementation whether they should be allowed or not. Then a PUT or PATCH to /api/me to set one or more fields?

Thanks @MinKR for your feedback.

I'm not 100% sure it should be config or just an attribute of the IdentityProvider (it should not be configurable for the JupyterHub class, for example)

Does JupyterHub provides its own IdentityProvider ? Can we assume that the default one (it seems to be PasswordIdentityProvider) is the one used when there is no authentication system ?

There are implications around the display name, because if it's totally unrestricted, that means users will be able to impersonate each other. I guess that's okay for anonymous access, though.

I was assuming that there is no guaranty about the identity in this use case, but it's mostly in collaborating context. If there is a need for guaranties, then we should use an authentication system.

Does it make sense for the IdentityProvider to specify which identity fields can be set? For example, color should probably ~always be settable, username never, display name and avatar_url will depend on the implementation whether they should be allowed or not. Then a PUT or PATCH to /api/me to set one or more fields?

Can you see situations where some field should not be set while other could, except for the username ?

Does JupyterHub provides its own IdentityProvider ?

Yes, it does.

Can we assume that the default one (it seems to be PasswordIdentityProvider) is the one used when there is no authentication system ?

Approximately, yes.

Can you see situations where some field should not be set while other could, except for the username ?

Yes, often display name should not be set, and in general any fields the IdentityProvider itself understands (likely avatar url, name, possibly initials) or has a source of information for should not be settable. But fields that are specific to Jupyter (like color) are rarely going to come from the identity provider, so should be fine to leave settable. A list/set of readonly (or writable for the inverse) fields on the identity provider might suffice.

To be clear, I'm not arguing against setting any fields, just making sure we do this in a way that IdentityProvider implementations and/or config have control over which fields are settable. E.g. one might want to use the default IdentityProvider while preventing spoofing by limiting display names. Maybe that's config, maybe it requires a subclass, but whatever it is, it should still be possible.