feat(identity): DID-anchored identifier branch for domainless publishers (§4.2.1, §5.1.1, Appendix C.1)

[yepgent]

Closes the domainless-publisher identity gap from #47. Additive throughout — the FQDN mainline is untouched.

What this does

Lets a publisher with no controllable FQDN — identity rooted in a W3C DID (did:plc, did:web) and a signed data store — appear in an ARD catalog with cryptographically verifiable authority.

Section	Change
§4.2.1	DID-anchored URN branch: urn:air:did:<method>:<method-specific-id>:<namespace>:<agent-name>. Initial set did:plc + did:web (host-only); DID occupies exactly 3 colon-segments. did:key/did:peer/path-bearing did:web deferred.
§5.1	Additive authority-alignment carve-out for identityType: "did" — verified DID control satisfies alignment; FQDN alignment not required. No rewrite of the FQDN rule.
§5.1.1 (new)	Normative 4-step resolution path: resolve DID Doc → select verificationMethod (kid, else first compatible) → verify detached JWS over JCS-canonicalized (RFC 8785) bytes → reject on failure.
Appendix C.1 (new)	Shows the DID branch preserves all five federation properties; written to compose with #24.
§4.4	Domainless (DID-anchored) worked example.
ADR 0010	Decision record.

Maintainer guidance from #47, applied

• ✅ Initial method set held to did:plc + did:web (web = DNS migration on-ramp); no open-ended method registry.
• ✅ Canonicalization pinned to JCS (RFC 8785) — explicitly MUST NOT be implementation-defined.
• ✅ §5.1 carve-out is additive, not a rewrite (new §5.1.1 carries the resolution path).
• ✅ One issue, one PR — URN branch and resolution path ship together (they are interdependent).
• ✅ Appendix C wording written to compose with Design: URN semantics for NAT'd and relay-accessed agents #24, flagged here rather than blocking on it.

Conformance / schema

No schema change required. The existing ai-catalog.json identifier pattern (^urn:air:[a-zA-Z0-9.-]+(:[a-zA-Z0-9._-]+)+$) already admits the DID-anchored form — the DID's internal colons parse as additional segments (verified against urn:air:did:plc:… and urn:air:did:web:…). CDDL and conformance fixtures unchanged; CI stays green.

Review

Per CODEOWNERS and the process note on #47, this touches normative §5.1 + Appendix C — tagging @rvguha as the final approver for those sections. Happy to split into a separate Design issue per #19 if a different shape is preferred.

Neighbors

• Design: URN semantics for NAT'd and relay-accessed agents #24 (URN semantics for NAT'd/relay agents) — same FQDN assumption, transport side; Appendix C.1 is written to compose, not conflict.
• feat(trust): add SOVP-v1 pre-execution infrastructure attestation type (§5.2.1, §5.2.2) #48 / feat(trust): add SOVP-v1 pre-execution infrastructure attestation type #41 (SOVP-v1, §5.2) — disjoint section space (§5.1.1 vs §5.2.1); no overlap.

Companion

Artifact-side field lives in drknowhow/install-manifest-spec#37 — optional publisher block (did + detached JWS over canonical manifest bytes), same JCS constraint, so an install-manifest can carry the identity binding this path verifies.

[litzki-systems]

Clean scope discipline. The §5.1/§5.1.1 carve-out stays genuinely additive and the JCS pin (RFC 8785) is the right call for interoperability.
One observation worth flagging for the record: the JCS canonicalization constraint here aligns with the approach in #48 (SOVP-v1 infrastructure attestation), where the same RFC 8785 baseline is used for the signed attestation payload. Both paths end up in disjoint section space, but they share a canonicalization primitive - which means a DID-anchored publisher that also carries a SOVP attestation (§5.2.1) would use a consistent signing discipline across identity and infrastructure layers. Worth noting in Appendix C.1 as a composition note if that scenario is in scope for future work.

[yepgent]

@litzki-systems — agreed, and thanks for naming the shared primitive. The JCS pin wasn't incidental: it was chosen to keep one signing mental model across the spec, so it lining up with SOVP-v1's RFC 8785 baseline (#48, §5.2.1) is the intended shape rather than a coincidence.

Folded a short composition note into Appendix C.1 (0e21e2a) — disjoint sections, shared canonicalization, no normative coupling, flagged explicitly as a composition property rather than a dependency so neither branch requires the other.