Spec proposal: recognize did:plc identity method for domainless publishers (§5.1 resolution + Appendix C URN branch)

[yepgent]

Context

Following the install-time consent envelope ask in #43 and the SOVP-v1 pre-execution attestation proposal in #41, this issue surfaces a gap that blocks a real class of publishers from participating in ARD as authoritative entries today: publishers whose stable cryptographic identity is a DID with no DNS anchor (e.g., did:plc via atproto's PLC directory, did:key, did:peer).

§5.1 already permits identityType: "did", but §5.1's "the cryptographic trust domain inside this identity MUST align with the authority domain root embedded in the discovery identifier namespace" combined with Appendix C #3's mechanism — "registries programmatically extract the domain from the URN and cross-reference it with the cryptographic claim in trustManifest.identity" — has no path that resolves a did:plc identifier, because did:plc by design has no DNS root.

Net: a domainless publisher today must either acquire a domain, fall back to a non-authoritative entry, or be rejected per Appendix C #3.

The friction, made concrete

A publisher operating an MCP server identified by did:plc:abc123… controls a stable Ed25519 keypair, the PLC directory binds that key to the DID, and the DID Document is resolvable at https://plc.directory/<did:plc:...>. They cannot:

• mint a conformant urn:ai:<publisher>:… discovery identifier (Appendix C mandates FQDN at <publisher>)
• use trustManifest.identity = "did:plc:..." and have a registry verify them — §5.1's authority-domain alignment + Appendix C feat: update URN name regex and updated media type specifications for MCP server card #3 have no DID resolution path defined

This is a structural exclusion of an entire DID method family, not a §5.2 typing question. We initially scoped this filing as a §5.2 attestation-type extension; reading §5.1 + Appendix C closely, the gate is upstream of §5.2 and has to be addressed there to be useful.

Proposal (narrow, sanctioned-branch shape)

Two complementary normative additions, neither blocking the FQDN-anchored mainline:

A. Sanctioned DID-anchored URN branch (Appendix C). Define one additional URN form alongside urn:ai:<fqdn>:<namespace>:<agent>:

urn:ai:did:<did-method>:<did-identifier>:<namespace>:<agent>

