Re: JSONWebSignature2020 vs JcsEd25519Signature2022

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

https://transmute-industries.github.io/merkle-disclosure-proof-2021/#proof-suite

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
N-Quads.

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
opinion...

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
them.

OS


On Fri, Jan 27, 2023, 3:23 PM Tomislav Markovski <tomislav@trinsic.id>
wrote:

> 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 <markus@danubetech.com>
> 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 (https://transmute-industries.github.io/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:
>>
>> https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-c390.md
>>
>> 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:
>>
>>
>> https://github.com/transmute-industries/RsaSignature2017/blob/master/src/__tests__/Mastodon.Integration.spec.js
>>
>> More recently these 2 items seem like they might potentially support the
>> request as it exists in fep-c390.
>>
>> https://github.com/w3c/vc-jws-2020
>> https://github.com/decentralized-identity/JcsEd25519Signature2020
>>
>> 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
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>>