Group trust metadata by contributor and generalize signatures - #117
Draft
jonathanhefner wants to merge 6 commits into
Draft
jonathanhefner wants to merge 6 commits into
jonathanhefner wants to merge 6 commits into
Conversation
Limit `TrustManifest` to Catalog Entries and remove `host.trustManifest` from the normative prose, CDDL, data model, conformance rules, verification guidance, and authoring guides. A nested Host signature has no defined artifact subject, does not approve the surrounding catalog, and lacks a demonstrated Host-specific claim workflow. Record that rationale in ADR-0026 and leave operator authentication as a residual risk for the separate catalog-signature profile.
Require every `Subject` to identify the artifact it describes, and require signed entry manifests to bind any catalog version they rely on. Verify those signed release coordinates against the containing entry so valid artifact bytes and trust claims cannot be transplanted or relabeled as another release. Record the design rationale in ADR-0025, extend the threat model, and align the normative prose, CDDL, examples, xRegistry mapping, and author guidance. Clarify that catalog-level integrity remains complementary to publisher-signed release binding. Signed-off-by: Jonathan Hefner <jonathan@hefner.pro>
Narrow `TrustManifest.identity` to the issuer of the manifest claims, leaving artifact identity to the signed `subject` and runtime identity to protocol-specific profiles. Define one interoperable `urn:air` and root `did:web` verification profile with explicit namespace authorization, detached JWS construction, DID key selection, ES256 requirements, current-state lifecycle semantics, and fail-closed Level 3 behavior. Keep the common JWS envelope extensible so separately defined profiles can supply different key-selection rules. Remove the misleading generic SPIFFE, HTTPS, and DNS resolution procedure, record the design in ADR-0027, and align the guidance, examples, threat model, and earlier ADR history with the narrower issuer model.
Combine upstream PRs Agent-Card#108, Agent-Card#109, and Agent-Card#110 as a temporary review base. Resolve the overlapping host-removal and did:web documentation edits by preserving entry issuer verification and removing Host Trust Manifests.
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.
This was referenced Sep 14, 2026
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.
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
1 participant
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.
This draft is based on top of #108, #109, and #110, which have all been approved. It will be rebased onto
mainonce those PRs are merged. Until then, the last commit in this PR contains the relevant changes -- preceding commits belong to the prerequisite PRs.Summary
Allow publishers, assessors, and federated registries to contribute trust metadata about the same artifact, with independent signatures over the fields each endorses.
entry.trustManifestentry.trustManifests[identity], each retaining its attestation and provenance arrayssignaturesarrays on entries and the catalog root, selecting fields through arrays of keysentry.trustManifest.subjectentry.digestdirectlyMotivation
did:webrules authenticate independent contributors while preserving the additional checks for publisher authority.Rationale
ADR-0028 explains the construction and tradeoffs.
The schema, guides, mappings, examples, and threat model are updated together.
Notes