From 46b4fa743bd269f6912d2573374dd692615fe17e Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Wed, 11 Dec 2024 10:16:59 -0500 Subject: [PATCH] content: draft: Add 'principle' protecting anonymous contribution in SLSA (#1249) As work on the source track progresses the topic of 'identity' comes up quite a bit. There has been some confusion about what this means, that it could be that SLSA intends to require legal identities for all contributors. That isn't the case. Many in the open source world prefer to contribute without revealing their 'real' identities as has been practiced for many years. SLSA does not intend to change that. This PR tries to make it clear that SLSA does not require real identities. refs #1133 --------- Signed-off-by: Tom Hennen Signed-off-by: Tom Hennen Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Co-authored-by: Andrew McNamara --- docs/spec/draft/principles.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/docs/spec/draft/principles.md b/docs/spec/draft/principles.md index d82fcc319..19c775c80 100644 --- a/docs/spec/draft/principles.md +++ b/docs/spec/draft/principles.md @@ -107,10 +107,35 @@ In practice, though, these configurations are almost impossible to get right and keep right. There are often over-provisioning, confused deputy problems, or mistakes. Even if a platform is configured properly at one moment, it might not stay that way, and humans almost always end up getting in the access control -lists. +lists. Access control is still important, but SLSA goes further to provide defense in depth: it **requires proof in the form of attestations that the package was built correctly**. **Benefits**: The attestation removes intermediate platforms from the trust base and ensures that individuals who are accidentally granted access do not have sufficient permission to tamper with the package. + +## Support anonymous and pseudonymous contributions + +SLSA supports anonymous and pseudonymous 'identities' within the software supply chain. +While organizations that implement SLSA may choose otherwise, SLSA itself does not require, +or encourage, participants to be mapped to their legal identities. + +**Nothing in this specification should be taken to mean that SLSA requires participants to +to reveal their legal identity.** + +**Reasoning**: SLSA uses identities for multiple purposes: as a trust anchor for attestations +(i.e. who or what is making this claim and do I trust it to do so) or for attributing actions +to an actor. Choice of identification technology is left to the organization and technical +stacks implementing the SLSA standards. + +When identities are strongly authenticated and used consistently they can often be leveraged +for both of these purposes without requiring them to be mapped to legal identities. +This reflects how identities are often used in open source where legal name means much less +to projects than the history and behavior of a given handle over time does. Meanwhile some +organizations may choose to levy additional requirements on identities. They are free to do +so, but SLSA itself does not require it. + +**Benefits**: By _not_ requiring legal identities SLSA lowers the barriers to its adoption, +enabling all of its other benefits and maintaining support for anonymous and pseudonymous +contribution as has been practiced in the software industry for decades.