--- a/base/index.html
+++ b/head/index.html
@@ -13,6 +13,12 @@
       "shortName": "ai-catalog",
       "edDraftURI": "https://ai-catalog.io/",
       "localBiblio": {
+            "RFC3986": {
+                  "title": "Uniform Resource Identifier (URI): Generic Syntax",
+                  "href": "https://www.rfc-editor.org/rfc/rfc3986",
+                  "status": "RFC",
+                  "publisher": "IETF"
+            },
             "RFC8785": {
                   "title": "JSON Canonicalization Scheme (JCS)",
                   "href": "https://www.rfc-editor.org/rfc/rfc8785",
@@ -470,6 +476,14 @@
 align with the publisher domain of the entry's <code>identifier</code>.</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>An artifact may legitimately hold more than one verifiable identity at
+the same time, for example a SPIFFE ID for runtime workload identity
+and a DID for publisher-anchored organizational identity. Additional
+identities are declared through the OPTIONAL <code>alsoKnownAs</code> member (see
+<a href="#optional-members">Optional Members</a>). The <code>identity</code> field remains the
+single canonical subject identifier: consumers MUST use <code>identity</code> when
+referencing the artifact's trust subject or checking identity
+equivalence between entries.</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
@@ -483,6 +497,27 @@
 <dd>A string providing a type hint for the identity URI (e.g., "did",
   "spiffe", "dns"). This field is OPTIONAL when the type is evident
   from the URI scheme.</dd>
+<dt><code>alsoKnownAs</code></dt>
+<dd>
+<p>An array of strings, each containing a globally unique URI
+  [[RFC3986]] that identifies the same subject as <code>identity</code> under an
+  alternative identity scheme. The following rules apply:</p>
+<ul>
+<li>An alias is an equivalent identity of the subject; <code>identity</code>
+  alone remains canonical and is used for referencing and
+  equivalence checking.</li>
+<li>The array is an unordered set: it MUST NOT contain duplicate
+  values or the value of the <code>identity</code> field.</li>
+<li>The domain-alignment rule defined in <a href="#identity">Identity</a>
+  applies only to <code>identity</code>. Aliases MAY belong to different
+  trust domains or identity schemes.</li>
+<li>Aliases are publisher claims covered by the Trust Manifest
+  <code>signature</code>; no per-alias proof is required. Consumers MUST NOT
+  rely on an alias from a manifest whose signature is absent or
+  fails verification (see
+  <a href="#verifying-alternative-identities">Verifying Alternative Identities</a>).</li>
+</ul>
+</dd>
 <dt><code>trustSchema</code></dt>
 <dd>A Trust Schema object as defined in <a href="#trust-schema-object">Trust Schema</a>.</dd>
 <dt><code>attestations</code></dt>
@@ -511,6 +546,9 @@
 <pre><code class="language-json">{
   &quot;identity&quot;: &quot;did:web:acme.com:agent:finance&quot;,
   &quot;identityType&quot;: &quot;did&quot;,
+  &quot;alsoKnownAs&quot;: [
+    &quot;spiffe://acme.com/ns/finance/sa/finance-agent-pod&quot;
+  ],
   &quot;trustSchema&quot;: {
     &quot;identifier&quot;: &quot;urn:trust:acme-enterprise-v1&quot;,
     &quot;version&quot;: &quot;1.0&quot;,
@@ -710,6 +748,25 @@
 <li>Confirm the JWT claims bind the <code>publisher.identifier</code> to the Trust
    Manifest's <code>identity</code>.</li>
 </ol>
+</section>
+<section id="verifying-alternative-identities">
+<h3>Verifying Alternative Identities</h3>
+<p>Aliases need no verification procedure of their own. Because the
+signed payload covers <code>alsoKnownAs</code>, verifying the Trust Manifest
+<code>signature</code> as described in
+<a href="#trust-manifest-signatures">Trust Manifest Signatures</a> also verifies
+every listed alias: a valid signature proves that the publisher
+controlling the canonical <code>identity</code> claims each alias as an
+equivalent identity of the subject. Consumers MUST NOT rely on aliases
+from a manifest whose signature is absent or fails verification.</p>
+<p>Once the signature is verified, a consumer MAY use whichever identity,
+canonical or alias, matches the identity schemes it is able to
+resolve — for example, using a DID alias for DID-based discovery when
+its tooling cannot resolve a canonical SPIFFE ID.</p>
+<p>Note that the signature proves the publisher claims the alias, not
+that the alias's own trust domain acknowledges the link. Consumers
+making authorization decisions inside the alias's trust domain MAY
+additionally obtain proof of control native to the alias scheme.</p>
 </section>
 <section id="verifying-artifact-integrity">
 <h3>Verifying Artifact Integrity</h3>
@@ -1155,6 +1212,7 @@
     }
     class TrustManifest {
         identity string
+        alsoKnownAs string[]
         trustSchema TrustSchema
         attestations Attestation[]
         provenance ProvenanceLink[]
@@ -1304,6 +1362,7 @@
 <pre><code>TrustManifest = {
   identity: text,
   ? identityType: text,
+  ? alsoKnownAs: [* text],
   ? trustSchema: TrustSchema,
   ? attestations: [* Attestation],
   ? provenance: [* ProvenanceLink],