Update objective and goals. #15

dlorenc · 2020-09-14T23:07:19Z

This is based on the discussions on scope in the previous two WG meetings and the
scope document originally shared here: https://docs.google.com/document/d/1_9jZSQLzoeqD8cgYMiRWRSdI7O5P1wJwdRjlXBKErUU/edit#heading=h.23hd1ivmr3lp

kimsterv · 2020-09-14T23:24:56Z

lgtm. change the name of the PR s/mission/objective?

ghindman · 2020-09-15T00:36:34Z

This seems much broader in scope than my understanding of the goals of this working group. Supply Chain Integrity seems like it crosses quite far over into the existing non-OpenSSF SBOM/DBOM working group, and is a slightly different problem. IMO Developer Identity is about how projects know and trust the entities committing code into their projects. How that is implemented may give confidence/feed into how third parties decide whether or not to consume that project, but is still a different problem.

I completely realize that I missed the first couple of meetings where this was discussed, so feel free to ignore me if I am rehashing closed topics.

dlorenc · 2020-09-15T14:04:09Z

This seems much broader in scope than my understanding of the goals of this working group. Supply Chain Integrity seems like it crosses quite far over into the existing non-OpenSSF SBOM/DBOM working group, and is a slightly different problem. IMO Developer Identity is about how projects know and trust the entities committing code into their projects. How that is implemented may give confidence/feed into how third parties decide whether or not to consume that project, but is still a different problem.

Yes, this is definitely a broadening in scope. @kaywilliams can discuss how this will relate to the SBOM/DBOM work - but my 2 cents is that we will not be working on any new standards in that space. I should probably specifically call that out in the non-goals section.

The Developer Identity work you outlined is still one of the main priorities for me, and I hope this group :) This is definitely not a closed issue/discussion, the goal of this PR was to create a place to have it before the next meeting!

mayakacz

Thank you for changing the proposed name, that is something I would like us to do urgently, even while we debate scope.

This is based on the discussions on scope in the previous two WG meetings and the
scope document originally shared here.

This document has multiple unaddressed or unresolved comments, and a discussion meeting tomorrow, on 2020/09/15, to address specifically this scoping question.

This PR seems premature.

I still don't love the reference to developer names at all (vs., say, only referring to keys). I don't think this is the right threat model. If I am a known 'good' user, and my account is compromised (which is ), then the verification of my account did not help identify this compromise. It might help in mitigation (e.g., looking for signed commits), but then again, the issue there is the use of my cryptographic identity, not my personal identity.

As @ghindman points out, if the scope of this WG is meant to only to deal with provenance, and integrity, then that might make sense. Currently, the dashboard project does seem to be the place we are heading to surface this information but not necessarily generate this information.

This seems much broader in scope than my understanding of the goals of this working group.

I would agree. Also agree that if the goal is in fact provenance, then we should consider how to engage with existing groups in NTIA, OWASP and MITRE around their SBOM efforts.

mayakacz · 2020-09-15T14:10:58Z

README.md

@@ -35,28 +37,23 @@ These problems need solutions!

 <img align="right" src="./dog_meme.jpg">

-* Give open source maintainers a way to do work under their chosen name, representing their real employers in secure ways.
+* Give open source maintainers a way to do work under their chosen name, and to prevent others from impersonating them.
 * Give open source projects tools and infrastructure to verify the identities of their maintainers.
 * Give consumers of open source libraries more data for determining the risks of depending on said library.


Overlaps with the Project Security Metrics project from the Identifying Security Threats WG.

mayakacz · 2020-09-15T14:11:35Z

README.md

 * Respect the privacy of everyone involved.
 * Give OSS maintainers better ability to ensure that project governance policies (like independent signoff) are followed.
-* Give OSS consumers tools to detect surges in activity from unknown committers.
+* Give OSS consumers tools to detect changes in activity from unknown committers.
+* Allow consumers of open source to examine the full provenance of their open source supply-chains.


A lot of the 'provenance' discussion is also part of the dashboard - in that that information would need to be surfaced somewhere.

threat_models.md

mayakacz · 2020-09-15T14:14:10Z

README.md

@@ -1,10 +1,12 @@
-# WG Developer Identity
+# WG Supply Chain Integrity (Formerly Developer Identity)


Suggested change

# WG Supply Chain Integrity (Formerly Developer Identity)

# WG Supply Chain Integrity

