Re: [w3ctag/design-reviews] RDF Canonicalization (Issue #855)

Thanks @rhiaro, we'll need to take this up in the WG.

As for the use of quads vs. triples, note that this a spec for datasets, not just graphs, so the [`graph name`](https://www.w3.org/TR/rdf11-concepts/#dfn-graph-name) component is necessary for recording this information. Use cases including Verifiable Credentials depend on the use of datasets, and not just graphs, so canonicalizing the entire dataset is important. Algorithmically, including the `graph name` as a potential location for a blank node in addition to the `subject` and `object` positions has a fairly minor impact.

Although RDF Concepts suggests an interpretation of a set of graphs, all but one of which can have a graph name, it is fully consistent with the N-Quads representation which is convenient for the algorithm. A hypothetical variation might have created a hash for each graph and then hash the `graph name`/`graph hash` pairs, but it remains necessary to consider that blank nodes may appear across graphs, and indeed as the `graph name`, so it doesn't really change the need to consider blank nodes across the dataset and not just within each graph.

Good point about noting the implications on the algorithm for some potential future vulnerability. Note that there is [text to indicate that the algorithm can be use with different hashing algorithms with minimal change](https://www.w3.org/TR/rdf-canon/#dfn-hash-algorithm)

> NOTE
> Implementations can be written to parameterize the hash algorithm without any other changes. However, using a different hash algorithm is expected to generate different output from [RDFC-1.0](https://www.w3.org/TR/rdf-canon/#dfn-rdfc-1-0).

However, the security issues that might motivate this can be better highlighted.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/855#issuecomment-1664698763
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/855/1664698763@github.com>

Received on Thursday, 3 August 2023 22:02:20 UTC