Re: Ideal set of features and DID Methods?

On Fri, Feb 20, 2026 at 9:30 AM Jori Lehtinen <lehtinenjori03@gmail.com> wrote:
> I'm confindent you did not read the spec...

Jori, you're doing it again (presuming incompetence / bad faith):

https://www.w3.org/policies/code-of-conduct/#unacceptablebehavior

I read the spec, and it's clear I misread part of it now (around
alg=none), but asserting that I didn't do something I did do is not
motivating me to provide the feedback you are seeking. I always have
the choice of doing something more productive with my time and
responding to constructive criticism. That said, I could have provided
my feedback in a more constructive way (the "Yikes" was unnecessary)
and I will endeavor to do that in the future.

> In the JWH model you the trust comes from your own copy. If you can't merge the new history presented by the DID without conflict and all signatures passing it gets MUST be rejected.

I don't understand how a verifier would trust a history that can be
regenerated at will by the controller of the DID.

> >  Yikes... alg=none by default, yet another JSON Web conflation, no
> ability to do set-based signatures, no witnesses. I get that the spec
> was AI-assisted, but it's broken in at least four ways right now:
>
> alg=none means none of the history is signed.

On second read, I can see that alg=none is disallowed, which is good.
That addresses one of my concerns.

> The reason I base it on them is the JOSE standards have a touching point with a lot of known concepts and are familiar...

Yes, but that's not the issue I raised. It was about the conflation of
the data model with the envelope format. Perhaps seeing what a log
looks like would be useful... some complete examples in the spec,
perhaps.

> You are right that the there is a lot of traverse wich creates over head if not handled in a smart asynchronous way.

I don't understand what that means. There is no "smart asynchornous
way" to avoid 33% compounding bloat in the data structure... unless
you are saying: Yes, there is 33% compounding bloat in the data
structure and that's a side-effect of the design. For example, for a
DID Document, every change to that DID Document would make the history
33% larger... maybe? I can't tell without some examples.

> There is a root for logical time....

I presume you are referring to the root pointer. Logical time isn't
good enough for most of the Verifiable Credential use cases... if a
verifier is going to trust the history, they need to know if the
history was re-written by the controller or not, and logical time
doesn't solve that problem.

-- manu

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

Received on Friday, 20 February 2026 15:06:25 UTC