DeCanonicalization: (was JSONWebSignature2020 vs JcsEd25519Signature2022)

Sorry for spam, list rejected first attempt with some delivery error.

---------- Forwarded message ---------
From: Orie Steele <>
Date: Fri, Jan 27, 2023, 8:49 PM
Subject: Re: JSONWebSignature2020 vs JcsEd25519Signature2022
To: Tomislav Markovski <>
Cc: Markus Sabadello <>, W3C Credentials CG (Public
List) <>, <>, <>

Indeed, it could be a parameter of the crypto suite... We built an
experimental merkle proof scheme with parameterized canonicalization a
while back:

Costly in implementation complexity, interoperability and compute time...

It's true JCS only protects JSON... But when that's all you need, why ship
an RDF library in the binary?

Last I checked a normatively legal verifiable credential was JSON not

Though I agree that JCS is not needed when application/credential+ld+json
is protected with JOSE or COSE.

Content addressing is most compelling use case for canonicalization...

Canonicalization is not a requirement for verifiable credentials, in my

Canonicalization might be a requirement for data integrity proofs, if it
is, it will remain a reason they are slower and more vulnerable to supply
chain attacks.

The choice of algorithm will modulate these faults but it cannot eliminate


On Fri, Jan 27, 2023, 3:23 PM Tomislav Markovski <>

> Side comment: I always wondered why data integrity signatures suites
> define the canonicalization algorithm in the suite as a constant,
> instead as a proof parameter using the "canonicalizationAlgorithm" term
> defined in the security vocab v1. That way, JsonWebSignature2020 can be
> used with both URDNA and JCS without creating multiple suite names.
> On Fri, Jan 27, 2023 at 4:01 PM Markus Sabadello <>
> wrote:
>> JsonWebSignature2020 should use URDNA2015.
>> The problem with using only JCS in a Data Integrity Proof is that it then
>> only covers the document itself, not the underlying RDF dataset.
>> Changes in the @context would not result in a signature becoming invalid.
>> If people really want to do this, then it should be called something like
>> JcsJsonWebSignature2023 to distinguish it from JsonWebSignature2020.
>> But I think the vc-jws (
>> proposal would be preferable; however, with the same limitation that it
>> only signs the document itself.
>> Markus
>> P.S.: I understand your argument about performance improvement, but I
>> don't really understand why this would result in crypto agility gain.
>> On 1/25/23 19:10, Orie Steele wrote:
>> Friends,
>> I recently became aware of:
>> The proposal suggests there may be a desire to use "Data Integrity
>> Proofs" with "Activity Streams"...
>> This would be relevant to Mastodon and other fediverse projects.
>> There has been past work in this area, here are some links:
>> More recently these 2 items seem like they might potentially support the
>> request as it exists in fep-c390.
>> There are 2 technical issues that have been discussed previously which I
>> would like to resurface in the context of this request:
>> 1. Should JsonWebSignature2020 use URDNA2015 and JCS, or just JCS?...
>> (for those who don't know, URDNA uses JCS under the hood for `@json` types).
>> 2. Should JsonWebSignature2020 use `proofValue`... with detached JWS just
>> like it does today?
>> It feels like we might have a nice performance improvement and crypto
>> agility gain, by having `JsonWebSignature2020` use JCS... but otherwise
>> align with the proposal from fep-390.
>> Regards,
>> OS
>> --
>> Chief Technical Officer
>> <>

Received on Saturday, 28 January 2023 03:11:16 UTC