Re: hashlinks vs trusty URIs

ok, I missed that trusty URIs require an actual transformation in some
cases, e.g:

>  To support self-references, i.e. resources that contain their own trusty
URI, the generation process involves not just to compute the hash from a
given artifact but to actually transform the artifact into a new version
that contains the newly generated trusty URI.

That's definitely not desirable. Ivan and Manu -- the approach you describe
makes sense and is consistent with the current approach for LD proofs (the
canonicalization step). I hadn't seen discussion of it yet, and I'm
interested in joining wherever those conversations are happening. I'm also
interested in learning more about what Ivan mentioned about XML signatures.

To back up, I don't have one specific question, rather a category of
unknowns. Here's the context:

In VC-EDU we have a number of data standards that have historically been
written in XML. Since RDF can be serialized as XML, we've not worried too
much about the emphasis on JSON-LD (compared to XML) in VCs. But the time
for hand-waving around this issue is past, so there are a variety of issues
(ranging in depth):

   - The VC data model lists certain syntaxes (JSON, JSON-LD), and while
   it's clear that's not meant to be exhaustive, it doesn't have
   recommendations for adding new syntaxes. Can we just do it? Or do we need
   to add some sort of extension? We'd like to have certain things hosted as
   official w3c artifacts (e.g. XML schemas), so maybe we just need to worry
   about the latter category of artifacts
   - Are there other groups focused on XML/RDF signatures and tooling
   (using similar approaches to our JSON-LD proofs)? Basically we want to
   understand if we should join existing efforts or build something new?
   - In theory, it seems like if the signature is computed on the RDF
   graph, it should preserve across XML/RDF and JSON-LD/RDF, but this is an
   example of something we've been hand-waving about and need to ensure.
      - The question about hashlinks vs trusty uris was really a rathole on
      this fork of investigation, so ignore that for now.

Some examples of where these issues are arising:

   - The EDCI effort is using XML VCs to comply with eIDAS legal signature
   requirements, but they don't have anything official from w3c to base that
   on and would like guidance
   - PESC/XML transcripts are very widely used in North America. They had
   been focused on mapping to JSON-LD, but would be interested in whether
   we're providing proper XML support

Maybe a topic for a future CCG call? A lot to unpack here...

Thanks,
Kim

On Sat, Jun 6, 2020 at 7:19 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 6/6/20 3:28 AM, Ivan Herman wrote:
> > I would think having a separate vocabulary to make statements like
> >
> > <graph URI> <:hasHash> "hash value" .
>
> My read on the paper is the same as Ivan's read.
>
> The cleaner solution is to annotate the RDF graph, like the above, and
> is effectively what the Linked Data Proof stuff does (as a part of graph
> canonicalization).
>
> Modifying the RDF graph or transforming it is what was being done for a
> decade+ before Dave Longley invented the generalized solution.
> Modification of an RDF graph to hash it has terrible complexity
> consequences on software that needs to use the modified graph and
> determine if that modified graph is the same one that is sitting on a
> local system. In short, you create a very complex transformation and
> comparison issue when you modify RDF graphs in order to hash them (or
> refer to them using hashes).
>
> To provide an alternative, the RDF Dataset Canonicalization Algorithm
> canonicalizes the RDF graph in a way that a hash can be generated for it
> without having to modify the original information. That hash could be
> paired with hashlinks, but I'm struggling to understand the specific use
> case (and don't have the spare cycles to put further thought into it
> this moment).
>
> I only had about 15 minutes to read through the Trusty URIs paper (first
> time I had heard of it, nice arxiv archeology work!). My take away is
> that it does things that are unnecessary with the solutions we have
> available to us today. The basic generalized RDF hashing building blocks
> are there via the RDF Dataset Canonicalization Algorithm. That hash can
> then be used by any technology that can express a hash and metadata
> about that hash (Linked Data Proofs/Signatures, Hashlinks, Magnet URIs,
> Named Information, etc.)
>
> Understanding the specific use case you're going after might help... or
> if you think Trusty URIs can do something that can't be done with the
> current generalized tooling we have?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>