Re: Ideal set of features and DID Methods?

(And also I guess I interperted what I you tought you did as bad faith from
me..., but I apologize in every case)

To clarify my bad writing...

I interpreted *what you tought I did* as bad faith from me... Eg. I would
have made a bad spec where I haven't tought things trough

pe 20.2.2026 klo 17.32 Jori Lehtinen (lehtinenjori03@gmail.com) kirjoitti:

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