Feature request: Support signing Model Card metadata

[Ali6x1000]

Problem

Currently, model-transparency signs model artifacts (weights/files) but does not cryptographically bind the model's metadata (e.g., license, authorship, intended use) to the signature. This allows documentation to be altered without invalidating the model's signature.

Proposed Solution

Add a --readme flag to the CLI that parses Hugging Face-style YAML front matter from a Model Card (README.md). This metadata should be validated and injected into the in-toto predicate during the signing process.

This ensures that the model's context and metadata are verified alongside the artifacts themselves.

[ralphbean]

I think I don't agree that the modelcard details should be encoded directly in the predicate. The modelcard contains a lot of useful information, but it acts like another claim - claiming some facts about the model. I think we would be overloading the integrity-verification purposes of the OMS signature if we embedded modelcard details inside it. However, I agree that we need a way for a consumer to know what other claims may have been present at the time of model signing. I'm trying to work through some ideas around that over at https://docs.google.com/document/d/10FYbIMi2GAz4rtwvusreip9GmkYWJX1w2IDH-fLuqmI/edit?tab=t.civkgucbp9ya

[sevansdell]

I think this is important to figure out! I have had conversations with Hidden Layer (Eowin Wickins) about this, and there was an understanding that the model card contents itself might evolve over time through standardization with CoSAI. For now I see the two high level questions as:

1. What can be the requirement to sign/attest what is in the model card as we allow its contents to standardize over time. And,
2. how should that model card signing/attestation be related to the model signing/attestation.

[mihaimaruseac]

+1, I think this needs to wait until CoSAI standardization. It's too early now to place in just one single place.

For 2: we also need to support the case where the model card is available at train (or signing) time (unlikely, but this is the scenario where we can include it in the signature), versus when it becomes available later (at which point, it is better to have it in another attestation, rather than generating a new signature)