Hey, thanks for opening this. To confirm, these tokens represent user identity (email), and not a machine/CI identity? Context: https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#requirements-to-support-signing-with-cicd-workload-identities

This is a straightforward change if so. Can you add a configuration under federation/external, and update config/fulcio-config.yaml? Type will be “email”.

If this is a ci identity, there’s more work to do which we can chat about, but I don’t believe it is.

We also have a list of requirements for new providers, it’s a WIP but if you could, can you take a look and answer these questions - #397

One more question: is this something that will be automated or where a user is present? I ask because we have two options for where to add the new provider. One is directly in fulcio’s configuration, what I noted above. The other option is in our federated identity provider, but this initiated an OpenID Connect authentication with the user, which requires user presence.

Thanks @haydentherapper , I'll try and answer the questions as best I can, but I'm a user of Gitpod trying to help the project move along, rather than a member of it's development team.

The idea is to have all commits within Gitpod signed automatically by the user who has the session open, without any additional work by that user. Because the user has already logged into Gitpod and authenticated with their chosen IDP, it stands to reason that they do not need to reauthenticate again just to sign their commits. The session they are in should be enough.

Gitpod is a web IDE, not a CI platform, so the user will be present. That being said, we want to avoid any additional UI interactions like a redirect to DEX if we can help it (we could do that now if we wanted). Gitpod has already authenticated the user and will provide a JWT token of the Email type so that Fulcio and Gitsign can validate it.

if we get this right, then any user coding in a Gitpod workspace will automatically have all of their commits signed, which from an industry supply chain attack perspective is a massive win, given the huge number of users on Gitpod. The reason I'm advocating for this strongly is because I am a big proponent of good security by default for as many users as possible.

I'll take a look a look at the config file update, and we can discuss any additional questions on Gitpods viability in the MR.