- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 18 Sep 2023 11:26:51 -0400
- To: Phil Archer <phil.archer@gs1.org>
- Cc: Sebastian Crane <seabass-labrax@gmx.com>, Gregg Kellogg <gregg@greggkellogg.net>, RDF Dataset Canonicalization and Hash Working Group <public-rch-wg@w3.org>
On Mon, Sep 18, 2023 at 11:15 AM Phil Archer <phil.archer@gs1.org> wrote: > From: Dan Yamamoto <dan@iij.ad.jp> > Therefore, I believe the internal hash function should be interchangeable. However, as others have suggested, I think there is a need to introduce a mechanism to specify what hash function is used explicitly. Just to jump in quickly on this thread; it feels like the harms are being exaggerated given the way we know that RDFC-1.0 is used today. If we look at how the VC Data Integrity specifications use the algorithm, you /always/ know which internal hash algorithm was used (or should be used) because it's signalled to you via the Data Integrity algorithm identifier. You don't have to guess, you are told exactly which internal hash algorithm to use. I wonder if folks are missing this detail? It was always expected that the internal hash information would be signalled to the caller, and that's exactly what Data Integrity does. Perhaps all we need to do in the spec is ensure that one of the outputs is the internal hash function used and to tell spec writers that use RDFC-1.0 that any algorithm that uses it needs to clearly stipulate which internal algorithm to use when calling the algorithm (and if not, the default will be used)? This feels more like a miscommunication than a design issue. Does the above help clarify? -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Monday, 18 September 2023 15:27:34 UTC