Re: Ideal set of features and DID Methods?

On Sun, Jan 25, 2026 at 2:04 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> The recent discussion around did:cel, did:webvh, did:nostr, CEL,
> Glogos, Dacument, and the various ways of creating a cryptographic
> event log helped highlight that while we're converging on a set of
> useful features for standardized DID Methods, we're also not quite
> there yet from a community consensus standpoint on which features
> should go into which DID Methods. There also seems to be consensus
> that fragmentation beyond a minimal set of DID Methods that cover the
> majority of use cases we have will harm adoption.
>
> We also have a W3C DID Methods Charter proposal that lists three
> general classes of DID Methods that the group will standardize:
> ephemeral, web-based, and fully decentralized.
>

Subject: Re: Ideal set of features and DID Methods?

Manu, Melvin, Steve, and all —

I've been following this thread with interest. I want to offer a different
frame — not on which DID Methods to standardize, but on whether the current
DID architecture addresses the right requirements.

I agree with Manu's analysis of the three categories and with Steve's
instinct that implementers won't support more than a handful of methods.
But the feature set discussion so far focuses almost entirely on
issuer-side and verifier-side concerns — CELs, witnesses, key rotation.
These matter. Key recovery comes up too (Adrian raises it below), though
notably only rotation has been standardized, not recovery. What's missing
from the discussion is what the holder can do — not just how keys are
managed, but how the holder controls what gets disclosed about them.

**The privileged issuer problem**

In the early days of DIDs — at ID2020, at the first Rebooting Web of Trust
workshops — we were explicit that there should be no privileged role in the
architecture. The holder, the issuer, and the verifier were peers. Over the
past decade, the issuer's role and its trust anchors have quietly taken
over. The VC ecosystem now structurally centers "who says what about whom"
— and the "whom" has a diminishing ability to make their own claims or
control what gets disclosed about them.

Kyle Den Hartog put it sharply last summer: we've been "bestowing new hard
power in the issuer by removing hard power from the subject," repeating the
same pattern that marginalized self-signed certificates in x509 (a mistake
I wanted to address when I was editor of the IETF TLS standard, but failed
to get traction). Manu acknowledged this too — that we've "over-optimized
for large government issuers." I called it systematic inversion [1]:
mechanisms designed to constrain power becoming tools that embed it.

**Holder-controlled elision, not issuer-granted disclosure**

The holder should be able to elide any credential down to the atomic level
without invalidating signatures. Not "disclose what the issuer permits" —
elide what the holder chooses. I raised this distinction on this list last
February [2] — elision is a broader capability than selective redaction or
selective disclosure. It needs to support progressive trust and layered
encryption beyond the narrow credential-presentation use case.

Most current selective disclosure designs give the issuer structural
control over what can be redacted. The holder's privacy is contingent on
the issuer's business model. I wrote about how this played out in "Has SSI
Become Morally Bankrupt?" [3] — the ecosystem drifted until it became
indistinguishable from the centralized systems it set out to replace.

**Herd privacy goes deeper than "no phone home"**

I support the No Phone Home initiative — Blockchain Commons signed it [4].
But its scope is primarily credential status checks, mDL server retrieval,
and federated protocol redirects. The correlation problem goes deeper.

The community's response will be: "We don't phone home — we addressed
this." And at the credential presentation layer, progress has been real.
But DID resolution and the layers beneath it still leak. When a verifier
resolves an issuer's DID to retrieve the public key for signature
verification, it creates observable traces at every layer of the network
stack.
DNS queries for the issuer's domain are plaintext by default, and per RFC
9076, users can be re-identified from DNS query patterns alone. The HTTPS
GET to fetch the DID document hits the issuer's web server or CDN, logging
the verifier's IP, timestamp, and the specific DID path — and if the issuer
hosts their own DID document (common for did:web), they see every
resolution. Even with encrypted HTTPS, the SNI field in the TLS handshake
reveals the target domain unless Encrypted Client Hello is deployed, which
it mostly isn't. Beyond resolution itself, VCs require JSON-LD context
references that processors still typically fetch from remote servers. As
the W3C JSON-LD working group acknowledged [5], unique context URLs can
function as tracking beacons. (Yes I know that these should be pinned, but
in practice, they are not). In did:webvh, witnesses and watchers add
further observers with cross-ecosystem visibility into DID lifecycle events.

The did:webvh spec recommends DNS-over-HTTPS as a SHOULD, not a MUST, and
that addresses only one layer. Caching reduces the frequency of the leak
but doesn't eliminate it — the first resolution is still observable, cache
invalidation creates periodic signals, and small issuers with unique
domains have no herd cover. VDRs and blockchains shift the observer from
the issuer to the ledger operator but don't eliminate the problem, and the
methods gaining traction (did:web, did:webvh) deliberately avoid them.

