Skip to content

Define Entry Trust Manifest publisher-domain alignment - #107

Draft
jonathanhefner wants to merge 1 commit into
Agent-Card:mainfrom
jonathanhefner:agent/trust-manifest-publisher-domain-alignment
Draft

Define Entry Trust Manifest publisher-domain alignment#107
jonathanhefner wants to merge 1 commit into
Agent-Card:mainfrom
jonathanhefner:agent/trust-manifest-publisher-domain-alignment

Conversation

@jonathanhefner

Copy link
Copy Markdown
Contributor

Summary

The specification requires a Trust Manifest’s identity domain to align with the publisher domain in the containing Catalog Entry’s identifier. That requirement cannot currently be applied consistently because Catalog Entry identifiers are extensible, not every identifier communicates a publisher domain, and the alignment procedure is undefined.

This PR defines a clear boundary for core Entry Trust Manifests: they are supported on Catalog Entries with publisher-authorized urn:air identifiers. Entries with other identifiers remain valid Catalog Entries, but cannot include a core Entry Trust Manifest.

For supported entries, the specification defines interoperable publisher-domain alignment for did:web, HTTPS, and SPIFFE identities. When alignment cannot be established, consumers disregard the Trust Manifest’s claims and apply their normal policy for an entry without a usable Trust Manifest.

ADR-0024 records this decision and its rationale. The accompanying documentation and examples are updated accordingly.

Rationale

This keeps two distinct use cases separate:

  • Registries can publish Catalog Entries using non-urn:air identifiers when they cannot truthfully assign a publisher-controlled identifier.
  • Entry Trust Manifests remain publisher-scoped and therefore require an identifier that communicates the publisher domain unambiguously.

The specification can add support for other identifier or identity forms later if it defines an equally unambiguous publisher-domain relationship for them.

Publisher-domain alignment is only a consistency check. It does not establish domain control, publisher or signer authorization, signature validity, artifact integrity, authenticity, or trust. Those properties continue to require their corresponding verification procedures and an independent trust policy.

Related work

This PR addresses the publisher-domain alignment concern in #70.

It complements #105, which permits registries to use non-urn:air identifiers while intentionally leaving Trust Manifest behavior out of scope.

It proposes a narrower alternative to the identity-related change in #81. That PR’s digest concern is independent.

#104 is currently a merge prerequisite because it removes examples that would otherwise contradict this rule.


AI usage disclosure: This PR was developed with AI assistance under my direct supervision and review.

Make the existing publisher-domain requirement interoperable by limiting Entry Trust Manifests to publisher-authorized `urn:air` entries and defining how `did:web`, HTTPS, and IDNA-shaped SPIFFE identities supply the comparison domain.

Delegate identity syntax to the governing standards, compare complete IDNA2008 domains exactly after ASCII case normalization, and keep ports, paths, queries, and fragments in the identity but outside publisher-domain comparison. Keep publisher authorization as a producer requirement while defining the consumer response when usable alignment cannot be established.

Record that alignment checks consistency only and that a Trust Manifest signature covers its `identity` but not the containing Catalog Entry identifier by itself. Update stale identity examples, the authoring guide, and ADR-0024 to reflect the boundary.

Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
@jonathanhefner

jonathanhefner commented Sep 6, 2026

Copy link
Copy Markdown
Contributor Author

I am now recommending #110 instead of this PR.

#110 establishes an end-to-end interoperability baseline, whereas this PR only tries to elminate ambiguity in one part of the spec. I'll leave this PR open until a decision is made on #110, but will convert to draft.

@jonathanhefner
jonathanhefner marked this pull request as draft September 6, 2026 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant