Trust Manifest MUST rules cannot be satisfied by open identifier formats or the spec's own appendix examples

[liady]

Two normative MUSTs in the Trust Manifest section cannot be satisfied by the spec's own appendix examples, because both rules assume structure that the open formats do not guarantee.

1. Identity binding is undefined for non-URN identifiers

"Trust Manifest > Identity" says:

the identity field's authority or trust domain MUST align with the publisher domain segment of the entry's URN identifier field. ... Consumers MUST reject a Trust Manifest whose identity domain does not align with the publisher domain of the entry's identifier.

But identifier is explicitly an open text format (any URI or URN; the urn:air form is only recommended, and custom formats are expected for closed or local systems). The "Mapping to Claude Code Plugins Marketplace" appendix itself uses urn:claude-plugin:adspirer:ads-agent style identifiers, which have no domain segment at all - so a conformant consumer following the MUST would have to reject the Trust Manifests in the spec's own examples.

The binding rule needs a scoping clause: e.g. it applies when the identifier uses the urn:air form (or another domain-anchored scheme), and consumers fall back to other verification (publisher attestations, signatures) otherwise.

2. Digest rejection rule vs the appendix's sha1 examples

"Verification Procedures > Digest Format" says: "Consumers MUST reject digest values using algorithms shorter than SHA-256."

The same Claude Plugins appendix maps the marketplace's source.sha (a git commit SHA) to trustManifest.provenance[].sourceDigest as "sha1:...". Two problems:

• The examples violate the MUST: consumers are required to reject exactly the digests the appendix shows.
• A git commit SHA is a revision identifier, not a content digest of anything a consumer can fetch and hash, so mapping it to sourceDigest is arguably a category error regardless of algorithm (related to the artifact-integrity issue).

Suggested resolution: either carve out revision identifiers from the digest rule (e.g. a separate sourceRevision field), or change the appendix mapping so sha lands in metadata rather than sourceDigest.

[rrrodzilla]

@liady's part 1 is right, and the scoping clause in #81 should land. But the clause moves the MUST onto a test that the spec never tells a consumer how to run.

The rule today:

Consumers MUST reject a Trust Manifest whose identity domain does not align with the publisher domain in the containing entry's identifier.

#81 scopes that "to identifiers that carry a publisher domain segment (such as the urn:air form)". Given an arbitrary identifier string, a consumer has to answer three questions at runtime, and the spec answers none of them:

1. does this identifier carry a publisher domain segment
2. which segment is it
3. what counts as "align" (exact match, suffix match, registrable domain)

For urn:air you can answer 1 and 2 by reading ADR-0015 and counting colons. That's fine while the rule is a SHOULD. As a MUST, getting it wrong means a consumer accepts a signed trust claim from the wrong publisher.

I wouldn't leave this to implementers, because a mis-parsed identifier doesn't raise anything. It hands back a domain, just not the right one, and the alignment check then runs against that. I hit this in July on the URI scheme I wrote (arXiv 2601.14567). Someone proposed an extension that inserted extra segments into the path, and I ran one of their examples through my own published reference parser. It parsed, put the new segments into the capability path, and derived the lookup key 031da299... instead of the d9786664... that the identity on its own derives. A resolver using that key looks in the wrong place and finds nothing, and no layer reports an error. The extension also reserved a delimiter that one of my published test vectors was already using as an ordinary path segment, so you couldn't tell the two forms apart without a version marker.

Reading the proposal didn't surface either one. I only had them because the scheme has a grammar, a canonical form, and test vectors, which is the same set I'd want from any scheme the alignment rule recognizes:

• a normative grammar (ABNF) that says which production is the publisher authority, so nobody has to infer it from the examples
• a defined canonical form, so two spellings of the same identifier compare equal before the alignment check runs
• published test vectors, so you can check that two implementations agree rather than assume it

agent:// publishes all three, and I'm pointing at them as an example of what that looks like in practice, not proposing it as an identifier here. urn:air should stay exactly as ADR-0015 accepted it.

As a follow-up to #81 rather than a competitor to it, the spec could either name the schemes the alignment rule recognizes and point at each one's grammar, or state the properties a scheme needs to count as domain anchored. I'm happy to draft either. Separately, #81 has been open a month with a merge conflict and no review, and the fix in it is worth landing regardless.