--- a/base/index.html
+++ b/head/index.html
@@ -13,6 +13,12 @@
       "shortName": "ai-catalog",
       "edDraftURI": "https://ai-catalog.io/",
       "localBiblio": {
+            "xRegistry": {
+                  "title": "xRegistry: A Universal Registry Specification",
+                  "href": "https://github.com/xregistry/spec",
+                  "status": "Draft",
+                  "publisher": "CNCF"
+            },
             "RFC8785": {
                   "title": "JSON Canonicalization Scheme (JCS)",
                   "href": "https://www.rfc-editor.org/rfc/rfc8785",
@@ -23,6 +29,18 @@
                   "title": "JSON Web Key (JWK)",
                   "href": "https://www.rfc-editor.org/rfc/rfc7517",
                   "status": "RFC",
+                  "publisher": "IETF"
+            },
+            "RFC7518": {
+                  "title": "JSON Web Algorithms (JWA)",
+                  "href": "https://www.rfc-editor.org/rfc/rfc7518",
+                  "status": "RFC",
+                  "publisher": "IETF"
+            },
+            "RFC8725": {
+                  "title": "JSON Web Token Best Current Practices",
+                  "href": "https://www.rfc-editor.org/rfc/rfc8725",
+                  "status": "BCP 225",
                   "publisher": "IETF"
             },
             "RFC6234": {
@@ -57,7 +75,7 @@
 
 <section id="abstract">
   <h2>Abstract</h2>
-  <p>This document defines the AI Catalog, a JSON format for discovering heterogeneous AI artifacts such as MCP servers, A2A agents, Claude Code plugins, datasets, and model cards. Each catalog entry declares the artifact's type via a media type and references or inlines the native artifact metadata, enabling a single discovery mechanism across protocols and platforms. The specification defines three conformance levels — Minimal, Discoverable, and Trusted — allowing implementations to start with a simple list of entries and progressively add host identity, well-known URI discovery, and verifiable trust metadata as needed. An optional Trust Manifest extension provides identity binding, compliance attestations, provenance tracking, and cryptographic signatures without wrapping or modifying the artifact's native format. Informative appendices describe mappings to OCI distribution registries, the MCP Registry server.json format, and the Claude Code Plugins marketplace.</p>
+  <p>This document defines the AI Catalog, a JSON format for discovering heterogeneous AI artifacts such as MCP servers, A2A agents, Claude Code plugins, datasets, and model cards. Each catalog entry declares the artifact's type via a media type and references or inlines the native artifact metadata, enabling a single discovery mechanism across protocols and platforms. The specification defines three conformance levels — Minimal, Discoverable, and Trusted — allowing implementations to start with a simple list of entries and progressively add host identity, well-known URI discovery, and verifiable trust metadata as needed. An optional Trust Manifest extension provides identity binding, compliance attestations, provenance tracking, and cryptographic signatures without wrapping or modifying the artifact's native format. Informative appendices define a substrate-neutral distribution-mapping contract and concrete bindings to OCI distribution registries and xRegistry, plus mappings to the MCP Registry server.json format and the Claude Code Plugins marketplace.</p>
 </section>
 
 <section id="sotd">
@@ -199,11 +217,13 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:air:example.com:mcp:weather&quot;,
+      &quot;displayName&quot;: &quot;Weather Service&quot;,
       &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
       &quot;url&quot;: &quot;https://api.example.com/.well-known/mcp/server-card.json&quot;
     },
     {
       &quot;identifier&quot;: &quot;urn:air:example.com:a2a:research&quot;,
+      &quot;displayName&quot;: &quot;Research Assistant&quot;,
       &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
       &quot;url&quot;: &quot;https://agents.example.com/researchAssistant&quot;
     }
@@ -219,6 +239,13 @@
 <dd>An open map of string keys to arbitrary values for custom or
   non-standard metadata. See <a href="#metadata-extensibility">Metadata Extensibility</a>
   for key naming conventions.</dd>
+<dt><code>signature</code></dt>
+<dd>A string containing a detached JWS [[RFC7515]] signature computed over
+  the JCS-canonicalized [[RFC8785]] catalog document (excluding the
+  <code>signature</code> member itself), providing catalog-level integrity over the
+  <code>entries</code> array and <code>host</code>. It is verified exactly as a Trust Manifest
+  signature (see <a href="#trust-manifest-signatures">Trust Manifest Signatures</a>).
+  See <a href="#trust-manifest-substitution">Trust Manifest Substitution</a>.</dd>
 </dl>
 </section>
 <section id="host-info">
@@ -275,6 +302,8 @@
 <p>For closed or local systems where a different identifier format is used, client implementations are responsible for parsing and processing the custom format as appropriate.</p>
 <p>See <a href="#multi-version-entries">Multi-Version Entries</a> for uniqueness rules when multiple versions are present.</p>
 </dd>
+<dt><code>displayName</code></dt>
+<dd>A string containing a human-readable name for the artifact.</dd>
 <dt><code>type</code></dt>
 <dd>
 <p>A string containing the identifier that specifies the type of the
@@ -310,23 +339,6 @@
 </dl>
 <p>The following members are OPTIONAL:</p>
 <dl>
-<dt><code>displayName</code></dt>
-<dd>A string containing a human-readable name for the artifact.
-  This field SHOULD be set only when the referenced artifact does not
-  already carry its own canonical human-readable name — for example a
-  raw dataset (<code>application/parquet</code>), a model blob, or a skill bundle
-  (<code>application/agent-skills+zip</code>), none of which embed a self-describing
-  name. When the referenced artifact does carry such a name — for
-  example the <code>name</code> field of an A2A Agent Card or the <code>title</code> field of
-  an MCP Server Card — that artifact is the authoritative source and
-  <code>displayName</code> SHOULD be omitted to avoid duplicating a value that can
-  drift out of sync. When <code>displayName</code> <em>is</em> present, however, it takes
-  precedence: it is the authoritative value for display, and a consumer
-  SHOULD render it as given even when it differs from a name carried by
-  the referenced artifact. Setting <code>displayName</code> is how a publisher
-  deliberately overrides the artifact's own name. See
-  <a href="#resolving-an-artifacts-display-name">Resolving an Artifact's Display Name</a>
-  for the full consumer resolution order.</dd>
 <dt><code>description</code></dt>
 <dd>A string containing a short description of the artifact.</dd>
 <dt><code>tags</code></dt>
@@ -351,35 +363,6 @@
   providing verifiable identity and trust metadata for this artifact.
   See <a href="#trust-manifest">Trust Manifest</a> for details.</dd>
 </dl>
-<section id="resolving-an-artifact-s-display-name">
-<h3>Resolving an Artifact&#x27;s Display Name</h3>
-<p>Because <code>displayName</code> is OPTIONAL, a consumer rendering a catalog entry
-cannot assume it is present. To obtain a human-readable name, a consumer
-SHOULD resolve one in the following order:</p>
-<ol>
-<li><strong><code>displayName</code> on the entry</strong>, if present. A publisher-supplied
-   <code>displayName</code> always wins, even when it differs from a name carried by
-   the referenced artifact.</li>
-<li><strong>The referenced artifact's own canonical name</strong>, if the consumer has
-   already fetched or cached the artifact — for example the <code>name</code> field
-   of an A2A Agent Card or the <code>title</code> field of an MCP Server Card.</li>
-<li><strong>The trailing segment of the entry's <code>identifier</code></strong> as a last
-   resort — the portion after its final <code>:</code> or <code>/</code> delimiter. For
-   example, <code>urn:air:example.com:mcp:weather</code> yields <code>weather</code> and
-   <code>urn:air:anonymous.modelcontextprotocol.io:mcp:brave-search</code> yields
-   <code>brave-search</code>.</li>
-</ol>
-<p>A consumer SHOULD NOT dereference an artifact at render time solely to
-obtain a name. A registry, directory, or other service built on top of a
-catalog SHOULD resolve the name once at ingestion — alongside any other
-derived metadata it attaches, such as relevance scores or tags — and
-cache the result, rather than fetching artifacts on the rendering path.</p>
-<p>This order also covers a referenced MCP Server Card whose <code>title</code> is
-itself absent: step 2 yields no name, so the consumer falls through to
-the <code>identifier</code> segment in step 3. A publisher MAY still set
-<code>displayName</code> on such an entry to provide a better name than the bare
-identifier segment.</p>
-</section>
 </section>
 <section id="multi-version-entries">
 <h2>Multi-Version Entries</h2>
@@ -401,6 +384,7 @@
   &quot;entries&quot;: [
     {
       &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance&quot;,
+      &quot;displayName&quot;: &quot;Acme Finance Agent&quot;,
       &quot;version&quot;: &quot;2.1.0&quot;,
       &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
       &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance/v2.1.json&quot;,
@@ -408,6 +392,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance&quot;,
+      &quot;displayName&quot;: &quot;Acme Finance Agent&quot;,
       &quot;version&quot;: &quot;2.0.0&quot;,
       &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
       &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance/v2.0.json&quot;,
@@ -463,17 +448,44 @@
   identity schemes is open.</dd>
 </dl>
 <p>When a Trust Manifest appears within a Catalog Entry, the <code>identity</code>
-field's authority or trust domain MUST align with the publisher domain segment of
-the entry's URN <code>identifier</code> field. This binding ensures trust claims are
-cryptographically bound to the authorized publisher of the catalog entry.
-Consumers MUST reject a Trust Manifest whose identity domain does not
-align with the publisher domain of the entry's <code>identifier</code>.</p>
+field MUST match the entry's <code>identifier</code> field. This binding ensures trust
+claims are unambiguously associated with the catalog artifact.
+Consumers MUST reject a Trust Manifest whose <code>identity</code> does not
+match the containing entry's <code>identifier</code>. The <code>identity</code> is restated
+here — rather than read from the entry's <code>identifier</code> — so that it falls
+within the signed payload; this is an intentional duplication, not
+redundant metadata, and removing it would leave the signature uncommitted
+to which identifier the trust claims apply.</p>
 <p>When a Trust Manifest appears on a Host Info object, <code>identity</code>
 SHOULD match the host's <code>identifier</code> field when present.</p>
 <p>When multiple entries share the same <code>identifier</code> (with different <code>version</code>
 values), each entry MAY carry its own Trust Manifest. There is no
 requirement that all versions carry identical trust metadata — trust
 properties may evolve across versions.</p>
+</section>
+<section id="manifest-validity">
+<h2>Manifest Validity</h2>
+<p>A Trust Manifest exists to carry verifiable trust evidence; an empty one
+adds nothing and misleads consumers into believing trust metadata is
+present. Beyond the required <code>identity</code>, a Trust Manifest MUST therefore
+contain at least one <em>substantive</em> trust member:</p>
+<ul>
+<li>a <code>signature</code> (with its required <code>subject</code> and <code>issuedAt</code>),</li>
+<li>a non-empty <code>attestations</code> array,</li>
+<li>a non-empty <code>provenance</code> array, or</li>
+<li>a <code>trustSchema</code>.</li>
+</ul>
+<p>The members <code>identity</code> and <code>identityType</code> (which restate or describe the
+entry identifier) and the informational members <code>privacyPolicyUrl</code>,
+<code>termsOfServiceUrl</code>, and <code>metadata</code> do NOT satisfy this requirement.
+<code>subject</code>, <code>issuedAt</code>, and <code>expiresAt</code> are not substantive on their own:
+an unsigned <code>subject</code> digest is attacker-settable and unverifiable, so
+they count only as part of a <code>signature</code>.</p>
+<p>A Trust Manifest that would carry only non-substantive members MUST be
+omitted entirely rather than included empty — the <code>trustManifest</code> member
+is itself OPTIONAL, so no information is lost. Consumers SHOULD treat a
+Trust Manifest that violates this rule as if no Trust Manifest were
+present.</p>
 </section>
 <section id="optional-members">
 <h2>Optional Members</h2>
@@ -498,13 +510,33 @@
   artifact.</dd>
 <dt><code>termsOfServiceUrl</code></dt>
 <dd>A string containing a URL to the terms of service.</dd>
+<dt><code>subject</code></dt>
+<dd>A Subject object as defined in <a href="#subject-binding">Subject Binding</a> that
+  cryptographically binds this Trust Manifest to the specific artifact it
+  describes. A Trust Manifest that carries a <code>signature</code> MUST include a
+  <code>subject</code>.</dd>
+<dt><code>issuedAt</code></dt>
+<dd>A string containing an ISO 8601 [[RFC3339]] timestamp indicating when
+  the Trust Manifest was created and signed. A Trust Manifest that
+  carries a <code>signature</code> MUST include <code>issuedAt</code>.</dd>
+<dt><code>expiresAt</code></dt>
+<dd>A string containing an ISO 8601 [[RFC3339]] timestamp after which the
+  Trust Manifest MUST be considered stale. Consumers SHOULD reject a
+  Trust Manifest whose <code>expiresAt</code> is in the past.</dd>
 <dt><code>signature</code></dt>
-<dd>A string containing a detached JWS [[RFC7515]] signature computed
-  over the Trust Manifest content. This enables integrity verification
-  of the trust metadata independent of the artifact.</dd>
+<dd>A string containing a detached JWS [[RFC7515]] signature computed over
+  the canonicalized Trust Manifest content, including the <code>subject</code> and
+  <code>issuedAt</code> members. Because the signed payload commits to the artifact
+  digest carried in <code>subject</code>, neither the trust claims nor the artifact
+  reference can be substituted without detection. See
+  <a href="#trust-manifest-signatures">Trust Manifest Signatures</a>.</dd>
 <dt><code>metadata</code></dt>
 <dd>An open map of string keys to arbitrary values for extending trust
-  metadata.</dd>
+  metadata. Unlike the Catalog Entry's <code>metadata</code> (which is
+  informational and unsigned), this map is part of the signed payload
+  when the Trust Manifest carries a <code>signature</code>; use it for extensions
+  that must be cryptographically bound to the manifest, and use the
+  entry's <code>metadata</code> for unsigned, informational extensions.</dd>
 </dl>
 <p>For example, a Trust Manifest with identity, attestations, and
 provenance:</p>
@@ -538,9 +570,53 @@
   ],
   &quot;privacyPolicyUrl&quot;: &quot;https://acme-corp.com/legal/privacy&quot;,
   &quot;termsOfServiceUrl&quot;: &quot;https://acme-corp.com/legal/terms&quot;,
+  &quot;subject&quot;: {
+    &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance/v2.1.json&quot;,
+    &quot;mediaType&quot;: &quot;application/a2a-agent-card+json&quot;,
+    &quot;digest&quot;: &quot;sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08&quot;
+  },
+  &quot;issuedAt&quot;: &quot;2026-03-15T10:00:00Z&quot;,
   &quot;signature&quot;: &quot;eyJhbGciOiJFUzI1NiJ9..detached-jws-signature&quot;
 }
 </code></pre>
