Document / standardize a common process for onboarding Trusted Publishing platforms

[voxpelli]

Following on the npm security announcements and its discussions there is a common concern (see eg. this comment) that the number of platforms supported for Trusted Publishing by npm is limited to just GitHub and GitLab right now.

When reading through the Trusted Publishers for All Package Repositories document there is no clear guidance (or I missed it) for:

1. How to make a publishing platform eligible to become a Trusted Publishing source
2. What a package registry like npm, PyPi etc typically should consider when onboarding new Trusted Publishing sources (or whether they eg. can / should / may allow any compliant source to be a Trusted Publishing source)

Specifically I think there is a lack of:

• A standardized / recommended set of attributes for the JWT claims, beyond the mere descriptive one in Identity Providers and Claims
• A standardized / recommended / generic set of "workflow file" paths and "environment name" definitions such as the ones used by npm for GitHub and GitLab right now.

Disclaimer: I'm a bit outside my area of expertise here but I want to kickstart the conversation and help bridge the gap.

[miketheman]

2. What a package registry like npm, PyPi etc typically should consider when onboarding new Trusted Publishing sources (or whether they eg. can / should / may allow any compliant source to be a Trusted Publishing source)

Here's PyPI's guidance: https://docs.pypi.org/trusted-publishers/internals/#how-do-i-become-a-trusted-publishing-provider

[di]

Yeah, I think we probably could just up-level PyPI's guidance here, since nothing is really specific to PyPI there.

One thing I'll call out:

A standardized / recommended set of attributes for the JWT claims

I think there isn't really a "standard set" of claims to recommend. Not every publisher looks like GitHub/GitLab where there are source repositories and workflow files. E.g. when supporting Google Cloud, there aren't very many "custom" claims at all aside from one that corresponds to the service account being used for the workload.

[voxpelli]

@di Maybe a single standard set can't work, but perhaps one or two recommended ones could?

Currently the "3. Reasonable OIDC claim set" in the PyPi isn't very helpful for a new platform that wants to implement something that can be supported by all the Trusted Publishing registries and moving to an actual spec for Trusted Publishing where it can be something that both publishers and registries can become compliant with – that would open things up much more and essentially just leave what @woodruffw mentioned in this related thread: pypi/warehouse#15838 (comment)

Trusted publishing offers diminishing security returns for smaller IdPs: a big part of the security model/value for trusted publishing is the idea that each trusted IdP is large, has on-call staff, has key revocation/rotation policies that they can apply in the event of an emergency, etc. These might be true for smaller IdPs as well, but they're less guaranteed. In the setting of smaller IdPs, IMO manually configured API tokens actually provide better security properties (since revocation of publishing credentials doesn't potentially require handling a rarely-interacted-with internal IdP service).

Eg: if something like tangled.sh or such would want to implement everything technically from their side so that only the trust aspect would remain, that would be benificial I think.

[di]

Sure, I think we could imagine something like "here's the set of claims we would expect from a source repository, here's the set of claims we would expect from a cloud provider", etc, but I think the actual set of claims would still be very dependent on the behavior/functionality of the provider in question. E.g., for something like Spindle, we probably would want to include a claim for the server owner's DID as well as the hostname, which would be unique for that provider.

As an aside, there's another consideration with self-hosted instances as well that we (PyPI) are currently working through with GitLab that is not mentioned here, which is that supporting self-hosted instances essentially means adding a new IdP per instance. However, since each instance is only really used by a very small subset of users and is not generally available, we additionally need a way to scope a specific IdP to a specific set of users.

[woodruffw]

Maybe a single standard set can't work, but perhaps one or two recommended ones could?

Unfortunately I don't think this works in practice: Trusted Publishing as a design intentionally keys off of unique facets from each publisher provider (IdP), meaning that the identity model of each provider intentionally bleeds through.

For example, it might be tempting to abstract both GitHub and GitLab as having a org/repo slug and a workflow filename, but this abstraction breaks down quickly: a GitLab slug can also contain group components, and the two have totally different filename rules for workflows. And naturally they use different claim sets to express these differences 🙂

There's also a contextual aspect: the set of providers that make sense for one ecosystem don't inherently make sense for others: a supermajority of CI publishing activity on PyPI comes from GitHub, but for another ecosystem it might be another publisher (including one that's bespoke to that ecosystem).

Overall, I agree with @di here: I think we could generalize what PyPI says as a reference point, but the actual minutiae of claims and provider suitability are too implementation and ecosystem specific respectively.