OIDC API Key Role RFC

[segiddins]

RFC for https://github.com/rubygems/rubygems.org/pull/3716

[indirect]

This is a great start! The motivation section does a great job with "why", and the guide section does a great job with "what". I think most of what's in the "guide" section right now is actually implementation/reference details, and the guide should be something like "You are a RubyGems developer with MFA enabled, and you want to automated publishing gems. Here's how you do that: Step 1, 2, 3."

For reference/comparison, here is the PyPi parallel effort, called "Trusted Publishers":

• Announcement blog post: https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/
• Internal details docs: https://docs.pypi.org/trusted-publishers/internals/
• End-user documentation: https://docs.pypi.org/trusted-publishers/
• Implementation code: https://github.com/pypi/warehouse/tree/main/warehouse/oidc

If it's easier to compare/contrast using the Python version as a base, that seems reasonable.

[segiddins]

@indirect is what I added what you have in mind?

[indirect]

Yes! I think that's close enough to discuss and approve the overall idea. 👍🏻

To ship the implementation as completed, I think we'll need the "guide" to be a bit more fleshed out, including the actual steps that are needed. For example, what are the gem publishers supposed to do with the example JSON documents? Where does the ID that they supply to the GitHub Action come from? etc. Feel free to either flesh out the guide here and then copy it into the docs later, or include the more complete docs alongside the implementation once you are more sure about how it will work.

[segiddins]

including the actual steps that are needed

I think I included that? To start with, I plan on shipping the OIDC work without a public facing UI, which means the way to get set up will be through an admin using the admin interface.

Once we have some beta users and confirm the implementation (and with it, associated data structures) works for all involved, I was planning to build a UI at that point.

If that doesn't work for you, then I have to go back and build all that now, which will delay getting the core implementation released.

[indirect]

It's fine to ship it for testing with manual setup by maintainers. :+1: I just mean the actual docs, even if setup is manual by admins, will need to explain more granular detail about e.g. how to get the ID you put into the GitHub Action config.

[segiddins]

Would it be better if i changed it to use the provider URL instead of the ID, and added in a unique index on the URL?

[indirect]

I'm not sure, but probably, if that makes it clearer what the config value is for?

[segiddins]

OK never mind, I mis-understood. We end up using the ID because we need something to look up that uniquely identifies the API Key Role, without a priori being able to scope to a user.

I suppose we could do something like a user-supplied label that is combined with the account handle? But that's not great since the handles can change...

I think using the ID is fine for now. You will get it back (eventually) when you POST to create the API Key Role, you can find it when GETing the list of the current users API Key Roles, etc.