New Name

[dlorenc]

There's been some interest in potentially renaming this WG. Let's use this issue to discus that, including potentially a brainstorm for new names. If we decide to make a change, let's figure out the process for that here.

[ghindman]

I think removing "developer" is absolutely the right move, both for the privacy implications to individuals, and also because we shouldn't be limiting the work to recognizing people - bots and infrastructure touch code and perform privileged operations all the time.

Maybe Digital Identity Verification or Digital Identity Attestation ?

[justincormack]

The name should describe the security problem we are trying to solve, or the tools we will provide. Maybe the problem is giving and revoking trust, or trust issues in the supply chain. Identity might be a solution (do I always trust @ghindman or do I trust "Gavin Hindman") but it allows for other solutions too that do not involve identity, such as analysing content of items that might be trusted.

[ghindman]

IMO the security problem this group is primarily tasked with is recognition, not trust - do I have confidence in the origination of this thing I'm thinking about trusting, or have already trusted to do something - eg., I could use an attribution classifier to screen all comments and pull requests to try to identify entities with multiple accounts or spot account hijacks.

[dlorenc]

The name should describe the security problem we are trying to solve, or the tools we will provide.

I think my problem is that I can't really articulate any single problem that needs to be solved yet, and I definitely don't know what tools are needed. Just that there are a bunch of challenges in an area.

IMO the security problem this group is primarily tasked with is recognition, not trust

I hadn't thought of it that way, but I think I agree. For example, I don't trust Gavin Hindman or @ghindman yet - his employer might though :) Everyone has a different set of people/entities/systems they trust. I would like to be able to confidently recognize that code/artifacts I use came from the things I trust.

[dlorenc]

such as analysing content of items that might be trusted.

Really good point. This seems to open things up very very widely though and starts to include things like static analysis, malware detection, etc. I'm personally less interested in those areas here. Let's see what everyone else thinks though!

[ghindman]

+1 I've sort of come to the conclusion over the last several weeks thinking about this that there's a continuum of recognition -> trust -> privilege. I may want to try to recognize contributors, but I don't trust them. I may trust key reviewers, but I don't grant them privilege to do anything other than +1 a patch or PR.

The first one is super hard and makes the others more difficult, and seems like more than enough for this WG to bite off initially.

[dlorenc]

One name option: "developer identity management"

Maybe the "management" word at the end makes the intention more clear. Identity Management is a pretty common term, and the decentralized, ad-hoc nature of many open source software projects means developers/maintainers are posed with unique sets of challenges.

[ghindman]

I don't believe "developer" should be anywhere in the name both for the privacy implications, and because I don't think it's correct - anything that comes out of this wg should apply to the bots and infrastructure tools/service accounts that commonly/increasingly make changes to projects as much as people.

[mayakacz]

I don't believe "developer" should be anywhere in the name both for the privacy implications, and because I don't think it's correct - anything that comes out of this wg should apply to the bots and infrastructure tools/service accounts that commonly/increasingly make changes to projects as much as people.

Fully agreed. I would like a linter to be able to attest to some properties of a repo directly, for example.

This seems to open things up very very widely though and starts to include things like static analysis, malware detection, etc.

I don't see these as separate. I might trust a user's contribution, based on the user, but if a malware scanner comes back with a red flag I'll take a second look. All of these elements contribute to my decision, to varying degrees.

What I would like is a way to verifiably consume metadata about the open source I choose to use, including 'end' artifacts but also any steps in that supply chain, and also help me decide which projects to use based on these risks. I think a lot of that data I want is being addressed by the dashboard initiative. What isn't (yet) addressed is a way for that data to be easily verified, against a known set of trusted authorities, and to choose which authorities' information to trust. I think about it like the early days of https - even where there are certs, which CAs do I trust? Who is a root?

If this is the 'right' problem for this group (or direction, at least), then I see this as being about "trust", "integrity and verification", "transparency", "independent verification", or other similar terms. (I think "attestation" is one potential implementation and a piece of the solution, not the overarching goal.) Something like "supply chain verification" is closer to what I have in mind, and comes much closer to existing SBOM efforts.

+1 I've sort of come to the conclusion over the last several weeks thinking about this that there's a continuum of recognition -> trust -> privilege. I may want to try to recognize contributors, but I don't trust them. I may trust key reviewers, but I don't grant them privilege to do anything other than +1 a patch or PR.

I think we can't even start to discuss how much you trust everyone, or each factor, until you can actually consume that information somehow. But agreed with this point fully. I can imagine a world where I 'trust' a security review from a particular company, say, but I also trust my friend Jan because I know them. Your trust model might not include Jan.

The important point here is that we cannot define a definitive web of trust - taking https as an example again, you (or your employer) can add (and remove) CAs from your trusted list. And you can change your DNS if you want to get the info from somewhere else!

[dlorenc]

What I would like is a way to verifiably consume metadata about the open source I choose to use, including 'end' artifacts but also any steps in that supply chain, and also help me decide which projects to use based on these risks. I think a lot of that data I want is being addressed by the dashboard initiative. What isn't (yet) addressed is a way for that data to be easily verified, against a known set of trusted authorities, and to choose which authorities' information to trust. I think about it like the early days of https - even where there are certs, which CAs do I trust? Who is a root?

Agreed completely. I think the dashboard is more focused on "repository-level" information, so there's definitely some overlap, but the scope here is a little different since we need to look at 'end' artifacts as well.

[dlorenc]

I think these are the candidates I can see so far in the issue:

• Digital Identity Verification
• Digital Identity Attestation
• Developer Identity Management
• Supply Chain Attestation and Verification (from email)
• Identity Attestation
• Source Identity
• Preventing Malicious Code

Let's get some more options in here so we can setup a poll!

[dlorenc]

Updated with the others from email. Poll created here: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_7aa56185b28e2e01&akey=e9e9227bd6033e2e

[dlorenc]

I'll let this run for a week.

[ghindman]

I get a "Poll Already Ended" error

[dlorenc]

Sorry - typo. One sec.

[dlorenc]

Try now. Updated to this link: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_7aa56185b28e2e01&akey=e9e9227bd6033e2e

[dlorenc]

The results are available:

1. Digital Identity Attestation  (Condorcet winner: wins contests with all other choices)
2. Identity Attestation  loses to Digital Identity Attestation by 7–6
3. Developer Identity Management  loses to Digital Identity Attestation by 9–3, loses to Identity Attestation by 9–3
4. Supply Chain Attestation and Verification  loses to Digital Identity Attestation by 7–5, loses to Developer Identity Management by 7–6
5. Digital Identity Verification  loses to Digital Identity Attestation by 10–2, loses to Supply Chain Attestation and Verification by 7–6
6. Source Identity  loses to Digital Identity Attestation by 9–4, loses to Digital Identity Verification by 6–5
7. Preventing Malicious Code  loses to Digital Identity Attestation by 10–1, loses to Source Identity by 11–2

[lukehinds]

yay! we have a name. I personally am good with "Digital Identity Attestation", good choice.

[david-a-wheeler]

This should be closed, due to #23 . This group is renaming again, but I'll create a new issue to capture that :-).