Re: Ideal set of features and DID Methods?

On Sat, Feb 21, 2026 at 8:04 PM Christopher Allen
<ChristopherA@lifewithalacrity.com> wrote:
> 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.

To cut to the chase: The reason many of the things you want haven't
happened yet is because there is no clear consensus or collective
effort to achieve SOME of the things you want to see (People aren't
putting in the effort for a variety of reasons). For some of the other
stuff, the current architecture can do it, but there is no economic
motivation to do so (not in a financial sense, but an "actual value
generated to society" sense).

I am, personally, sympathetic to what you want to see happen. There's
a vision there that feels right. I think it's safe to say that our
company is sympathetic as well (having invested tens of millions of
dollars into these very technologies). So, what I'll try to share
below is why I think it hasn't happened yet.

> Manu acknowledged this too — that we've "over-optimized for large government issuers."

Ehhh, I feel like I'm being quoted out of context here. We (the
ecosystem) have focused on government issuers because they issue
credentials that society values. If we don't at least focus some
effort on it, there is little economic value in the ecosystem
(financial or societal) and it fails. That is not without some
negative consequences, which you rightly point out. However, what you
suggest as an alternative is bound to be under resourced and likely to
fail (as it has failed over the many decades prior).

People are quite unlikely to trust an individual directly unless they
really know you, so they defer to an authority to provide digital
credentials for transactions that have high economic value or could
cause high economic damage to them if not processed properly.

The DID/VC architecture is still peer-to-peer, but self-issued digital
credentials have little economic value by themselves. IOW, society is
not set up to value them in the same way that they value an
institution-issued credential. This isn't a technology problem, it's
how society is currently structured and there are good reasons its
structured in this way (that do have downsides). So, for some of your
problems, you need to restructure society to operate differently --
technology alone can't address the issue you are trying to address.

IOW, I don't trust a stranger to say that they can pay me later... I
want someone else I trust more to say it (and take on the credit
risk).

> These matter. Key recovery comes up too (Adrian raises it below), though notably only rotation has been standardized, not recovery.

Yes, well, that just needs someone to come along and put in the effort
of proposing a technical solution, do the spec work, build consensus,
and put it in the spec. I think people are experimenting with this
(did:webvh and did:cel, for instance). Again, the issues here are: 1)
No one has dedicated effort to this in a way that's leading to
consensus, and 2) we're still experimenting on the right way to do it.

> 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.

I'm going to push back hard on this point. No, that's not accurate at all:

1. Nothing in the architecture prevents a subject from self-issuing
their own claims. You can do that today with VCs, and have always been
able to do that.

2. The holder always has the opportunity to not share a credential
with a third party.

3. There are very good reasons why an issuer might not want  two
claims to be disclosed together. For example, if I make the following
two claims: "John is a good employee. John needs daily guidance to
stay on task. John worked for us for 5 years." -- I don't want that
forwarded on to another employer without a mandatory disclosure of the
second statement -- because I don't want my claims to be misused,
leading to reputational damage to me (as the issuer).

So, I think your design goal of "don't give the issuer the choice of
what they want to be selectively disclosable about what they say" is a
good idea. We did discuss this in the group and that's where we
landed. Little has changed to argue against that point. That's not to
say that it's not without its ramifications -- yes, the holder doesn't
have control over eliding negative statements that the issuer has said
about them. However, the holder does have the option of not sharing
those statements, or going elsewhere to get more favorable statements
from some other issuer.

> **Holder-controlled elision, not issuer-granted disclosure**
>
> The holder should be able to elide any credential down to the atomic level without invalidating signatures.

No, they shouldn't be able to ALWAYS do that; that's an anti-pattern.
Just imagine that an issuer is an individual saying something about a
subject: "I know John. John is a good neighbor. John has a high net
worth. John is addicted to alcohol." -- That issuer doesn't want to be
quoted out of context, they are not ok with the last statement being
elided from the other statements. If you make that a mandatory part of
the technology stack, people will stop using it for most use cases.

I think the best we can do is try to nudge the ecosystem to make
everything elidable in the vast majority of cases... but there are
some cases where you don't want that.

> **Herd privacy goes deeper than "no phone home"**
>
> But DID resolution and the layers beneath it still leak.

You're overgeneralizing your argument. It's highly dependent on the
architecture and DID Method. More below...

> 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).

Citation? Please point to VCs or DIDs in production today that use
unique context URLs.

The specs are clear about pinning. For example, all of our production
software pins context files... we know this because failing to issue a
VC because a context wasn't pinned is a common failure mode in our
software. That is not to say that organizations, including ours, might
accidentally have some junior programmer write some software that
accidentally fails to do this, but it is just that -- a bug that needs
to be fixed. Just like TLS software that have CVEs are bugs that need
to be fixed.

The arguments you make here feel fairly weak. Most of them collapse
to: "People COULD do a bad thing, therefore the technology is broken
and we need to throw it out and use XIDs!"

For example, the reason Oblivious HTTP and DNS-over-HTTPS are SHOULDs
and not MUSTs is because they are not broadly deployed. If they had
TLS-level deployment, we'd move them to MUSTs, but we're not there
yet. To throw out the architecture because society hasn't gotten to
TLS-level support (which took decades) feels misguided to me.

I do agree that did:web and did:webvh don't have the characteristics
that you desire. I'd argue that did:cel does, or a stripped down
version of did:webvh (which would effectively be did:cel) could.

> 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.

The DID architecture has always allowed this through these mechanisms:

1. A DID controller issues a VC specifying a public key it has control over.
2. A DID controller issues a VC specifying a service endpoint it has
control over.
3. A DID controller anchors hashes to the VCs above in the DID document.

We have allowed that since DID v1.0, and you could have built on top
of that. The spec has always been capable of supporting your key
separation and elidable endpoint features (which I do think are good
features to have).

If you had just contributed those extensions to the spec over the past
several years, we would have already closed that capability gap.

Again, the problem here isn't with the architecture, it's that people
didn't put in the effort to do the concrete work of building consensus
and modifying the spec and instead went off and did their own thing.
Yes, I do realize that XIDs probably do a bunch of other things, and
sometimes it's easier to experiment and build off in a corner instead
of engaging with the slow standardization process... but building in a
corner has its downsides as well and the reason the standardization
process is slow at times is because there just aren't enough people
doing work.

My hope is that we can eventually merge these features into the DID
spec because they've always been possible -- we just need someone
that's going to step up and do the work. Yes, doing experimental
implementations are an important first step, but they only get us
about 30% of the way to where we need to be to get this stuff
integrated into the standards.

> 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.

Again, strong pushback on what you're saying above. I've shown where
some of the things you are asserting are accommodated by the current
DID/VC architecture, and where others aren't a good idea. Some of the
rest I can't speak to because I haven't read all 22 technologies you
mention (only so much time in the day).

I do think that experimentation and "let many flowers bloom" is
healthy for the ecosystem. Similarly, I do think calling out the
shortcomings of DIDs and VCs as they exist today is also a good and
healthy thing. I just saw a number of things you say that did not
resonate for a variety of reasons (inaccuracy being one of them).

> I do think the community should look at the Gordian Stack as a possible roadmap

I do agree that would be a healthy thing to do... I'm sure there is
stuff in there we could learn from... the thing we're missing right
now is the extra people and bandwidth to do the hard work of writing
implementations, building consensus, writing spec text, creating test
suites and shepherding the features through the standardization
process.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Sunday, 22 February 2026 16:12:03 UTC