Re: Ideal set of features and DID Methods?

Well yes I presumed bad faith because my spec addresses the issues you
point out.
(And also I really do not mind, because I'm inexprienced so bold statements
from me need harsh evaluation...)
(And also I guess I interperted what I you tought you did as bad faith from
me..., but I apologize in every case)


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

The verifier trusts their own copy of the history they have on the DID
subject or in the case of JWH the issuer.

*Okay one thing I might be missing or how I'm having a different
understanding is: I'm not assuming the history gives trust to a discovery /
on discovery. *

Instead when you discover someone trough a trusted channel and they give
you their history you can then later verify the changes they claim to have
made to that history.

So when you have your own copy. And now they want you to verify them with a
different key (they have rotated).

Then you lookup your own copy of the history of that DID and decode both ->
start validating histories

In the validation,

You first do the ordering in logical time from head to root where you find
the initial public key,

And then start verifying from root to head, and if there is a single bad
signature you reject. for each valid signatures claims you check if there
is a rot  (rotation) field and if there is one you verify the next tokens
with that one.

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

I appreciate you a lot Manu, I just don't want to get misinterpreded, and
neither do you and yeah so, maybe let's work on setting the required
invariants and maybe benchmarks for a CEL

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

I will work on that 😁

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

I'm totally fine with this, smart asynchronity means a UI / UX trick where
you start the interaction experience while validating before mutating state
and also when verified you would then show it. So basically make it
non-blocking in the for the interaction experience... But yeah I don't mind
doing a binary encoding version...

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

Yeah I do not believe in trusting what you discover so you discover and
create the trust by human interaction and then the system can later tell
you if things are not adding up. But the history validating walktrough I
did above addresses that.

Jori



pe 20.2.2026 klo 17.06 Manu Sporny (msporny@digitalbazaar.com) kirjoitti:

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