Obtain values from a ZKP-enabled credential

This tutorial will allow you to perform a credential Verify flow and obtain only the claim information from a ZKP-credential that has been requested, in addition to the Subject Identifiers and whether the credential has been fully verified or not.

This guide intends to show the workings for ZKP-enabled credentials but generally will follow the standard presentation request during a Verify flow, to learn more details on a Verify flow take a look at the other tutorials.

ZKP-enabled credentials use the BBS+ signature suite, MATTR is heavily involved in developing these standards within the community. If you are planning on using this feature for production workloads please get in touch for more information on how we can help you as these standards continue to evolve.

The use of JSON-LD Framing is also a novel technique to request verifiable presentations, not all features from JSON-LD framing are supported and configurations must be thoroughly tested to ensure there are no unforeseen results.

Prerequisites

You need access to the MATTR Platform APIs. If you're experiencing any difficulties, contact us.

In order to complete this tutorial you will need the following:

• A local development environment or remote service setup to accept json/application Callbacks

• A known decentralised identifier (DID) to be used for messaging (i.e. a DID using keyType of Ed25519)

• A Query by Frame presentation request template configured in your tenant and know the id.

• A ZKP-enabled credential issued to the mobile wallet that can be matched the using the presentation request (i.e. matching type and issuer and associated claims)

Sample app

If order to shortcut the steps involved, we will use the verify credentials using presentation request callbacks sample app that will step you through creating a simple Node.js Express server to orchestrate many of the steps below.

Setup the sample app

Create your environment variables in a .env file and save to the folder (rename .env-template).

1TENANT=YOUR_TENANT_URL
2TEMPLATEID=<presentation-request-template-uuid>
3VERIFIERDID=<verifier-did>

• For TENANT add in the domain of your tenant

• Add the id of the presentation request template from your tenant to TEMPLATEID -- make sure this is the template of the privacy-preserving template

• Add a DID to VERIFIERDID that that exists on your tenant

Start the server

Append your valid Platform access token to the end of the start command to start the Express server

1npm start <access_token>

The access token is stored in local memory and used to make API calls to your tenant over HTTPS

Once you run the server you should see a QR code displayed in your terminal

Scan using the mobile wallet app

Once the mobile app matches a credential, it will display the claims that have been requested and highlight all the claims from the same credential that are not going to be disclosed to the presentation requestor.

This is an example of a large credential with limited claims being sent:

Receiving the credential presentation callback

Once a valid presentation is sent by the mobile app, the Platform will perform some checks to ensure the validity of the presentation:

• Issuer DID of each credential can be resolved

• JSON-LD context is valid for subject claims

• Proof is valid & the credential has not been tampered with

• If present check any credential against its RevocationList2020 status

These checks will inform the verified boolean and where the content is mapped to fields and presented to the callback URL as an application/json body.

Response to callback URL

1{
2    "presentationType": "QueryByFrame",
3    "challengeId": "GW8FGpP6jhFrl37yQZIM6w",
4    "claims": {
5        "id": "did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi",
6        "http://schema.org/familyName": "Shin",
7        "http://schema.org/educationalCredentialAwarded": "Certificate Name"
8    },
9    "verified": true,
10    "holder": "did:key:z6MkgmEkNM32vyFeMXcQA7AfQDznu47qHCZpy2AYH2Dtdu1d"
11  }