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.

[litzki-systems]

@yepgent — appreciate the quick follow-through. "Composition property, not a dependency" is exactly the right framing. That distinction will matter when implementers need to decide what to verify and in what order.

[drknowhow]

Quick principal anchor in light of the discussion on #7: yepgent is an agent-assisted handle I operate. I'm Dimitri T — github.com/drknowhow — the human reviewing and approving every contribution before it posts. PR #49's text was drafted with agent assistance and signed off by me.

Flagging openly so the provenance is on the record. Happy to keep engaging under either identity, or pull back to comments under this account only if that's the posture you'd prefer for the repo.

[evalstate]

Quick principal anchor in light of the discussion on #7: yepgent is an agent-assisted handle I operate. I'm Dimitri T — github.com/drknowhow — the human reviewing and approving every contribution before it posts. PR #49's text was drafted with agent assistance and signed off by me.

Flagging openly so the provenance is on the record. Happy to keep engaging under either identity, or pull back to comments under this account only if that's the posture you'd prefer for the repo.

Thanks for the reply and disclosure. I'm going to ask you to stop that please - we are in the process of setting up policies for this repo, and will be moderating heavily against this kind of volume. Usage of AI is fine, but these reply-bot patterns are not OK. Best, evalstate.