Define did:web verification for signed Entry Trust Manifests

[jonathanhefner]

This draft is submitted for parallel review. It depends on #108 and #109 and will be rebased onto main as those changes merge. Until then, the commit list includes the release-binding prerequisite from #108, while some Host-related text will disappear after #109.

---

Summary

The specification currently defines a detached JWS for Trust Manifests, but it does not define an interoperable way to determine who is authorized to sign a manifest or which verification key a consumer must use. Its generic key-resolution guidance treats DID, HTTPS, SPIFFE, and DNS identities as interchangeable lookup mechanisms even though each has a different authorization and lifecycle model. For DID documents in particular, finding a key under verificationMethod does not establish that the key is authorized to make assertions.

This PR narrows TrustManifest.identity to one role: it identifies the issuer to which the manifest's claims are attributed. The signed subject identifies the artifact release and representation, while runtime or workload identity remains the responsibility of the artifact protocol or a future runtime-security profile.

For signed Entry Trust Manifests, this PR defines one interoperable publisher-authentication profile. A standard urn:air identifier authorizes the root did:web DID for the same publisher domain. The issuer signs the canonicalized manifest with ES256, and the protected JWS kid selects a P-256 JWK that the current DID document explicitly authorizes under assertionMethod.

ADR-0027 records the decision and its boundaries. The normative specification, threat model, examples, mapping guidance, and author documentation are updated to use the same model.

Rationale

Letting a manifest select an arbitrary identity and then resolving a key from that identity proves only that the signature was made by whoever controls the selected identity. A catalog writer could replace both values and produce an internally consistent self-signed manifest.

The standard urn:air identifier already contains the artifact publisher's domain. Requiring the exact corresponding root did:web DID gives independent implementations a deterministic authorization rule without requiring AI Catalog to operate a registry of signing identities. DID Web delegates control of that name to the existing DNS and Web PKI trust infrastructure; the DID document then identifies the publisher's currently authorized assertion key.

This establishes publisher-domain control, not publisher reputation. A consumer or registry still decides whether that authenticated publisher and its claims satisfy local policy. The profile likewise does not provide historical proof after a key is removed, transparency-log guarantees, or rollback protection.

Choosing one algorithm, key representation, verification relationship, and failure procedure provides a mandatory producer-consumer intersection for v1. Additional identity methods and signing arrangements can be added as separate profiles once their authorization rules and end-to-end use cases are defined.

Under this profile, the publisher and Trust Manifest issuer are the same domain authority. Publishing automation may perform the signing operation with a key authorized by the publisher's DID document, but a separately identified issuer signing on the publisher's behalf requires a future delegation profile.

Verification profile

The profile specifies:

• exact authorization between the signed urn:air publisher component and a root did:web issuer;
• detached compact JWS construction over the JCS-canonicalized Trust Manifest;
• protected alg and kid headers for this profile, and rejection of headers that nominate an attacker-controlled key source;
• ES256 with a P-256 publicKeyJwk as the interoperable v1 algorithm and key representation;
• DID Web resolution, exact DID and verification-method matching, and authorization through assertionMethod;
• verification against the current DID document, including the limits of issuedAt and key rotation;
• subject, entry, artifact, expiry, and fail-closed requirements for Level 3 verification; and
• safe handling of temporary resolution failure without requiring the entire catalog to be discarded.

Scope

This design builds on the signed release binding recorded by #108. In particular, the signed subject.identifier supplies the publisher namespace that authorizes the Trust Manifest issuer; the verification profile cannot safely derive that authorization from an unsigned entry identifier.

It also builds on the Entry-specific Trust Manifest scope recorded by #109. Authentication of the catalog operator and authorization of a top-level catalog signature remain separate concerns.

This PR deliberately does not define:

• path-based did:web identities, publisher delegation, hosted signing services, or corporate-affiliation inference;
• SPIFFE, HTTPS-key-URL, DNS, other DID-method, Sigstore, or additional-algorithm signature profiles;
• runtime or workload identity;
• historical DID document resolution, trusted timestamps, transparency logging, or complete rollback prevention;
• how consumers decide whether an authenticated publisher is reputable or authorized for a particular use;
• a signer-authorization profile for the top-level catalog signature;
• provenance-statement signature formats; or
• a generic credential profile for publisher-identity attestations.

The examples in this PR demonstrate the required structure but are not cryptographic known-answer vectors. A focused follow-up should add a fixed artifact, DID document, canonical payload, valid signature, and representative invalid cases so implementations can test that they compose the referenced standards identically.

Related work

This proposal supersedes #107, which defines publisher-domain alignment as a consistency check but deliberately does not establish domain control, signer authorization, key selection, or signature validity. For signed Entry Trust Manifests, this PR retains the unambiguous standard urn:air publisher boundary and replaces generic domain alignment with an exact root did:web authorization rule and a complete verification procedure.

The proposal intentionally does not retain #107's generic HTTPS and SPIFFE alignment rules because domain comparison alone is not a signature profile for either mechanism. It likewise does not impose publisher-domain alignment on unsigned Trust Manifests, whose claims are not authenticated by a Trust Manifest signature.

---

AI usage disclosure: This PR was developed with AI assistance under my direct supervision and review.

[jdamick]

why only root did:web ?