-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify language around 'identity' #1133
Comments
Related questions about 'identity' in this comment thread:
I think it's clear there's more work to do here. |
My initial thinking on this is that at a high level, SCPs will need to be responsible for:
I do not think developer tools should try to assert the legal identity of users in provenance attestations. Also, I don't think we should reference signatures directly due to how easily they can be misused in version control systems. We should default to "strongly authenticated" verbiage to ensure tools can use the best possible authn technologies. |
Regardless of the specific requirements we put on SCPs I wonder if we can make a clear statement about non-requirements as well. Something along the lines of "Nothing in this specification should be taken to mean that open source software contributors need to, or should, be mapped to legal their identities." |
I think being clear about:
I imagine we'd say "strongly authenticated" and qualify with a non-exhaustive set of examples that include SCP mechanisms, enterprise hosted identity providers, and so on. Not referencing signatures / the ability to sign as a means for authenticating a developer would perhaps stand out in that case. @zachariahcox, could you clarify the concerns you have with their misuse in version control systems? Maybe we can caveat / suggest possible solutions if someone were to go that route. |
The way the spec talks about 'identity' it could be taken to mean that at Source Level 2+, SLSA wants to require source control platforms to verify the legal identity of open source contributors. I don't believe that is anyone's intent, I certainly didn't intend for that interpretation. I think that what we meant to get at was being able to associate some token (e.g. account name, handle, signing key) trusted by the specific community with commits & reviews (which most, if not all, source control systems already use to manage changes).
We should make the language we use much more crisp to avoid any ambiguity.
I'll track down some language and make a proposal but I wanted to document this as an issue as it came up as a hot topic during a panel discussion at OSS EU on Tuesday.
If anyone has any suggestions or disagrees your thoughts are welcome.
The text was updated successfully, but these errors were encountered: