> On 18 Sep 2023, at 17:26, Manu Sporny <msporny@digitalbazaar.com> wrote: > > 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)? > I do not think the issue is with spec writers. RDFC-1.0 is meant for any lambda users of Linked Data, not only for spec writers. While what you say is o.k., what we need is a way to convey the information of what hash function was used when we provide the hash of a specific graph, because that hash may travel from one lambda user to the other. Ivan > 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/ > ---- Ivan Herman, W3C Home: http://www.w3.org/People/Ivan/ mobile: +33 6 52 46 00 43
Received on Monday, 18 September 2023 15:49:26 UTC