Repository navigation
Conversation
Allow publishers, assessors, and registries to contribute independently to the same entry. Identity-keyed Trust Manifests hold their claims, while entry and catalog signatures select the fields each signer endorses. Use detached JWS over canonical paths, values, context, and timestamps. Bind claims to shared entry release coordinates and digest without a duplicated subject. Reuse did:web key verification while distinguishing contributor attribution, publisher authority, and complete catalog snapshot coverage. Update the schema, examples, guides, distribution mappings, and threat model together while retaining existing transport signing delegation.
Expose the claimed signer as a required identity URI so consumers can inspect endorsements without profile-specific extraction from JWS headers. Keep signature arrays to support several endorsements from the same identity. Bind the exact signer value into the canonical payload. Require the did:web key reference to match that identity and retain DID document, controller, and assertion-key authorization checks. Update the proposed ADR, schema, guide, examples, and threat model consistently.
A signer identity can participate in multiple verification procedures, so its URI cannot reliably select the rules as profiles evolve. Require `profile` and bind its exact value into the signed payload so the selection travels with the endorsement and cannot be relabeled. Name the existing root did:web/ES256 Signer Profile `did-web-v1`, reserve standard tokens, and use URI identifiers for independent profiles. Require supported and locally permitted selection without fallback while preserving separate publisher authorization and coverage checks. Update the schema, examples, guide, ADR, and threat-model summary. Validate the documentation builds and JSON excerpts, plus local ES256 fixtures and independent JOSE checks of profile binding.
Use `aicatalog_trustmanifests` to satisfy xRegistry attribute naming rules, which permit only lowercase letters, digits, and underscores. The logical AI Catalog field remains `trustManifests`.
State explicitly that inline `data` must satisfy JCS input requirements for artifact verification. Require exact, case-sensitive comparison of the authenticated `signer` and contributor manifest key without URI normalization, while preserving third-party endorsements.
Give each contributor a self-contained manifest with one signature and a signed subject. Replace selected-field payloads with whole-manifest and whole-catalog signing while retaining authenticated signer, profile, and timestamp metadata. Reserve the immediate `additionalSignatures` member and exclude it from the payload so later support can preserve existing signatures. Keep nested signatures and reserved fields covered by catalog signatures, and distinguish object kinds through protected JWS `typ` values. Use an array with explicit contributor identities to support independent contributions without identity-key collisions. Defer inter-manifest references, multiple signers, extension binding, and original-URL binding. Update the ADR, examples, guides, mappings, and threat model together. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Require producers to make complete catalogs valid input to JCS, including unsigned catalogs and all nested values. This lets downstream operators import entries or embed complete catalogs without introducing canonicalization incompatibilities. Keep consumer validation during ingestion optional, preserve required signing and verification checks, and allow ordinary JSON serialization. External artifact digests continue to cover exact retrieved bytes. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Compose signer authentication with whole-catalog coverage and exact `host.identifier` matching. This establishes attribution to the declared operator without conflating it with publisher authority, retrieval origin, or consumer trust in that operator. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Permit signed subjects to identify exact content or a live HTTPS resource. Require digest presence and value to mirror the entry, preserve release matching, and verify both bindings when both are present. Make the different assurances explicit throughout verification, profiles, guides, mappings, and the threat model. Apply the rule to all artifact types without changing native OCI signing policy. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Add `subject.extensionDigests` as an exact-key map of whole-value JCS digests. Reuse existing hash rules without duplicating extension contents or introducing nested path selection. Verify each extension independently. A missing or mismatching value loses its authenticated coverage without invalidating the artifact endorsement or other matching extension bindings. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Move privacy and terms links into one official entry extension that a publisher or catalog operator can populate. Use the ordinary extension digest mechanism for optional authentication; no current profile requires coverage of these links. Keep the existing URL meanings and requirements, and distinguish a verified artifact endorsement from authentication of its policy links or documents. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Fifteen fixtures for the signed Trust Manifest rules: contributor and signer equality, kid authorization and controller, endorsement time, release coverage after operator edits, and profile selection, with a reordered positive control. A standard-library checker applies the rules and a generator reproduces the fixtures from fixed seeds.
jonathanhefner
force-pushed
the
agent/identity-keyed-trust-manifests
branch
from
October 6, 2026 19:46
00f1a05 to
99d8bfd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Offered for Agent-Card#117, opened against its branch so it can fold in or be cherry-picked.
This adds fifteen offline fixtures for the signed Trust Manifest rules in this PR, covering contributor and signer equality without URI normalization, kid authorization and controller checks under the did:web Signer Profile, endorsement time, Entry Release Coverage after an operator edits version, digest, or URL, and exact profile selection with no fallback, together with a positive control whose members and manifests are reordered. Each fixture carries its catalog, the DID documents a verifier would resolve, the artifact bytes for URL entries, the verification instant, the expected outcome with a rejection code, and where useful a premise showing the JWS itself is cryptographically valid so the rejection is clearly a rule. A standard-library checker in tools applies the rules and a generator reproduces the fixtures from fixed seeds, so nothing is added to pyproject or the lockfile and the spec and docs builds are unaffected. The fixtures target the shape at 00f1a05 and are easy to regenerate if the signature or subject members change again before merge.
AI usage disclosure: This PR was developed with AI assistance under my direct supervision and review.