We need a process flow for specs to become standards

[camaleon2016]

We need a process for a spec created in a Project to become a standard. We can build out what this looks like, but there should a way for the TAC to be kept in the loop properly as spec go before any standards process.

[lehors]

To be clear: this is about submitting an OpenSSF specification to a formal standards body such as JTC1.
I agree that we should decide what approval this requires. I don't know that we need to have a complicated process but this should at least have the approval from the TAC.

[sevansdell]

related: #337? two opportunities for improving tac process documentation related to specs.

[SecurityCRob]

has there been any progress on this issue?

[SecurityCRob]

Jory will be visiting us on 3Sept to discuss this and how we can move forward together on Standardization!

[SecurityCRob]

There are currently 4 specs that we should consider going through the standardization process:
1.) SLSA - https://github.com/slsa-framework/slsa
2.) sigstore - https://github.com/sigstore/
3.) OpenVEX - https://github.com/openvex
4.) OSV - https://github.com/ossf/osv-schema

[david-a-wheeler]

The EU typically prefers international standards. The EU's CRA has given many organizations an extra reason to be interested in formal standards.

So... I think we're going to see more interest in the days ahead in implementing these processes to convert specifications into international standards. Jory is exactly the right person to talk to about this.

[david-a-wheeler]

The Linux Foundation's Joint Development Foundation (JDF) specifically exists to help turn specifications into international standards. You don't need to re-invent that part (and you don't want to :-) ).

Getting the TAC's agreement that it's ready for the process seems valuable.

[sevansdell]

@camaleon2016 I propose we close this out with a new process TAC page linking to Jory Burson's talk given on 9/3/24 Deck presented. https://docs.google.com/presentation/d/15UDIo_lkf-KO0bU-pA5gAne0IOwy6e96KK057a3HWpg/edit#slide=id.p Will this address this issue?

[lehors]

@camaleon2016 I propose we close this out with a new process TAC page linking to Jory Burson's talk given on 9/3/24 Deck presented. https://docs.google.com/presentation/d/15UDIo_lkf-KO0bU-pA5gAne0IOwy6e96KK057a3HWpg/edit#slide=id.p Will this address this issue?

I don't think so. Jory's slides are useful in that they give a good idea of the path to standardization once we decide to move one of our specs down that way but they do not address the main question this issue is about: how do we come to make the decision that a spec should gone done that path?

I think we need to develop a minimal process establishing how a TI can request to the TAC approval for a spec to be submitted for standardization.

And when I say "minimal" I really mean it. For all I know it might be as simple as saying somewhere in our documentation that TI should put the request before the TAC for approval. :-)

[sevansdell]

@lehors agreed! @camaleon2016 would you be willing to propose some very lightweight decision process language in a PR? Where might this best live in our TAC repo?

[david-a-wheeler]

I propose a simple mechanism: "The OpenSSF TAC votes to convert a spec into a standard". A WG (or project/SIG directly under the TAC) can ask the TAC for such a vote. If the TAC votes "yes", then the OpenSSF is pursuing creating a formal standard.

Creating a standard can be valuable, but is time-consuming, so the TAC should make that call. There's already a process for raising issues to the TAC. This is how we handle other major technical decisions.

[lehors]

Agreed! That fits my definition of "minimal process". :-)
I think we should go one step further and specify that such request should be made by opening an issue in the TAC repo. Once a majority of the TAC members have approved we can close the issue and proceed.
Note: explicitly relying on GitHub for this makes it possible to run such a process outside the calls.