Yeah, this is something that would need to be defined and included in the final RFC: Sigstore itself is flexible in terms of allowing multiple identities (or even threshold schemes, although that's probably not desirable in this case), so the integration point needs to decide how/whether it allows that.
For something like crates.io, I can see a few reasonable approaches:
- In
crates.io's own account settings page(s), allow users to enable their verified email address as a signing identity. Supplementally, allow users to configure multiple verified email addresses, a la PyPI (although this might require larger changes tocrates.io). - Add a package/crate configuration view for each uploaded crate, where crate owners can configure accepted signing identities. This allows multiple owners to coordinate on valid signing identities.
- Develop a notion of "trusted metadata," e.g. for the
package.repositoryandpackage.authorsfields. In this case, these fields would be considered valid signing identities, under either a TOFU scheme (first upload tocrates.iodetermines that they're trusted, subsequent changes need to be manually validated on the website) or a fully manual scheme (first upload tocrates.iodoes not expose any associated signing materials until the user logs into the website and explicitly marks one or more identities as valid).
We're still working out the best choice (in terms of UX) for PyPI, so I expect that cargo and crates.io will be able to glean some decisions from what we end up doing 
.