Re: hashlinks vs trusty URIs

Thank you very much Manu and Ivan for this wealth of information, which I'm
still digesting.

> Happy to discuss on a call, it would be good to get this out to a
community that is motivated to work on XML-LD.

We are very motivated to figure out guidance for VCs and XML, and I think
XML-LD would be compelling for important use cases like PESC XML
transcripts. I'll make this the topic of a future CCG call.

The use cases I'm not yet sure of are those like EDCI
<https://github.com/european-commission-europass/Europass-Learning-Model/blob/master/edci_credential.xml>,
where VCs are represented in XML in order to use XML Advanced Electronic
Signatures (XAdES) for legal signature requirements. Ivan's response
pointed to way more nuance in XML signatures than I was ever remotely aware
of, so I need to read up on this. I think for use cases like this, we are
more interested in understanding what's the quickest path to legal
compliance, which is also affected by other efforts underway. We'll have to
do some more prodding on this first to understand our options.


On Mon, Jun 8, 2020 at 7:48 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> What Ivan said, and...
>
> On 6/7/20 7:03 PM, Kim Hamilton wrote:
> >   * 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
>
> Yes, just do it -- writing XML-LD has been on my list of things to do
> for years, mostly as an April 1st spec, but it looks like you actually
> have a use case for it. I'm having to do something similar for CBOR-LD
> recently... expect that both will be very closely aligned. The general
> process is this:
>
> Use JSON-LD compact, and then translate to XML-LD by walking the tree
> and serializing to XML (using XML attributes and tags appropriately).
> You can go from XML-LD to JSON-LD and do processing using existing
> JSON-LD libraries that way as well.
>
> You can run XML Digital Signatures over the XML-LD output, but honestly
> it's going to be overly complicated... but I've heard other folks in the
> banking community doing this due to their XML-based systems. The
> approaches aren't incompatible.
>
> The other approach is to use JSON-LD and Linked Data Signature libraries
> to generate a digital signature, then JSON-LD compact and then walk the
> tree generating XML-LD in the process.
>
> You are correct in that the Linked Data Signature is syntax agnostic, so
> the same signature can be used in JSON, XML, CBOR, etc... it's one of
> the innovations that Linked Data Proofs brings to the table over JOSE
> JWTs, XML Digital Signatures, etc.
>
> Happy to discuss on a call, it would be good to get this out to a
> community that is motivated to work on XML-LD.
>
> >   * 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?
>
> As Ivan mentioned, nobody is working on XML/RDF signatures for
> production systems these days (that I know of)... everyone has moved on
> to less maddening things. That said, I do think that we have the tooling
> now that would give you XML-LD and Linked Data Security at that layer
> with only about a week or so of hacking involved for a proof of concept.
> A production deployment would leverage the existing JSON-LD and RDF
> Dataset Normalization libraries we already have.
>
> The biggest lift is in writing a translator from JSON-LD->XML-LD->JSON-LD.
>
> >   * 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.
>
> Yes, this is true and should hold for what you're describing. There are
> a few details that you have to make sure you get right (mostly the
> loss-less conversion from JSON-LD -> XML-LD -> JSON-LD)... and if you
> get those details right, everything else should fall into place.
>
> >   * 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
>
> Yeah, and they won't until XML-LD becomes a thing. You could describe
> XML-LD as a mapping from JSON-LD to XML and back. There are just two
> transformations you'd need:
>
> toXMLLD(jsonLdDocument, options)
> fromXMLLD(xmlDocument, options) -> jsonLdDocument
>
> If you define those correctly, which should only take about a week or so
> of hacking, everything else should be reusable from the current JSON-LD
> ecosystem.
>
> >   * 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
>
> Depends on how much backwards compatability they want... you can also
> just shove the entire XML document in a string literal and sign that. :)
>
> Many ways to accomplish this task... would need to know more about the
> requirements to hammer out the details.
>
> -- 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
>
>