This was not a very long-lived name, not sure if it is necessary to refer to it.

I agree that we shouldn't reference the old name, and keep the focus on the current objectives

This is more than just a readme change, though, the current name is reflected in the name of this repo, the mailing list/groups/calendar, and the rest of the OpenSSF docs that talk about workstreams, etc.. I would not change it until the topic has been closed and all the other references can be touched in unison. Too much confusion about what is where already.

+1 to @ghindman , I'm just trying to minimize confusion around this until everything lands.

mayakacz · 2020-09-15T14:23:49Z

The Developer Identity work you outlined is still one of the main priorities for me, and I hope this group :) This is definitely not a closed issue/discussion, the goal of this PR was to create a place to have it before the next meeting!

I think we crossed in the interwebs. Makes sense, thanks.

This is based on the discussions on scope in the previous two WG meetings and the scope document originally shared here: https://docs.google.com/document/d/1_9jZSQLzoeqD8cgYMiRWRSdI7O5P1wJwdRjlXBKErUU/edit#heading=h.23hd1ivmr3lp

ghindman · 2020-09-15T15:44:41Z

Thank you for changing the proposed name, that is something I would like us to do urgently, even while we debate scope.

Your would like it changed due to your concerns about cryptographic identity vs personal identity? (which I agree with)

discussion meeting tomorrow, on 2020/09/15, to address specifically this scoping question

Where was this meeting scheduled? I don't see it on the google calendar for the workgroup or in the Google discussion group.

dlorenc · 2020-09-15T15:47:16Z

Where was this meeting scheduled? I don't see it on the google calendar for the workgroup or in the Google discussion group.

Sorry, copied it over there. That calendar should be "deprecated" and everything is on the OSSF-wide one here: https://calendar.google.com/calendar/r?cid=czYzdm9lZmhwNWk5cGZsdGI1cTY3bmdwZXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

ghindman · 2020-09-15T15:50:38Z

Hrm, I still only see the regular WG meeting for tomorrow, nothing for today.

dlorenc · 2020-09-15T15:52:15Z

Hrm, I still only see the regular WG meeting for tomorrow, nothing for today.

That's correct, the regular WG meeting. Ah I see- it's 9/16 not 9/15.

ghindman · 2020-09-15T16:04:25Z

👍

rhaning · 2020-09-15T17:04:08Z

README.md

-* Give open source maintainers a way to do work under their chosen name, representing their real employers in secure ways.
-* Give open source projects tools and infrastructure to verify the identities of their maintainers.
+* Give open source maintainers a way to do work under their chosen name, and to prevent others from impersonating them.
+* Give open source comunities the tools tools and infrastructure to verify the identities of their maintainers, based on whatever criteria they require.


Fix typos and suggest slightly different phrasing:
"Provide open source communities with the tools and infrastructure to validate the integrity of their maintainers, based on their chosen criteria."

Hmm, I see where you're going but don't love this phrasing either. When you talk about the "integrity of maintainers" that starts to cross over into "personal integrity".

Maybe "verify properties of their maintainers" ?

I was thinking more along the lines of build integrity, but I see how this could be misinterpreted as well. How about just "verify maintainers"?

"verify maintainers" and "verify properties of maintainers" are both clear, but have different meanings.

The "whatever" in the current phrasing, "verify the identities of their maintainers, based on whatever criteria they require" seems too open for me, as it could allow for someone to ask for private information.

I'm trending towards liking "privileged entities" when referring to a specific identity. The work of this group should apply to anything that can unilaterally do something that requires privilege. The context and the role of that something doesn't really matter. Could also be applied to bots or service accounts in a devops environment, for example. I think bounding this as specific individuals is the wrong path. My comment over in the threat doc characterized this as: "systems in place that provide evidence/trust that a privileged entity is who they say they are, and they are 'trustable'."

README.md

ghindman · 2020-09-15T17:28:15Z

README.md

 * Give consumers of open source libraries more data for determining the risks of depending on said library.
-* Give consumers and maintainers a public record of who implemented changes to an Open Source software project.
+* Give consumers and maintainers a trustworthy public record of who implemented changes to an Open Source software project.


This is a distinction that I brought up in the kernel topic last meeting that I think needs deeper discussion. In many open-source projects, the people who submit/merge the code to the tree are not the implementers of most of that code, which has been aggregated from a broader community through mailing-lists, etc..

