Re: DID Method Catalogue (was Re: Web 7.0 DID OS)

On Mon, Mar 16, 2026 at 4:35 PM Eduardo C. <e.chongkan@gmail.com> wrote:

> I will read your proposal in detail. In advance, I am under the impression
> that the existing specification says the DID or VC should include the
> resolver URLs itself?
>

That's certainly not how DIDs and VCs are normally used.  DIDs contain a
method name in the string itself, e.g., did:btcr's name is 'btcr' and
did:key's name is "key".

Resolving parties can use any resolver that supports the method.

Neither the DID nor the VC link to any specific resolver.

More comments inline.

I am currently working on 2 pieces of what I think is similar
> InterOperability Infrastructure:
>
> https://github.com/Attestto-com/identity-resolver
> Pluggable on-chain identity discovery for wallet addresses. Given a wallet
> address and chain, discover all DIDs, SBTs, attestations, and credentials
> attached to it. The consumer decides which identity types to accept and in
> what priority — no hardcoded assumptions, *no hardcoded endpoints. --
> this is because a platform should be able to choose what to accept. *
>

Please do not do this.

Decentralized technologies are specifically designed to get rid of
centralized surveillance of online activity. IMO, the whole point of
"wallet addresses" is to separate my PII from my cryptographic roots of
authority. Famously, with bitcoin, you can't even go from the address to
the public key as that gets obscured with the pay-to-public-key-hash
pattern.

You might be picking up on Vitalik's "Soulbound tokens", which have largely
been dismissed by the decentralized identity community precisely because it
puts too much correlatable information online. We really don't want systems
that automagically correlate people across systems.

That said, there is a push for a /whois pattern of usage with DIDs, where
the DID document itself could point to a resource for looking up third
party credentials issued to that subject. This is a way to selectively do
what you want, restricted to the VCs that the DID controller wants to
publish, rather than "all the DIDs, SBTs, attestations, and credentials
attached to a particular cryptographic ID (address or otherwise)." The
latter is a privacy problem that many of us in this community would
actively resist.

To wit, it is a significant problem that the current Rubric focuses too
much on a handful of select methods for examples. It is not appropriate,
for us, in the DID WG, to publish opinions that elevate one method over
another, just like it would be inappropriate for the HTML WG to advocate
for any given website over another.

We provide a specification for interoperability. We don't, as an
organization, take opinions on which methods are better or worse.

Of course, as professionals, we definitely have these opinions. We just
don't think the W3C is the right organization to assert subjective opinions
about which implementation of its specifications are better or worse. Test
suites that stick to normative elements of W3C specifications are fair
game, but anything that goes beyond normative requirements runs headlong
into the political nightmare of the voluntary, competing collaborators that
actually do the work at the W3C.


> https://github.com/Attestto-com/identity-bridge
> Sites broadcast a discovery event, installed wallet extensions announce
> themselves with their DID identity and metadata. Multiple wallets can
> coexist — the END user always chooses.
>

This is an intriguing ambition (assuming I'm following you), but I think
the challenge is getting it adopted by browser makers. DC-API is currently
the hoped-for fix for this linkage in the user experience. It isn't ideal,
but fortunately, it is still under active development at the W3C FedID WG
https://www.w3.org/2025/02/wg-fedid.html and has support from Google and
Apple, giving it a leg up for adoption. I strongly encourage you to join
that effort and get your ideas and concerns into the mix.

I know it can be hard to bring outside ideas into a well-established
institution like the W3C--people like me will comment on the shortcomings
of your approach--but I can attest to the commitment of the FedID WG chairs
to advance the best version of the spec, including responding to a wide
array of concerns that have been raised. From getting rid of the registry
to finding the right way to talk about CTAP, the group has proven--for
me--to be more than open to constructive criticism.

I won't say there isn't politics involved. Of course there is. But you can
best influence the conversation by participating in the WG as it advances
the DC-API specification.

Now, to answer an earlier question from Michael Herman

>
> On Sun, Mar 15, 2026 at 8:39 AM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
>> Why not create a way to ask a DID Subject (Endpoint) which interfaces it
>> supports: methods and parameters?
>> ...the same way openapi works to conventional REST services.
>>
>
We already have. This is what services are in DID Documents. The DID
controller (typically the subject) gets to put any service they like in the
DID document, communicating to clients who resolve the DID (and get the DID
document) exactly which interfaces it supports. My favorite service
endpoint right now is to enable NOSTR communication with the controller,
secured by the DID. Easy peasy.

I think the failure mode I'm seeing in this set of questions is the
expectation that all services for all DIDs are somehow available to the
public for collection and analysis. Such a process would be difficult, and
we designed it that way. In fact, with methods like BTCR2, it's not
possible at all. You can't enumerate all the DIDs in use and in many cases,
you can't resolve the DID itself because the necessary data is private and
VCs issued to or from DIDs need never be publicly revealed. The best you
can do with BTCR, without the controller giving you the extra data, is to
know that you don't have all the updates to recreate the provenance as
recorded on-chain. Of course, if you do, then you can look up services in
the DID document. With DIDs, there is no designed solution for knowing
anything about what VCs may have been issued. That's very much the point of
separating the identifiers from the attestations.

Finally, to comment on bumblefudge's email:

> *From:* bumblefudge von CASA <bumblefudge@learningproof.xyz>
>> *Sent:* Sunday, March 15, 2026 12:03:31 AM
>>
>

> A much more _manual_ process[^1] for evaluating DID methods has been
>> undertaken at the Decentralized Identity Foundation[^2], building on older
>> work (in particular the DID Traits[^3] evaluative framework and the modular
>> Universal Resolver[^4] for testing and evaluation purposes). DID:webs has
>> been in the hotseat twice being asked hard questions about what's in prod
>> and what's unstable, and I'm with Manu, you gave them an unfair shake.
>>
>> More constructively, though, if there are additional DID methods you
>> would like to champion through an apples-to-apples tire-kicking and
>> fact-checking process, we are always looking for volunteers to spin up the
>> docker containers and run the tests locally and, most helpfully of all, PR
>> in harder tests! You'd be surprised how many `true==true?` tests Claude
>> sneaks in there when you're not double-checking...
>>
>
I would also point to my own work with the DID Method Rubric, a publication
of the W3C, available at https://w3.org/tr/did-rubric. This is undergoing a
major renovation right now, in part to incorporate DIF's DID Traits into
the rubric. It is designed for that apples-to-apples comparison on the
criteria that matter to you.

One of the key features of that work is that each evaluation MUST describe
who is responsible for the assessments, when they were done, and who paid
for it. I personally would NOT trust any assessments without authorship as
the conversations to produce these evaluations inevitably require
significant nuance and fine tuning. We argue over what the criteria really
mean and how exactly the method does or does not measure up. It is not a
process that is well suited to probabilistic simplification and it
inevitably involves human judgment.

If you'd like to see what I mean, we did three in-depth evaluations of
did:web, did:v1, and did:ion, all available at https://didevaluations.com

Now, if you want to vibe code something based on the DID rubric, I'd be
happy to help. In fact, the new jsonification of the rubric should make
that much easier.

 --
Joe Andrieu
President
joe@legreq.com
+1(805)705-8651
------------------------------
Legendary Requirements
https://legreq.com