[design] where do attestations and evidence fit into the layers?

[trumant]

Overview

Layer 4 assessments evaluate input data which could include attestations of compliance to one or more controls and their requirements and can capture and/or produce output data in the form of evidence.

Both of these concepts, attestations and evidence can be incorporated into one or more of the layers, resulting in a richer, more communicative schema and one that affords the functionality that is common in compliance assessment and audit use cases.

Next Steps

• Propose schema changes and accompanying documentation via PR
• Socialize proposed schema changes with impacted community members
• Generate new Go types to represent the evidence and attestation concepts

[eddie-knight]

"attestations and evidence can be incorporated into one or more of the layers"

Hey @trumant, could you elaborate on this? The evidence gathered and attestation results are both useful in the audit activities, and potentially during enforcement, but I don't anticipate any changes would be necessary for that.

Privateer adds "payload" as an interface / un-typed object... perhaps we could add that in the layer 4 schema?

[trumant]

@eddie-knight See https://github.com/trumant/pvtr-github-repo/blob/redesign-payload-interface/architecture.md#input-evidence-data-from-multiple-sources-may-duplicate-andor-make-conflicting-assertions and the sections that follow that speak to this.

My claim, broadly, is that layer 4 should evolve, specifically that AssessmentRequirement should expand to have a notion of AssessmentMethods that capture input data to the assessment process and also capture the evidence/facts that the method used to reach a conclusion.

My belief is that exporting this richer, more detailed data from Layer 4 will dramatically improve the capabilities of Layers 5 and 6.

[xee5ch]

Layer 4 assessments evaluate input data which could include attestations of compliance to one or more controls and their requirements and can capture and/or produce output data in the form of evidence.

Maybe to step back a bit, what do we specifically mean by attestation of compliance to one or more controls? Some standards and developer communities consider attestation and endorsement separate things, but it is hard to know what is meant by attestation here.

I am very interested in the design piece and will check out @trumant's attestation architecture spec in the branch. Is the place to provide relevant feedback about it?

[eddie-knight]

Sure, I'm curious to get more thoughts here

[trumant]

what do we specifically mean by attestation of compliance to one or more controls

What "I" meant when I wrote the issue is specifically an in-toto attestation, see https://github.com/in-toto/attestation?tab=readme-ov-file#in-toto-attestation-framework as I logged this issue to quickly record some conversation that was occurring during a working group meeting.

[jpower432]

My claim, broadly, is that layer 4 should evolve, specifically that AssessmentRequirement should expand to have a notion of AssessmentMethods that capture input data to the assessment process and also capture the evidence/facts that the method used to reach a conclusion.

+1 in support of the introduction of AssessmentMethods and the standardization of metadata for raw evidence.

A couple of benefits I see:

• AssessmentMethods could support expressing multiple validation technologies per requirement. This could be useful if a requirement needed automated and human review for different aspects of the validation.
• Providing information about the inputs/artifacts could enable Layer 4 to be "audit-ready" by offering traceability to the supplementary data/evidence for aggregation in Layer 6.