+</section>
+<section id="subject-binding">
+<h2>Subject Binding</h2>
+<p>The Subject object binds a Trust Manifest to the specific artifact it
+describes, closing the substitution gap in which an attacker who
+controls the catalog document leaves a validly-signed Trust Manifest in
+place but repoints the entry to a different artifact. Because the
+Subject is part of the signed payload, the artifact reference and its
+content digest cannot be changed without invalidating the signature.</p>
+<p>A Subject object MUST contain:</p>
+<dl>
+<dt><code>mediaType</code></dt>
+<dd>A string containing the media type of the bound artifact. This MUST
+  equal the containing Catalog Entry's <code>mediaType</code>.</dd>
+<dt><code>digest</code></dt>
+<dd>A string containing the cryptographic digest of the artifact content,
+  in the format defined in <a href="#digest-format">Digest Format</a>. For an
+  artifact referenced by <code>url</code>, the digest is computed over the exact
+  bytes served. For an artifact embedded in <code>data</code>, the digest is
+  computed over the JCS-canonicalized [[RFC8785]] JSON value.</dd>
+</dl>
+<p>The following member is OPTIONAL:</p>
+<dl>
+<dt><code>url</code></dt>
+<dd>A string containing the URL of the bound artifact. When present, it
+  MUST equal the containing Catalog Entry's <code>url</code>. Consumers MUST reject
+  a Trust Manifest whose <code>subject.url</code> does not match the entry's <code>url</code>.</dd>
+</dl>
+<p>A Trust Manifest that carries a <code>signature</code> MUST include a <code>subject</code>.
+When verifying such a manifest, consumers MUST confirm that the fetched
+artifact's media type and digest match the <code>subject</code> before relying on
+any claim in the Trust Manifest. See
+<a href="#verifying-artifact-integrity">Verifying Artifact Integrity</a>.</p>
+<p>The <code>subject.mediaType</code> and <code>subject.url</code> intentionally restate the
+entry's <code>mediaType</code> and <code>url</code> so that those values fall within the signed
+payload. This is a deliberate duplication, not redundant metadata:
+without it, an attacker who controls the catalog document could change
+the entry's media type or location without invalidating the signature.</p>
 </section>
 <section id="trust-schema-object">
 <h2>Trust Schema Object</h2>
