-
Notifications
You must be signed in to change notification settings - Fork 225
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. |
@zachariahcox any more thoughts on this discussion? |
I'm also interested if folks think this should be restricted to the Source Track at first (where the issue came up) or if we should have a separate landing page 'Identities in SLSA' to discuss the topic? (I'm leaning towards the latter). |
fwiw I agree with your instincts to broaden, along the lines of 'Identities in SLSA'. I wondered if projects like Sigstore, which are even more closely identity-adjacent, might have prior art or concept definitions SLSA could borrow. Nothing immediately leaped out but I did see that the OpenID docs gesture loosely in the direction of an identity being "the outcome of an authentication process". It'd be good to have SLSA include some words on how identity should and shouldn't be understood in this context. |
Chiming in a little late... some thoughts:
I completely agree, and agree with @zachariahcox 's suggestion to focus on "strongly authenticated" (the security objective), but like @adityasaky would like to also better understand what the specific concerns are with signatures in VCS's.
I'd even go a bit further and say that identities are for consistency within some application context, e.g., within a single enterprise (all users of company XYZ) or within an SCS. Maybe this is already what you meant @adityasaky ?
@TomHennen I also agree with the latter. Identities are a cross-cutting aspect across tracks.
This is a good idea @hepwori . I do think we need to be a bit careful for SLSA not to prescribe the use of Sigstore, but we can certainly align on general terminology. |
Yeah, that's what I meant! It's for consistency within the context of the policy, which may be for a particular application or organization-wide. |
@hepwori So, I don't know if it was on purpose but from the Sigstore docs, I always felt they sidestepped the question of what abstract concept an identity maps to. They just refer to identities as either proof of ownership of a key or federated identities through OIDC. It's been a while since I've looked through Sigstore, but I think they've largely just used identity as a thing unto itself and not talked about what an identity maps to whether it be a human, set of humans, a system, or anything else. As a specification as opposed to a suite of tooling I think we might want to be a bit clearer but I think focusing on "what we are" over "what we aren't" is probably the way to go. I think mapping or not mapping identity to literal human is largely out of scope. I think folks will implement SLSA internally at their organization and do want to map OIDC or key to employee. However, in the open source space there's nothing SLSA gives folks to make unmasking even possible, not that we'd ever want to get into that in the first place. Now with that said, I do think we've had enough folks (on both sides of the argument) rehash the misconception that we're somehow working to unmask anonymous/pseudonymous open source contributors that having it somewhere in our docs we can point to us explicitly stating we're not doing this. I have seen both folks from the open source community make wild claims that SLSA is trying to dox open source contributors, but I've also seen folks from large enterprises who are worried about XZ want SLSA to unmask anonymous potential bad actors. |
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: