W3C home > Mailing lists > Public > public-credentials@w3.org > November 2018

Re: JSON-LD vs JWT for VC

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 3 Nov 2018 21:20:44 +0100
To: Michael Weiß <mixis@filts.net>, public-credentials@w3.org
Message-ID: <673f2b15-5e95-4453-ee5a-feecacfa72c9@gmail.com>
On 2018-11-03 17:25, Michael Weiß wrote:
> 
> 
>> On Nov 2, 2018, at 07:50, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>> On 2018-11-02 07:28, Chris Boscolo wrote:
>>> On Thu, Nov 1, 2018 at 8:51 AM Dave Longley <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com> <mailto:dlongley@digitalbazaar.com>> wrote:
>>>    On 10/29/2018 06:20 PM, Chris Boscolo wrote:
>>>     > IMO, it just seems unsafe to allow data that has been signed to be
>>>     > modified in any way and still produce the same signature.
>>> To be clear that particular comment isn't criticizing that canonicalization needs to be done, it is criticizing that it needs to be done prior to verifying the signature. It was in response to Manu's comment that the JSON can be modified with whitespace after it has been signed.
>>
>> This seems to me like a completely generic computing problem. If the receiver's system is broken and vulnerable to input data errors all bets are off.
> 
> 
> Even if we assume a flawless receiver, there is more computation to be done before the receiver can drop invalid data.

No arguments with that.


> If we also assume non malicious senders, there still remains a case for canonical data on the wire, that hopefully is compact, easy and fast to parse.

This is more problematic.  For JSON-LD-signatures (I'm not versed in JSON-LD so I may be off-track here) sending the canonicalized data may not be realistic since it is not JSON.

For Canonical JSON it is technically feasible but not necessarily not what you want:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01#appendix-C

thanx,
Anders
Received on Saturday, 3 November 2018 20:21:10 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:50 UTC