Group trust metadata by contributor and generalize signatures

README.md

@@ -52,7 +52,7 @@ Without a common discovery standard, we see duplicative and incompatible efforts
 
 ## What are we doing?
 
-In this repo, we are defining the **AI Catalog**: a typed, nestable JSON container for discovering heterogeneous AI artifacts. Each catalog entry identifies an artifact by media type and may either reference the native artifact metadata by URL or inline it directly. The specification also defines an optional Trust Manifest extension for identity, attestations, and provenance metadata.
+In this repo, we are defining the **AI Catalog**: a typed, nestable JSON container for discovering heterogeneous AI artifacts. Each catalog entry identifies an artifact by media type and may either reference the native artifact metadata by URL or inline it directly. The specification also defines optional Trust Manifests keyed by contributor identity and signatures over selected fields for authenticating artifact metadata, attestations, and provenance.
 
 *Important Note:* The **AI Catalog** standard does not replace or redefine protocol-specific artifact formats. It provides a common discovery and trust layer around them.
 
@@ -64,7 +64,7 @@ The project defines a schema for a secure, extensible AI Catalog. This may inclu
 
 * **Common catalog metadata**, such as publisher, documentation links, descriptions, icons, and versioning.
 * **Verifiable metadata**, such as attestations, certifications, provenance, and trust signals.
-* **Identity metadata**, such as Decentralized Identifiers (DID) or Secure Production Identity Framework For Everyone (SPIFFE).
+* **Identity metadata**, including a `did:web` profile for authenticating artifact publishers.
 * **Custom metadata** defined by individual producers or consumers for their own needs.
 
 Actual properties for inclusion will be debated in PRs.

adr/0015-agent-identifier-naming.md

@@ -8,6 +8,11 @@ Accepted
 
 **Participants:** Pamela Dingle (Microsoft), Sam Betts (Cisco), Junjie Bu (Google), Darrel Miller (Microsoft), Alan Blount (Google), Srinivas Krishnan (Google), Krishna Thota (Google), Tadas Antanavicius (Pulse MCP), Ramiz Polic (Cisco), Jeffrey Damick (Amazon)
 
+**Later clarification:** [ADR-0027](0027-did-web-entry-signature-profile.md)
+narrows the interoperable v1 signature profile to a root `did:web` issuer and
+assigns runtime or workload identity to separate profiles. The logical-name and
+cryptographic-issuer separation established here remains unchanged.
+
 ## Context
 The `ai-catalog` specification originally recommended using URNs or URIs for the `identifier` field in catalog entries, but did not mandate a specific format. This led to inconsistency in examples and potential interoperability issues across different registries and orchestrators.
 

adr/0020-substantive-trust-manifest.md

@@ -6,6 +6,10 @@
 
 **Participants:** Luca Muscariello (Cisco)
 
+**Later clarification:** [ADR-0027](0027-did-web-entry-signature-profile.md)
+supersedes this ADR's description of `identity` as a workload principal. The
+manifest-validity rule established here remains unchanged.
+
 ## Context
 
 The Trust Manifest is an OPTIONAL companion to a Catalog Entry. Within

adr/0025-bind-signed-trust-manifests-to-releases.md

