feat(spec): Trust Manifest threat modeling review - suggested updates.

[muscariello]

• Require a present Trust Manifest to carry a substantive member (signature, attestations, provenance, or trustSchema); ADR-0015.
• Add a substrate-neutral distribution-mapping contract with OCI and xRegistry bindings; ADR-0014.

[github-actions]

Preview: https://ai-catalog.io/pr/47/

This comment is updated automatically while the pull request preview is available.

[muscariello]

@darrelmiller @mindpower I went through a threat modeling session on the trust manifest. This is the set of modifications that I suggest to address some of the comments by Pamela and others.

I did not do an accurate analysis since quite some time and if we want to get to v1 this is necessary.

[ramizpolic]

This PR can also resolve the issue (Support multiple identities per catalog entry #52) depending if we have a decision. It may be useful extend this PR to include multiple trustmanifests, which would address both the concerns around identity and threat modelling in one go.

[olijboyd]

I've implemented what this PR specifies end to end, because I wanted TomeVault's own catalog signed this way rather than waiting for v1, so I can offer some evidence from the implementing side. The subject binding closes the substitution case cleanly. Our vector suite runs the swap both ways, a validly signed pre-binding manifest accepts a substituted artifact, and the same swap fails once subject is inside the signed payload, which is ADR-0015's argument demonstrated in running code. The signatures verify under jwcrypto and authlib as well as our own verifier, so the signing input is interoperable rather than just self-consistent, and it isn't only a lab exercise either: tomevault.io serves its catalog with this binding today, subject digest bound to the mcp.json bytes actually being served, if anyone wants a live implementation to poke at.

Three things bit me on the way through, offered as notes rather than review findings.

The one that genuinely blocks a conformant implementation is a field-name mismatch the binding check depends on. The Catalog Entry prose defines the artifact's media type as type, "the media type declared in the type field", while specification/examples/ai-catalog.json and ADR-0014 both say mediaType, so subject.mediaType is checked against an entry field the normative prose never defines. We went with mediaType to match the examples and the binding, but it wants settling one way or the other before v1.

F7 can be satisfied by a fetch that still fails two ways, and I know because ours did: a rebind between the address check and the connection, and a redirect off a validated URL into somewhere private. Resolving once, pinning the connection to the validated address, and refusing redirects closed both, and it may be worth the ADR saying that much, because "validate the target" reads as satisfied by a one-time check in front of an ordinary HTTP client.

The large-integer caveat is real in practice too. An integer outside the JCS-safe range throws mid-canonicalisation, so a verifier has to catch that and return a rejection instead of letting it surface as an internal error.

If a reference verifier, or the threat-model document ADR-0014 points at (trust-manifest-threat-model.md isn't in the repo yet), would help this land, I'm glad to contribute either. The reason we lean on this PR so hard is that the attestations we attach are quality and consistency claims about content that drifts, and that kind of claim only means anything bound to the exact bytes it was made about. Once this lands I'd like to bring an attestation type for measured quality and consistency, but that's a follow-up and this PR comes first.