Re: Ideal set of features and DID Methods?

>  In theory, yes. In practice, no. The feedback we have from a number of
small and big governments are that they are not comfortable with going
fully decentralized yet. They want DNS-based identifiers that have a
known trust model. They might consider moving to fully decentralized
in time, but these organizations are not known for being early
adopters. They have too much reputational risk at stake. That is why
we need did:web (as much as a number of us don't like it).

I can acknowledge this being a practical reality.

>  That's not good enough. You also need to ensure that the history is
anchored in time to something you trust, somehow. This is what proof
of work does in Bitcoin, proof of stake does in Ethereum, watchers do
in did:webvh, and witnesses do in did:cel.

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.

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

My spec explicitly states:
" Implementations *MUST* follow JWT best current practices from [RFC8725
<https://z-base.github.io/json-web-history/#bib-rfc8725>]. In particular,
implementations *MUST* enforce algorithm allowlists and *MUST* reject
alg=none."

>  Basing it on Json Web Anything tends to conflate the signature
envelope with the data model, and it looks like that's the case here.

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

>  Using JW* means that you get 33% bloat for every log entry and
counter-signature you do... signing overhead goes exponential fast.
How are you going to support anything but the controller of the
document signing?

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

> Not having a witness (time root) means that history can be arbitrarily
re-written by the controller.

There is a root for logical time....

> Each one of those is a fatal flaw that would need to be fixed. While
others will argue that building on top of JWS is perfectly fine, we
have found it to be ill suited for these sorts of use cases.

I'm confindent you did not read the spec...

Regards,
Jori

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

> On Fri, Feb 20, 2026 at 5:55 AM Jori Lehtinen <lehtinenjori03@gmail.com>
> wrote:
> > I honestly think we should focus only on the high assurance
> decentralized model, because it works for all use cases...
>
> In theory, yes. In practice, no. The feedback we have from a number of
> small and big governments are that they are not comfortable with going
> fully decentralized yet. They want DNS-based identifiers that have a
> known trust model. They might consider moving to fully decentralized
> in time, but these organizations are not known for being early
> adopters. They have too much reputational risk at stake. That is why
> we need did:web (as much as a number of us don't like it).
>
> > So basically the rotation event (and all other event too) have to always
> be singed by the last known private key.
>
> That's not good enough. You also need to ensure that the history is
> anchored in time to something you trust, somehow. This is what proof
> of work does in Bitcoin, proof of stake does in Ethereum, watchers do
> in did:webvh, and witnesses do in did:cel.
>
> > Here is my take on a Cryptographic Event Log:
> > - https://z-base.github.io/json-web-history/
>
> 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.
>
> Basing it on Json Web Anything tends to conflate the signature
> envelope with the data model, and it looks like that's the case here.
>
> Using JW* means that you get 33% bloat for every log entry and
> counter-signature you do... signing overhead goes exponential fast.
> How are you going to support anything but the controller of the
> document signing?
>
> Not having a witness (time root) means that history can be arbitrarily
> re-written by the controller.
>
> Each one of those is a fatal flaw that would need to be fixed. While
> others will argue that building on top of JWS is perfectly fine, we
> have found it to be ill suited for these sorts of use cases.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>