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

Jon, Yes, agreed, I was confused. is exactly what the use case of BC
anchoring is for.


--
Eduardo Chongkan



On Mon, Mar 16, 2026 at 6:49 PM Joe Andrieu <joe@legreq.com> wrote:

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