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.

NOTE: This is an experimental feature in our platform.

As ZKPs are experimental, they only work with did:key method at this point. To experiment with this feature, use your API endpoint to create a DID with "method":"key" and "keyType":"bls12381g2" parameters set.

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.

You can read more about our work on privacy-preserving verifiable credentials on our blog.

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 Decentralized 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).

Copy to clipboard.
1TENANT=YOUR_TENANT_SUBDOMAIN.vii.mattr.global
2
3TEMPLATEID=<presentation-request-template-uuid>
4
5VERIFIERDID=<verifier-did>

Start the server

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

shell
Copy to clipboard.
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

https://www.datocms-assets.com/38428/1621225395-qrcode-terminal.webp?auto=format

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:

https://www.datocms-assets.com/38428/1620705775-selective-disclosure.svg

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 contents is mapped to these fields and presented to the Callback URL as an application/json body.

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