@@ -639,6 +715,30 @@
 <p>This section describes how consumers verify the trust metadata
 carried by a Trust Manifest. Verification is OPTIONAL — consumers
 that do not need trust assurance can skip this entirely.</p>
+<section id="safe-fetching">
+<h3>Safe Fetching</h3>
+<p>Verification procedures direct consumers to fetch URLs that originate in
+the Trust Manifest itself (<code>attestation.uri</code>, <code>statementUri</code>,
+<code>registryUri</code>, and key-resolution endpoints). Because a manifest may be
+attacker-controlled before its identity is anchored, these fetches are a
+server-side request forgery (SSRF) and denial-of-service surface.
+Consumers performing verification MUST:</p>
+<ul>
+<li>Resolve and reject URLs targeting private, loopback, link-local, or
+  cloud metadata addresses (e.g., <code>127.0.0.0/8</code>, <code>::1</code>,
+  <code>169.254.0.0/16</code>, <code>fc00::/7</code>, <code>10.0.0.0/8</code>, <code>172.16.0.0/12</code>,
+  <code>192.168.0.0/16</code>), and re-check the resolved address after any
+  redirect.</li>
+<li>Restrict fetches to the <code>https</code> scheme (or inline <code>data:</code> URIs) and
+  refuse to follow redirects that cross into a disallowed address range.</li>
+<li>Enforce a maximum response size and a request timeout. When
+  <code>attestation.size</code> is present, reject responses that exceed it; in all
+  cases apply a consumer-defined ceiling.</li>
+<li>Treat every fetched document as untrusted input.</li>
+</ul>
+<p>Consumers SHOULD prefer inline <code>data:</code> attestations and Data-URI logos
+to avoid leaking verification activity to third-party endpoints.</p>
+</section>
 <section id="digest-format">
 <h3>Digest Format</h3>
 <p>Digests in this specification use the format <code>algorithm:hex-value</code>,
@@ -651,20 +751,53 @@
 </section>
 <section id="trust-manifest-signatures">
 <h3>Trust Manifest Signatures</h3>
-<p>The <code>signature</code> field carries a detached JWS [[RFC7515]] computed
-over the Trust Manifest content. To create or verify a signature:</p>
+<p>The <code>signature</code> field carries a detached JWS [[RFC7515]] computed over
+the Trust Manifest content, including the <code>subject</code> and <code>issuedAt</code>
+members. To create or verify a signature:</p>
 <ol>
 <li><strong>Canonicalize</strong> the Trust Manifest JSON using JCS (JSON
-   Canonicalization Scheme) [[RFC8785]]. Remove the <code>signature</code>
-   field itself before canonicalization.</li>
-<li><strong>Sign</strong> (or verify) the canonical bytes as a detached JWS
-   payload using the publisher's private (or public) key.</li>
-<li><strong>Encode</strong> the resulting JWS in compact serialization and store
-   it in the <code>signature</code> field.</li>
+   Canonicalization Scheme) [[RFC8785]]. Remove the <code>signature</code> field
+   itself before canonicalization; all other members — including
+   <code>subject</code> and <code>issuedAt</code> — remain in the signed payload.</li>
+<li><strong>Select an algorithm</strong> from the allowlist in
+   <a href="#signature-algorithms">Signature Algorithms</a>. The JWS <code>alg</code> header
+   parameter MUST identify the algorithm used.</li>
+<li><strong>Sign</strong> (or verify) the canonical bytes as a detached JWS payload
+   using the publisher's private (or public) key.</li>
+<li><strong>Encode</strong> the resulting JWS in compact serialization and store it
+   in the <code>signature</code> field.</li>
 </ol>
-<p>This approach ensures the signature is stable regardless of JSON
-key ordering or whitespace, and can be verified independently of the
-artifact content.</p>
+<p>This approach ensures the signature is stable regardless of JSON key
+ordering or whitespace. Because the signed payload includes the
+<code>subject</code> binding, a verified signature commits the publisher to a
+specific artifact digest, not merely to the trust claims.</p>
+<p>Producers SHOULD avoid placing numeric values that do not round-trip
+under JCS serialization (e.g., integers outside the range exactly
+representable as IEEE 754 doubles) in a signed Trust Manifest, as such
+values can cause a verifier's canonicalization to differ from the
+producer's. Where large integers are required, encode them as strings.</p>
+</section>
+<section id="signature-algorithms">
+<h3>Signature Algorithms</h3>
+<p>To prevent signature-forgery attacks, producers and consumers MUST
+constrain the JWS algorithms used for Trust Manifest signatures.</p>
+<ul>
+<li>Consumers MUST reject a signature whose JWS <code>alg</code> header is <code>none</code>.</li>
+<li>Consumers MUST reject symmetric (MAC-based) algorithms such as
+  <code>HS256</code>; Trust Manifest signatures MUST use an asymmetric algorithm so
+  that verification cannot be performed with attacker-supplied secret
+  material (preventing public-key-as-HMAC-secret confusion).</li>
+<li>Producers MUST use, and consumers MUST support, one or more of the
+  following asymmetric algorithms [[RFC7518]]: <code>ES256</code>, <code>ES384</code>,
+  <code>EdDSA</code>, <code>PS256</code>, <code>PS384</code>, or <code>RS256</code>.</li>
+<li>Consumers MUST determine the expected algorithm and key from the
+  resolved trust anchor (see <a href="#trust-anchoring">Trust Anchoring</a>) and
+  MUST NOT let the <code>alg</code> header alone select a verification algorithm in
+  a way that downgrades security. Consumers SHOULD pin the expected key
+  via the JWS <code>kid</code> header.</li>
+</ul>
+<p>These constraints follow the JSON Web Token current best practices
+[[RFC8725]].</p>
 </section>
 <section id="key-resolution">
 <h3>Key Resolution</h3>
@@ -686,6 +819,29 @@
   or look up a DNSKEY/TXT record containing the JWK thumbprint.</dd>
 </dl>
 </section>
