Add additional reasons to JSON-LD+LD-Proofs section

[msporny]

Making some notes from discussion had earlier today with @dlongley, where he stated something to this effect:

LD proofs allow data translation, remove redundant bloat, and keep the data model layer separate from the signature layer

JWTs mix the data model and the signature layer, you can't translate data formats (can't do CBOR-LD/other things and keep signatures), and you need a full copy of the serialized version of what you signed kept around ... which becomes worse the more the more signatures you add

The fact that you can sign an actual graph with LD proofs means you can actually selectively disclose relationship data down to the most granular level ... a single triple, you can't do that with anything else

Can't do that with JWT ... unless you reinvent a graph format... and ... ultimately, you need JSON-LD processing (or something like it) to do the above ... which is why you can't remove that particular operation and claim there is equivalence between the two mechanisms.

Therefore graph normalization is a fundamental difference. it's a trade off. can you represent your data as a graph, can you translate between data formats / representations without losing a signature, and can you aggregate multiple signatures, etc. without bloat? You can only do that if you have a graph representation for your data and some kind of canonicalization algorithm that can be reapplied to different data that produces the same result.

[David-Chadwick]

With JWT and JSON you don't need a graph, you dont need to canonicalise the VC or the graph structure and you dont need JSON-LD processing. In short everything is much simpler, is fully standardised, and is widely deployed. And you can support selective disclosure in a variety of ways. Since RPs would normally have to keep an audit trail of received VPs, then it is not an issue about storing the signed VP/VCs. JSON-LD proofed VP/VCs will still need to be kept in the audit trail.

[msporny]

With JWT and JSON you don't need a graph

If you can't get the data into an atomic form, you can't do selective disclosure.

you dont need to canonicalise the VC or the graph structure and you dont need JSON-LD processing.

If you don't canonicalize, you can't losslessly transform to other data formats (such as CBOR) without also having to re-sign the data.

So, yes, you have a simpler solution, that's not capable of doing selective disclosure, automatic translation into other data formats while maintaining the integrity of the signature, aggregation of digital signatures as sets or chains, or something that can be natively stored and queried in document-oriented databases.

These are all design trade-offs, and it's nice that your customers don't need any of those features... it is simpler, in the same way that a bicycle is simpler than a car. :P

[dlongley]

@David-Chadwick, the point of this is: What technology must you add if you want to get certain features?

It makes sense to choose the simplest technology that provides all the features that you ever need.

For example, if you want to be able to translate from serialization X to serialization Y without invalidating your proofs nor carrying along a copy of what was signed, you will need to do something other than JWT. JWT presumes this is not a use case for the technology. This example and others were given in the OP.