Re: Moving BBS+ signature scheme specification for JSON-LD Signatures into CCG

+1 also supportive and big kudos to Mattr.

Oliver

On Fri, May 1, 2020 at 6:13 PM Mike Varley <mike.varley@securekey.com>
wrote:

> +1 from SecureKey.
> Having a specification of this proof mechanism that can drive the
> development of test suites for interoperability has lead to successful*
> interop results in the SVIP project. Other aspects of the specification
> seems like a bonus :)
>
> (*) - granted these specs for SVIP were 'rushed' and require more
> community input, and the "building the bridge while trying to cross it" was
> very stressful, the spec => test suite => interop pattern has gleaned
> positive interoperability results.
>
> MV
>
> On 2020-05-01, 11:45 AM, "Jordan, John CITZ:EX" <John.Jordan@gov.bc.ca>
> wrote:
>
>     Likewise, the Province of BC is very keen to be a part of putting
> these innovations into action.
>
>     We would like some help to understand what it is we can do to be most
> helpful in this regard.
>
>     Best  (and recovering from the intensity IIW!)
>     John
>
>
>     From: Orie Steele <orie@transmute.industries>
>     Date: Friday, May 1, 2020 at 8:40 AM
>     To: Manu Sporny <msporny@digitalbazaar.com>
>     Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
>     Subject: Re: Moving BBS+ signature scheme specification for JSON-LD
> Signatures into CCG
>     Resent-From: <public-credentials@w3.org>
>     Resent-Date: Friday, May 1, 2020 at 8:40 AM
>
>     Obviously supportive of this, let's get it adopted as a work item. We
> have done our best to get the spec in order, but there are still some
> issues open which could impact the suite representation significantly...
> But overall, the was my favorite thing from IIW, and I'm very eager to
> support both the code and the spec!
>
>     On Fri, May 1, 2020, 10:32 AM Manu Sporny <msporny@digitalbazaar.com
> <mailto:msporny@digitalbazaar.com>> wrote:
>     On 4/30/20 9:02 PM, Kyle Den Hartog wrote:
>     > As many of you know from IIW, Mattr has been working on a method to
>     > achieve selective disclosure with ZKPs in a way that works with
> JSON-LD
>     > signatures and plugs directly into vc-js. With that, we've written a
>     > specification on how this JSON-LD signatures scheme would work and
> would
>     > like to move it into the CCG as a work item to go with the LD-proofs
> work.
>
>     Digital Bazaar is deeply supportive of this work because:
>
>     * It enables a "dip your toes in the water" approach to ZKPs
>       and how they are used in the Verifiable Credentials
>       ecosystem.
>
>     * It is agnostic to the signature packaging format (JOSE vs.
>       LD Proofs), enabling the entire ecosystem to use it.
>
>     * It does not require a DLT, and is thus ledger-agnostic.
>
>     * It separates selective-disclosure and link secrets, the
>       former being useful for a wider variety of use cases than the
>       latter.
>
>     * It is possible to make it a drop-in technological replacement
>       for existing signature schemes, such as
>       Ed25519SignatureSuite2018.
>
>     There were a number of concerns raised by Nathan George during the IIW
>     presentation that we feel need to be explored to ensure that we have
> all
>     of the security corner cases covered.
>
>     We applaud Mattr (Kyle, Tobias, Mike L., and supporting organizations)
>     for their work in this space. Very excited to see this work move
> forward.
>
>     -- manu
>
>     --
>     Manu Sporny - https://www.linkedin.com/in/manusporny/
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://tinyurl.com/veres-one-launches
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
>