+<section id="trust-anchoring">
+<h3>Trust Anchoring</h3>
+<p>Verifying a Trust Manifest signature proves that the manifest was signed
+by the holder of the key associated with its <code>identity</code>. It does NOT, by
+itself, prove that the <code>identity</code> is the legitimate publisher of the
+artifact. An attacker who controls the catalog document can replace both
+the <code>identity</code> and the key it resolves to, then sign the forged manifest
+with their own key — every internal check would still pass.</p>
+<p>Consumers MUST therefore anchor the <code>identity</code> (or signing key) to a
+trust root established out of band, independent of the catalog document.
+Acceptable anchors include:</p>
+<ul>
+<li>A pinned allowlist of trusted publisher identities or keys.</li>
+<li>A registry or marketplace that vets publisher identities and serves
+  the catalog over a channel the consumer independently trusts.</li>
+<li>An identity method that proves control of a name the consumer already
+  trusts (e.g., a <code>did:web</code> whose domain matches an expected publisher,
+  validated against that domain's TLS-authenticated endpoint).</li>
+</ul>
+<p>A verified signature without an anchored identity establishes integrity
+and internal consistency only; consumers MUST NOT treat it as proof of
+publisher authenticity.</p>
+</section>
 <section id="verifying-host-identity">
 <h3>Verifying Host Identity</h3>
 <p>To verify the host of a catalog:</p>
@@ -710,17 +866,37 @@
 <li>Confirm the JWT claims bind the <code>publisher.identifier</code> to the Trust
    Manifest's <code>identity</code>.</li>
 </ol>
+<p>The <code>publisher</code> object resides on the Catalog Entry, outside the Trust
+Manifest signature. Consumers MUST treat <code>publisher</code> fields as advisory
+unless a verified <code>publisher-identity</code> attestation cryptographically
+binds <code>publisher.identifier</code> to the signed manifest's <code>identity</code>.</p>
 </section>
 <section id="verifying-artifact-integrity">
 <h3>Verifying Artifact Integrity</h3>
-<p>When a Trust Manifest includes <code>provenance</code> entries with <code>sourceDigest</code>:</p>
+<p>When a Trust Manifest carries a <code>signature</code>, it MUST include a <code>subject</code>
+that binds it to the artifact (see <a href="#subject-binding">Subject Binding</a>).
+To verify artifact integrity:</p>
 <ol>
-<li>Fetch the artifact content from the entry's <code>url</code>.</li>
-<li>Compute the digest using the algorithm specified in the
-   <code>sourceDigest</code> field.</li>
-<li>Compare the computed digest to the declared value. Reject the
-   artifact if they differ.</li>
+<li>Verify the Trust Manifest signature
+   (<a href="#trust-manifest-signatures">Trust Manifest Signatures</a>) and anchor
+   the identity (<a href="#trust-anchoring">Trust Anchoring</a>).</li>
+<li>Confirm <code>subject.mediaType</code> equals the entry's <code>mediaType</code>, and, when
+   <code>subject.url</code> is present, that it equals the entry's <code>url</code>.</li>
+<li>Fetch the artifact content from the entry's <code>url</code>, or take it from
+   the entry's <code>data</code>, observing the limits in
+   <a href="#safe-fetching">Safe Fetching</a>.</li>
+<li>Compute the digest of the fetched bytes (for <code>url</code>) or of the
+   JCS-canonicalized value (for <code>data</code>) using the algorithm named in
+   <code>subject.digest</code>.</li>
+<li>Compare the computed digest to <code>subject.digest</code>. Reject the artifact
+   if they differ.</li>
 </ol>
+<p>Because the <code>subject</code> is part of the signed payload, this check binds
+the publisher's signature to the exact artifact, defeating catalog-level
+substitution of the artifact URL or content. The OPTIONAL
+<code>provenance[].sourceDigest</code> records the digest of an upstream <em>source</em>
+(e.g., a Git commit) and is complementary to — not a substitute for —
+the <code>subject</code> digest.</p>
 </section>
 <section id="verifying-attestations">
 <h3>Verifying Attestations</h3>
@@ -731,6 +907,24 @@
    declared digest.</li>
 <li>Validate the attestation per its <code>type</code> (e.g., verify a JWT
    signature, confirm a PDF certificate is current).</li>
+</ol>
+</section>
+<section id="provenance-statements">
+<h3>Provenance Statements</h3>
+<p>A Provenance Link MAY reference a signed provenance statement via
+<code>statementUri</code> and the key that signed it via <code>signatureRef</code>. To verify
+such a statement:</p>
+<ol>
+<li>Fetch the statement document from <code>statementUri</code>, observing
+   <a href="#safe-fetching">Safe Fetching</a>.</li>
+<li>Resolve the key indicated by <code>signatureRef</code> using the procedure in
+   <a href="#key-resolution">Key Resolution</a> and anchor it per
+   <a href="#trust-anchoring">Trust Anchoring</a>.</li>
+<li>Verify the statement's signature using an algorithm from
+   <a href="#signature-algorithms">Signature Algorithms</a>.</li>
+<li>Confirm the statement's subject matches the artifact's <code>subject</code>
+   digest. Treat an unverifiable statement as absent, not as a failure
+   of the artifact itself.</li>
 </ol>
 </section>
 </section>
@@ -970,13 +1164,14 @@
 <ul>
 <li><code>specVersion</code> — the specification version string</li>
 <li><code>entries</code> — an array of Catalog Entry objects, each containing at
-  minimum <code>identifier</code>, <code>type</code>, and exactly one of <code>url</code> or
+  minimum <code>identifier</code>, <code>displayName</code>, <code>type</code>, and exactly one of <code>url</code> or
   <code>data</code></li>
 </ul>
 <p>All other fields (<code>host</code>, <code>publisher</code>, <code>trustManifest</code>,
 <code>metadata</code>) are OPTIONAL. This level is sufficient for use cases that
 only need a simple list of AI artifacts — for example, a catalog of
-MCP servers or A2A agents.</p>
+MCP servers or A2A agents. A <code>trustManifest</code>, when present at any level,
+MUST be substantive (see <a href="#manifest-validity">Manifest Validity</a>).</p>
 </section>
 <section id="level-2-discoverable-catalog">
 <h2>Level 2: Discoverable Catalog</h2>
@@ -991,8 +1186,19 @@
 <h2>Level 3: Trusted Catalog</h2>
 <p>In addition to Level 2 requirements, a Trusted Catalog:</p>
 <ul>
-<li>Includes <code>trustManifest</code> objects on entries and/or the host, as
-  defined in <a href="#trust-manifest">Trust Manifest</a></li>
+<li>Includes a <code>trustManifest</code> object on every entry whose trust is to be
+  relied upon, and MAY include one on the host, as defined in
+  <a href="#trust-manifest">Trust Manifest</a></li>
+<li>Each such <code>trustManifest</code> MUST carry a <code>signature</code>, a <code>subject</code>
+  binding it to the artifact (<a href="#subject-binding">Subject Binding</a>), and
+  an <code>issuedAt</code> timestamp</li>
+<li>Consumers MUST verify the signature, anchor the identity
+  (<a href="#trust-anchoring">Trust Anchoring</a>), and confirm the <code>subject</code>
+  digest before relying on any claim</li>
+<li>SHOULD provide catalog-level integrity, either by serving the catalog
+  through a content-addressed channel (see
+  <a href="#security-considerations">Security Considerations</a>) or by including a
+  top-level catalog <code>signature</code></li>
 <li>MAY include <code>publisher</code> objects on entries with verifiable identifiers</li>
 <li>Enables verifiable identity, compliance attestations, and provenance
   tracking</li>
@@ -1028,14 +1234,18 @@
   verification guards against transport-level tampering but not
   catalog-level substitution.</strong></dd>
 <dt><strong>Layer 2 — Signed Trust Manifest</strong></dt>
-<dd>The Trust Manifest includes a <code>signature</code> field (detached JWS).
-  The consumer verifies the signature against the publisher's public
-  key before trusting any claims in the Trust Manifest — including
-  provenance digests, attestations, and identity bindings. This closes
-  the substitution gap from Layer 1: an attacker cannot forge a
-  signed Trust Manifest without the publisher's private key.
-  Consumers SHOULD verify signatures when present and SHOULD reject
-  Trust Manifests whose signature does not validate.</dd>
+<dd>The Trust Manifest includes a <code>signature</code> field (detached JWS) and a
+  <code>subject</code> that binds the signature to the artifact's content digest
+  (see <a href="#subject-binding">Subject Binding</a>). The consumer verifies the
+  signature, anchors the signer's identity to a trust root
+  (<a href="#trust-anchoring">Trust Anchoring</a>), and confirms the <code>subject</code>
+  digest before trusting any claim. This closes the substitution gap
+  from Layer 1: because the signed payload commits to the artifact
+  digest, an attacker cannot repoint the entry to a different artifact
+  or forge claims without the publisher's private key. Consumers that
+  rely on trust metadata MUST verify signatures and MUST reject Trust
+  Manifests whose signature does not validate, whose <code>subject</code> does not
+  match the fetched artifact, or whose identity cannot be anchored.</dd>
 <dt><strong>Layer 3 — Content-Addressed Distribution (OCI)</strong></dt>
 <dd>The catalog is distributed through an OCI registry where all content
   — entries, artifacts, and Trust Manifests — is addressed by
@@ -1072,10 +1282,37 @@
   unauthorized modification.</li>
 <li><strong>Layer 1</strong> enables post-fetch integrity checks but does not prevent
   whole-entry substitution.</li>
-<li><strong>Layer 2</strong> prevents Trust Manifest forgery, ensuring provenance
-  digests and attestations are authentic.</li>
+<li><strong>Layer 2</strong> binds the signed Trust Manifest to the artifact digest
+  via <code>subject</code>, preventing both Trust Manifest forgery and artifact
+  substitution under a valid signature.</li>
 <li><strong>Layer 3</strong> makes modification structurally impossible through
   content-addressing.</li>
+</ul>
+</section>
+<section id="trust-manifest-substitution">
+<h2>Trust Manifest Substitution</h2>
+<p>Because a Trust Manifest is a peer element of the catalog entry rather
+than part of the artifact, an attacker who can write the catalog
+document can attempt to substitute the artifact, the Trust Manifest, or
+both. This specification defends against substitution with three
+compounding mechanisms:</p>
+<ul>
+<li><strong>Subject binding.</strong> A signed Trust Manifest MUST include a <code>subject</code>
+  that commits to the artifact's media type and content digest (see
+  <a href="#subject-binding">Subject Binding</a>). The artifact reference therefore
+  cannot be changed without invalidating the signature.</li>
+<li><strong>Trust anchoring.</strong> A signature is only meaningful once the signer's
+  identity is anchored to a trust root established out of band (see
+  <a href="#trust-anchoring">Trust Anchoring</a>); otherwise an attacker can sign a
+  forged manifest with their own key.</li>
+<li><strong>Catalog-level integrity.</strong> Per-entry signatures do not prevent an
+  attacker from adding, removing, or reordering whole entries. Hosts
+  SHOULD additionally provide catalog-level integrity, either by serving
+  the catalog through a content-addressed channel (Layer 3) or by
+  including a top-level catalog <code>signature</code> computed over the
+  JCS-canonicalized [[RFC8785]] catalog document (excluding the
+  <code>signature</code> member itself) and verified exactly as a Trust Manifest
+  signature.</li>
 </ul>
 </section>
 <section id="identifier-typosquatting">
