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

Hi Manu,

Thanks to you for the feedback and opportunity.

About the specific errors you pointed out, the reason was that the missing
data in the spec was interpreted as "Not Met", that is caused by the specs
not meeting a standard in terms of what data they contain that we used for
the Matrix.

Please note the assessments you see, and the demo itself *was indeed vibe
coded* *and the intention was to show the POC. I was expecting comments on
the data and if approved, I was also expecting that each method owner would
submit an updated JSON, having evaluated their spec against the tool
expected JSON. T**he form was initially thought as Newcomers Onboarding
Aid, not to be used as a de-facto assessing tool for the Catalogue or the
Rubric acceptance criteria but to help devs get an idea of how everything
works, how to standardize, and to have visibility of the other methods and
claims, be able to see what was missing for interops between 2+ methods in
an easier way, how other methods cover the requirements, and so on. -- Not
as a grading tool, but as visibility one. *

Then:

*1- Assessment Criteria — "What does 'met' mean?"       *





The 22 requirements exist, but there's no shared rubric for evaluating
them. For example:




  - R6 (Key Rotation): Does "supported" mean the spec mentions it, the spec
defines a protocol, or there's a working implementation? did:webvh has a
full cryptographic log — that's clearly
  beyond "met." did:key is generative (no rotation by design) — is that a
fail or N/A?

  - R11 (Cannot Be Administratively Denied): did:web depends on a domain —
does that fail R11? Or is it "partial" because the controller owns the
domain?
  - R8 (Privacy Preserving): What bar? Any DID on a public chain is
correlatable. Is privacy about the DID itself or about credential
presentation?

*  Need from W3C: A shared rubric per requirement — what constitutes met,
partial, not applicable, and not met. Without this, any assessment is
subjective.*

*  2. Maturity Model — Levels and Signals -- Stays, hoes or changes name?
Idea on this was to get visibility on the overall method development and
implementation process for teams. *

  Our current L0-L4 model uses signals like "has a spec," "has
implementations," "has tests." But:

  - What signals actually matter? GitHub stars? Number of implementations?
Spec completeness? Community size? Deployment in production?
  - Is maturity linear (L0→L4) or multi-dimensional (spec maturity vs.
ecosystem maturity vs. security maturity)?
  - Should "Legacy" be a maturity level or a separate lifecycle status? A
method can be mature AND legacy (like did:sov).


*  Need from W3C: Agreement on maturity dimensions and what signals map to
which levels. Or — scrap prescriptive levels entirely and show raw signals,
letting readers draw their own  conclusions.*

*  3. Taxonomy — Categories and Lifecycle Status*

  - Registry types: "blockchain", "web", "peer", "ledger" — are these the
right buckets? did:webvh is web-based but has a cryptographic log — is it
"web" or something new? or both?
  - Lifecycle: "Active", "Legacy", "Experimental", "Deprecated" — who
decides? The method community? The WG? Observable signals?
  - Feature taxonomy: The 14 features we track (CRUD, key rotation,
multi-sig, DIDComm, etc.) — are these the right ones? Are we missing
capabilities the WG considers important?

 * Need from W3C: Blessed taxonomy for categories, lifecycle statuses, and
the feature set to evaluate.*

*  4. Data Authority — Who Submits, Who Validates?*

  -* Self-assessment:* Method communities submit their own claims. Fast,
scales, but fox-guarding-henhouse risk.
  *- Peer review:* Claims require validation by at least one independent
party. Slower but more credible.
 * - WG-verified:* The DID WG blesses the data. Most authoritative but
doesn't scale.
  *- Hybrid:* Self-assessment with a "verified" badge for WG-reviewed
claims. Unverified claims shown with a disclaimer.

*  Need from W3C: Which model, and what the review process looks like in
practice.*

*  5. Scope - What Should v1 Cover?*

  The current tool tries to do everything, grades, use case mapping,
maturity, overlap analysis, gap detection, self-assessment. The feedback
suggests starting narrower:

  - *Option A: *Feature matrix only *(no grades).* Show what each method
claims to support, let readers compare.
 * - Option B: *Feature matrix + community-sourced maturity signals. No
letter grades, just data.
  *- Option C: *Full analysis but only for WG-verified methods. Everything
else shows "Not Assessed."

  *Need from W3C: What's the right scope for something they'd co-publish
vs. what stays as an independent community tool?  I think maybe A, then B
later on. *

*  6. Use Case to Requirement Mapping*

  I mapped 22 requirements to 18 W3C use cases. But:

  - The mapping itself is interpretive. Does "Prescriptions" really require
R15 (Cryptographic Future-Proof)? Does "Digital Executor" require R20
(Registry Agnostic)?
  - Should the mapping be normative (WG-blessed) or informative (editorial
opinion)?

 * Need from W3C: Review and sign-off on the use case → requirement
mapping, or agreement that it's informative-only.*

Finally, Should I split these 6 decision threads into 6 Issues to discuss
them separately on the repo, under one parent issue? I would create those
once the WG agrees.

In general:

1- Where should it reside? Same repo?
2- What features do we keep, or add?
3- I personally prefer using Tailwind + Vue.js for my projects, can we use
that? -- current version was plain html, vibe coded with no structural
guidance.
4- I would include a .codex.md file so others can tell their LLM to refer
to that when working on the repo.

Regards,

Eduardo Chongkan



On Sat, Mar 14, 2026 at 11:04 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Sat, Mar 14, 2026 at 1:19 AM Eduardo C. <e.chongkan@gmail.com> wrote:
> > There are more screenshots here;
> https://github.com/w3c/did-extensions/pull/677,
> > You can check the tool here:
> https://chongkan.github.io/did-extensions/explorer.html, it was fed form
> the repo as it was, and the idea is that all new methods, use the new json
> so that tool can stay up to date and run during CI -- ( if it gets approved
> )
>
> Hey Eduardo, I really like your initiative and concept behind the
> tooling! Thank you for putting an example together so we can get an
> idea of the changes/tooling you'd like to see in the ecosystem. I
> agree that tools like these are going to be helpful to provide to the
> larger ecosystem.
>
> All that said, I think some of what you have done is dangerous and
> crosses "no-go" lines that the DID WG established a while ago. You
> might not be aware of this, but the DID WG (and the CCG) have been
> trying to establish a useful set of information to expose to people
> that are interested in DIDs. We haven't done some of the things you
> did in your PR because they were identified as things that DID Method
> authors would not like -- that is, there are places where your tool is
> making judgement calls on DID Methods that the tool could not have
> possibly reviewed and is publishing information that is grossly
> inaccurate.
>
> For example, your tool has given a rating of an "F" to did:webs,
> did:btcr, did:btco, and 44+ other DID Methods, on features that I know
> that many of them have. IOW, the tool is giving "F" grades to DID
> Methods for not having features that they definitely have.
>
> The tool has marked did:webvh as a Legacy DID Method and L0 maturity
> (the lowest maturity)... even though it is highly mature and that
> community is one of the most active DID Method communities right now.
>
> The tool has marked did:key is failing to meet every DID Use Case
> requirement (when it passes most of them).
>
> The tool suggests a maturity path for DIDs which is inaccurate... and so
> on.
>
> Are you interested in working with the DID Working Group to establish
> the things that we think we can safely publish and go from there. Your
> vision is a good one (as far as educating the masses and letting them
> filter/pick), however, it feels like you might have vibe-coded this
> thing together and the LLM made some really questionable choices.
>
> So, +1 to the general direction, but there are details here that
> matter and we might want to start with something that is more focused
> and less controversial. What do you think, Eduardo?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>