@@ -0,0 +1,130 @@
+# ADR-0025: Bind Signed Trust Manifests to Artifact Releases
+
+**Status:** Proposed
+
+**Date:** 2026-09-03
+
+## Context
+
+A signed entry Trust Manifest currently binds the signer's claims to an
+artifact's media type, content digest, and optionally its URL. The containing
+Catalog Entry's `identifier` and `version` remain outside that signature.
+
+ADR-0015 established that the two existing identity fields serve different
+purposes. `entry.identifier` is the artifact's logical name in the catalog,
+whereas `trustManifest.identity` is the cryptographic identity associated with
+the Trust Manifest. They need not be the same URI; their domains need only
+align.
+
+The development work that later introduced `subject` temporarily required
+those two fields to be exactly equal. Because `trustManifest.identity` is
+inside the signed payload, that temporary equality rule also placed
+`entry.identifier` under the signature. The accompanying security analysis
+could therefore focus on the remaining problem: binding the signature to the
+artifact's exact representation through its media type, digest, and optional
+URL.
+
+Review subsequently restored the domain-alignment rule from ADR-0015, but the
+definition of `subject` remained representation-only. Once those two decisions
+were combined, no field inside the signed payload was required to equal
+`entry.identifier`. The artifact bytes were still protected, but their logical
+catalog identifier was not.
+
+Catalog Entries that share an `identifier` can represent different releases
+using `version`. The resolution procedure compares those versions when
+selecting the latest release or satisfying a version constraint. A present
+`entry.version` can therefore determine which artifact a consumer receives,
+even though it remains outside the Trust Manifest signature.
+
+An attacker who can modify a catalog can retain a valid signed manifest and
+its exact artifact bytes while changing only the entry's logical identifier or
+version. For example, the attacker can label an old, vulnerable release as a
+newer version. A consumer requesting the latest release, or requiring a
+minimum version containing a security fix, can then receive the vulnerable
+code while the signature, URL, media type, and digest all verify.
+
+A top-level catalog signature detects changes to the catalog document, but it
+authenticates a different statement. It establishes that the catalog signer
+published a particular snapshot, including its identifiers and versions. An
+entry Trust Manifest establishes that its signer made claims about a
+particular artifact. When the catalog and Trust Manifest have different
+signers, the catalog signature does not establish that the Trust Manifest
+signer assigned those release coordinates. Conversely, an entry signature
+does not protect the catalog's collection-wide structure. The two controls
+provide complementary guarantees.
+
+## Decision
+
+For a signed Trust Manifest attached to a Catalog Entry, extend `subject` to
+identify both the logical artifact release and its exact representation.
+
+For a signed entry Trust Manifest:
+
+- `subject.identifier` is REQUIRED in every Subject and MUST exactly equal
+  `entry.identifier` when the Subject appears on a Catalog Entry.
+- `subject.version` is REQUIRED when `entry.version` is present and MUST
+  exactly equal it. When `entry.version` is absent, `subject.version` MAY be
+  present and no entry-version comparison is required.
+- `subject.type` remains REQUIRED and MUST exactly equal `entry.type`.
+- `subject.digest` remains REQUIRED and MUST match the artifact content.
+- `subject.url` remains OPTIONAL. When present, it MUST exactly equal
+  `entry.url`.
+
+Consumers MUST perform the entry-to-subject comparisons in addition to
+verifying the signature, anchoring its identity, and checking the artifact
+digest. A signature over a mismatched subject does not authenticate the
+containing entry.
+
+Catalog-level integrity remains complementary. Per-entry signatures cannot
+detect removal of a valid entry, injection of unrelated entries, or
+reordering. A catalog signature or trusted content-addressed distribution can
+protect the catalog snapshot as a whole. Neither an entry signature nor a
+catalog signature alone prevents replay of an older, correctly signed value.
+A consumer that must prevent rollback needs either a trusted source of current
+release information or local state recording the newest release it has already
+accepted.
+
+The release-coordinate comparison rules in this decision are limited to signed
+Trust Manifests attached to Catalog Entries. Requiring every Subject to include
+an `identifier` does not define what the Subject of a signed Host Trust Manifest
+represents. This decision also does not change the meaning of `identity` or
+define how an identity resolves to an authorized signing key. Those concerns
+require separate decisions.
+
+The specification's CDDL is updated to represent `subject`, `issuedAt`, and
+`expiresAt`, which were already defined in the normative prose but missing from
+the machine-readable data model.
+
+## Consequences
+
+- A valid signed manifest and artifact cannot be transplanted to another
+  logical identifier or relabeled as another version without detection.
+- The same signed manifest remains usable in catalogs that omit the optional
+  entry `version`; when a catalog supplies a version, it must agree with the
+  signed subject.
+- Mirrors remain possible because `subject.url` stays optional.
+- Catalog signatures continue to protect collection-level decisions and may
+  be made by a different principal than the Trust Manifest signer.
+- Signing the release coordinates does not by itself prevent rollback to an
+  older, correctly labelled and validly signed release. Consumers still need a
+  trusted source of current release information or a record of the newest
+  release they have already accepted.
+
+## Alternatives Considered
+
+### Rely only on catalog-level integrity
+
+Rejected as the sole mitigation. It protects the catalog operator's snapshot,
+but does not establish that the Trust Manifest signer made claims about the
+listed identifier and version. It also couples that claim to one catalog.
+
+### Bind only the artifact digest
+
+Rejected. It proves which bytes were endorsed but permits those exact bytes and
+claims to be relabeled under another logical artifact or release coordinate.
+
+### Require `subject.url`
+
+Rejected. Location binding would prevent mirrors and does not substitute for a
+stable logical identifier. Publishers may opt into location binding by
+including the existing optional field.