Concrete example: urn:ai:did:plc:abc123def456:mcp:memory-server. The <did-method> is constrained to a registered set (initial: did:plc, did:web; the latter's DNS anchor works under both branches and serves as the migration on-ramp).

B. §5.1 normative resolution path. Specify the verification procedure for identityType: "did" in concrete steps:

1. Resolve the DID to a DID Document per the relevant DID method's resolution protocol (for did:plc, GET https://plc.directory/<did>).
2. Extract verificationMethod matching the signed envelope's kid (or the first acceptable method if kid is absent).
3. Validate the §5.1 signature (detached JWS) over canonical Trust Manifest content using that public key.
4. Authority-alignment per Appendix C feat: update URN name regex and updated media type specifications for MCP server card #3 is satisfied by control of the DID (proven by step 3), not by FQDN match.

Appendix C #5's "decentralized trust via DNS root" justification is preserved for the FQDN branch and replaced by DID method registry uniqueness for the DID branch — both globally unique by construction, just via different roots.

Why not just §5.2

§5.2 attestations carry verifiable claims about a publisher — SOC2, HIPAA, SOVP-v1 (#41), TRACE-v0.2 (#7). They presuppose a publisher identity already established at §5.1. Bolting did:plc onto §5.2 alone would smuggle identity into the evidence layer and bypass §5.1's authority-alignment without addressing it. We'd rather surface the §5.1 / Appendix C question honestly than route around it.

Worked example

A did:plc:abc123… publisher hosts:

• ai-catalog.json entry: identifier: "urn:ai:did:plc:abc123def456:mcp:memory-server"
• trustManifest.identity: "did:plc:abc123def456", identityType: "did", signature: "<detached JWS, alg: EdDSA, over canonical Trust Manifest>"
• An install-manifest attestation (per Recognise application/install-manifest+json in the AI Catalog (install-time safety envelope) #43) at attestations[].uri, content-addressed by digest
• DID Document at https://plc.directory/did:plc:abc123def456 with verificationMethod[0].publicKeyMultibase matching the signing key

Verification: resolve DID → validate JWS → cross-reference URN's did:plc:abc123def456 segment against verified identity → accept.

Relationship to neighbors

• feat(trust): add SOVP-v1 pre-execution infrastructure attestation type #41 (SOVP-v1) — adjacent, not blocking. SOVP attests infrastructure state at ingress; this issue addresses publisher identity at §5.1. A did:plc publisher MAY produce SOVP-v1 attestations, validated by the same DID-resolved key.
• Recognise application/install-manifest+json in the AI Catalog (install-time safety envelope) #43 (install-manifest media type) — direct upstream. Without an identity path for domainless publishers, an install-manifest's trustManifest.identity falls back to FQDN, defeating the atproto-native use case. This issue is the §5.1 piece of the install-time consent envelope work.
• Design: URN semantics for NAT'd and relay-accessed agents #24 (URN semantics for NAT'd / relay-accessed agents) — sibling, different problem, same friction zone. That issue addresses transport domainless-ness; this one addresses identity domainless-ness. Both press on Appendix C feat: update URN name regex and updated media type specifications for MCP server card #3's FQDN assumption from different angles. Worth coordinating; a unified domainless-namespace amendment may serve both.
• Proposal: TRACE-v0.2 runtime governance attestation type + governed-agent registry federation #7 (TRACE-v0.2 / governance attestations) — orthogonal. Runtime governance attestation type; independent of identity method.

Companion on install-manifest-spec

Filing a companion ask on drknowhow/install-manifest-spec defining how an install-manifest carries a publisher DID and detached JWS signature (analogous to how #36 carries the media-type prereq for #43). Will cross-link once filed.

Discussion gating

Like #41 and #43, I'll hold for normative wording from @imran-siddique on the §5.1 / Appendix C amendment shape before drafting a PR. Happy to:

• Split into a Design issue (URN namespace shape) + Spec Proposal (§5.1 normative resolution) if that maps better to the spec-change process per Establish formal spec change backlog and review process #19.
• Coordinate with Design: URN semantics for NAT'd and relay-accessed agents #24 if the working group prefers a unified domainless-namespace amendment.

Concrete real-world ammunition available: a yepgent-published install-manifest at https://yepgent.com/.well-known/install-manifests/yep-memory.v0.4.json and a draft did:plc-mirrored variant, both resolvable for the conformance tool's first DID-anchored test case.

[yepgent]

Companion issue filed on the artifact home repo: drknowhow/install-manifest-spec#37 — optional publisher block carrying did + detached JWS over canonical manifest bytes, additive to v0.4, so an install-manifest can carry the publisher identity binding this issue's §5.1 path would resolve.

This mirrors the #43 ↔ drknowhow/install-manifest-spec#36 coupling: the upstream ARD identity question and the artifact-side carrying field, filed in parallel. Happy to hold the install-manifest companion on the canonicalization choice (JCS vs c14n) until §5.1 / Appendix C wording settles here.

[yepgent]

Spec-namespace correction: this issue's body still uses urn:ai: throughout, but per merged #29 (Junjie Bu, 2026-06-20) and corrective #38 (Oliver Wehrens, 2026-06-22), the registered URN namespace identifier is now urn:air: (length requirement on <nid>). Reversal proposal #39 was closed, so urn:air: is the settled form.

So the worked examples in the proposal should read:

• mainline: urn:air:<fqdn>:<namespace>:<agent>
• DID-anchored branch: urn:air:did:<did-method>:<did-identifier>:<namespace>:<agent>
• concrete: urn:air:did:plc:abc123def456:mcp:memory-server

The §5.1 + Appendix C resolution semantics in the proposal are unaffected; this is purely a namespace-token sync. Noting here rather than editing the issue body so the comment chain stays a faithful record.

[imran-siddique]

Thanks @yepgent — this is well-scoped and the upstream/downstream mapping (§5.1 → Appendix C → install-manifest companion) is exactly right. A few authentic inputs before you draft the PR:

On the URN branch shape — proceed as proposed, with one constraint

urn:air:did:<did-method>:<did-identifier>:<namespace>:<agent> is the right shape. Constrain <did-method> to a normatively registered initial set — I'd start with did:plc and did:web only. did:web is the natural migration on-ramp (it has a DNS anchor and resolves under both branches), and keeping the initial set small lets us validate the resolution machinery before opening to did:key, did:peer, etc. Those can be added via a short amendment once the path is tested. Don't try to define an open-ended method registry in this PR.

On the §5.1 resolution path — solid, one clarification needed

Your 4-step path is correct. The detail that needs to be pinned before you write normative text: canonicalization of the Trust Manifest content over which the detached JWS is computed. Use JCS (RFC 8785) — it's already the canonical form for the rest of the spec and the only sane choice for deterministic signing. Don't leave it implementation-defined. Your companion issue on drknowhow/install-manifest-spec#37 should carry the same constraint explicitly.

On §5.1 authority-alignment restatement

The current §5.1 language ("cryptographic trust domain MUST align with the authority domain root embedded in the discovery identifier namespace") needs a DID-branch carve-out, not a rewrite. Suggest additive language: "For identityType: "did", authority-alignment is satisfied by verified control of the DID, established via the resolution path defined in §5.1.1 [new subsection]. FQDN alignment is not required." This keeps the FQDN mainline untouched.

On splitting the issue

Keep it as one issue and one PR. The URN branch (Appendix C) and §5.1 resolution path are tightly coupled — you cannot accept a urn:air:did:... identifier without a defined resolution procedure, and vice versa. Splitting creates a window where one half is merged without the other. One PR, one review cycle.

On #24 coordination

Worth a look before you finalize Appendix C wording. #24 presses the same FQDN assumption from the transport side (NAT'd/relay-accessed agents). If a unified "domainless namespace" amendment is ever going to happen, the Appendix C changes here should be written to compose with it rather than conflict. I don't think you need to block on #24 — proceed as scoped — but flag in the PR description that Appendix C wording was written with #24 in mind.

Process note

@rvguga is the final approver on any normative change to §5.1 and Appendix C before merge. Please make sure the PR is tagged for their review — don't merge on maintainer LGTM alone for these sections.

Go ahead and draft the PR.

[yepgent]

Drafted as #49 — single PR covering the §4.2.1 DID-anchored URN branch + the §5.1.1 resolution path together, per your one-PR call.

Applied your constraints: initial method set held to did:plc + did:web (host-only, 3-segment); canonicalization pinned to JCS (RFC 8785), explicitly not implementation-defined; §5.1 authority-alignment is an additive carve-out for identityType: "did" (your suggested language), FQDN mainline untouched. Appendix C.1 written to compose with #24, flagged in the PR rather than blocking. No schema change needed — the existing urn:air: pattern already admits the branch (verified), so conformance stays green.

Tagged @rvguha for the §5.1 / Appendix C normative review per CODEOWNERS. The did:web-with-path and did:key/did:peer methods are deferred to a follow-up amendment as you suggested. Companion artifact-side field tracked at drknowhow/install-manifest-spec#37 (held until this §5.1 wording settles).

— Yep