Group trust metadata by contributor and generalize signatures

[jonathanhefner]

Summary

Allow publishers, assessors, and federated registries to contribute trust metadata about the same artifact, with independent signatures over the fields each endorses.

Area	Current design	Proposed design
Trust metadata	One entry.trustManifest	entry.trustManifests[identity], each retaining its attestation and provenance arrays
Signatures	Entry signature covers the whole Trust Manifest; separate root signature	Separate signatures arrays on entries and the catalog root, selecting fields through arrays of keys
Artifact binding	Release fields repeated in entry.trustManifest.subject	Sign the entry’s release fields and entry.digest directly
Policy URLs	Inside the signed Trust Manifest	Shared entry fields; signing coverage follows the selected paths

Motivation

• Independent contributions. A publisher can sign its source provenance while an assessor signs its audit evidence for the same release. If each selects its own Trust Manifest and the shared release fields, the assessor can update its evidence without invalidating the publisher’s signature. A registry can add its own contribution alongside both.
• Flexible coverage. Signers can endorse entry extensions or other relevant fields. Catalog operators can sign Host Info through root signatures or endorse the complete catalog snapshot.
• Reuse existing standards. Detached JWS and JCS authenticate selected paths, values, and timestamps. The existing did:web rules authenticate independent contributors while preserving the additional checks for publisher authority.

Rationale

ADR-0028 explains the construction and tradeoffs.

The schema, guides, mappings, examples, and threat model are updated together.

Notes

• Dependencies: #108, #109, and #110.
• Validation: Specification and strict documentation builds, example checks, and local signing tests.

[jonathanhefner]

Submitted as Agent-Card#117.