W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: VC - ZKP & CL Signatures

From: Brent Zundel <brent.zundel@evernym.com>
Date: Mon, 20 Apr 2020 15:58:40 -0600
Message-ID: <CAHR74YW9_Dd2-wgkVZY4DqpHJVAtvsaNfmdtaQiYv0snp=5LHA@mail.gmail.com>
To: Philip Kaiser <philip.kaiser@evan.team>
Cc: "public-credentials@w3.org" <public-credentials@w3.org>, Sebastian Dechant <sebastian.dechant@evan.team>
Philip,

That example in the VC Data Model spec was included to show one potential
way to organize the data from a CL signature into a W3C verifiable
credential.
Decoding the example signature in any way won't yield anything other than
random nonsense because, unfortunately, the values provided are incomplete.
The full CL signature in that example, with the complete values for
'issuerData,' 'attributes,' and 'signature,' was much too large to include
in the example, so those fields were subjected to significant elision.

The Ursa libraries are very valuable for providing ZKP signature primitives
for anonymous credentials.
There has also been a lot of work in Indy and Aries (referred to there as
the rich schemas project) to bridge the gap between W3C verifiable
credentials and the ZKP-capable anonymous credentials made possible by
Ursa.

The following Aries RFCs and Indy HIPEs describe the rich schema work:
Aries RFCs:
Overview
<https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas>
Common
<https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common>
Contexts
<https://github.com/hyperledger/aries-rfcs/tree/master/features/0249-rich-schema-contexts>
Schemas
<https://github.com/hyperledger/aries-rfcs/tree/master/features/0281-rich-schemas>
Encodings
<https://github.com/hyperledger/aries-rfcs/tree/master/features/0418-rich-schema-encoding>

Indy HIPEs:
Overview
<https://github.com/hyperledger/indy-hipe/tree/master/text/0119-rich-schemas>
Common
<https://github.com/hyperledger/indy-hipe/tree/master/text/0120-rich-schemas-common>
Context
<https://github.com/hyperledger/indy-hipe/tree/master/text/0138-rich-schema-context>
Schema
<https://github.com/hyperledger/indy-hipe/tree/master/text/0149-rich-schema-schema>
Encoding
<https://github.com/hyperledger/indy-hipe/tree/master/text/0154-rich-schema-encoding>
Mapping
<https://github.com/hyperledger/indy-hipe/tree/master/text/0155-rich-schema-mapping>
Credential Definition
<https://github.com/hyperledger/indy-hipe/tree/master/text/0156-rich-schema-cred-def>
Alignment with W3C Verifiable Credentials
<https://github.com/hyperledger/indy-hipe/tree/master/text/0160-rich-schema-w3c-credentials>

Please let me know if you need any further clarification.

Brent Zundel

On Mon, Apr 20, 2020 at 9:53 AM Philip Kaiser <philip.kaiser@evan.team>
wrote:

> Hello,
>
>
>
> I currently am experimenting with implementing ZKP-capable VCs using
> Hyperledger Ursa.
>
> However, when using Ursa to create CL signatures the results (consisting
> almost exclusively of numbers) vastly differ from the signatures given in
> the example over at
> https://www.w3.org/TR/vc-data-model/#zero-knowledge-proofs which has me
> confused.
>
> Decoding the example signature from base64 only yields random nonsense.
> What kind of encoding or signature creation method is used there and why
> does the signature Ursa yields (using the examplatory code from their
> documentation) look entirely different?
>
>
>
> Thanks in advance,
>
>
>
> Philip
>
>
>
Received on Monday, 20 April 2020 21:59:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC