A general suggestion to everyone working out the details of a namespacing proposal – you should create an FAQ in whatever RFC becomes of this. This discussion here is quite long and high-velocity, making is difficult to keep up with all the changing details.
I would guess the most commonly ask questions would involve existing crates with hyphens in their name.
The fact that GitHub doesn’t care about names and allows renames means it’s infeasible for cratesio to track names on GitHub. It can perform a one-time copy of the name and then associate GitHub org id with that name.
So:
Register GitHub org “foo”
Register cratesio namespace “foo”
Rename GitHub org “foo” to “bar”
Cratesio can’t handle renames, so it keeps the name “foo”, but still has to allows the “bar” org to manage it. It’d be silly if rename on GitHub locked org out of their packages, and matching by name would be insecure because someone else could rename to “foo”.
And there’s a question whether renamed “bar” org on GitHub is going to be allowed to register “bar” namespace on cratesio. It’s using that name on GitHub, but if it can register more, then that’s one org to many namespaces mapping. If not, then the “bar” they want is impossible to register.
So in the end it seems that the best cratesio can do is to have the same level of indirection between GitHub orgs and namespaces as it has between crates and GitHub orgs: the namespace, like crate, is an independent entity living on cratesio, and GitHub orgs can be added to it to manage it.
In this model, can an individual user be registered as a crates org?
I think it might be useful to create “Corgo” that translates a [package.metadata.org-dependencies] into “real” (git? path?) Cargo dependencies as a proof of concept. It’d be useful to have something to point to and say “hey this scheme actually works”. (If my “pun” name isn’t desired, cargo org or similar works too, ofc.)
Then, after the first crate publish, would there be any further check of the domain?
I just realized that this could be a one-time check. At first cargo-publish of the crate soc.github.io:utilities, that crate is created on crates-io, iff ownership of soc.github.io is confirmed.
After initial publish, this org key is only used to identify the crate in question, and the accounts with publish permission is handled as it is today. The domain ownership key can even be removed, as its only use was the one-time association.
My understanding of your proposal is you’re suggesting crates.io users do the following to register an organization:
Register a domain
Configure a web server (for the following two items below)
Perform AuthN against crates.io via what is effectively X.509 DV
Publish organization membership via a file served from the domain (via HTTPS I assume? so they’ll need an X.509 certificate as well)
Regarding your earlier comments above complexity, the above seems relatively complicated to me, especially when the user’s goal is merely “create a crates.io organization and publish a crate”.
Furthermore this provides relatively poor UX, and additional attack surface versus just using the IdP crates.io already uses (i.e. GitHub).
Where GitHub provides a point-and-click experience with strong authentication (e.g. U2F) and active monitoring for suspicious activity, the method you’re describing requires a lot of backend sysadmin work solely for the purposes of authenticating an identity with crates.io.
I would personally prefer the point-and-click experience.
While I'm sure this is all wonderfully intuitive to you, I would not consider that a good user experience for what is fundamentally an access control management tool.
You're also kind of missing the point re: "active monitoring for suspicious activity". The kind of interesting authentication and access change events that GitHub monitors for in its own account system are oblivious to changes you're making in a text file...