Joshua Lock

Central requirements in a single document and focused how-to guides sounds like a good way to go.

I think we need to know how we will accomplish this prior to 1.0, even if we don't actually implement anything before 1.0 is released.

Apologies, I provided feedback in a couple of meetings where this came up but did not do so in a durable way. I like the document and agree we should...

2FA as common requirements at higher levels sounds more than reasonable. Agree that hardware backed security key is the gold standard, do we want to recommend for/against other options? SMS...

We're deferring definition of SLSA L4 until after 1.0, which includes the multi-party approval [Access](https://slsa.dev/spec/v0.1/requirements#access) requirement that this issue relates to.

Recommending 2FA for all administrators as part of the guidelines will be great for 1.0, yes please.

Guidelines for "build system/service" (name liable to change) implementers has been agreed under the "evidence of security claims" part of the SLSA 1.0 proposal, assuming the [PR for proposal 3](https://github.com/slsa-framework/slsa-proposals/pull/7/files)...

When to tackle this depends on making a decision whether to include Policy & Verification #46 in 1.0

Thanks, the Slack link has expired before. I don't think slack.openssf.org existed last time we ran into this but as that's the link from the main OpenSSF site to Slack...

This issue relates to the multi-party approval [Access](https://slsa.dev/spec/v0.1/requirements#access) requirement at SLSA L4, which we have deferred until post 1.0.