Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attestation Context\Meta-data\Meta-information #78

Open
dn-scribe opened this issue Dec 21, 2021 · 0 comments
Open

Attestation Context\Meta-data\Meta-information #78

dn-scribe opened this issue Dec 21, 2021 · 0 comments

Comments

@dn-scribe
Copy link

Following #58 here, opening the mentioned issue.

The statement-level meta-data should hold enough information to enable:

  1. Simple policy decisions that are agnostic to the predicate details.
  2. Enable a first level of indexing of the attestations for later recall.
  3. Enable parsing of the predicate.

The current mandatory fields in the statement level are the subject and the predicate-type, which is, as a matter of fact, the predicate-media-type.

Fields that could be of use at the statement level include:
Predicate abstract type - "sbom", "provenance"
Predicate media type - the exact format (uri) (for SBOM- SPDX, SPDX-Lite, CycloneDX, for provenance - slsa-provenance)
When was the attestation taken: Timestamp #46
Where was the attestation taken: Location in pipeline - . I suggest an abstract location and a specific location: the abstract context could be a string with recommended values (user workstation, git-server, build machine etc.), and the specific context could be some machine ID.
Project id - could be a url such as https://github/myproject or simply a string set by the entity creating the attestation. There is a difference between the project id and the subject; the subject would typically be an artifact, but a project may produce many subjects.
One could of course use multiple subject fields (as supposed to be supported), but that is not natural.
An application specific object field - it is always convenient to have a placeholder for a generic object for implementation-specific. As I understand this is supposed to be supported see the parsing rules, but it would be better not to rely on the "undefined" but to explicitly define an application-specific object placeholder.

Such fields enable elaborated policies at the statement level (for example: require an sbom produced at build, without caring about the SBOM details), and would enable indexing to support searching attestations: search by project, subject, time, part of pipeline etc.

What are the attestation community thoughts about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant