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