+1! I think the discrepancies in nomenclature (commiter, author, maintainer, etc.) are probably causing confusion here.

README.md

ghindman · 2020-09-15T18:09:05Z

README.md

-* Enforce or mandate identity requirements for projects.
-  We will simply make this service available and easy-to-use, leaving it up to projects and communities to adopt if they choose to do so.
+* Enforce or mandate identity policy and requirements for projects.
+  We will simply make these services and tools available and easy-to-use, leaving it up to projects and communities to adopt if they choose to do so.


Actually I don't know that this line is required at all - this should be implicit in the Goals section.

Ah, this might be a scoping question. We should do this, and I don't think it's covered anywhere else(?) in the WGs.

Co-authored-by: Gavin Hindman <gavin.hindman@intel.com>

mayakacz reviewed Sep 15, 2020

View reviewed changes

dlorenc force-pushed the mission branch from 2f49874 to 00db582 Compare September 15, 2020 14:58

Update mission statement, name and goals.

3b0d242

This is based on the discussions on scope in the previous two WG meetings and the scope document originally shared here: https://docs.google.com/document/d/1_9jZSQLzoeqD8cgYMiRWRSdI7O5P1wJwdRjlXBKErUU/edit#heading=h.23hd1ivmr3lp

dlorenc force-pushed the mission branch from 00db582 to 3b0d242 Compare September 15, 2020 15:12

rhaning reviewed Sep 15, 2020

View reviewed changes

ghindman reviewed Sep 15, 2020

View reviewed changes

README.md Show resolved Hide resolved

ghindman reviewed Sep 15, 2020

View reviewed changes

README.md Outdated Show resolved Hide resolved

ghindman reviewed Sep 15, 2020

View reviewed changes

README.md Outdated Show resolved Hide resolved

ghindman reviewed Sep 15, 2020

View reviewed changes

Update README.md

404f2d1

Co-authored-by: Gavin Hindman <gavin.hindman@intel.com>

dlorenc force-pushed the mission branch from 9b052d4 to 404f2d1 Compare September 18, 2020 13:26

dlorenc changed the title ~~Update mission statement, name and goals.~~ Update objective and goals. Sep 18, 2020

kaywilliams mentioned this pull request Sep 18, 2020

Scope: extend to supply chain identities more broadly? #9

Closed

dlorenc merged commit e0ab6c3 into ossf:main Sep 21, 2020

dlorenc deleted the mission branch September 21, 2020 13:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update objective and goals. #15

Update objective and goals. #15

dlorenc commented Sep 14, 2020

kimsterv commented Sep 14, 2020

ghindman commented Sep 15, 2020

dlorenc commented Sep 15, 2020

mayakacz left a comment

mayakacz Sep 15, 2020

mayakacz Sep 15, 2020

mayakacz Sep 15, 2020

mayakacz Sep 15, 2020

rhaning Sep 15, 2020

ghindman Sep 15, 2020

dlorenc Sep 15, 2020

mayakacz commented Sep 15, 2020

ghindman commented Sep 15, 2020 •

edited

dlorenc commented Sep 15, 2020

ghindman commented Sep 15, 2020

dlorenc commented Sep 15, 2020

ghindman commented Sep 15, 2020

rhaning Sep 15, 2020 •

edited

dlorenc Sep 15, 2020

rhaning Sep 15, 2020

mayakacz Sep 15, 2020

ghindman Sep 15, 2020

ghindman Sep 15, 2020

dlorenc Sep 15, 2020

ghindman Sep 15, 2020

mayakacz Sep 15, 2020

		@@ -1,10 +1,12 @@
		# WG Developer Identity
		# WG Supply Chain Integrity (Formerly Developer Identity)

	# WG Supply Chain Integrity (Formerly Developer Identity)
	# WG Supply Chain Integrity

Update objective and goals. #15

Update objective and goals. #15

Conversation

dlorenc commented Sep 14, 2020

kimsterv commented Sep 14, 2020

ghindman commented Sep 15, 2020

dlorenc commented Sep 15, 2020

mayakacz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mayakacz commented Sep 15, 2020

ghindman commented Sep 15, 2020 • edited

dlorenc commented Sep 15, 2020

ghindman commented Sep 15, 2020

dlorenc commented Sep 15, 2020

ghindman commented Sep 15, 2020

rhaning Sep 15, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghindman commented Sep 15, 2020 •

edited

rhaning Sep 15, 2020 •

edited