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.

[olijboyd]

AIR is letting a publisher sign their resource and a consumer record what it fetched. But there's no independent third party verification yet… Whether an instruction or skills file is any good, and whether it has quietly drifted since it was listed, is the part that actually protects the user, and today it can only live in a vendor extension. A grade sitting in a vendor extension is just a value. Anyone re-serving the catalog can flip it from bad to good and nothing in AIR tells the consumer to check.

I already setup TomeVault to grade AI instruction & skills files; now I've implemented AIR so it also signs the verdict, and monitors them for conformance and drift. The flat tv: values on the entry credit the original author and are fine for discovery, but they're only a hint, not something to trust. The grade you trust comes from a signed record which the entry references by digest. A consumer reads the grade from that signed record and ignores the flat values when the two disagree. I've signed 180k+ skills this way.

This is already built and public. The reference verifier is Apache-2.0 (https://github.com/tomevault-io/ai-catalog-reference), ships the substitution-attack tests, and verifies the record against the published key. A matching JavaScript verifier on npm checks the same records. You can pull one and check it yourself. Fuller write-up: https://tomevault.io/docs/attestation/agent-conformance-air-extension.

I'd like to help make third-party verification a real part of the standard so I'd value your read on whether this is the right way to close it.

[mindpower]

The latest adr is 0016. Update the number here?

[mindpower]

I don't remember that we require that.

The AI Catalog specification requires alignment (domain binding), not an exact match.

The identifier and the identity will almost never be exact matches because they serve different purposes and use different URI schemes (e.g., a urn:air:... versus a spiffe://... or did:web:...).

What the specification strictly requires is that the authority/trust domain embedded in the identity matches the publisher domain segment inside the identifier.

For example,:

• identifier: urn:air:example.com:travel:concierge (Publisher domain = example.com)
• identity: spiffe://example.com/travel/concierge (Authority domain = example.com)

This satisfies the spec because the domains align (example.com), cryptographically binding the workload to the authorized publisher namespace. The strings themselves do not need to be exactly the same.

[mindpower]

This statement is not correct.

identity and identityType do not restate or describe the entry identifier.

The purpose if identity is entirely different from the identifier:

• identifier describes the logical name used for catalog search and discovery (e.g., urn:air:example.com:travel:concierge).
• identity and identityType describe the Cryptographic Workload Principal—meaning they define who actually owns and runs the agent at runtime (e.g., a spiffe type identity like spiffe://example.com/travel/concierge).

Rather than restating the discovery name, identity and identityType provide the cryptographic anchor used for zero-trust security, runtime authentication, and verifiable compliance.

[mindpower]

1. this is not an valid agent identifier name (should start with urn:air::...)
2. The identityType below is "did" but the identity is not did.

[mindpower]

Please update the sequence number.