@@ -1133,6 +1370,7 @@
         specVersion string
         entries CatalogEntry[]
         host HostInfo
+        signature string
     }
     class HostInfo {
         displayName string
@@ -1154,10 +1392,17 @@
     }
     class TrustManifest {
         identity string
+        subject Subject
         trustSchema TrustSchema
         attestations Attestation[]
         provenance ProvenanceLink[]
+        issuedAt string
         signature string
+    }
+    class Subject {
+        url string
+        mediaType string
+        digest string
     }
     class TrustSchema {
         identifier string
@@ -1180,6 +1425,7 @@
     CatalogEntry --> "0..1" Publisher : publisher
     CatalogEntry --> "0..1" TrustManifest : trustManifest
     HostInfo --> "0..1" TrustManifest : trustManifest
+    TrustManifest --> "0..1" Subject : subject
     TrustManifest --> "0..1" TrustSchema : trustSchema
     TrustManifest --> "*" Attestation : attestations
     TrustManifest --> "*" ProvenanceLink : provenance
@@ -1354,6 +1600,7 @@
   &quot;entries&quot;: [
     {
       &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance-a2a&quot;,
+      &quot;displayName&quot;: &quot;Acme Finance A2A Agent&quot;,
       &quot;version&quot;: &quot;2.1.0&quot;,
       &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
       &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance.json&quot;,
@@ -1385,6 +1632,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:air:acme.com:server:finance-mcp&quot;,
+      &quot;displayName&quot;: &quot;Acme Finance MCP Server&quot;,
       &quot;version&quot;: &quot;1.4.0&quot;,
       &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
       &quot;url&quot;: &quot;https://api.acme-corp.com/.well-known/mcp/server-card.json&quot;,
@@ -1403,11 +1651,13 @@
         &quot;entries&quot;: [
           {
             &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance-a2a&quot;,
+            &quot;displayName&quot;: &quot;Finance A2A Agent&quot;,
             &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
             &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance.json&quot;
           },
           {
             &quot;identifier&quot;: &quot;urn:air:acme.com:server:finance-mcp&quot;,
+            &quot;displayName&quot;: &quot;Finance MCP Server&quot;,
             &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
             &quot;url&quot;: &quot;https://api.acme-corp.com/.well-known/mcp/server-card.json&quot;
           },
@@ -1454,6 +1704,7 @@
   &quot;entries&quot;: [
     {
       &quot;identifier&quot;: &quot;urn:air:acme.com:agent:assistant&quot;,
+      &quot;displayName&quot;: &quot;Acme Corporate Assistant&quot;,
       &quot;version&quot;: &quot;3.0.0&quot;,
       &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
       &quot;url&quot;: &quot;https://api.acme-corp.com/agents/assistant.json&quot;,
@@ -1511,11 +1762,13 @@
     &quot;entries&quot;: [
       {
         &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance:mcp&quot;,
+        &quot;displayName&quot;: &quot;Acme Finance MCP Server&quot;,
         &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
         &quot;url&quot;: &quot;https://api.acme-corp.com/.well-known/mcp/server-card.json&quot;
       },
       {
         &quot;identifier&quot;: &quot;urn:air:acme.com:agent:finance:a2a&quot;,
+        &quot;displayName&quot;: &quot;Acme Finance A2A Agent&quot;,
         &quot;type&quot;: &quot;application/a2a-agent-card+json&quot;,
         &quot;url&quot;: &quot;https://api.acme-corp.com/agents/finance&quot;
       }
@@ -1539,46 +1792,154 @@
 catalog with protocol-specific entries, allowing clients to choose
 MCP or A2A based on their capabilities.</p>
 </section>
-<section class="appendix" id="mapping-to-oci-distribution">
-<h1>Mapping to OCI Distribution</h1>
-<p>This appendix describes how AI Catalog documents can be distributed
-through OCI registries, enabling content-addressed storage, signing,
-and replication using existing container infrastructure.</p>
-<section id="logical-format-vs-physical-distribution">
-<h2>Logical Format vs. Physical Distribution</h2>
+<section class="appendix" id="mapping-to-distribution-substrates">
+<h1>Mapping to Distribution Substrates</h1>
 <p>The AI Catalog specification defines a <strong>logical format</strong>: a JSON
 document with <code>entries</code>, <code>displayName</code>, <code>type</code>, and <code>trustManifest</code>
 fields that are immediately meaningful to anyone working with AI
 artifacts. Authors write simple JSON. APIs serve simple JSON. Clients
 consume simple JSON.</p>
-<p>OCI provides a <strong>physical distribution layer</strong>: content-addressed
-storage, cryptographic signing via Cosign/Notation, global replication
-through registries, and referrer-based metadata association. These are
-valuable infrastructure capabilities, but OCI's data model uses
-container-oriented vocabulary (<code>manifests</code>, <code>layers</code>, <code>config</code>,
-<code>digest</code>) that does not naturally describe a catalog of AI artifacts.</p>
-<p>This specification treats OCI as one distribution option, not as the
-canonical data model. The logical AI Catalog format remains the
-authoring and consumption interface. Tooling bridges the two:</p>
-<pre><code>Authoring                         Distribution                    Consumption
-─────────                         ────────────                    ───────────
-ai-catalog.json    ──pack──►    OCI Registry     ──unpack──►   ai-catalog.json
-  entries[]                       Index/Manifests                  entries[]
-  trustManifest                   Referrers                        trustManifest
-</code></pre>
-<p>This separation means:</p>
-<ul>
-<li><strong>Simplicity for authors</strong>: Publishers write AI Catalog JSON using
-  domain vocabulary. No knowledge of OCI manifests, digests, or layer
-  descriptors is required.</li>
-<li><strong>Simplicity for consumers</strong>: Clients that fetch from
-  <code>/.well-known/ai-catalog.json</code> or a registry API receive the logical
-  JSON format. They never need to parse OCI structures.</li>
-<li><strong>Power for infrastructure</strong>: Registries that want content-addressed
-  integrity, signing, and replication can store catalogs as OCI
-  artifacts using the mapping defined below.</li>
-</ul>
-</section>
+<p>That logical format can be <strong>physically distributed</strong> over more than one
+substrate — an OCI registry, an [[xRegistry]] registry, or a plain HTTP
+server. Each substrate has its own data model and its own native
+capabilities. To keep the logical format authoritative and to avoid
+diverging, substrate-specific dialects, every binding defined by this
+specification MUST satisfy the same contract: packing a logical document
+into the substrate and unpacking it again MUST reproduce an equivalent
+logical document.</p>
+<pre><code>Authoring                      Distribution                    Consumption
+─────────                      ────────────                    ───────────
+ai-catalog.json   ──pack──►   OCI / xRegistry / HTTP  ──unpack──►   ai-catalog.json
+  entries[]                     substrate-native form                entries[]
+  trustManifest                                                      trustManifest
+</code></pre>
+<p>This separation keeps authoring and consumption simple: publishers and
+clients work with domain vocabulary (<code>entries</code>, <code>displayName</code>,
+<code>mediaType</code>, <code>trustManifest</code>), while infrastructure that wants
+content-addressing, signing, replication, or registry APIs uses whichever
+binding below matches its substrate.</p>
+<section id="binding-invariants">
+<h2>Binding Invariants</h2>
+<p>A conforming binding MUST preserve each of the following invariants. This
+list — not any single substrate's vocabulary — is the conformance bar for
+a pack/unpack round-trip.</p>
+<table>
+<thead>
+<tr>
+<th style="text-align: left;">Logical concept</th>
+<th style="text-align: left;">Invariant a binding MUST preserve</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td style="text-align: left;">Entry identity (<code>identifier</code>)</td>
+<td style="text-align: left;">A stable, addressable identity for each entry</td>
+</tr>
+<tr>
+<td style="text-align: left;">Artifact content + <code>mediaType</code></td>
+<td style="text-align: left;">The artifact bytes are retrievable together with their media type</td>
+</tr>
+<tr>
+<td style="text-align: left;">Catalog structure / nesting</td>
+<td style="text-align: left;">Nested catalogs remain navigable as a hierarchy</td>
+</tr>
+<tr>
+<td style="text-align: left;">Trust Manifest association</td>
+<td style="text-align: left;">An entry's Trust Manifest is discoverable from that entry</td>
+</tr>
+<tr>
+<td style="text-align: left;">Content integrity</td>
+<td style="text-align: left;">The served bytes are verifiably bound to <code>trustManifest.subject.digest</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Signing</td>
+<td style="text-align: left;">The Trust Manifest's authenticity is cryptographically verifiable</td>
+</tr>
+</tbody>
+</table>
+</section>
+<section id="delegate-don-t-duplicate">
+<h2>Delegate, Don&#x27;t Duplicate</h2>
+<p>Substrates differ in what they can express natively. OCI is
+content-addressed and has first-class signing (Cosign/Notation);
+xRegistry is a hierarchical resource API with versioning and
+cross-referencing but no native digest or signature primitive.</p>
+<p>To avoid expressing the same guarantee twice, a binding <strong>delegates</strong> an
+invariant to a native substrate primitive when one exists, and otherwise
+<strong>carries</strong> it in the logical Trust Manifest. A binding MUST NOT restate,
+in substrate vocabulary, a guarantee it has delegated, and MUST NOT drop
+a guarantee the substrate cannot express.</p>
+<table>
+<thead>
+<tr>
+<th style="text-align: left;">Invariant</th>
+<th style="text-align: left;">OCI primitive (delegate)</th>
+<th style="text-align: left;">xRegistry primitive (delegate)</th>
+<th style="text-align: left;">Carried fallback</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td style="text-align: left;">Identity</td>
+<td style="text-align: left;">Repository path + digest</td>
+<td style="text-align: left;"><code>resourceid</code> / <code>xid</code></td>
+<td style="text-align: left;"><code>entry.identifier</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Content + media type</td>
+<td style="text-align: left;"><code>layers[0]</code> + <code>artifactType</code></td>
+<td style="text-align: left;">Resource document + <code>contenttype</code></td>
+<td style="text-align: left;">Entry artifact + <code>mediaType</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Nesting</td>
+<td style="text-align: left;">Nested Image Index</td>
+<td style="text-align: left;">Nested Group / <code>xref</code></td>
+<td style="text-align: left;">Nested entry</td>
+</tr>
+<tr>
+<td style="text-align: left;">Manifest association</td>
+<td style="text-align: left;">Referrers API (<code>subject</code>)</td>
+<td style="text-align: left;"><code>xref</code> / extension attribute</td>
+<td style="text-align: left;">Inline <code>trustManifest</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Content integrity</td>
+<td style="text-align: left;">Content-addressed digest</td>
+<td style="text-align: left;"><em>(none — carried)</em></td>
+<td style="text-align: left;"><code>subject.digest</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Signing</td>
+<td style="text-align: left;">Cosign / Notation referrer</td>
+<td style="text-align: left;"><em>(none — carried)</em></td>
+<td style="text-align: left;">Detached JWS in Trust Manifest</td>
+</tr>
+</tbody>
+</table>
+<p>The two sections that follow are concrete bindings of this contract. The
+OCI binding delegates the most (identity, content integrity, signing);
+the xRegistry binding delegates structure, identity, and discovery but
+carries content integrity and signing because xRegistry has no native
+primitive for them.</p>
+</section>
+</section>
+<section class="appendix" id="mapping-to-oci-distribution">
+<h1>Mapping to OCI Distribution</h1>
+<p>This appendix binds the <a href="#mapping-to-distribution-substrates">Mapping to Distribution
+Substrates</a> contract to OCI
+registries, enabling content-addressed storage, signing, and replication
+using existing container infrastructure. OCI's data model uses
+container-oriented vocabulary (<code>manifests</code>, <code>layers</code>, <code>config</code>, <code>digest</code>)
+that does not naturally describe a catalog of AI artifacts, so tooling
+bridges the logical format and the OCI representation.</p>
+<p>Of the binding invariants, the OCI binding <strong>delegates</strong> identity,
+content integrity, and signing to OCI's own primitives. Consequently
+<code>trustManifest.subject.digest</code> is expected to equal the OCI descriptor
+digest of the served artifact, and the detached JWS in the Trust Manifest
+MAY be omitted from the packed representation because Cosign/Notation
+referrers carry signing instead. Unpacking reconstitutes (or re-signs)
+the logical Trust Manifest from those referrers.</p>
 <section id="conceptual-mapping">
 <h2>Conceptual Mapping</h2>
 <p>The OCI image specification (v1.1+) supports arbitrary artifact types
@@ -1800,6 +2161,182 @@
 while infrastructure-oriented deployments leverage OCI distribution.</p>
 </section>
 </section>
+<section class="appendix" id="mapping-to-xregistry">
+<h1>Mapping to xRegistry</h1>
+<p>This appendix binds the <a href="#mapping-to-distribution-substrates">Mapping to Distribution
+Substrates</a> contract to [[xRegistry]],
+a hierarchical registry model organized as Registry → Groups → Resources
+→ Versions. xRegistry contributes structure, identity, versioning,
+cross-referencing, and a registry API; it has no native content-addressing
+or signature primitive.</p>
+<p>Of the binding invariants, the xRegistry binding <strong>delegates</strong> entry
+identity, catalog structure, artifact content, and manifest discovery to
+xRegistry's own primitives, but <strong>carries</strong> content integrity and signing
+in the Trust Manifest. The detached JWS and <code>subject.digest</code> remain
+authoritative exactly as in plain-HTTP distribution, because xRegistry
+cannot express either guarantee natively.</p>
+<section id="conceptual-mapping-2">
+<h2>Conceptual Mapping</h2>
+<p>An AI Catalog document maps to an xRegistry <strong>Group</strong> whose <strong>Resources</strong>
+are the catalog entries; each entry's artifact is the Resource document.</p>
+<table>
+<thead>
+<tr>
+<th style="text-align: left;">AI Catalog (Logical)</th>
+<th style="text-align: left;">xRegistry (Physical)</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td style="text-align: left;">AI Catalog document</td>
+<td style="text-align: left;">A Group instance (e.g. in a <code>aicatalogs</code> Group type), or the Registry root when serving a single catalog</td>
+</tr>
+<tr>
+<td style="text-align: left;">Catalog Entry</td>
+<td style="text-align: left;">A Resource within that Group</td>
+</tr>
+<tr>
+<td style="text-align: left;">Entry <code>identifier</code></td>
+<td style="text-align: left;">Resource <code>&lt;SINGULAR&gt;id</code> and <code>xid</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Entry <code>mediaType</code></td>
+<td style="text-align: left;">Version <code>contenttype</code> (with <code>format</code> when a named format applies)</td>
+</tr>
+<tr>
+<td style="text-align: left;">Entry artifact content</td>
+<td style="text-align: left;">Resource document — inline (<code>&lt;RESOURCE&gt;</code> / <code>&lt;RESOURCE&gt;base64</code>) or external (<code>&lt;RESOURCE&gt;url</code>)</td>
+</tr>
+<tr>
+<td style="text-align: left;">Entry metadata (displayName, description, tags)</td>
+<td style="text-align: left;"><code>name</code>, <code>description</code>, <code>labels</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Entry version</td>
+<td style="text-align: left;">Version <code>versionid</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Nested Catalog Entry</td>
+<td style="text-align: left;">A nested Group referenced from the entry's Resource via <code>meta.xref</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Trust Manifest</td>
+<td style="text-align: left;">An extension attribute on the Resource (an object), or a related Resource referenced by <code>xref</code></td>
+</tr>
+<tr>
+<td style="text-align: left;">Content integrity (<code>subject.digest</code>)</td>
+<td style="text-align: left;">Carried in the Trust Manifest (xRegistry has no native digest)</td>
+</tr>
+<tr>
+<td style="text-align: left;">Signing</td>
+<td style="text-align: left;">Detached JWS retained in the Trust Manifest (xRegistry has no native signature)</td>
+</tr>
+</tbody>
+</table>
+</section>
+<section id="packing-ai-catalog-to-xregistry">
+<h2>Packing: AI Catalog to xRegistry</h2>
+<p>Tooling converts an AI Catalog JSON document into xRegistry resources:</p>
+<ol>
+<li>
+<p><strong>The catalog</strong> becomes a Group instance. Catalog-level metadata maps
+   to Group attributes: <code>displayName</code> to <code>name</code>, host identity and other
+   metadata to <code>labels</code> or extension attributes.</p>
+</li>
+<li>
+<p><strong>Each catalog entry</strong> becomes a Resource in that Group. The entry's
+   artifact content is stored as the Resource document — inline via
+   <code>&lt;RESOURCE&gt;</code> / <code>&lt;RESOURCE&gt;base64</code>, or by reference via <code>&lt;RESOURCE&gt;url</code>.
+   <code>mediaType</code> maps to <code>contenttype</code>; entry metadata maps to <code>name</code>,
+   <code>description</code>, and <code>labels</code>. Multiple entry versions map to Versions.</p>
+</li>
+<li>
+<p><strong>Trust Manifests</strong> are carried as an extension attribute on the
+   Resource (for example <code>aicatalog_trustmanifest</code>), or as a related
+   Resource referenced from <code>meta.xref</code>. The detached JWS and
+   <code>subject.digest</code> are retained unchanged because xRegistry provides no
+   native signing or content-addressing to delegate to.</p>
+</li>
+<li>
+<p><strong>Nested catalog entries</strong> become nested Groups; the parent entry's
+   Resource references the nested Group through <code>meta.xref</code>.</p>
+</li>
+</ol>
+</section>
+<section id="unpacking-xregistry-to-ai-catalog">
+<h2>Unpacking: xRegistry to AI Catalog</h2>
+<p>Tooling converts xRegistry resources back to an AI Catalog JSON document:</p>
+<ol>
+<li>Retrieve the Group in document view (the xRegistry <code>?doc</code> projection),
+   which returns a single self-contained JSON document analogous to
+   <code>ai-catalog.json</code>.</li>
+<li>For each Resource, read its document (inline or via <code>&lt;RESOURCE&gt;url</code>)
+   and <code>contenttype</code> to recover the entry's artifact content and
+   <code>mediaType</code>; map <code>name</code>, <code>description</code>, and <code>labels</code> back to entry
+   metadata.</li>
+<li>Read the Trust Manifest from the extension attribute or <code>xref</code>'d
+   Resource, and verify its detached JWS and <code>subject.digest</code> against the
+   served bytes.</li>
+<li>Resolve <code>xref</code>'d nested Groups into nested catalog entries.</li>
+<li>Assemble the logical <code>application/ai-catalog+json</code> document.</li>
+</ol>
+</section>
+<section id="xregistry-document-example">
+<h2>xRegistry Document Example</h2>
+<p>The following shows the xRegistry document-view representation of a Group
+holding two entries. This is generated by tooling, not authored by hand:</p>
+<pre><code class="language-json">{
+  &quot;aicatalogid&quot;: &quot;acme-services&quot;,
+  &quot;self&quot;: &quot;https://registry.acme.com/aicatalogs/acme-services&quot;,
+  &quot;xid&quot;: &quot;/aicatalogs/acme-services&quot;,
+  &quot;epoch&quot;: 1,
+  &quot;name&quot;: &quot;Acme Services Inc.&quot;,
+  &quot;entriesurl&quot;: &quot;https://registry.acme.com/aicatalogs/acme-services/entries&quot;,
+  &quot;entriescount&quot;: 2,
+  &quot;entries&quot;: {
+    &quot;finance-a2a&quot;: {
+      &quot;entryid&quot;: &quot;finance-a2a&quot;,
+      &quot;xid&quot;: &quot;/aicatalogs/acme-services/entries/finance-a2a&quot;,
+      &quot;name&quot;: &quot;Acme Finance A2A Agent&quot;,
+      &quot;contenttype&quot;: &quot;application/a2a-agent-card+json&quot;,
+      &quot;labels&quot;: {
+        &quot;ai-catalog.identifier&quot;: &quot;urn:acme:agent:finance-a2a&quot;
+      },
+      &quot;entryurl&quot;: &quot;https://cards.acme.com/finance/a2a-card.json&quot;,
+      &quot;aicatalog_trustmanifest&quot;: {
+        &quot;issuedAt&quot;: &quot;2025-01-01T00:00:00Z&quot;,
+        &quot;subject&quot;: {
+          &quot;mediaType&quot;: &quot;application/a2a-agent-card+json&quot;,
+          &quot;digest&quot;: &quot;sha256:aaa111...&quot;
+        },
+        &quot;signature&quot;: &quot;eyJhbGciOiJFUzI1NiJ9..detached-JWS..&quot;
+      }
+    },
+    &quot;finance-mcp&quot;: {
+      &quot;entryid&quot;: &quot;finance-mcp&quot;,
+      &quot;xid&quot;: &quot;/aicatalogs/acme-services/entries/finance-mcp&quot;,
+      &quot;name&quot;: &quot;Acme Finance MCP Server&quot;,
+      &quot;contenttype&quot;: &quot;application/mcp-server-card+json&quot;,
+      &quot;labels&quot;: {
+        &quot;ai-catalog.identifier&quot;: &quot;urn:acme:server:finance-mcp&quot;
+      },
+      &quot;entryurl&quot;: &quot;https://cards.acme.com/finance/mcp-server.json&quot;
+    }
+  }
+}
+</code></pre>
+</section>
+<section id="content-integrity-and-signing">
+<h2>Content Integrity and Signing</h2>
+<p>Because xRegistry has no native content-addressing or signature
+primitive, this binding does not delegate those invariants: the Trust
+Manifest's detached JWS and <code>subject.digest</code> remain the source of truth,
+verified against the served Resource document during unpacking — the same
+model as plain-HTTP distribution. An implementation MAY additionally
+expose the digest as an extension attribute for discovery convenience, but
+that copy is advisory; the Trust Manifest remains authoritative.</p>
+</section>
+</section>
 <section class="appendix" id="mapping-to-mcp-registry-server-json">
 <h1>Mapping to MCP Registry server.json</h1>
 <p>This appendix describes how the MCP Registry <code>server.json</code> format
@@ -1830,7 +2367,7 @@
 Instead, it provides the discovery and trust layer that <code>server.json</code>
 does not address.</p>
 </section>
-<section id="conceptual-mapping-2">
+<section id="conceptual-mapping-3">
 <h2>Conceptual Mapping</h2>
 <table>
 <thead>
@@ -1850,7 +2387,7 @@
 </tr>
 <tr>
 <td style="text-align: left;"><code>title</code></td>
-<td style="text-align: left;">Stays in the artifact (<code>server.json</code> carries its own <code>title</code>); entry <code>displayName</code> is omitted unless the artifact lacks a name</td>
+<td style="text-align: left;">Entry <code>displayName</code></td>
 </tr>
 <tr>
 <td style="text-align: left;"><code>description</code></td>
@@ -1921,6 +2458,7 @@
 reflects the Registry format:</p>
 <pre><code class="language-json">{
   &quot;identifier&quot;: &quot;urn:air:anonymous.modelcontextprotocol.io:mcp:brave-search&quot;,
+  &quot;displayName&quot;: &quot;Brave Search&quot;,
   &quot;version&quot;: &quot;1.0.2&quot;,
   &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
   &quot;url&quot;: &quot;https://registry.modelcontextprotocol.io/servers/brave-search/server.json&quot;,
@@ -1980,6 +2518,7 @@
   &quot;entries&quot;: [
     {
       &quot;identifier&quot;: &quot;urn:air:anonymous.modelcontextprotocol.io:mcp:brave-search&quot;,
+      &quot;displayName&quot;: &quot;Brave Search&quot;,
       &quot;version&quot;: &quot;1.0.2&quot;,
       &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
       &quot;url&quot;: &quot;https://registry.modelcontextprotocol.io/servers/brave-search/server.json&quot;,
@@ -1988,6 +2527,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:air:modelcontextprotocol.github.io:mcp:filesystem&quot;,
+      &quot;displayName&quot;: &quot;Filesystem&quot;,
       &quot;version&quot;: &quot;1.0.2&quot;,
       &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
       &quot;url&quot;: &quot;https://registry.modelcontextprotocol.io/servers/filesystem/server.json&quot;,
@@ -1996,6 +2536,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:air:example.github.io:mcp:weather-mcp&quot;,
+      &quot;displayName&quot;: &quot;Weather&quot;,
       &quot;version&quot;: &quot;0.5.0&quot;,
       &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
       &quot;url&quot;: &quot;https://registry.modelcontextprotocol.io/servers/weather/server.json&quot;,
@@ -2073,6 +2614,7 @@
 server can reference the Server Card as its artifact content:</p>
 <pre><code class="language-json">{
   &quot;identifier&quot;: &quot;urn:air:example.com:mcp:finance-server&quot;,
+  &quot;displayName&quot;: &quot;Acme Finance MCP Server&quot;,
   &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
   &quot;url&quot;: &quot;https://api.acme-corp.com/.well-known/mcp/server-card.json&quot;,
   &quot;description&quot;: &quot;MCP server for financial data and trading tools&quot;,
@@ -2142,7 +2684,7 @@
     README.md
 </code></pre>
 </section>
-<section id="conceptual-mapping-3">
+<section id="conceptual-mapping-4">
 <h2>Conceptual Mapping</h2>
 <table>
 <thead>
@@ -2174,7 +2716,7 @@
 </tr>
 <tr>
 <td style="text-align: left;">Plugin <code>name</code></td>
-<td style="text-align: left;">Entry <code>identifier</code> (derived as URN); the plugin manifest carries its own name, so entry <code>displayName</code> is omitted</td>
+<td style="text-align: left;">Entry <code>displayName</code> and <code>identifier</code> (derived as URN)</td>
 </tr>
 <tr>
 <td style="text-align: left;">Plugin <code>description</code></td>
@@ -2255,6 +2797,7 @@
   &quot;entries&quot;: [
     {
       &quot;identifier&quot;: &quot;urn:claude-plugin:anthropic:agent-sdk-dev&quot;,
+      &quot;displayName&quot;: &quot;agent-sdk-dev&quot;,
       &quot;type&quot;: &quot;application/vnd.anthropic.claude-plugin+json&quot;,
       &quot;url&quot;: &quot;https://github.com/anthropics/claude-plugins-official/tree/main/plugins/agent-sdk-dev&quot;,
       &quot;description&quot;: &quot;Development kit for working with the Claude Agent SDK&quot;,
@@ -2269,6 +2812,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:claude-plugin:adspirer:ads-agent&quot;,
+      &quot;displayName&quot;: &quot;adspirer-ads-agent&quot;,
       &quot;type&quot;: &quot;application/vnd.anthropic.claude-plugin+json&quot;,
       &quot;url&quot;: &quot;https://github.com/amekala/adspirer-mcp-plugin.git&quot;,
       &quot;description&quot;: &quot;Cross-platform ad management for Google Ads, Meta Ads, TikTok Ads, and LinkedIn Ads.&quot;,
@@ -2289,6 +2833,7 @@
     },
     {
       &quot;identifier&quot;: &quot;urn:claude-plugin:aikido:security&quot;,
+      &quot;displayName&quot;: &quot;aikido&quot;,
       &quot;type&quot;: &quot;application/vnd.anthropic.claude-plugin+json&quot;,
       &quot;url&quot;: &quot;https://github.com/AikidoSec/aikido-claude-plugin.git&quot;,
       &quot;description&quot;: &quot;Aikido Security scanning — SAST, secrets, and IaC vulnerability detection.&quot;,
@@ -2333,6 +2878,7 @@
     &quot;entries&quot;: [
       {
         &quot;identifier&quot;: &quot;urn:claude-plugin:anthropic:example-plugin:mcp&quot;,
+        &quot;displayName&quot;: &quot;Example Plugin MCP Server&quot;,
         &quot;type&quot;: &quot;application/mcp-server-card+json&quot;,
         &quot;url&quot;: &quot;https://github.com/anthropics/claude-plugins-official/blob/main/plugins/example-plugin/server-card.json&quot;
       },
