Propose the concept of a crates.io username for identity

[carols10cents]

This RFC introduces the concept of a crates.io username separate from GitHub (or any potential future OAuth provider) usernames to be able to support multiple OAuth providers someday and adequately handle potential username collisions.

Introducing the concept of a crates.io username in the back end of crates.io and in the user experience is a prerequisite to eventually offering multiple OAuth providers.

Important

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.

Rendered

[Diggsey]

Looks very well thought out.

Should there be a limit to how frequently one can change one's username? (Considering the old name will be reserved from some period of time)

Also I think there should be some way to revert a change of name if it's within the reservation window (ie. the old name hasn't been freed up yet) in case the rename was a mistake or the account was compromised.

[carols10cents]

@Diggsey And I'd be fine adding here that we will allow the person who previously had a name to "revert" to it within the period of time that the username isn't allowed to be used-- I'm torn on whether we want to build in a mechanism for users to be able to do the revert themselves, or have it be something admins could do after emailing us to see how often it's needed. 🤷🏻‍♀️

[DrFrugalOfficial]

Hey, I just read your RFC, and I have something on my mind.

Since there is already a refactoring happening, it might be quite beneficial to switch profile URLs to use the ID instead of the username.
Because renaming is a feature that is already planned, this would make links safe against link-rot.

From your example in the markdown, this would mean this old URL
https://crates.io/users/carols10cents
would become
https://crates.io/users/396

The downside of course is that any URLs that already exist on the internet might break.
One might argue, that there will certainly be a subset which breaks, once a user renames his account.
A very good compromise would in my eyes be switching to the ID for the URLs and use them in the UI (Owner link in a crate), but support legacy URLs, by trying to resolve/forward to the corresponding profile with that user name.

Yes, this is a bit of overhead of course, but it would prevent malicious actors creating a crates.io account with a name that got available again.
If there exist URLs to that user's profile from back then, it would now point to this new entity, instead of the account before.
It is less dangerous than doing the same thing with crates directly, but I see it as a form of proxy social engineering, which could be exploited.
Example: there is a well known developer and people link to his profile with remarks like "look, he has a lot of high quality crates, you might find what you need for your project there".

You can decide yourself, if it is worth the hassle.

[DrFrugalOfficial]

Second thing that came to my mind:

It might make sense to run the script to initialize the new login user name in at least 2 batches.
The first one targeting active users which maintain a crate, or have logged in with in the last year, or....
The second one everyone else.

There is probably no 100% clean and correct solution for the name collision dilemma.
It would give people the chance to take their proper user name, if their intended one was taken due to GitHub/crates.io name squatting.

The downside being that it would de-prioritize accounts without crates, or which have not been online in a certain time.
You can decide yourself, where the priorities lie.

[tgross35]

View changes since the review

I'm sure this has been covered but perhaps worth documenting, what's the reason to not use email as the identifier? From a user perspective it's nicer to have one thing to remember rather than possibly needing to do "forgot my username".

Maybe at least it could be possible to log in with an email address rather than the associated username even if one does exist?

[programmerjake]

two reasons I can think of: you may not want your email address to be public, and what happens if you lose/change your email address but wanted to keep the same username?

[PuercoPop]

emails are not a good identifier to use for user identity. People change emails over time.

Which is why most sites/login systems let you change your email (or even register more than one to the same account)

[Turbo87]

Also email addresses are not public on crates.io and if we turned them into identifiers all of a sudden that would be a massive GDPR breach 😅

I think ultimately it's also for legacy reasons, since we want to stay compatible with the current chosen names.

[tgross35]

Yup that's all reasonable. Just think it may be worth documenting.

Also email addresses are not public on crates.io and if we turned them into identifiers all of a sudden that would be a massive GDPR breach 😅

They need not be public; identifying by numeric ID should be feasible (as a commenter above mentioned). Crates.io can show the name and/or linked account names for a given ID if available.

[Turbo87]

I don't know about you but I'd rather be known by a proper name than a random number. I think this would also have security implications since typos would probably become more common etc.

... and please don't suggest UUIDs now 😅

[Mark-Simulacrum]

View changes since the review

Am I correctly interpreting that this means we don't surface a warning until crates.io learns of the new user? That seems potentially confusing, especially in regards to being asked to add people as owners.

This also seems like it interacts poorly with the impersonation attack prevention, since the crates.io UI would then actively mislead people into thinking they have the right user.

Is this a technical limitation (e.g., we don't have enough rate limit budget to continually ask GitHub for user IDs)?

[Mark-Simulacrum]

View changes since the review

Does it seem useful to flag prominently that a username was renamed, even if we don't show the before/after names? Relatedly, perhaps we can prevent adding users that were renamed to/from for a holding period (e.g., 1 day), to give time for us to detect impersonation and slow down attacks of that nature?

[Mark-Simulacrum]

View changes since the review

Maybe related point: it would be worth considering if GitHub:1233 should be accepted, to allow unambiguous addition/removal of GitHub users without a race condition against renames

(E.g., rust-lang/team could conceptually use this for its syncing, though we're moving away from having any users other than the bot rust-lang-owner account on our crates).