W3C home > Mailing lists > Public > public-credentials@w3.org > September 2020

Re: Propose New Work Item: Ed25519 Signature 2020

From: Kim Hamilton <kimdhamilton@gmail.com>
Date: Mon, 7 Sep 2020 10:29:20 -0700
Message-ID: <CAFmmOzeRhp25RfDZkm+Cuy3VnvZdOAB=2CtRW-nwUvWTd7WBAA@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Thanks Orie. CCG bookkeeping-wise, we just need you to fill in this "create
work item" github template
You can link to your original email in the archives
for the description of the work item, but we need extra info like
codeowners, etc. (The template will prompt you for everything needed.)


On Mon, Sep 7, 2020 at 9:14 AM Orie Steele <orie@transmute.industries>

> Friends,
> A few of us (Manu, Dave and Tobias) have been working on a new linked data
> signature suite "Ed25519 Signature 2020"
> Here are some links to our work in progress:
> https://transmute-industries.github.io/vc.js/ed25519-signature-2020/
> https://github.com/transmute-industries/vc.js/tree/master/packages/ed25519-signature-2020
> We would like to move the spec to the CCG, and continue to iterate on it
> as an official W3C CCG work item.
> I will now summarize what's new about this suite / spec, and why we think
> incubation in the CCG would be helpful:
> 1. A model for anti cryptographic agility.
> Ed25519Signature2018 used detached JWS, and while it is limited to
> supporting Ed25519 EdDSA, its structure is actually closer to Json Web
> Signature 2020... It invited extension, because it relied on JOSE.
> We want to provide an example of a suite which does not rely on JOSE,
> which reflects some of the design aesthetics (many of which I personally
> don't agree with) that have been developed in the CCG over the past few
> years.
> With Json Web Signature 2020 now a shining example of the opposite
> approach, we think a counter example is needed to better illuminate the
> arguments against cryptographic agility.
> 2. Support for Multibase
> We're not 100% aligned on its use, but we are hopeful that we might be
> able to better represent raw bytes using mutlibase, and mitigate some of
> the contention we have seen over base64, base64url and base58, base58btc,
> etc...
> https://tools.ietf.org/html/draft-multiformats-multibase-00#appendix-D.1
> Another major reason to consider multibase is that bi-directional
> transformations between JSON-LD and CBOR-LD can take advantage of the
> multibase and automatically compress string encodings like base64,
> base64pad, base64url, base64urlpad, etc... in absence of multibase... the
> codec logic for CBOR-LD could become expensive.... multibase is also much
> more friendly for non web browser environments like IoT development using
> Rust and Go Lang.
> Multibase / multiformats are also the bridge towards better integrations
> with IPFS / IPLD....
> https://github.com/multiformats/cid#what-is-it
> With better support for multibase in JSON-LD, it should be easier to start
> to better integrate IPLD and CBOR-LD.
> 3. Better standards for linked data suites
> We are also eager to provide better examples for other spec authors to
> draw from.
> Some of the major areas for improvement are:
> 3.1  better language around verification method requirements, and the
> relationship between verification methods and keypairs.
> 3.2 conventions around test vectors
> 3.3 better examples of how to extend JSON-LD contexts for LD Proofs and VCs
> We hope that after getting stronger consenus on what a good "linked data
> proof suite spec" looks like, we can make some revisions to:
> https://w3c-ccg.github.io/ld-proofs/
> We're think that the best way to do that is to start with an exemplar
> suite ( Ed25519Signature2020 ) that has the features / language we want,
> and reverse engineer the language which we can use to better support the
> ld-proofs spec.
> Some of the early areas we have identified are:
> 1. better language regarding naming conventions
> 2. examples of JSON-LD context extensions
> 3. conventions regarding test vectors
> Once ld-proofs has been upgraded, we think it will be easier to create
> linked data suites, and the suites can be more focused on unique
> differences and less focused on filling the gaps missing the ld-proofs spec.
> Regards,
> OS
> --
> Chief Technical Officer
> www.transmute.industries
> <https://www.transmute.industries>
Received on Monday, 7 September 2020 17:29:45 UTC

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