Re: Propose New Work Item: Ed25519 Signature 2020

Thanks Orie. CCG bookkeeping-wise, we just need you to fill in this "create
work item" github template
<https://github.com/w3c-ccg/community/issues/new?assignees=wyc%2C+vsnt%2C+kimdhamilton&labels=proposed+work+items&template=ccg-new-work-item-template.md&title=%5BPROPOSED+WORK+ITEM%5D>.
You can link to your original email in the archives
<https://lists.w3.org/Archives/Public/public-credentials/2020Sep/0008.html>
for the description of the work item, but we need extra info like
codeowners, etc. (The template will prompt you for everything needed.)

<https://github.com/w3c-ccg/community/issues/new?assignees=wyc%2C+vsnt%2C+kimdhamilton&labels=proposed+work+items&template=ccg-new-work-item-template.md&title=%5BPROPOSED+WORK+ITEM%5D>

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

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