Re: Thoughts on the LDS WG chartering discussion

> On 10. Jun 2021, at 07:27, David Booth <david@dbooth.org> wrote:
> 
>> . . .
>> 1. Why is there any need to sign a graph and not just the bytes? See the explainer document at
>> https://w3c.github.io/lds-wg-charter/explainer.html#noProblem
>> for the answer to this.
> 
> Sorry to belabor this, but I read the explainer document, and I still do not see an answer to this question.

Can we just use mathematics to explain this?

Take a graph with n triples. What are the number of ways of ordering these triples
into a serialization? I think it is n!

I wrote a little factorial program in Scala 3 for fun

scala> def fact(n: BigInt): BigInt =
     |   n match
     |      case 1 => n
     |      case x => x * fact(n-1)
scala> fact(3)
val res0: Long = 6
scala> fact(5)
val res2: Long = 120
scala> fact(120)
val res4: BigInt = 6689502913449127057588118054090372586752746333138029810295671352301633557244962989366874165271984981308157637893214090552534408589408121859898481114389650005964960521256960000000000000000000000000000

Oh, wow that grows really fast!

So we don’t need many triples before the number of possible documents to be signed is larger than the number of atoms in the universe, and not much more to get to the number of particles in the universe,…

And that is without taking into account the different ways of placing white space between nodes or punctuation marks, or the different formats to express the same data!

So it just makes a lot of sense to be able to express a canonical way of ordering a graph so that one can then have only 1 signature for all these variants.

It makes it possible to for example store data with the signature, without even bothering to verify it at the point of reception. Perhaps it is a robot that is sending the data, and signature verification may only be needed sometimes. Or it allows a DB to sign the graph once and then server it with people’s preferred namespaces, formats, etc.. without needing to recalculate the signature each time.

Henry

Received on Saturday, 12 June 2021 17:08:03 UTC