Gemara + in-toto: audit-layer attestation and trust boundaries

Summary

Drafted with 🤖 and reviewed /heavily edited by human 😃

Continues: #23 (closed via #450, which addresses the questions around evidence). This issue picks up the remaining piece: how attestation crosses trust boundaries at the audit layer (Layer 6), and how in-toto/SLSA fits there.

The Evidence model gave Evaluations a way to cite the data that informed a conclusion. That answers "what did this assessment look at." It doesn't yet answer "how does a third party come to trust the result without re-running it". This is where in-toto attestation becomes relevant for Gemara integration, and where Layer 6 (AuditLog) currently has no defined relationship to it.

Considered Options

Gemara as Material

Gemara AuditLog points at SLSA/in-toto attestation already exists and lets that attestation's own subject/materials carry the trust. No new consumer requirement for the in-toto ecosystem.

It might look like this:

• A Policy defines a requirement.
• An SVR simple verification result references the Policy it was checked against.
• A trusted verification process derives high level yes/no outcomes from Enforcement and Evaluation Logs and applies properties
• SLSA provenance is generated for how the SVR was produced; its subject digest identifies the SVR, and its materials/resolvedDependencies are the EvaluationLog/EnforcementLog that fed the check. That chain-of-custody is entirely in-toto's structure (thus Gemara doesn't need to also model it)
• An AuditResult.evidence[] cites one Evidence entry pointing at the provenance attestation. Dereferencing it yields both the SVR's identity and what backed it (via materials). No separate Gemara-side link is needed between "the SVR" and "its provenance," because that relationship already lives inside the attestation document itself.

Gemara as Predicate Type

An EvaluationLog and/or Enforcement Log is itself an assertion someone may want to ship and verify independently. The use case of "this tool produced this EvaluationLog, on this date, covering these controls" isn't expressible in an existing predicate. This matters if a consumer wants to verify the EvaluationLog's own integrity/authorship directly, not just its role as material for something else's build or drawn conclusion. However, some of the Gemara fields conflict with in-toto's -- Resource/ResourceDesctiptor and metadata.gemara-version would duplicate the url in the predicateType. Resource doesn't currently have a digest because it is always meant to reference an artifact. Evidence is meant to reference artifacts associated with a Resource to inform the results.

Additional Considerations

Compliance against any control catalog may require assertion for controls where the underlying checks don't share one scope.

A OSPS Baseline example:

• some are machine-checkable per repo,
• some are machine-checkable per org,
• some require human assertion about project procedures, with no sharable artifact to point at.

Open Threads

1. Does AuditResult.evidence[] citing one Evidence entry → an SVR/provenance attestation match what others assume?
2. Who produces the SVR: maintainer-asserted roll-up, consumer re-derivation from materials?
3. Given in-toto's existing SVR predicate (verifier.id, verifier.policies, properties) already covers some of what a Gemara-specific predicate would need to invent, does Gemara ever need its own predicate type, or does EvaluationLog/EnforcementLog fields just map into SVR's properties?
4. Technical Debt: #EvidenceMapping is @status("stable") while #Evidence, which embeds it and is itself reachable through the stable #EvaluationLog/#AssessmentLog, is still marked @status("experimental"). A label mismatch that understates real breaking-change risk.