This is what I meant last year when I said the No Phone Home initiative
"feels like plugging holes in a dam that's already cracking" [1]. The
problem is architectural. If a DID Method's resolution mechanism creates a
correlatable trail at the DNS, HTTP, or TLS layer, no amount of
credential-layer privacy can fix it.

This isn't just my concern. Vitalik Buterin's Ethereum privacy roadmap [13]
identifies the same structural problem: privacy must work across payments,
application activity, RPC reads, and network-level anonymization
simultaneously, because "privacy guarantees" that hold against passive
chain observers fail against infrastructure providers who see query
metadata. He's declared 2026 the year Ethereum reverses its "backsliding"
on self-sovereignty. We should be asking the same of our identity
infrastructure.

Steve is right that the number of methods matters — but adding methods
without fixing the underlying privacy architecture just multiplies the
problem. Three methods built on strong holder-privacy requirements would
serve the ecosystem better than fifty that share the same structural
blindspot.

One concrete step I've already proposed: elision in DID documents
themselves [6] — allowing holders to commit to public keys and service
endpoints without revealing them until needed for a specific proof-purpose.
Key separation means not disclosing all your keys to all verifiers.
Elidable endpoints mean not advertising your service infrastructure to
every resolver.

**Why I've been building rather than blocking**

In 2019, when I did not run for re-election as co-chair of this group, I
did so because I didn't want to just complain or block. I believed the
architecture needed deeper changes than the group's charter allowed, and I
didn't think it was productive to stand in the way of work others found
valuable while arguing for a different foundation.

So for the last six years I've been working to prove the alternative. At
Blockchain Commons we built the Gordian Stack — 22 technologies from the
bottom of the stack to the top — as a working proof of concept that the
requirements I consider non-negotiable are technically achievable.
Self-certifying identifiers with radical elision. Holder-controlled
redaction that preserves signature validity. Progressive trust. Herd
privacy across the full stack. No dependency on DNS or any specific
infrastructure. Data minimization as a structural constraint, not a policy
preference. Support for post-quantum cryptography, multi-party computation,
and both tor onion and dead-drop connections.

XIDs (eXtensible IDentifiers) [7], built on Gordian Envelope [8], sit near
the top of that stack. I'm not proposing XIDs as a DID Method. I don't plan
to make them conform to the current DID spec — the spec doesn't accommodate
the requirements I've outlined above. But I do think the community should
look at the Gordian Stack as a possible roadmap — demonstrable evidence
that what I'd call a "DID 3.0" is feasible today, not theoretical. For
those interested, there's a 20-minute overview of the full stack at [9].

**On key recovery**

Adrian is right that key recovery is our biggest barrier to scale — and
it's telling that the community has standardized key rotation but not
recovery. Blockchain Commons addressed this through SSKR (Sharded Secret
Key Reconstruction) [10], used by dozens of cryptocurrency wallets, and
 we've demonstrated Gordian Clubs [11] — cryptographic group structures
that manage recovery through mathematics rather than administrative
authority. This connects to the Exodus Protocol principle [12]: if
something requires permission to operate, it's not autonomous. Recovery
that depends on a centralized service is another dependency that can be
denied, seized, or shut down.

I'd ask the group to consider whether the next charter should treat
holder-controlled elision and full-stack herd privacy — not just at the
credential layer, but through resolution, context retrieval, and witness
infrastructure — as required features rather than optional ones. The
technical foundations exist.

— Christopher Allen
  Blockchain Commons

[1] https://www.lifewithalacrity.com/article/musings-gdc25/
[2] https://lists.w3.org/Archives/Public/public-credentials/2025Feb/
(selective redaction thread)
[3] https://www.blockchaincommons.com/musings/musings-ssi-bankruptcy/
[4] https://www.blockchaincommons.com/news/No-Phone-Home/
[5] https://github.com/w3c/json-ld-syntax/issues/430
[6] https://lists.w3.org/Archives/Public/public-credentials/2025Mar/
(elision in DID document thread)
[7] https://www.blockchaincommons.com/musings/XIDs-True-SSI/
[8] https://developer.blockchaincommons.com/envelope/
[9] https://www.youtube.com/watch?v=f7MFW8RfcOE
[10] https://developer.blockchaincommons.com/sskr/
[11] https://www.lifewithalacrity.com/article/musings-clubs/
[12] https://www.lifewithalacrity.com/article/musings-exodus-protocol/
[13]
https://ethereum-magicians.org/t/a-maximally-simple-l1-privacy-roadmap/23459