Propose New Work Item: Ed25519 Signature 2020

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



-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>