Re: Ideal set of features and DID Methods?

> trust by human interaction

I guess this mean Social Trust.

You only start trusting the cryptokey after interacting with what the
cryptokey represents.

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

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