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

Hi all,

Promised an update. Took a bit longer than "tonight" but here it is.

What changed in the tool (DID Method Checklist
<https://attestto-com.github.io/did-method-checklist/>):

   1. No more letter grades. The tool now shows coverage percentages only,
   reflecting what each method's community has documented against the 22 W3C
   requirements. Not our evaluation, not a ranking. Each method team owns
   their self-assessment.
   2. Verified claims vs inferred scores. The tool now separates what a
   method's spec explicitly documents from what's inferred by requirement
   overlap. If a method doesn't claim an industry vertical, it says "No
   industry verticals documented" with an invitation to submit via the
   checklist. No more red F's for undocumented features.
   3. Editorial notes system. Human-written notes with severity levels
   (critical/warning/info) and source links. This is the layer where peer
   review and corrections go.
   4. LLM disclaimer front and center. The initial data was populated with
   an LLM for demo purposes, and the tool says so in orange text on every
   page. Each method team should review, correct, and complete their entry so
   other projects can understand how to interoperate with their method.
   5. Self-Assessment wizard. Step-by-step flow for method teams to
   document their own capabilities. Signing is optional. Export as JSON for
   submission via PR.

Separately: I submitted did:pki for peer review (w3c/did-extensions#697).
It bridges national PKI hierarchies (X.509 CA chains) to DID Documents.
Costa Rica's SINPE hierarchy resolves end-to-end via a live DIF Universal
Resolver driver.

Re: the 6 decision points I raised on March 16, I still think those are the
right questions. Happy to split them into issues on the repo if there's
interest from the WG. In the meantime, I went with Option A (feature
matrix, no grades) as the default posture.

BumbleFudge, I looked at DIF's recommended process and the DID Traits
framework. The checklist questionnaire (checklist.md) is structured to be
compatible with both. Would welcome feedback on alignment. Q, if the PKH is
retired, should we flag that in the repos? Should we look for responses
from the other methods and see if we need to update the status?

Kind regards,

Eduardo Chongkan
Attestto | https://attestto.org

--
Eduardo Chongkan



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

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