# in-toto Community Meetings

**CNCF Public Calendar:** https://tockify.com/cncf.public.events/monthly?search=in-toto
**Pre 2023 Meeting Notes:** https://hackmd.io/@adityasaky/ry4Wuico3

## 11/01/2024

### Agenda
* New community members introductions (if any)
* in-toto Helm Charts (poke) (link?)
* KubeCon preparations
* [Roadmap PR](https://github.com/in-toto/community/pull/35)
* AoB

### Attendees

* Santiago Torres-Arias
* Jack Kelly
* Marcela Melara
* Tom Hennen
* John Kjell
* Kairo Araujo
* Thomas Meadows
* Aditya
* Sunil Ravipati
* Alan Chung-Ma

### Notes

#### Introductions
* No new faces

#### Helm Charts
* There's approval to move forward with this
* Confirming who the maintainers are
* Kairo and John to start off
* There may be some DNS configuring needed later
* +1 (Jack)
* Links:
* Hosting a helm repository via github pages
* https://helm.sh/docs/topics/chart_repository/#github-pages-example
* Referencing a helm chart via oci example
* `helm install my-release oci://registry-1.docker.io/bitnamicharts/<chart>`
* https://github.com/bitnami/charts
* Santiago: will create a new repository and unblock this ask

#### Kubecon Preparations
* Sign up sheet for booth duty
* John: will send one out
* Is this a combined TUF/in-toto booth?
* schrodinger's booth
* Yes but TUF isn't prepared for it?
* Will coordinate
* Do we expect an in-toto maintainer meet?
* Tuesday is SigstoreCon
* Maybe one evening

#### Roadmap
* There's been good feedback on the PR for the roadmap
* One open feedback point is to describe that this is both a description of ongoing / future work as well as a description of recent work
* In a sense, it combines review and roadmap roles
* Merged!

#### AoB
* Marcela: update on policies work
* Meeting twice a month (EMEA / APAC friendly times)
* Opportunity to collaborate with other projects such as Macaron (Behnaz from Oracle)
* As of yesterday, going to send Behnaz some more complicated in-toto layouts to see how they'd be implemented using Macaron
* Santiago: are there thoughts on the roadmap for this effort?
* John: some conversations about policies 2.0 vs 3.0
* Also, macaron isn't part of the CNCF, there are organizational questions about adopting as well

## 10/05/2024

### Agenda
* New community members introductions (if any)
* Graduation review help!
* CNCF governance review
* in-toto Helm Charts
* AoB

### Attendees
* Santiago Torres-Arias
* Aditya Sirish
* Justin Cappos
* Mikhail Swift
* Tom Meadows
* Kairo de Araujo
* Jack Kelly
* John Kjell
* Cole Kennedy

### Notes

#### Introductions

None this time

#### Graduation review help

* Santiago met with TOC sponsor, one or two outstanding issues
* No process for subprocess onboarding / offboarding
* Need a third name for an interview
* Santiago <-> Cole to evaluate if an adopter can help out
* Santiago will be making some changes to the governance docs, ITSC to review
* This includes onboarding / offboarding subprojects and their maintainers
* Cole: Will ITSC have final say on who the maintainers are? Filtering mechanism?
* Santiago: Yes. The change in question would just be surfacing that policy more clearly

#### CNCF Governance Review

* Trishank has taken on the CNCF governance review
* John: Probably similar to the presentation to TAG-security, except a focus on the governance to ensure it encourages contributions

#### in-toto Helm Charts

* Kairo: Propose a separate in-toto repository with helm-charts
* Initially will include Archivista
* Will open an issue on in-toto/community to propose this

## 09/06/2024

### Agenda
* New community members introductions (if any)
* Should we establish guidance for how opinionated we are on new predicate types? This could speed up reviews of types.
* Policy WG Updates
* Case study/Blog (Cole)

### Attendees
* Aditya Sirish (NYU)
* Tom Hennen (Google)
* Alan Chung Ma
* Marcela Melara (Intel)
* Jack Kelly (ControlPlane)
* Matthias Glastra
* Noel Cortes (Lockheed Martin)
* John Kjell (TestifySec)
* Cole Kennedy (TestifySec)
* Tom Meadows (TestifySec)
* Sunil Ravipati

### Notes

* Intros
* None
* Predicate types
* Marcela: There are open PRs for new predicate types, how oppinionated should these predecate types be?
* Marcela: Deployment and reference predicates proposed among others
* Marcela: Potentially people feel uncomfortable modifying exisisting predicates.
* Tom: Agree. People also not comfortable proposing spec changes for cases that are currently unsupported
* Tom: Extension for the same or closely similar usecases. New for distinctly different rather than forcing.
* John: Do we have an oppinionated implementation or a library. More than one way to do things with existing predicates. Let people know that is fine, more than 1 way to do things in programming.
* John: Could need a practical user's guide, decision making process for which attestations to use, when are optional fields important for policy
* Marcela: For existing predicates that could meet the same goal test it out first to show a need for a new one. Discussion ongoing for very generic predicates having many optionals leading to less guidance.
* Tom: Someone could be raising a proposal in the design phase, others may have a working example
* Marcela: Most things come in as PRs first rather than issues. Some conflicting docs.
* Matthias: CNCF project like phases could be useful for predicates. Start sandbox and progress with community use.
* Tom: DIY vs Endorsed
* Marcela & Tom: Maybe define which group/community/individual owns the predicate?
* John: Policy working group to maintain consistency with the attestations
* Cole: lots of orgs with lots of data without consistency.
* Policy WG updates
* John: Trishank working on ITE10 & 11(?) considering json schema + JSONET
* John: Difference between variable substitution and templating
* Graduation progress
* John: Happy to help
* Jack & Cole: Not heard anything extra regarding graduation
* Cole: If we need user interviews we might have some users happy to help
* Case study
* Cole: Still under NDA, user of Witness and Archivista.
* Cole: Value in centeralized evidence store. Don't need to migrate CI/CD platform. Community tools solving real business problems.
* Marcela: Awesome to have case study. Tangencially, any plans to integrate with BOMctl to analyze SBOM?
* Cole: Happy to discuss further
* Cole: Blog in the next few weeks. Looking to present full Case Study at an in-toto maintainers track. A section on users and statistics would be good.

## 08/01/2024

### Agenda
* Policy working group updates:
* John: they have been going through usecases
* Some focus on developing information about these usecases without requiring deep in-toto knowledge
* Next: they will go through the usecases from bottom up (i.e., what are the constituent steps on a policy)
* Participation: tom: intuition is that we should wait until we get a more concrete proposal before getting more participation
* New special interest group:
* Security baseline (Dana): open PR with some diagrams and other things with many references to in-toto and references to witness and archivisita
* It would be a good thing to support from the in-toto community
* CNCF Tag-security:
- there are efforts to bring down barriers between both CNCF and OpenSSF.
- There may also be some different baseline efforts between the two, so we may want to be involved in both.
- The baselines are a bit focused on more of the low-level practices (e.g., how to configure github securely/etc). There may be work with the way that the security toolbelt fits in this
- Anybody can join this sig, (it's probably under the best practices working group)
* SLSA source track:
* Trying to understand how SCPs can provide security guarantees without getting bogged down on the specifics of how each platform implements one of them
* in-toto highlights:
* Crowdstrike gave some visibilty for in-toto
* Some features in the news
* cncf blog
* Possibly a good idea to reach out to CS to see if they are interested in discussing in-toto
* Graduation interviews: PSA
* in-toto-golang:
* attestation people are complainig about compliance with the spec
* a couple of times the attestation group has gone to the respective repos to make the approrpriate updates so that they consume the protos
* How to engage with the right people with -go

### Attendees
* Justin Cappos (NYU)
* John Kjell (TestifySec)
* Tom Hennen (Google)
* Tom Meadows (TestifySec)
* Marcela Melara (Intel)
* Santiago Torres-Arias (Purdue)

### Notes

## 06/07/2024

### Agenda
* Meeting logistics
* Slack notification before every meeting
* A meeting link that ITSC have admin access to
* Cole will take care of this
* New community member introductions (if any)
* Ayush Gupta (welcome!)
* Docs [Jack Kelly]
* Happy to see progress here, especially from Witness and
* Would like to see a separate Slack channel to coordinate
* Slightly overwhelming work
* 30+ applications for project yesterday
* Lukas and Justin processing applications
* A lot of work that needs sharing
* Let's find a group of people to help
* Thomas keen on collaborating
* What is the deadline for the LF work?
* Can be seen from the LF website (needs login)
* Coordination: two options
* Specific communications in specific channels we have already
* Meta comms should probably go into a separate doc-specific channel or in #in-toto itself
* Let's start with #in-toto first and then decide if we need a specific channel later
* Make liberal use of Slack threads!
* in-toto-golang [Marcela]
* Earlier this year, go-consolidation effort
* Are we archiving the in-toto-golang repo?
* Folks have not received the message that the repo is technically deprecated
* How we should proceed with informing the community?
* We should tell them about newer, modern efforts such as Witness, Archivista, and so on
* Notice: "no longer maintained, see here and here instead"
* Is support for link attestators live yet in Witness? Was a big blocker
* Background: why Testify moved from in-toto-golang to Witness
* Pretty close to feature-complete, but need a diff chart for what's missing
* Examples: need Cosign support for signing attestations
* Call for help: need community feedback on what is wanted vs not
* File issues in in-toto-golang and Witness?
* Can use LFX mentorship round for support
* Aditya needs help to merge a draft (please link)
* Example: attestation-verifier
* How should folks contribute to new efforts? [Trishank]
* Could someone volunteer to lead archiving in-toto-golang and pointing to Witness and friends here?
* To write deprecation docs
* Attestation framework also needs help with things like bindings
* When to use what
* Who are the -golang maintainers?
* Could we use help from the LFX folks here?
* Jack would like to volunteer, but would also like some help from the -golang maintainer group
* Adding support for non "link" type attestation to witness policy [Cole]
* https://github.com/in-toto/go-witness/issues/267
* Want to converge with ITE-11
* Looking for feedback
* Need step names for linking them together
* Step names tell you what you need to know
* Should we tie to just Rego? Do we want other options like Cue?
* Cognitive dissonance from multiple languages? [Trishank]
* Machines should be creating the "compiled" low-level policies
* The high-level policy shouldn't be machine-generated
* Idea: users can add something on top of layouts? Then machines will write implementation details
* Attestation-verifier seems like a good choice
* Especially for tickets
* Let's fold support back into Witness
* Policies
* Layers of policies (maybe sublayouts?)
* Let's start a Slack thread in #in-toto to discuss
* Graduation status? [Trishank]
* Many +1s
* A new person (please add name) is starting review
* Minor cleanups from us
* Mostly on them to move from old to new format
* Any other business?
* Ayush to start a Slack thread on CNCF

### Attendees
* Aditya Sirish (NYU)
* Zach Steindler (GitHub, OpenSSF TAC)
* Jack Kelly (ControlPlane, ITSC)
* Justin Cappos (NYU, ITSC)
* John Kjell (TestifySec)
* Kairo de Araujo (TestifySec)
* Tom Meadows (TestifySec)
* Cole Kennedy (TestifySec, ITSC)
* Tom Hennen (Google)
* Noel Cortes (Lockheed Martin)
* Ayush Gupta (Open Source Contributor)
* Marcela Melara (Intel, OpenSSF TAC)
* Trishank Karthik Kuppusamy (Datadog)
* Mike LeBeau (TestifySec)
* Adam Nauth (Best Buy)
*
### Notes

*
*
*

## 05/03/2024

:movie_camera: https://zoom.us/rec/share/x_wiHIReWXw-2669uyV1MfPIEvvJo4NvDreyxhCEvAYhgGsS7eiPfay8EYFTttK1.Fn30n1KybWjI-mVW

### Agenda
* New community member introductions (if any)
* Open source summit NA 2024 updates
* GitHub <-> attestations
* https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/
* https://github.blog/2024-04-30-where-does-your-software-really-come-from/
* Docs

### Attendees

* Aditya Sirish (NYU)
* Zach Steindler (GitHub, OpenSSF TAC)
* Jack Kelly (ControlPlane, ITSC)
* Justin Cappos (NYU, ITSC)
* Santiago Torres-Arias (Purdue, ITSC)
* John Kjell (TestifySec)
* Kairo de Araujo (TestifySec)
* Tom Meadows (TestifySec)
* Cole Kennedy (TestifySec, ITSC)
* Tanner Jones (TestifySec)
* Tom Hennen (Google)
* Noel Cortes

### Notes

* Intros
* None today
* OSS NA
* Discussion on serialization stuff. Dedicating some cycles to generalize source track for SLSA?
* Deployment attestation that was discussed for a bit:
* The discussion centered around what goes into the deployment
* Further, some review of the usecase (i.e., know what's running right now)
* Effectively a Deployment attestation is an attestation about a VSA (i.e., does this policy apply in this environment)
* i.e., should this be its own predicate, or should it be a VSA with some attributes
* OSS NA talks:
* John and Thom gave a talk on in-toto + witness + etc
* A lot of the discussion is around how to make things easier, not just possible
* .
* .

* in-toto Layouts, client tools, etc:
* General discussion around how do we start supporting attestations as defined by the attestation group
* More discussion around how do we start writing policy in better ways
* Thom and Tom: Layout transpilations, using best practices, examples, demos, etc.
* Cole: how do we handle alert fatigue etc
* Tom: Chat w/ Aditya: request access to doc (private for now) that describes a sketch for templating to turn a higher level user-facing policy into an in-toto layout
* John: we get to have a lot of conversations in an abstract sense. Plus, we don't need to have an in-toto layout to apply to everything.

* GH Attestations:
* GitHub is providing an attestation store. You can also have GHA generate slsa prov + sboms + attest to action in the background for you
* Cole: what is the general pattern for build. What about the policy enforcement/etc?
* Adam: besides the types that are supported, what are the other types of attestations you're looking into, are there patterns to support other types? (A: there are a lot of things that are being considered right now)
* Adam: can you submit your own attestations as a third party/etc? (A: yeah, when you call attest action will they submit the result in sigstore bundle to GHAAS. There are no commitments around how long is the data going to be stored. However, the AS may not be the place for long term storage or the "last place" where the attestations should be)
*

## :tulip: 04/05/2024 :tulip:

:movie_camera: https://zoom.us/rec/share/5xrBYUGZ-qarwMmipTz34jTvw-An0YEh9Wwc95faoZryT5VZATiT5gVW3AC09GZo.gfH-3kU_Y4ENWjPc

### Agenda
* New community member introductions (if any)
* Laurent Simon
* Google, working on SLSA, Scorecard within OSSF
* Isaac Hepworth
* Google, Chair of SCI WG at OSSF
* Andrew McNamara
* Here from discussion of VSAs from SLSA
* Kubecon Meetup Updates (TBD)
* Project updates
* in-toto-golang consolidation
* Witness joined the in-toto community, some shared functionality with in-toto-golang
* Consoliate and retire the in-toto-golang tool in favor of Witness
* Identified functionality in in-toto-golang, now being added to Witness
* Outstanding:
* Use Witness to generate in-toto Links
* Add policy and attestation verifier functionality into Witness
* Would also like to nudge [ITE-11](https://github.com/in-toto/ITE/issues/55)
* witness
* terminology updates (santiago)
* [Terminology Discussion](https://github.com/in-toto/witness/discussions/284)
* Looking for feedback from the community
* Within Witness, there's conflicting terms wrt the spec
* In particular under discussion: "attestors" vs "collectors"
* A list of conflicting terms will be collected
* Want to avoid renaming in the future
* Question around use of "externalParameters" in SLSA
* archivista
* Demo from SecurityHub at KubeCon: https://www.youtube.com/watch?v=camLVqnVel8
* attestation (msm)
* Policy verification attestation --> which predicate? VSA, SCAI, other?
* Tom H: https://docs.google.com/presentation/d/1_1ikfSaja87-Qx2ev26DYdiNgS6AEvVFO92oSwNGvJ8/edit?usp=sharing
* Produces know a lot about how they expect something to be built
* Consumers less so
* Need to record the fact that someone has evaluated an artifact and has decided it meets certain needs
* Record some of the properties the artifact has based on the policy evaluation
* Zach: fuzzy on who the trusted parties are in the context of the VSA
* Sometimes it's the producer, sometimes it's the consumer?
* Tom: discussion about how VSAs could be used for the NPM case
* Zach: highlights desire to provide the plumbing for these semantics without making the policy verification assurance, which would be for the consumer to do
* John: interesting thing is the attributes communicated in the VSA
* Thinking through what the important traits are and who is doing the verification
* And how do you convey the trust to downstream consumers
* Andrew: in SLSA, there was a conformance program we were trying to launch
* That has some auditor / external entity that can state conformance
* VSA is a shortcut to trust based on other policy
* Tom Meadows: can you do policy verification every time you deploy?
* VSA helps make it simple enough + latency worries
* Marcela: clearly a need to capture a policy decision
* The original VSA on the SLSA end was doing that for decisions around Provenance
* But clearly also a need to express policy decisions in other places
* And hence the generalization effort
* The discussion on formats: the format is almost secondary to making sure we have the right semantics
* Justin/Cole: VSAs kick in for sublayouts
* When you have something like a sublayout, you provide someone else the means to create policy/layout
* What are the actual properties we're getting out here? Trust?
* Aditya: Delegation would still be to a sub-policy
* VSA is a result of verifying the sublayout but the delegation is still to the entity defining the policy
* Deploy attestation predicate
* Laurent: a lot of the work that's been done is on production of software
* Not so much on consumption
* An admission controller wants to know "can I deploy this in this environment?"
* Shift left: say as an attestation: "this is where you can deploy this container"
* It also simplifies policy evaluation
* Andrew: so does this overlap with the VSA?
* Laurent: VSA is a determination about the artifact's properties
* Deployment attestation is about consumers making a determination whether to deploy an artifact
* Justin: why not do this as part of a layout?
* Tom M: would this be time sensitive?
* gsoc (santiago)
* OSS NA '24 meetup (msm)
* AOB

### Attendees
* Justin Cappos (NYU)
* Aditya Sirish (NYU)
* Cole (TestifySec)
* Zach Steindler (GitHub; OpenSSF TAC)
* Andrew M (Red Hat)
* Kairo de Araujo (TestifySec)
* Jack K (ControlPlane)
* Marcela Melara (Intel)
* Alan Chung Ma
* Isaac Hepworth
* John Kjell
* Laurent Simon
* Tom Hennen
* Ishaan Jain
* James Carnegie
* Noel
* Tom Meadows

## :tulip: 03/01/2024 :tulip:

### Agenda
* New community member introductions (if any)
* Project updates
* in-toto-golang consolidation
* witness
* attestation collection
* archivista
* gsoc (santiago)
* KubeCon
* Meetup
* Booth Schedule
* KubeCon talks
* AOB

### Attendees
* Santiago Torres-Arias (Purdue)
* Aditya Sirish (NYU)
* Alan Chung Ma (Keytos)
* Trishank Karthik Kuppusamy (Datadog)
* Kairo De Araujo (TestifySec)
* Justin Cappos (NYU)
* James Carnegie (Docker)
* Toddy Mladenov (Microsoft)
* John Kjell (TestifySec)
* Jack Kelly (ContrlPlane)
* Marina Moore (NYU)
* David Dooling (Docker)
* Cole Kennedy (TestifySec)
* Marcela Melara (Intel)
* Tanner Jones (TestifySec)
* Sunil Ravipati
* Mikhail Swift (TestifySec)

### Notes

#### New community member introductions
* None today

#### Projects Updates
* in-toto-golang consolidation / witness
* Meeting regularly
* Link attestor in witness
* Can pull in other predicates defined in in-toto/attestation as well
* Discussed witness policy <-> ITE-10/11
* Prototyped support for attestation collection in attestation-verifier
* We need to discuss how collection can be upstreamed into the attestation spec
* Aditya: can we think of a collection as a successor to the link predicate?
* Aditya: With some chages, we can see it seems like it could work
* It has materials + products and supports "mixins" for different information sources / collectors
* All of this would go in environment / byproducts in the original link
* With this model, it's easier to write policies about expected data sources + what they say
* Archivista
* Kairo: Making it so Archivista can be used to identify the policy for some artifact
* In addition to the attestations of course
* Doing so with support for key rotation as well
* Plan to demo in the next meeting
* GSoC
* Santiago: plan to submit a couple of projects
* A sigstore integration or plugging somethings better into GUAC
* There's interest in the Jenkins plugin but it needs more work such as adding sigstore support and updating SLSA support
* Rebuilderd implementation could be updated to support SLSA provenance
* Maybe a demo for SLSA that is similar to in-toto/demo but uses in-toto tooling to generate SLSA predicates
* Marcela: some implementations need to be updated to support attestations / predicates via the protos
* Some discussion about time commitments -- it's maybe a couple hours a week after the summer starts
* John and Trishank interested in mentoring

#### KubeCon EU
* Meetup
* John: we don't have project meetings this time
* Quite a few of us have the all access pass
* There'll be lunch / coffee etc as a result
* So we'd just have to find a table
* If folks don't have the all access pass, we can find some other place to meet
* We could discuss in-toto-golang consolidation, DSSE extensions, etc.
* Cole: Can we ask the CNCF for a room?
* If we can't get a room through them, Cole might be able to reserve a room someplace
* Booth
* Marina: Made a spreadsheet for folks to sign up for booth duty
* https://docs.google.com/spreadsheets/d/1e7Z8Qtva7Pl2tMc8gdbQhJCCLm_thFXrsRTG4Iu452A/edit#gid=0
* Booth is TUF + in-toto
* KubeCon Talks
* Maintainer track
* Navigating the Software Supply Chain Defense Landscape
* Panel with John / Marina
* Tom Meadows has talks at colocated events that might touch on in-toto
* SBOMs That You Can Trust (Chainloop)
* Yahoo folks are talking about Sigstore that also touches on attestations
* ContribFest

#### AOB
* Marcela: There are several in-toto and supply chain related talks at OSS NA
* Santiago: for the Docker folks, any movement on the OCI <-> attestations work?
* James: in the short term, we'll be moving forward with the spec as is
* Interested in working on this some more
* The Docker folks missed the in-toto/attestation meeting
* Santiago: Sigstore is moving towards not storing attestations in the log
* Trishank / John: Discussion around custom extension types in DSSE
* https://github.com/secure-systems-lab/dsse/pull/61
* https://github.com/secure-systems-lab/dsse/issues/59
* That PR / issue could use more eyes / opinions
* Santiago: Maybe we could just call it the ITE-7 extension more generally speaking
* Aditya: The original motivation for extensions was to ensure there was no confusion in the fields that must be verified
* Eg: a client must not assume it needn't verify the tlog because that field is dropped from the envelope
* Trishank: Also important to consider cases with a mix of required and optional fields

## 02/02/2024

### Agenda
* New community member introductions (if any)
* in-toto Go consolidation
* Tom Meadows: standardising documentation websites across in-toto
* Jonny Stoten: in-toto attestation storage in OCI registries
* Santiago: in-toto release/publish attestation

### Attendees
* Santiago Torres-Arias (Purdue)
* Aditya Sirish (NYU)
* Marcela Melara (Intel)
* Jack Kelly (ControlPlane)
* Cole Kennedy (Testifysec)
* Joel Kamp (Docker)
* Tom Meadows (Testifysec)
* David Dooling (Docker)
* James Carnegie (Docker)
* Mikhail Swift (TestifySec)
* Justin Cappos (NYU)
* Ian Dunbar-Hall (Lockheed Martin)
* Trishank Karthik Kuppusamy (Datadog)
* Mike LeBeau (TestifySec)
* John Kjell (Testifysec)
* Noel Cortes (Lockheed Martin)
* Jonny Stoten (Docker)
* Azeem
* Toddy Mladenov (MSFT)
* Zach Steindler (GitHub)

### Notes

* First successful CNCF Zoom Meet :tada:

#### Introductions
* Tom Meadows
* James Carnegie
* Joel Kamp
* David Dooling
* Toddy Mladenov

#### Go consolidation
* Move foundational capabilities like KMS to go-securesystemslib
* Can be reused downstream by go-witness, go-tuf, etc
* Also helps standardize DSSE extensions etc so all ecosystems are consistent
* First action is about governance of go-sslib
* Working in parallel on in-toto-golang / go-witness / witness streamlining
* Trishank mentioned in the last meeting about an abstract storage interface for attestations
* Santiago: did you reach out to Sigstore clients SIG?
* John: Hayden joined the last call and we chatted about how this would work <-> sigstore/sigstore
* There are some differences in opinion and some outstanding conversations
* Tom: I'm going to sigstore community meetings
* With time things can be ironed out and we can likely maintain a shared library over time
* Joel Kamp: It'd be great to have a single library for all this
* Tom: We're actually working on KMS support in go-witness based off sigstore/sigstore implementation which is high quality

#### Standardizing Documentation
* Tom: Documentation / information of in-toto are on a few different places with separate web frameworks
* Spent some time on how to improve docs for Witness
* Working to figure out how to get a better website / docs for Witness
* Also same goals for Archivista
* Built a proof of concept for how to standardize all of these docs
* Santiago: We should also probably revisit the main in-toto website
* We should at least start with a mention of Witness / Archivista on the main website
* Jack: Review link - https://github.com/cncf/techdocs/tree/main/assessments/0009-in-toto
* Santiago: Was waiting for graduation to start moving forward
* But since there's some lag, maybe we can ask the CNCF about a potential website refresh
* Justin: I've been working with the CNCF on the style guide changes / review etc
* We should change the style guide so it makes sense for the people who actually want to make changes
* Let's rework the contribution guide to make it work for contributors rather than something strict enforced top down
* Santiago: I like the model of in-toto/attestation where the subproject is handling these details
* https://github.com/in-toto/docs/pull/84
* Tom: tooling was discussed previously. One I put forwards was Docusaurus. I have a small implementation of consolodating docs across projects.
* *starts screenshare*
* docusaurus recommends 3 separate servers
* one main file for configuration, no complicated html or JS
* Biggest strength and weakness is we dont want contriubters to have to use HTML/CSS/JS docusaurus has that as optional. Mostly markdown with opt in reactjs.
* Aditya: Would this pull in API docstrings etc? Preferable to not have to update those separately / twice
* Tom: May be possible to pull that in, we should avoid repetition for sure
* Santiago: We should reach out to the CNCF for resources on infrastructure / cloud credits as well

#### in-toto/attestation storage in OCI

* Jonny: We're thinking about how to store in-toto attestations in OCI
* An attestation manifest sits next to an image
* That then points to in-toto *statements* as they aren't signed at the moment
* We're also looking at how to incorporate a future with signed attestations without breaking those relying on older unsigned statements
* We have a few options
* First we just put an unsigned DSSE envelope and put that next to the image, basically what the spec says minus the sig
* Has some disadvantages as the data in the envelope is duplicated in the registry (b64 encoding)
* Another approach is to insert a DSSE envelope and the payload is an OCI descriptor that's a reference to the original statement / digest
* The signature is over the OCI descriptor and the descriptor is resolved to get the actual statement
* Yet another approach is to use an in-toto resource descriptor instead of an OCI descriptor, refers to the statement again
* Worth documenting how Sigstore does it today
* Perhaps an ITE is in order
* What is a media type for a statement? Distinct from DSSE etc?
* Aditya: We have a related thought about resolving attestations in our verification workflow etc
* We should think about the impact on the verification, especially if the sig is over a reference to an unsigned attestation, etc.
* Zach: this might be scope creep, but what we're noticing in helping customers store in-toto attestations in registries is that different providers have different implementations. Azure container registry supports the OCI 1.1 referrer spec, which is different than Docker and AWS ECR today. Having a consistent way to relate in-toto documents to container images would be a huge win for the ecosystem!
* Marcela: The media type bit was discussed by in-toto/attestation
* We tried to provide guidance, would be nice to have more feedback on that
* Also added to the chat the PR for RD resolution in the attestation-verifier
* https://github.com/in-toto/attestation-verifier/pull/22
* Toddy: I can shed some light on OCI
* OCI 1.1 is supposed to be released possibly today
* There's a referrer spec that's used by some registries, others may support soon
* In Notary, the signing is based on the descriptor of the artifact
* David: Any notes about referrers / attestation discovery would be great context
* Santiago: homework for me as well, also describe what Sigstore did etc
* https://github.com/in-toto/attestation/blob/main/spec/v1/bundle.md#storage-convention

#### Release / publish attestation
* https://github.com/in-toto/attestation/pull/319
* Predicate proposal from Zach for release / publish
* Coming from the NPM usecase
* Trishank: Very useful for OSS registries
* Zach: Primary motivation was we did build provenance for NPM and then we added the publish attestation hastily
* Now going through the ITE-9 process
* There have been discussions in the Python community related to this
* Happy to help answer questions, clarify, shepherd the predicate through
* Marcela: Perspective from the attestation maintainers
* We're in agreement that the release predicate is ready for 0.1
* Some outstanding comments that need to be resolved / maybe worth bumping the thread
* Santiago: Think about pipeline from a predicate being accepted to being available in witness etc
* John: Discussing in go consolidation

#### AOB
* Aditya: KubeCon is coming up! Maintainer track, booth, etc
* Justin: Might want to consider another time for a meeting every third month or so for those who can't make this one

## 01/05/2024

INTERIM MEETING LINK: https://meet.google.com/wvm-fnrx-qpa

### Agenda
* New community member introductions (if any)
* [Trishank] How should we consolidate the in-toto Go tooling?
* https://github.com/secure-systems-lab/go-securesystemslib
* https://github.com/in-toto/in-toto-golang
* https://github.com/in-toto/attestation/tree/main/go
* https://github.com/in-toto/go-witness
* https://github.com/in-toto/attestation-verifier
* What do we tell end-users?
* What should they use for what?
* Could we get ITEs 10-11 into acceptance first?
* [Tom Meadows, TestifySec] How should we present in-toto subproject documentation?
* Proposed documentation contribution policy
* https://github.com/in-toto/docs/pull/84/files
* Adopt in-toto cross implementation tests
* https://github.com/in-toto/community/issues/10
* Already voted on by ITSC members
* (this agenda item was in the wrong section)

### Attendees
* Justin Cappos (NYU)
* John Kjell (TestifySec)
* Kairo De Araujo (TestifySec)
* Jack Kelly (ControlPlane)
* Tom Meadows (TestifySec)
* Toddy Mladenov (Microsoft)
* Aditya Sirish (NYU)
* Marcela Melara (Intel)
* Judy Bogart
* Alan Chung Ma

### Notes

#### New community member introductions
* Tom Meadows
* Joined TestifySec in December
* Working on Witness
* At Jetstack before, worked on cert-manager
* Toddy Mladenov
* Maintainer of Notary, works at Microsoft
* Supply chain security for about 2 years

#### Consolidate in-toto Go tooling
* We have a bunch of Go implementations that we need to consolidate
* Tom: My experience predominantly has been with go-witness
* Also used go-sslib for DSSE
* go-witness does not use go-sslib / in-toto-golang
* John: Support for extensions is the blocker for using go-sslib
* Tom: We have definitions for predicates etc as well
* go-witness also has signer interfaces that abstracts signing, would be good to consolidate that too
* John: Agree with all of that
* python-sslib supports more signers, that's an area we can work on for witness as well <-> go-sslib
* Sigstore also has its own implementations
* From a security perspective, consolidating all of this into one place is highly desirable
* The attestation repo -> we should start consuming proto defs in go-witness
* Also define witness specific protos in /attestation (ITE-9)
* in-toto-golang may be on the verge of duplicating work that should go in go-witness instead
* attestation-verifier <-> unification with witness policies is also a goal
* A dedicated working group to finish all of this would be nice
* Write some code!
* Marcela: As an /attestation maintainer, we provide proto defs for all implementations, not just Go
* There's a question of what must be implemented in a Go library vs on the spec side
* It makes sense to keep base packages for diff predicates / statement close to the spec
* Would welcome the witness ones as well
* How do we envision each repo or package being used?
* Aditya: Can we put together a task force that can consolidate all of this?
* We can better answer the question of how these diff packages are used then as well
* Related: ITE-10/11 need to move forward to allow for policy unification
* Justin: Now's a good time to express any concerns people have with them
* Else, we can start moving forward
* John: One more thing to consider is governance of go-sslib
* We trust NYU SSL but making governance more explicit would be helpful
* Action Item: to put the task force together on Slack
* Action Item: to move with ITE-10/11
* Action Item: governance for sslib

#### Proposed Documentation Contribution Policy
* Justin: Maybe 6 months ago we asked the CNCF to do docs review
* Some folks including Judy spent some time working with us to make suggestions
* One thing that was noted was that we don't have a guide for what docs look like
* Justin proposed a draft of this policy
* https://github.com/in-toto/docs/pull/84/files
* Modeled on the Kubernetes docs contribution guide
* If it's a small contribution, just propose it
* If it's more involved, talk to us
* The goal is to get to a stage where we can approve this relatively quickly
* Then we can start working on the documentation issues the techdocs assessment found
* We also have a bit of a strange repo setup with docs, community
* Maybe we should rename repositories to make things clearer
* Judy: In addition to documentation being in spec, the CNCF requires graduated projects to make docs available in the project website
* We need to create an architecture on the website to render the current docs
* Justin: Also, we actually have decent docs in terms of contents, but it's scattered across different places and not very visible
* Aditya: Rename docs to specification, maybe also rename in-toto/in-toto to in-toto-python
* Can render spec similar to TUF
* Judy: "Default repo" should be something docs related still rather than /community
* John: in-toto.io should be the starting point for docs related to all in-toto projects
* And still have /docs repo of some kind that is also rendered
* Tom: As a newbie to in-toto, when I go to github.com/in-toto, I except the readme but also really except the specification
* I except in-toto/in-toto to be the specification
* Judy: One recommendation is to better index / label parts of the spec as well
* Kairo: *audio issues* :(
* Jack: Is there a link to the report?
* https://github.com/cncf/techdocs/tree/main/assessments/0009-in-toto
* Justin: I personally think everything in the report is valuable
* Some of it you're like "wow we really need to fix this"
* Some you're like "well, maybe..."
* So let's get the contrib guide settled and then we can focus on the actual issues / recommendations
* Judy: One important thing we should decide is also the tech stack to render docs, readthedocs for python but it's not for everything else, etc
* Aditya: who needs to approve the guide?
* Justin: community, majority of the ITSC as well
* One thing to note is that Judy pointed we should modify parts that point back to Kubernetes
* Lots of mentions were already changed but some were kept to acknowledge where it came from / examples

#### How do we expose subproject docs?
* Tom: Witness + Archivista need a docs overhaul
* Opportunity for Tom and Kairo to help with this broader effort
* Something we've been discussing in Witness / Archivista is how we must be presenting docs on the website
* Right now, docs are just in the repo
* Should the website rendering be part of in-toto.io? Consistency? Sections for different projects?
* Important that people coming to in-toto can clearly see Witness / Archivista are part of in-toto
* Aditya: maybe a docs task force is in order?
* Justin: Judy raised a great point, we need to decide on the tool and we should do it ASAP, maybe as part of the guide definition
* Tom: Looking at a few options like mkdocs, docusource (and others)
* John: We're solving this problem for Witness / Archivista, should be generalizable to all repos in @in-toto
* Hopefully we can use the same tool to deploy / build all of this
* readthedocs has ads which is also something to think about, unless we opt to pay
* Justin: does CNCF have a preference?
* Judy: Maybe docusource, need to confirm with Nate W
* Action Item: organize task force on slack

#### AOB
* Justin: there's a seat on the TOC for maintainers, an in-toto maintainer could run
* We get one vote as a project
* Aditya: in-toto at KubeCon EU
* Jack: cross impl testing needs to move over

## 12/01/2023
INTERIM MEETING LINK: https://meet.google.com/aig-rasy-uxq

### Agenda
* New community member introductions (if any)
* Toddy
* David
* Thomas
* KubeCon Review
* Booth
* Shoutout from supply chain keynote (Fredrick)
* Good turnout for maintainers' talk
* SOTU
* Demo
* [ITE](https://github.com/in-toto/ite) 9-10 work
* Positive reception: 10/10
* People are still learning about supply chain security
* How do we make our tooling more accessible?
* When will the [video](https://www.youtube.com/watch?v=wuB--26-WpM) go up?
* [KubeCon NA 2023 playlist](https://www.youtube.com/watch?v=NcLAVtQ5H4A&list=PLj6h78yzYM2MYc0X1465RzF_7Cqf7bnqL)
* People want to understand the Attestation model
* CLOMonitor [updates](https://clomonitor.io/projects/cncf/in-toto)
* [Proposal] - Policy Working Group
* [Discussion] Datadog experiments
* Should subjects be materials or products in informational/transformational predicates?
* Should we support arbitrary policy languages/engines (e.g., Rego) in ITE-11?
* Happy to co-develop here
* Witness & Archivista donation follow-up?
* CNCF needs Santiago to file a legal review ticket
* [Discussion] Plugin Support?
* The Caddy [model](https://github.com/caddyserver/xcaddy)
* Use cases
* Mixing closed-source with open-source tooling
* Ideas
* Could we include some tooling/interfaces in the Attestation framework?
* e.g., gRPC interfaces for protobuf messages
* Pros: can implement different instances of the same interfaces
* Cons: maintenance overhead
* Witness as a "glue" tool
* Dynamic languages such as Python as "glue" tooling
* Any other business
* N/A

### Attendees
* John Kjell (TestifySec)
* Cole Kennedy (TestifySec)
* Mikhail Swift (TestifySec)
* Trishank Karthik Kuppusamy (Datadog)
* Toddy Mladenov (Microsoft)
* David Dooling (Docker)
* Thomas Meadows (TestifySec)
* Adam Nauth (Best Buy)
* Kairo De Araujo (TestifySec)
* Marcela Melara (Intel)
* Alan Chung Ma (Purdue)
*

### Notes
* (See agenda above)

## 11/03/2023
INTERIM MEETING LINK: https://nyu.zoom.us/j/91097299041

### Agenda
* New community member introductions (if any)
* KubeCon Demo (Marcela)
* KubeCon Planning
* Meeting agenda
* Booth personnel / schedule
* AOB

### Attendees
* Aditya Sirish (NYU)
* Justin Cappos (NYU)
* Jonny Stoten (Docker)
* Jack K (ControlPlane)
* Santiago Torres-Arias (Purdue)
* Marina Moore (NYU)
* Ian Dunbar-Hall (Lockheed Martin)
* John Kjell (TestifySec)
* Alan Chung Ma (Purdue)
* Tom Hennen (Google)
* Marcela Melara (Intel)
* Mikhail Swift (TestifySec)
* David Dooling (Docker)
* Lukas Puehringer (NYU)
* Adam Nauth (Best Buy)

### Notes

#### New community member introductions (if any)
* David Dooling from Docker

#### KubeCon Demo
* Dry run for KubeCon demo on Tuesday
* Some of it uses in-toto, some doesn't
* Lukas: Does the layout support a new DSL?
* Aditya / Marcela: ITE-11 adds CEL support
* Santiago: Part of the demo that fetches in other attestations has synergy with GUAC?
* Marcela: That's by design!
* https://github.com/in-toto/scai-demos/blob/main/docs/kccncna2023.md

### KubeCon Planning
* Meeting
* Monday at 10:30 AM local time
* Santiago: Possibly ITSC ought to meet too to discuss Witness/Archivista, graduation etc
* Justin: Not sure we can do a lot more about graduation at the moment, I reached out
* Santiago: How does Witness/Archivista donation affect graduation?
* John: There's precedent to something like this with other projects
* We've gotten more contributions to the projects as well, probably in part due to job listings
* Moving repos over will make things easier for people to contribute too
* We're ready to move things ASAP
* We also have some new folks joining who'll be working on open source things
* Santiago: We should add Witness/Archivista things to the meeting agenda
* Another thing to discuss is the Docker OpenPubKey
* John: There was also a discussion re OPK on #in-toto for Witness
* Some agenda items could also be in the TUF meeting in the afternoon to ensure the right people are in the rooms
* Santiago: in-toto + TFX is another thing we should discuss
* With a small delta, we could be using in-toto in tensorflow workloads
* Booth planning
* Sign up on the spreadsheet
* https://docs.google.com/spreadsheets/d/1Qnm05sI-4doYPhdjUNkX0NJYTuhMdE6HPmX_GnfpWlM/edit
* John: An overview doc
* Aditya: Any thoughts on printing out a hand out or so?
* John: Local print shops, we might be able to help

### AOB
* Jonny: Inspect cert contents in attestation-verifier
* Need to assert cert contents match predicate contents
* Tom: slsa-verifier does this types of checks on the cert for sigstore
* Aditya: TAP-18 helps with identity and issuer but other contents?
* Mikhail: ITE-7 can help here?
* Aditya: Yes but one of the requirements is a comparison of cert values and attestation values rather than separate checks on each
* It's a question of layers: in-toto separates signature verification from attestation verification
* But lines are blurred with sigstore signatures that embeds other information
* Maybe good to whiteboard?
* Santiago: How do we proceed?
* Jonny: I can share some sample policies I've been working on

## 10/06/2023
INTERIM MEETING LINK: https://nyu.zoom.us/j/91097299041

### Agenda
* New community member introductions (if any)
* Intel SCAI Donation
* in-toto/attestation-verifier repo transfer (Aditya)
* Witness / Archivista donation (John Kjell)
* in-toto <-> slsa-verifier? (Trishank?)
* SBOMit update (Ian or Marina or Justin)
* KubeCon Planning
* AOB
* Docker <-> OpenPubKey

### Attendees
* Justin Cappos (NYU)
* Aditya Sirish (NYU)
* Marcela Melara (Intel)
* Santiago Torres-Arias (Purdue)
* Tanner Jones (TestifySec)
* Tom Hennen (Google)
* Mike (TestifySec)
* Jack K (Control Plane)
* Kairo Araujo (VMware)
* Jonny Stoten (Docker)
* Ian Dunbar-Hall (Lockheed Martin)
* Adam Nauth (BestBuy)
* Mikhail Swift (TestifySec)
* John Kjell (TestifySec)
* Alan Chung Ma (Purdue)
* Trishank Karthik Kuppusamy (Datadog)

### Notes

#### New community member introductions
* Jonny Stoten
* From Docker, interested in adding signed attestations to Docker
* Mike
* From TestifySec, formerly GitLab
* Adam Nauth
* From Best Buy, exploring using in-toto for about a year, hoping to contribute, working through approvals
* Tanner Jones
* From TestifySec, Technical Account Manager working with US Navy

#### Intel SCAI Donation
* SCAI -> Supply Chain Attribute Integrity
* A predicate that captures attributes about artifacts
* Donation is of some APIs that use in-toto/attestation bits as well as some demos
* Also included is some policy checking code
* Repository is now under the in-toto org: https://github.com/in-toto/scai-demos

#### in-toto/attestation-verifier repo transfer
* Prototype verifier for ITE-10 and 11 layouts
* What about backwards compatibility?
* Handled with ITE-10 / ITE-11 and how they interplay with future in-toto spec versions
* Demo of the verifier
* General acceptance to move forward with this
* Link: https://github.com/in-toto/community/issues/14

#### Witness / Archivista donation
* John: TestifySec wants to donate these projects to in-toto
* Link: https://github.com/in-toto/community/issues/15
* Witness designed to be a modular with attestors for different integrations / systems
* Witness policies are similar to ITE-10/11 work
* Archivista is a mechanism to store attestations
* Verification becomes simpler by having attestations stored in a single place
* Archivista creates a graph based on attestation subjects, can be walked back during verification to pull in related attestations
* Looking for community thoughts and feedback, new attestors and predicates that can be added
* Marcela: I was looking at Sigstore's attestation storage capabilities
* Can you talk a bit about being able to provide similar auditability / transparency guarantees?
* Mikhail: with Archivista we're not focused on TL-like bits that Rekor does well
* We originally tried using Rekor as a store but didn't pan out
* Focused on being able to build a graph and search
* Mikhail: We consider Archivista "untrusted" to that end
* You put in attestations and pull them out, with Archivista providing hints
* "Trust but verify": Pull out attestations but actually verify against functionaries and so on with policies
* John: Archivista can store policies as well, and plan to use TUF in Archivista to bootstrap the policies
* ITE-2 + plan to wrap verification to generate attestation like the in-toto spec
* Aditya: supportive
* Marcela: related is the generalizing of the VSA predicate
* John: we ought to mark the projects appropriately to indicate maturity levels, especially with in-toto going up for CNCF graduation

#### in-toto <-> slsa-verifier
* Conversations ongoing to see if ITE-10/11 efforts can align with slsa-verifier

#### SBOMit
* Ian: TAC voted to accept project to sandbox
* SBOMit is a bridge between in-toto and SBOM generation to allow for verifying SBOM contents
* The project is primarily a specification
* Short term: provide attestations that can separately verify SBOM claims
* Long term: build in verification of SBOMs that use in-toto attestations

#### KubeCon Planning
* Booth
* Some folks have already signed up to help staff
* Justin also interested in helping out but not on the roster yet
* Alan: what is the goal of the booth?
* Aditya: Educate potential adopters / integrators about the project
* Project meeting
* Two hour meeting the day before KubeCon starts
* We should put together an agenda for that
* Get together at Chicago?
* Lunch or dinner would be nice
* Look at calendar and propose options for us to get together

#### Docker <-> OpenPubKey
* Tom: Can the Docker folks talk about OpenPubKey etc?
* Jonny: OpenPubKey removes CA compared to Sigstore
* Does need transparency logging and some other infra pieces to be a true solution in that space
* But not requring the CA was a consideration
* Tom: Would love to discuss more of the Sigstore context in that community
* We currently use Notary v1 for signing docker official images, but project is unmaintained
* We think Notation did not offer a particularly compelling story
* John: There was also some mention re TUF, more details?
* Jonny: Slightly less well defined in our heads
* Using TUF to distribute policy, so we know which key should be signing policy, attestations etc
* With OpenPubKey, we also need to distribute old OIDC public keys
* Could be just put them in a TUF repo
* We've also talked about using OpenPubKey to sign contents of a TUF repo but early days
* Trishank: maybe not the best meeting to discuss TUF but would love to welcome you to that community
* ITE-2 describes how TUF can be used with in-toto attestations
* Seems like OpenPubKey is less a Sigstore replacement and more a Fulcio replacement?
* Jonny: The way we want to use it at Docker is to remove that reliance on a CA
* More generally, that's not the purpose of OpenPubKey
* OpenPubKey could perhaps be used with Fulcio, so perhaps not really a direct alternative
* Trishank: We ought to understand how all these different systems work together, TUF, in-toto, Sigstore, OpenPubKey
* Justin: Marina Moore did a pretty detailed analysis of Sigstore etc, comparing with TUF and so on
* We'd be interested in working with you all to extend that to OpenPubKey
* Planned to reach out to Sharon

## 09/01/2023
INTERIM MEETING LINK: https://talky.io/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Meeting link moving forward
* CNCF TechDocs Assessment
* SCAI predicate donation (Santiago/Marcela)
* in-toto graduation proposal (Santiago)
* in-toto/friends script (Aditya/Santiago/high school)
* Witness Run Action for in-toto (John)
* Maintainer Review
* SLSA Source Track
* KubeCon Planning

### Attendees
* John Kjell (TestifySec)
* Aditya Sirish (NYU)
* Santiago Torres-Arias (Purdue)
* Mikhail Swift (TestifySec)
* Zach Steindler (GitHub)
* Alan Chung Ma (Purdue)
* Marcela Melara (Intel)
* Dave Welsch (CNCF TechDocs Assessment)
* Jack Kelly (ControlPlane)
* Dennis Zhang (NYU)
* Justin Cappos (NYU)

### Notes

#### New community member introductions

* Dave Welsch working on CNCF tech docs assessment for in-toto

#### Meeting Link moving forward

* We haven't had a lot of folks from communities who expressed concerns about Meet etc
* Maybe it's best to use CNCF / LF defaults with Zoom?
* AI: Santiago to explore options, perhaps hosted using Purdue credentials

#### CNCF TechDocs Assessment

* The TechDocs project was started at CNCF a couple years ago
* About 7 completed so far
* There's a criteria and rubric for documentation, ensures docs align with project's CNCF maturity
* Completed a first draft of the assessment
* Three areas: documentation itself, docs contributing information, the website
* Makes recommendations based on that evaluation and determines if aligns with project maturity
* PR coming soon on techdocs repo

#### SCAI Predicate Donation

* Marcela: Supply Chain Attribute Integrity predicate
* Express specific attributes for artifacts as attestations
* Supports attribute assertions (with some automation), showcases various use cases like properties of hardware platform, software stack, finegrained properties of the binaries being built
* Repo with some of these use cases and metadata: https://github.com/IntelLabs/supply-chain-attribute-integrity
* Santiago: Supports transferring this into the in-toto org, integrate with implementations, show off multi-predicate usecases more cleanly
* Justin: Does this require spec changes?
* Not specifically, under the purview of ITE-6, 10, 11
* Marcela: This transfer's been approved from the Intel side

#### in-toto Graduation Proposal

* https://github.com/cncf/toc/pull/1162
* Santiago: Thank you to everyone who contributed to the DD document!
* CNCF processes are in flux and they're still working out but as others have been submitting proposals, made sense to go ahead
* Requests community to help with this process, answer questions / provide clarifications as in-toto's grown and a lot of folks are unsure how it all works
* Justin: in-toto's verification with in-toto is pending
* Aditya: Let's start with in-toto-python
* We can start with an alpha verification workflow without trying to solve all the problems like the layout key distribution
* John: We've been working on this for Witness, described later in the meeting

#### in-toto/friends script

* Work primarily performed by a high school student over the summer
* https://github.com/in-toto/friends/tree/main/dependents-report
* Script populates the top 50 starred direct / indirect dependents of in-toto-golang
* Can be used to flesh out friends adoption stories

#### Witness Run Action for in-toto

* A GitHub action leveraging Witness to create different attestations
* Uses public instance of Archivista to store attestations
* Idea is to sign with sigstore and include TSA to enable verification without requiring rekor
* TestifySec has created a proof of concept to in-toto-golang's CI
* Witness defines several custom predicates that are generated by the action
* Link: https://github.com/testifysec/in-toto-golang/tree/witness_testing

#### Maintainer Review

* https://docs.google.com/document/d/1u0HTyOUZeXYIGGmiDk1GLRdaBlY_oGHUZDRe4tR8hyU/edit#heading=h.ed07efjkxz1h
* Some changes made with implementation specific teams, more work needed
* Santiago to help out with admin powers

#### SLSA Source Track

* https://github.com/slsa-framework/slsa/issues/956
* SLSA's started work on the source track
* in-toto's predicates for test results, code review etc can potentially be expanded / used for these SLSA requirements

#### KubeCon Planning

* We have a maintainer track talk
* We have a booth
* Sign up to help on the booth: https://docs.google.com/spreadsheets/d/1Qnm05sI-4doYPhdjUNkX0NJYTuhMdE6HPmX_GnfpWlM/edit?ouid=114763034171804471208&usp=sheets_home&ths=true
* We have a project meeting
* Nov 6th (Monday), 1030 AM

## 08/04/2023

### Agenda
* New community member introductions (if any)
* Graduation requirements
* Verify in-toto using in-toto
* Updated / completed in-toto/friends
* in-toto Cross-Implementation Test Setup (Pradyumna)
* Recent Discussions
* How not to verify attestations
* Media types
* Sigstore bundle vs DSSE signature extensions
* ITE-10
* Outreach
* Track on in-toto/community? Or in-toto/friends?
* S2C2F
* Alpha Omega
* Scorecard
* Maintainer review
* Attestation Review (Marcela)
* AOB

### Attendees
* John Kjell (TestifySec)
* Aditya (NYU)
* Ian Dunbar-Hall (Lockheed Martin)
* Marina Moore (NYU)
* Pradyumna Krishna
* Justin Cappos (NYU)
* Mikhail Swift (TestifySec)
* Lukas P (NYU)
* Jack K (ControlPlane)
* Tom Hennen (Google)
* Santiago Torres-Arias (Purdue)
* Marcela Melara (Intel)
* Zach Steindler (GitHub)
* Alan Chung Ma (Purdue)

### Regrets
* Trishank Karthik Kuppusamy (Datadog) [PTO]

### Notes

#### New community member introductions
* Marina: been a while
* Primarily works on TUF
* Pradyumna: previous GSoC contributor

#### Graduation Requirements
* Santiago: we're gearing up for CNCF graduation
* Been a year and some months since CNCF incubation
* Lot of traction and adoption since then
* GitHub, NPM, most CI systems have some form of attestation generation
* Companies building on in-toto semantics
* We're a mature project, belong with other graduated project
* We need to do some housekeeping in prep

##### Verify in-toto with in-toto
* Prototype available for in-toto-python
* Some similar work in our sister project TUF

##### Updated list of integrations / adoptions
* Major projects are using in-toto
* Looking through github dependents on in-toto-golang etc to track them
* Need to clean up forks and so on but major projects are using in-toto

##### Logistics
* No concrete date yet
* TOC indicating some reshuffle
* But targeting ASAP
* Hoping to get this done by KubeCon NA
* Seems like we have a lot of time but because there's a backlog we should hurry
* John Kjell: a month before KubeCon, they freeze votes and so on
* Non ITSC members are also encouraged to chip in any cycles they have!
* Most of the heavy lifting is done

#### in-toto Cross Implementation Testing
* Pradyumna: Developing the in-toto cross implementation test framework
* in-toto/demo as test script
* Basically, generating in-toto attestations using python impl, verifying with in-toto-go
* Also vice versa
* More work coming on DSSE tests and so on
* Aditya: we should move to the in-toto umbrella
* Also input re more tests and how maintainers need to react when something fails and so on
* ITSC will take up moving it to in-toto org when it's ready

#### Recent Discussions

##### How not to verify attestations
* Homebrew proposal discusses reconstructing attestations pre verification
* https://github.com/in-toto/attestation/issues/270
* Tom: some work on this in the spec already re parsing rules
* Homebrew language has been generalized now
* Santiago: there's a technical problem and a community question
* Are other communities intending to have rules that aren't in sync with in-toto's?
* Tom: I think not, we can just redirect the developers in this case to the parsing rules when the time comes
* AI: revisit the parsing rules again
* AI: engage with these devs as the time comes
* Aditya: this seems more like a misinterpretation in this one deployment case
* We can work with them

##### Media types
* How can a DSSE envelope expose a predicate type?
* Needs to be compatible with OCI store requirements re media type
* Useful to filter artifacts so that they can get only the provenance when necessary
* https://github.com/in-toto/attestation/issues/271
* Some constraints including length
* Aditya: A generic in-toto type may work for provenance now, bundle later?
* John: attestations are becoming larger
* Makes it important to be identify if worth downloading
* Marcela: important to provide guidelines
* Aditya: also things might fail open
* Serves as an unauthenticated predicate type
* Santiago: also maintianing another mapping complicates matters
* Marcela: perhaps we could update ITE-9 to include media type as well

##### DSSE Sig Extension vs Sigstore bundle
* Serialized sigstore bundle as a de-facto signature envelope
* Can't embed in in-toto attestation bundle
* Issue with supporting multiple signatures as well
* https://github.com/sigstore/sig-clients/issues/9
* Santiago: is it too hard to change the sigstore situation now?
* Aditya: engaging with them, proposed changes are compatible with sigstore's definitions so might be viable
* John: Is this a pattern? Are communities diverging?
* Santiago: in-toto was agnostic so there's a little bit of that
* Keep an eye on this and what we adopt as a recommendation
* Aditya: Not so much an in-toto spec issue but a DSSE didn't support extra fields at the time
* Marina: wrapping an envelope around an envelope in an untested way
* Duplication of fields and unclear how to process them
* AI: meet, talk with the clients, see how we can move towards a solution

#### ITE-10
* Approved to be merged as draft by Santiago
* Looking for feedback
* Plan to move prototype stuff into in-toto-golang, maybe Witness
* Marcela: Approved
* Tom: No further issues
* Santiago: merging as draft

#### Outreach
* Do we track on in-toto/friends?
* Better content strategy with blog posts, reaching out
* Blog post on SPDX for signing SBOMs using Sigstore
* Better way is to use in-toto and then sign

##### S2C2F Hackathon
* Good to have more cross pollination
* https://github.com/ossf/s2c2f/discussions/26

##### A-O and Scorecard
* A-O already technically using in-toto
* Scorecard has interest too
* https://github.com/ossf/scorecard/issues/3352

##### Should LF projects be using LF tools?
* A-O, Scorecard etc are LF projects
* Should we formalize at that level that these projecs should support generating as attestations?
* An endorsement at that level would be very useful
* Also: CI badging program
* John: Witness / Archivista community meeting coming
* Placement in CNCF: hopefully LF doesn't hold it against in-toto
* Non-cloud native adoptions
* Justin: CNCF does not like picking winners, even when there is only one solution
* ITSC can pick this up for cross LF integrations

#### Attestation Review
* Updates on the tooling and discussions re releasing next version
* Some support for go and py use of attestation framework
* in-toto and 3rd party implementations can directly use attestation framework as a dependency
* Verifying stability pre 1.1 release
* Working on outstanding issues

## 07/07/2023

### Agenda
* New community member introductions (if any)
* KubeCon NA Maintainer Track / ContribFest Proposal
* User panel discussing in-toto adoption stories + regulations
* Demo
* [Kairo de Araujo] Repository Service for TUF (RSTUF) will share updates about feature that is interesting for ITE-2
* https://github.com/repository-service-tuf/repository-service-tuf/issues/354
* Possibly relevant: Should cache artifacts be recorded as step materials / inputs?
* SLSA discussion: https://github.com/slsa-framework/slsa/issues/894
* Maintainer review

### Attendees
* Aditya Sirish (NYU)
* Adam Nauth (Best Buy)
* Ian Dunbar-Hall (Lockheed Martin)
* Jack Kelly (ControlPlane)
* Trishank Karthik Kuppusamy (Datadog)
* Victor Lu ()
* Santiago Torres-Arias (Purdue)
* Chasen Bettinger (Boost Security)
* John Kjell (VMware)
* Kairo de Araujo (VMware)
* Marcela Melara (Intel)
* Nisha (VMware?)

### Notes

#### New community member introductions
* Victor Lu
* Trying to understand this space of the security ecosystem
* Chasen Bettinger
* Previously at JupyterOne
* Now at Boost Security
* Trying to contribute to in-toto, have PRs open

#### Cache Artifacts
* Aditya: should links / provenance record cache artifacts as materials?
* https://github.com/slsa-framework/slsa/issues/894
* Santiago: Cache artifacts are intermediate artifacts
* We have a conditional on whether cache is used or not
* Jack: Cache is always going to be an impurity
* Must record you've used the cache, where it comes from, checksums
* Which build a cache came from even, chaining builds together
* Trishank: CI systems depend on container images, how do you record which one was used?
* Aditya: environment, parameters fields?
* Santiago: What about docker's cache? Intermediate layers should be incorporated
* Aditya: chaining build attestations for caches means we don't have distinct bundles
* Aditya: cache as a separate system and the build attestations point to its state attestations
* Santiago: We should document this
* Santiago: Explore how state of caches are poisoned + how we'd record it in in-toto attestations, explore security implications and document

#### KubeCon NA Maintainer Track + ContribFest
* A 40-45m slot
* A few different routes
* One is panel
* 5m: series of updates since last KubeCon
* Panel of users and maintainers
* Reached out to a few people who are already interested in joining panel
* The other is a more traditional talk
* SCAI demo
* Combine?
* 5 min intro / updates
* 5-10 min SCAI demo
* Jump into user stories for rest of the time
* What are the outcomes we want here?
* ITSC should decide
* in-toto hasn't focused on user stories so far
* There is more of an argument for panel
* Can SCAI demo be framed as a user story?
* Who is the audience for this talk? A panel requires a more experienced audience
* Proposal:
* Come up with a quick interview protocol for in-toto/friends / adopters
* Make a presentation out of this rather than have a full fledged panel
* We have the orgs and their stories represented
* "Here's how people are using in-toto" follows a traditional intro
* case studies
* Show off SCAI demo as well
* "Here's what's next", "Get involved"
* Santiago: Will discuss with missing members of ITSC as well
* Santiago: could also organize webinars with CNCF support

#### RSTUF and in-toto / ITE-2
* Kairo: RSTUF is a repository service for TUF
* Implements TUF as a service on the repo
* RSTUF has been used for an ITE-2 demo at OSS NA 2023
* RSTUF is missing some flexibility / features for ITE-2 still
* There are some tickets re these features
* RSTUF was designed for PEP458, PyPI
* Two in-toto aligned features:
* Any kind of delegated role using offline keys can be signed async
* Custom delegated roles, necessary for ITE-2 specific deployments
* Close to a first beta
* Santiago: Some background, ITE-2 is TUF + in-toto recommendation document
* Kairo: Deploy RSTUF instead of bespoke using TUF libraries, create ITE-2 roles
* Santiago: so you just configure RSTUF with the roles, simplifying deployment
* Kairo: RSTUF defaults to PEP 458 delegations structure, instead use ITE-2 structure
* With offline key support, ITE-2's other requirement will be met as well
* Nisha: looking at RSTUF to simplify deployments as well
* Kario: essentially making TUF adoption easy for everyone
* Kairo: contributions welcome!
* Beta coming in about a week, two of the three components already in beta but CLI is still alpha
* Beta won't have offline signing and custom delegations yet
* Other TUF features such as root key rotation etc will work in that release

#### Maintainer Review
* Review of maintainers of different in-toto subprojects
* Admin powers on the in-toto org need to be removed for Aditya etc
* ITSC will discuss and reach out to clean some things up
* Trishank will pick this up and follow up to remove privileges and so on

#### SCORED Deadline
* Now July 12th!
* Academic workshop for supply chain security colocated with ACM CCS
* Practitioner and research tracks, connect practitioners from both
* https://scored.dev/
* Reach out to Santiago or Marcela, on the org committee of SCORED

## 06/02/2023

### Agenda
* New community member introductions (if any)
* in-toto Spec v1
* Maintainer review
* Datalog for Policies (Shujun Qi)
* ITE-10/11

### Attendees
* Lois Anne DeLong (NYU)
* Sammy Gonzalez
* Aditya Sirish (NYU)
* Santiago Torres Arias (Purdue)
* Zach Steindler (GitHub, OpenSSF TAC)
* Trishank Karthik Kuppusamy (Datadog)
* Zack Newman (Chainguard)
* Shujun Qi (Chainguard)
* Cole Kennedy (TestifySec)
* Bob McWhirter (Red Hat)
* Marcela Melara (Intel)

### Notes

#### New Member Introductions
* Zack Newman, Bob McWhirter, Shujun Qi introduced themselves as first time attendees

#### in-toto Spec V1
* Merged a number of clarifications after the last meeting
* Aditya asked if there were any further concerns to address before it officially moves to V.1.0
* Trishank asked if there was a way to clarify some of the newer portions of the spec (i.e. new emphasis on attestations
* Should 1.0 be approved with a 2.0 roadmap?
* Aditya will submit a PR offering a 1.0 graduation review. The

#### Maintainer Review
* There is a need to review the status of in-toto projects in terms of who owns/maintains these programs
* This effort should include the development of clearer guidelines/requirements for these tasks.
* Aditya shared the following document and asked for review and comment https://docs.google.com/document/d/1u0HTyOUZeXYIGGmiDk1GLRdaBlY_oGHUZDRe4tR8hyU/edit?usp=sharingThe * The issue will be referred to the Steering Committee for Action

#### Datalog for Policies
* [Overall project plan](https://docs.google.com/document/d/1n6H2Ar73aKCvSB5rcOLlM24o9iUEUq1pIjoUCHE146o/edit#heading=h.3qv4zfsnqar9)
* [Demo repo](https://github.com/Shujun-Qi/PolicyEngineDemo)
* Shujin shared a brief demo of the project which proposes a policy engine.
* Trishank noted the importance of having a common language for these policies
* Bob McWhirter and Cole Kennedy referenced two other policy approaches
https://docs.seedwing.io/seedwing/index.html
https://github.com/testifysec/go-witness/tree/main/policy
* The important thing is not to push users to one particular policy engine. The idea is to review and take from these proposals the best features a standardized approach can eventually emerge.
* There's a need to consider ITE 10 and 11 in moving forward on determining best practices for policy languages.
* Bob McWhirter clarified that "our intended usage is as gates, perhaps in CI/CD, which looks at InToto and other metadata, not necessarily embedded *within* InToto."
* Aditya suggested that perhaps these issues are better addressed in its own subgroup.

#### Other Businesss
* Marcela "plugged" the SCORED workshop which is still seeking presentations.
https://scored.dev/

## 05/05/2023

### Agenda
* New community member introductions (if any)
* in-toto Spec clarifications merged
* https://github.com/in-toto/docs/blob/master/in-toto-spec.md
* in-toto/attestation Updates
* KubeCon EU report
* Maintainer review
* Misc. updates

### Attendees
* Lois Anne DeLong (NYU)
* Trishank Kathik Kuppusamy (Datadog)
* Aditya Sirish (NYU)
* Jack Kelly (Control Plane)
* Marcela Melara (Intel)
* Tom Hennen (Google)
* John Kjell (VMware)
* Ian Dunbar-Hall (Lockheed Martin)
* Cole Kennedy (TestifySec)
* Victor Lu

### Notes

#### New Community Members
* Jack Kelly of Control Plane introduced himself

#### in-toto Spec Clarification
* Aditya reported that the clarifications have been merged.
* The current status Of V1-RC can be found here https://github.com/in-toto/docs/blob/master/in-toto-spec.md

#### in-toto/attestation Updates
* Marcela: v1.0 of attestation spec released
* Tooling aspects: support for Go, Python, (soon) Java bindings
* in-toto implementations can use these as dependencies
* New predicates: test-results predicates
* Trishank: NPM Publish Attestations https://github.com/npm/attestation/tree/main/specs/publish/v0.1
* Aditya: Can we use links?
* Tom: VSA could be generated instead but packaging ecosystems may not be ready to make SLSA level claims yet
* Cole: ITE-10 could use these predicates to link build to packaging steps and so on
* Ian: would generate such attestations when package enters corp network
* Trishank: more specific predicates may be necessary until folks are ready to use layouts and generalized links
* Will loop Frederick in about upstreaming this

#### KubeCon EU Updates
* Maintainers talks attracted about 70 people
* Cole presented a demo of Witness
* Created movement on SLSA
* Aditya: Prepared a press release about timed to KubeCon, but it did not go out because CNCF missed our PR support request.
* Quotes can be added to an existing Google Doc

#### Maintainer Review
* A maintainer review of in-toto projects is needed.
* Aditya will set up a list of active projects and determine which should be prioritized for review.
* Add consistent processes/requirements for maintainers
* https://github.com/in-toto/community/blob/main/CONTRIBUTING.md

#### Misc. Updates
* There have been a number of releases on in-toto projects over the past few weeks, including
* A recent security audit revealed at least one issue to be resolved https://github.com/in-toto/docs/security/advisories/GHSA-p86f-xmg6-9q4x

## 04/07/2023

### Agenda
* New community member introductions (if any)
* Logistics
* Retiring meeting invite
* CNCF Calendar
* https://tockify.com/cncf.public.events/monthly?search=in-toto
* https://www.cncf.io/calendar/
* Governance & Elections Update
* First ITSC elected!
* in-toto Spec v1.0 (planned)
* in-toto Attestations v1.0 released
* Next Steps for ITEs
* ITE-6
* Up for acceptance
* https://github.com/in-toto/ITE/pull/48
* ITE-10
* Outreach efforts?
* Chainloop
* TACOS
* CycloneDX Attestations Working Group
* OpenSSF WGs
* ...
* in-toto & secure boot?
* Witness & Archivista
* KubeCon EU

### Attendees
* Lois Anne DeLong (NYU)
* Aditya Sirish (NYU)
* Justin Cappos (NYU)
* Santiago Torres Arias (Purdue)
* Zack Steindler (GitHub)
* Ian Dunbar-Hall (Lockheed Martin)
* Cole Kennedy (TestifySec)
* Sammy Gonzalez (Lockheed)
* Alan Chung Ma (Purdue)
* Parth Patel (Kusari)
* Mikhail Swift (TestifySec)

### Notes

#### Logistics
* Aditya noted that in-toto community meetings are now listed on the CNCF Calendar https://www.cncf.io/calendar/
* Moving forward meeting announcement will be posted only at this site.

#### Governance & Elections Update
* Santiago noted a board has been elected and their activities will be starting shortly. The new in-toto Steering Committee (ITSC) is:
* Santiago Torres-Arias, Academia, Purdue
* Justin Cappos, Academia, NYU
* Jack Kelly, Industry, ControlPlane
* Cole Kennedy, Industry, TestifySec
* Trishank Karthik Kuppusamy, Industry, Datadog

#### in-toto Spec v1.0 Planned
* Clarifications: https://github.com/in-toto/docs/pull/75
* Also worth considering: specifying format for exclude patterns
* https://github.com/in-toto/docs/issues/71

#### Attestations V1.0 Updates
* Released the first issue of predicate guidelines

#### ITEs

##### ITE 6
* Aditya asked if there were any objections to merging ITE 6
* Justin agreed to approve the one open PR and the ITE was merged.

##### ITE 10
* Aditya will be updating the current PR for this ITE, which updates in-toto layouts with mechanisms to verify the contents of new attestation types.
* Review and comments on the PR at https://github.com/in-toto/ITE/pull/38 are welcome.

#### Outreach Efforts
* Santiago called for volunteers that can work to support the use of in-toto. Recent project communities to which we could be raising awareness of in-toto include:

* Chainloop
* TACOS
* CycloneDX Attestations Working Group
* OpenSSF WGs

* There is a need to be more vocal about what in-toto is and does.
* Is there an in-toto presence on social media?
* Aditya is working on a blog post, which should clarify how much work "under the hood" is done by in-toto
* It was suggested we need to make some in-roads with the Open SSF communities.
* It was agreed to move this issue to the ITSC for their input and perhaps the formation of a task force to work on this issue.

#### in-toto and Secure Boot
* How could in-toto attestations be used to attest to more than just the software
* Don't neglect the Windows side -- not just Linux

#### Witness & Archivista
* Cole Kennedy did a presentation on the Witness and Archivista. The former "provide a source of rich trusted meta data for policy decisions." The latter serves as a "store for in-toto attestations," which are indexed on in-toto subjects.
* Archivista-supports any in-toto attestations and can produce records for all hashes. They are linked together by their in-toto hashes.
* The plan is to donate this project to the in-toto project.
* The presentation can be viewed at https://docs.google.com/presentation/d/1iF4iVdfl6WO_vdCj3C5BU_0E3QufGCxb6HyR1Dpj6s0/edit#slide=id.p
* One issue he mentioned was a need to collaborate across an open source standard.
* Lifecycle includes different forms of attestors, so data is collected at different stages. Two other attestors--product and metadata--collect this information in a form that can be consumed for specific purposes.
* At build time, all the system's libraries will be gathered together.

#### KubeCon EU
* Aditya made another request asked for project updates for KubeCon EU.

## 03/03/2023

### Agenda

* New community member introductions (if any)
* Governance & Elections
* KubeCon EU
* Next steps for ITEs
* ITE-10
* ITE-9
* AoB
* Foreshadowing new version of Witness

### Attendees
* Lois Anne DeLong (NYU)
* Trishank Karthik Kuppusamy (DataDog)
* Justin Cappos (NYU)
* Alan Chung Ma (Purdue)
* Wiktor Kozlik (Google)
* Santiago Torres Arias (Purdue University)
* Parth Patel (Kusari)
* Cole Kennedy (TestifySec)
* Marcela Melara (Intel)

### Governance and elections
* Santiago started by explaining the rationale for the change in governing structure.
* He shared a document that presents the framework and process for the election, which was fundamentally inspired by SPIFFE.
* Santiago will manage this initial procedure, but it is understood that once the governing group is elected, they can review and/or amend the process.
* He proposed that the nomination process will begin on March 4, with the group commencing work on April 11.
* Justin questioned whether the timetable for the process would impact eligibility for graduation, as the governance piece was one of our current missing pieces. He suggested we perhaps move the election process forward a bit.
* In response, Santiago suggested announcement of election results could be moved forward to March 31. The first action of the new group would then be to apply for graduation.
* The proposed election procedure will not include term limits, but this again is something the new committee can chang once it begins its work.

### KubeCon EU
* Santiago suggested setting some goals for this conference.
* Aditya is scheduled to present.

### Next steps for ITEs

#### ITE-6
* This has been merged as a draft. What is needed to move forward?

#### ITE-9
* This is still in draft process. What is needed to merge?
* Decided to hold off on discussion since its champion, Aditya, was not present

#### ITE-10
* Trishank noted that ITE 10 would allow for the use of other languages for attestations/layouts. Specifically,it "classifies policy definitions in in-toto layouts as pertaining to artifacts (already supported) and to properties of a software supply chain step," and "prescribes the use of existing policy languages such as CUE and Rego to define property policies.""
* Cole noted that ITE 10 includes work done for Witness. (See https://github.com/testifysec/witness-examples/tree/main/keypair)

#### Other Business
* Cole requested that an agenda item be included for the next meeting to discuss the upcoming new version of Witness. If interested, there is an action available on the Witness repo that can be reviewed.

## 02/10/2023 Meeting

### Call Information
* 11 AM **EST**
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Roadmap
* https://github.com/in-toto/docs/blob/master/ROADMAP.md
* Governance
* Witness / Archivista (Cole Kennedy / Mikhail Swift)
* https://github.com/testifysec/witness
* https://github.com/testifysec/archivist
* in-toto Specification v1.0
* Future versioning?
* Next steps for ITEs
* ITE-6
* https://github.com/in-toto/ITE/issues/41
* ITE-9
* ITE-10: Layouts for in-toto Attestations

### Attendees
* Lois Anne DeLong (NYU)
* Aditya Sirish (NYU)
* Alan Chung Ma (Purdue)
* Sanket Naik (Palosade)
* Trishank Karthik Kuppusamy (Datadog)
* Ian Dunbar-Hall (Lockheed Martin)
* John Kjell (VMware)
* Justin Cappos (NYU)
* Tom Hennen (Google)
* Keith Ganger (Lockheed Martin)
* Santiago Torres-Arias (Purdue)
* Cole Kennedy (TestifySec)
* Parth Patel (Kusari)
* Jarod Heck (Lockheed Martin)
* Marcela Melara (Intel)

### Notes

#### Roadmap
(See https://github.com/in-toto/docs/blob/master/ROADMAP.md)
* Aditya introduced the roadmap and encouraged review and feedback
* He noted that some things may be changed based on today's discussion

#### Governance
* Santiago presented the rationale for moving to a less top-down governance structure.
* The revised structure will be more in line with practices in other open source communities.
* Santiago would step down as consensus builder and would be replaced by an elected board of five members. He did stipulate that he hopes there would continue to be an academic presence on this board--at least one person or perhaps a set percentage.
* There was some discussion about the balance of representation on this board (i.e. percentage of academics, percentage of those already involved in an in-toto project)
* Santiago will be organizing the election. There will be more news about this in the coming weeks.

#### Witness / Archivista (Cole Kennedy / Mikhail Swift)
* https://github.com/testifysec/witness
* https://github.com/testifysec/archivist
* TestifySec is donating Witness and Archivista to the in-toto namespace.
* These two open source tools help organizations implement in-toto at scale.
* This process is currently in the works and will occur soon. It is waiting on the installation of a new governing board.
* Witness is currently the most up-to-date with ITEs.
* Hoping to finalize in time for KubeCon North America.

#### in-toto Specification v1.0
* Need to define what V1.0 is meant to entail in terms of ITEs
* Should future versions be tied to the release of particular ITEs?
* Santiago suggested that ITEs 6-10 be version 2.0.
* Trishank made a case for including ITE 6 in V1.0 because the attestation information may impact the release of SLSA 1.0.
* Cole cautioned not being too quick to close off the discussion on ITE 6 and 10.
* Decision was V1.0 should include ITEs 1-5, but some current aspects of ITE could be included.
* The attestation piece should not be held back by the work that still needs doing in ITE 6.

#### Next steps for ITEs

##### ITE-6
(see https://github.com/in-toto/ITE/issues/41)

##### ITE-9

##### ITE-10: Layouts for in-toto Attestations
https://github.com/in-toto/ITE/pull/38
* Currently in very early draft form
* Feedback is welcomed

#### Other business
* Aditya talked a bit about PBoms and will be having further discussions with the group that developed this (https://pbom.dev/)

## 01/06/2023 Meeting

### Call Information
* 11 AM **EST**
* https://meet.jit.si/in-toto-community-meeting

### Agenda
* New community member introductions (if any)
* Roadmap / Review
* https://github.com/in-toto/docs/blob/master/roadmap-reviews/2022/review_3_december_22.md
* Priorities for Roadmap 2023
* in-toto/community
* https://github.com/in-toto/community
* in-toto Specification v1.0 Planning
* ITE-5 Appendix: https://github.com/in-toto/ITE/pull/35
* Next steps for ITEs
* ITE-6
* ITE-7
* ITE-9
* ITE-2 tooling effort with TUF maintainers
* https://github.com/in-toto/in-toto/pull/444
* in-toto-python DSSE support
* in-toto-java / Jenkins Plugin SLSA Provenance v0.2
* SecCon / KubeCon EU

### Attendees
* Aditya Sirish (NYU)
* Justin Cappos (NYU)
* Ian Dunbar-Hall (Lockheed)
* Mikhail Swift (TestifySec)
* Lois Anne Delong (NYU)
* Trishank Karthik Kuppusamy (Datadog)
* Wiktor Kozlik (Google)
* Lakshya Gupta (GSoC)
* Santiago Torres-Arias (Purdue)
* Sanket Naik (Palosade)
* Parth Patel (Kusari)
* j-k
* Marcela Melara (Intel)

### Notes

#### New community member introductions (if any)
* Sanket Naik of Palosade was welcomed to the group

#### Roadmap / Review
See https://github.com/in-toto/docs/blob/master/roadmap-reviews/2022/review_3_december_22.md

* Aditya asked for suggestions of what should be prioritized in the next Roadmap.
* Conduct more formal reviews of existing projects so we can better prioritize support.
* Offer some guidance in terms of standards/norms, including better documentation on existing projects.
* Better storage and indexing for attestations, such as those being developed/supported by Guac
* Include the predicate dictionary
* "Evangelization for adoption?"
* Solutions that better support ITE 6 in the Reference Implementation.
* Roadmap should be up to date and active by the next meeting.

#### in-toto/community
https://github.com/in-toto/community

* Aditya noted that this repository should serve as a central landing point for community issues and encouraged its use

#### in-toto Specification v1.0 Planning
* The question raised was should the project accept the current specification as V. 1.0.
* If so, are ITE's such as ITE 5 to be included.
* See ITE-5 Appendix: https://github.com/in-toto/ITE/pull/35

#### Next steps for ITEs

##### ITE 9
* Created the ITE Predicate Review Team
* Having a formal acceptance route for new predicate types is needed to encourage new adopters
* ITE 6 should be addressed in parallel with this.
* Before the next meeting, Aditya and Santiago will review ITE 6 to see what might be missing.

##### ITE-7
* Once the implementations have merged the new changes, this can be accepted.

* ITE-2 tooling effort with TUF maintainers
https://github.com/in-toto/in-toto/pull/444

#### in-toto-python DSSE support
* Very close to having support in place for this within the next week or so.

#### in-toto-java / Jenkins Plugin SLSA Provenance v0.2
* This is very close to release as well.

#### SecCon / KubeCon EU
* The next Community Meeting will be moved back a week to avoid conflict with these conferences.

# Old Meeting Notes

https://hackmd.io/@adityasaky/ry4Wuico3