feat(spec): add ADR-0019 to support multiple identities via alsoKnownAs

[ramizpolic]

Summary

This PR resolves #52 (support for multiple identities per artifact) by adding an
OPTIONAL alsoKnownAs member to the Trust Manifest, following the approach
favored in the issue discussion and AI Catalog meeting over an identities[] array.

Real artifacts frequently 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. Today there is no first-class
place to declare them, forcing publishers to embed secondary identities
through attestations[] or metadata, where consumers cannot discover or
verify them.

Changes Included

1. Added ADR-0019: Documents the decision to declare alternative identities
   through an alsoKnownAs URI array inside the Trust Manifest (rather than
   on the Catalog Entry), so aliases are covered by the existing manifest
   signature and remain verifiable through the trust bundle.
2. Updated ai-catalog.md:
   • Added the alsoKnownAs member to the Trust Manifest optional members,
     with normative rules (canonical identity, no duplicates,
     domain-alignment applies only to identity).
   • Added a "Verifying Alternative Identities" verification procedure:
     verifying the manifest signature verifies every listed alias, no
     per-alias proof mechanism is required.
   • Updated the CDDL schema, data model diagram, and examples.

Motivation

Consumers can programmatically discover and pin alternate identities of the
same subject using whichever identity scheme their tooling resolves, while
identity remains the single canonical identifier for referencing and
equivalence checking. Because alsoKnownAs lives inside the signed manifest
content, no new signing mechanism is needed and the field is tamper-proof
under the catalog-poisoning threat model.

[github-actions]

Preview: https://ai-catalog.io/pr/91/

This comment is updated automatically while the pull request preview is available.

[kthota-g]

I feel there is inconsistency with type discovery for identity and alsoKnownAs. For identity, publishers can provide an explicit identityType hint. But for alsoKnownAs, the consumers are forced to rely on inferring the type from URI scheme. At least I felt there is a mismatch between identityType and alsoKnownAs looking at the manifest.

If we don't want to remove identityType or introduce identityType per alias, probably explicitly define that identityType is a type hint only for identity attribute.

[ramizpolic]

thanks for raising this @kthota-g. i have patched the spec to include details around type inference for alias identities, hope it addresses your concerns.

[darrelmiller]

@ramizpolic Can you clarify why we don't need identityType?

Can we also clarify if the purpose is both to be an alternative identify, and a record of a rename. i.e. the "alsoKnownAs" includes "formerlyKnownAs".