- From: Tomislav Markovski <tomislav@trinsic.id>
- Date: Fri, 27 Jan 2023 16:23:42 -0500
- To: Markus Sabadello <markus@danubetech.com>
- Cc: Orie Steele <orie@transmute.industries>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>, public-vc-wg@w3c.org, silverpill@firemail.cc
- Message-ID: <CAMJx-oC1u7_WiWEGQaaG4j6FvdeW1-AjNq-SjQX8RAcvfWaS1Q@mail.gmail.com>
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> > >
Received on Friday, 27 January 2023 21:24:06 UTC