Re: Propose New Work Item: Ed25519 Signature 2020

I'm not an expert on JAdES, but my guess is that it's more than a detached
JWS, and does not use linked data proofs / JSON-LD features, so it's
already not compatible with any of the existing Linked Data Signature
formats.

It is probably possible for the same public key material to be used to
produce JAdES,  JsonWebSignature2020 and vanilla JWS... and you could
convert Ed25519VerificationKey2020 multibase to an Ed25519 JWK and use it
to verify JAdES, JsonWebSignature2020 and vanilla JWS... But as the Ed25519
Signature 2020 spec says, it's not recommended to do that kind of key
conversion... (Its confusing for developers).

A linked data signature suite is 2 parts, the first part is about
expressing verification material (typically a public key)... obviously
public keys can be used for verification, and key agreement...
regardless of what the spec author says it should be used for... but the
spec can suggest that the key be used for only certain signatures schemes,
and not used for key agreement... and people who read the spec should try
and follow its guidance.

The second part is about a proof representation, typically this is JSON-LD
specific representation of a digital signature.

I've worked on suites that have lots of cryptographic agility
(JsonWebSignature2020 and GpgSignature2020), both of these have a single
key representation (JWK or Ascii Armored PGP Key), and both support a wide
array of cryptographic key types, signatures and encryption functionality.
Personally I like that JOSE and PGP have agility and adoption in digital
identity and software supply chain / infosec community, however, the
"cryptographic agility" of JOSE and PGP is seen as not desirable by some
folks:

https://github.com/w3c-ccg/lds-jws2020/issues/4

The purpose of this suite is to provide a good example of a suite that is
not cryptographically agile, so my guess is that support for JAdES or JWS
would be seen as undesirable for this particular suite.

OS






On Mon, Sep 7, 2020 at 12:13 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> Orie (etc.) – how do you see this work vis-a-vis the standardization of
> JAdES (
> https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=52897)
> by ETSI and the EU?   Since JAdES is based on JWS and JOSE – it would seem
> that a move away from that would preclude the use of this new “Ed255519
> Signature 2020” from being usable in the EU.
>
>
>
> Leonard
>
>
>
> *From: *Orie Steele <orie@transmute.industries>
> *Date: *Monday, September 7, 2020 at 12:14 PM
> *To: *"W3C Credentials CG (Public List)" <public-credentials@w3.org>
> *Subject: *Propose New Work Item: Ed25519 Signature 2020
> *Resent-From: *<public-credentials@w3.org>
> *Resent-Date: *Monday, September 7, 2020 at 12:12 PM
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmute-industries.github.io%2Fvc.js%2Fed25519-signature-2020%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568806905&sdata=PdAk3zCIZqgvIvqG7lOPbaymRme7f89uHesLzHDU1pY%3D&reserved=0>
>
> https://github.com/transmute-industries/vc.js/tree/master/packages/ed25519-signature-2020
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftransmute-industries%2Fvc.js%2Ftree%2Fmaster%2Fpackages%2Fed25519-signature-2020&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568811903&sdata=Yju40RtHGfFI8jEJscDHLU2tnSNNP0l9V0O8qe0Bw2w%3D&reserved=0>
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-multiformats-multibase-00%23appendix-D.1&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568821882&sdata=UUheH7CeFXOyDNeaTr6TP3dVLjgt6mvwTr7aLlyYQkE%3D&reserved=0>
>
> 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
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmultiformats%2Fcid%23what-is-it&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568826868&sdata=NN29PZuHmuG9s5Wfxmtlc245xJrAEd0EiqYe7G1nDUM%3D&reserved=0>
> 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/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fld-proofs%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568826868&sdata=ipsEMsL12Ugo1KDJVF7xudfgS14f0XegGsmKrD9Not4%3D&reserved=0>
>
> 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
>
>
>
> [image: Image removed by sender.]
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cb256ff68fe534f81902008d8534910a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637350920568831858&sdata=PsIv7bGbIKT7fFrVoBDCuxNCWtuuOoDyHiPgicf%2B7x4%3D&reserved=0>
>


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

<https://www.transmute.industries>