Clarify language around 'identity'

[TomHennen]

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.

[TomHennen]

Related questions about 'identity' in this comment thread:

#1094 (comment)

@marcelamelara

Identity management is a slippery slope ;) The juxtaposition of federated authentication and custom implementation is not really clear to me, especially with the given examples. Is the intent here that something like OAuth/email and key-based approaches are both ways to achieve this requirement?

It also seems like some crucial properties/requirements for the identities themselves should be included here: e.g., unique identities, the "root" issuer for identities, mapping between usernames and other identifiers on cloud-hosted SCPs, etc. Teasing these out might also clarify the security objective of the Identity Management requirement more generally.

@zachariahcox

I hope we don't need to define things down to that level!
It would be nice if we can just leave it at

Something or somebody stores and deals with source revisions: let's call that thing the "scp"
The SCP needs to explain how it identifies the actors who do things and record what it saw them do.
SCPs issue attestations of the above. VSAs can use them or not.

I think it's clear there's more work to do here.

[zachariahcox]

My initial thinking on this is that at a high level, SCPs will need to be responsible for:

1. tracking which actors made changes
2. optionally linking that actor to external (perhaps government-provided) identity management systems.
3. adding policy enforcement tooling to ensure that "all contributors have the external identity service linkage" etc.

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.

[TomHennen]

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."

[adityasaky]

I think being clear about:
a) identities are for internal consistency, so it's possible to track and set policies on the actions of the entity in question
b) identities are not required to be mapped to legal IRL identities
should address this, I'm in support of adding the text @TomHennen proposed.

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.

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.

[TomHennen]

@zachariahcox any more thoughts on this discussion?

[TomHennen]

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).

[hepwori]

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.

[marcelamelara]

Chiming in a little late... some thoughts:

I do not think developer tools should try to assert the legal identity of users in provenance attestations.

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.

identities are for internal consistency, so it's possible to track and set policies on the actions of the entity in question

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 ?

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).

@TomHennen I also agree with the latter. Identities are a cross-cutting aspect across tracks.

I wondered if projects like Sigstore, which are even more closely identity-adjacent, might have prior art or concept definitions SLSA could borrow.

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.

[adityasaky]

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?

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.

[mlieberman85]

@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.