Re: Propose New Work Item: Ed25519 Signature 2020

I wrote the original Ed25519 Signature 2018 suite document
<https://w3c-ccg.github.io/lds-ed25519-2018/>.

I remember it was around Rebooting-the-Web-of-Trust #4 in Paris when the
rationale was "Let's put a detached JWS into the LD Proof, to enable
interoperability between both worlds".

A while later, today, I totally agree with your explanation about
cryptographic agility.
I.e. you can get that agility by using Json Web Signature 2020, and you
will intentionally not get that agility by using Ed25519 Signature 2020,
which will do things "the Linked Data way".

So, full support for this!

Markus

On 07.09.20 18:12, Orie Steele 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>