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.