adr/0026-remove-host-trust-manifests.md

@@ -0,0 +1,98 @@
+# ADR-0026: Remove Host Trust Manifests
+
+**Status:** Proposed
+
+**Date:** 2026-09-04
+
+## Context
+
+A Trust Manifest may currently appear on either a Catalog Entry or a Host Info
+object. The shared structure is nevertheless defined in terms of an AI
+artifact: its identity, publisher, provenance, policies, and, when signed, a
+`subject` containing the artifact's media type and content digest.
+
+That model has a concrete security purpose on a Catalog Entry. The publisher
+signs claims that are bound through `subject` to the artifact a consumer will
+retrieve. A consumer can compare the signed subject with the entry and the
+artifact bytes before relying on those claims.
+
+There is no corresponding subject or verification target for a Host Trust
+Manifest. Host Info identifies the catalog operator but does not identify an
+artifact whose media type and bytes can be hashed. A Host signature over only
+the nested manifest would protect its internal claims without approving the
+surrounding Host Info object, its placement in the catalog, or the catalog
+snapshot. Even after anchoring its signer, a valid Host manifest could
+consequently be copied into another catalog without invalidating its signature.
+
+The specification also does not define a Host-specific claim vocabulary or a
+consumer decision that depends on independently signed Host claims. Several
+shared Trust Manifest members retain artifact-specific semantics, including
+publisher identity, provenance, and a privacy policy governing the artifact.
+General organizational credentials would require their own issuer, subject,
+claim, validity, status, and verification semantics.
+
+Host Info is already included in the bytes protected by the optional top-level
+catalog signature. Once the catalog signer is independently authorized, that
+is the appropriate scope for establishing the integrity of the operator
+metadata and its association with a particular catalog snapshot. Independently
+signed audit reports or organizational credentials can retain their native
+proof formats; a future profile may define how a catalog carries and evaluates
+them when there is a concrete use case.
+
+## Decision
+
+Remove `trustManifest` from Host Info. A Trust Manifest is defined only as an
+optional companion to a Catalog Entry and continues to carry claims about an AI
+artifact.
+
+This decision does not change Entry Trust Manifest contents or verification.
+It also does not define how a top-level catalog signature identifies an
+authorized catalog signer; that requires a separate decision.
+
+Operator-specific trust evidence is deferred from the core v1 data model.
+Implementations may experiment through the existing top-level
+`AICatalog.extensions` mechanism, but consumers cannot assume interoperable
+semantics for such extensions.
+
+## Consequences
+
+- Every Trust Manifest has the same artifact-oriented meaning and a Catalog
+  Entry that supplies its verification context.
+- Host Info remains the place for informational operator identity and
+  presentation metadata.
+- When present and verified using an authorized signer, catalog-level integrity
+  can protect Host Info and its association with the catalog snapshot. A signed,
+  verified, and anchored Entry Trust Manifest continues to protect an
+  individual publisher's artifact claims.
+- The core model does not provide a standard container for operator compliance
+  evidence or independently reusable organizational credentials.
+- Existing prerelease implementations that expose Host Trust Manifests must
+  remove the field, but there is no released v1 representation whose
+  compatibility must be preserved.
+
+## Alternatives Considered
+
+### Define separate Host and Entry Trust Manifest types
+
+Deferred. Separate structures would remove the artifact-subject contradiction,
+but a useful Host type still needs concrete claims, consumers, and verification
+semantics. No such end-to-end requirement has been established for v1.
+
+### Keep an unsigned Host evidence container
+
+Deferred. A catalog signature could protect an unsigned collection of Host
+attestation references, but the current fields do not yet provide interoperable
+semantics for evaluating organizational evidence. An extension can incubate
+that design without making it part of the core model.
+
+### Sign only the Host Trust Manifest's internal claims
+
+Rejected. This authenticates neither the containing catalog nor the
+association between those claims and that catalog. It adds a second signature
+and lifecycle without a demonstrated independent-consumption requirement.
+
+### Define the catalog or Host Info as the Host manifest's subject
+
+Rejected. Both contain the Host Trust Manifest itself, creating a circular
+representation unless special exclusion and canonicalization rules are added.
+The existing catalog signature already has the correct document scope.