Re: Experimental did:cel Witness Service (open-source)

Manu,

Here's what we've been thinking as we look to evolve did:webvh in its next
version. What I'm thinking about is how important is PQ on the long lasting
DIDs (with large DID Logs) and how should that affecting our thinking.

   - Prerotation has no impact on the size of the log with PQ because the
   pre-rotation commitments are hashes of the "next key".  We are considering
   making the auth keys and witness keys hashes as well, as the proofs
   themselves duplicate the keys, so don't really need to "spell them out" in
   the Log -- the hash is sufficient.
   - We are considering inlining (putting in the Log) the witness proofs
   vs. what we have today of a separate file for those proofs, but that's
   where the PQ thinking comes in. Currently, the separate file is pruned to
   only include the latest proof from each witness, where the latest proof
   "covers" previous Log Entries. That pruning eliminates the vast majority of
   witness proofs in an "expected" use case.  If we inline those proofs into
   the DID Log, they cannot be pruned. We think that's OK for today (2x size
   increase based on experiments) and we benefit from having just one file.
   But if the current PQ signature schemes persist, the inlining size cost is
   MUCH higher and the witness proofs dominate the entire log. With pruning,
   instead of trying to compress, we are removing things -- way more efficient.
   - The use of JSON Lines for did:webvh would also seem like a win in a PQ
   future. A verifier can tradeoff of keeping DID state locally and retrieving
   only the entries added since last retrieval -- likely with gzip compression
   in transit. Again -- not a massive difference today, but with PQ it is more
   interesting.
   - It also makes me think that trying to do "fancy" things in the log
   (e.g. CBOR, gzip) vs. plain old JSON is not going to matter when public
   keys and signatures dominate the log content. The little bit of JSON
   overhead will dwarfed.

Alan, your comment is indeed relevant. I'm guessing that transmitting data
will always matter, but storage, less so. So do we worry about Log size as
the transition is made to PQ -- and if we do, what do we do about it?  Or
do we just ignore the DID Log size today and in the future?

On Wed, Mar 11, 2026 at 10:46 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Wed, Mar 11, 2026 at 10:38 AM Stephen Curran
> <swcurran@cloudcompass.ca> wrote:
> > I've been thinking about log size recently, particularly when combined
> with PQ cryptography.  It seems to me that as we shift to the use of PQ
> algorithms, the size of the data will be dominated by the keys and
> signatures, and compression techniques will be much less useful. So if a 10
> year log has 5 years of PQ keys and signatures will not benefit much from
> compression.
>
> Maybe. :)
>
> I expect that keys that are re-used will be compressed greatly,
> compression is going to help a lot there (the same public key might be
> listed thousands of times, but will only need to go in the compression
> table once and from there on out, will take up a few bytes instead of
> thousands of bytes).
>
> However, if per-event pre-rotation is in play, you're right --
> compression isn't going to help you at all. This is one of the reasons
> did:cel doesn't do pre-rotation per event, though did:webvh escapes
> the worst of it (I think?) by externalizing the signatures.
>
> My hope is also that SQISign will win out over the current PQ
> standards, which have really large key sizes and signature sizes. For
> example, SQISign at security level "NIST I" has 64 byte public keys
> and 148 byte signatures.
>
> https://sqisign.org/
>
> ... which puts it in roughly the same category of storage requirements
> as elliptic curve signatures (~2x-ish more storage required for
> SQISign signatures, not the ~37x-ish storage needed for MLDSA or the
> ~122x-ish storage needed for SLHDSA).
>
> But, you're right... if we stick with MLDSA or SLHDSA, the total data
> you have to retrieve (no matter the log format) is going to balloon to
> 37x to 122x. I think, Stephen, did:webvh has a design pattern to get
> around this -- can you please remind me what happens there? I know you
> externalize into two separate files, but what I'm wondering is if you
> have to download both to verify (if you don't cache, that is).
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>


-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc.