Controls should be less prescriptive and less focused on specifics of Github, etc.

[JustinCappos]

My view is the baseline is too focused on assumptions that the projects are using Github, etc. and are less flexible than they could be about other ways to meet the same security properties. This has the potential for us to bake in a lot of things that don't make sense into the future and also be seen as pushing projects to specific vendors.

For example:

OSPS-02 1 Access Control The project's version control system MUST restrict collaborator permissions to the lowest available privileges by default.

Looking at this, I think what is meant is that one must set Github's collaborator permissions in a specific manner for a repo. However, other version control systems may not have this exact way of setting permissions. In gittuf, there isn't a central place to set collaborator permissions, but this is intertwined with functionality that this is found in places like the CODEOWNERS file for Github. I've heard from the group discussions that the intent with this rule isn't to require CODEOWNERS / file access permissions on the repo itself / blocking read access to different repos, or similar functionality, but this isn't clear enough from this statement, since these permissions are all available and could be set this way by default.

A focused question is what are "collaborator permissions" outside of the context of Github? What does this mean for a vanilla git repository?

My suggestion to fix this is to give an example for each control about what you're trying to achieve and to explain the purpose rather than being so prescriptive.

[TheFoxAtWork]

+1 - the Collaborator definition may be the appropriate place to expand on this.
perhaps:

projects MUST define permissions to the lowest available privileges by default for their version control system

[david-a-wheeler]

+1. I've started trying to help do this, but it will require multiple eyes.

Sometimes it's just terminology, e.g., GitHub says "pull request" while practically everyone else uses the term "merge request" for the same idea. But the bigger problem is when things fundamentally work differently to achieve the same result. I often try to use the Linux kernel as a counter-example; it's very widely used, but it does things differently (due to scale), and considering it can help us focus on the objectives instead of being overly prescriptive.