Introducing the Bloom Credential Playground

The Bloom Credential Playground is the perfect place to start learning about decentralized identity. The Credential Playground is a CLI that demonstrates each component of Bloom’s decentralized identity implementation. Using the CLI, you can initialize DIDs, issue Verifiable Credentials, encrypt credentials for storage in a user controlled Encrypted Data Vault, share credentials with a third party and verify the integrity of a shared credential.

In the CLI all data is stored in a local SQLite table. The production SDKs store account keys locally, while data is stored in a cloud-hosted Encrypted Data Vault.

DID Terms & Definitions

DID (Decentralized Identifier): A unique identifier that does not require a central registry. DIDs contain all of the information needed to identify an entity and challenge the entity to prove ownership of the identifier. Bloom uses Ethereum public/private key pair based DIDs.

VC (Verifiable Credential): An assertion about a DID that contains all of the information needed to prove its validity. Verifiable credentials are often used to connect centralized systems to the decentralized identity ecosystem. For example, a Verifiable Credential can prove a connection between a DID and a passport issued by a government.

Selective Disclosure Merkle Tree: The data structure containing Verifiable Credentials which is issued to a user. Using the Selective Disclosure Merkle Tree, client devices compute Verifiable Credentials at the time when a user wishes to share their information. Selective Disclosure Merkle Trees are more powerful than normal Verifiable Credentials because they only have to be issued once and users have granular control over exactly how much or how little information to share, all while maintaining the integrity of the proof.

Encrypted Data Vault: A service that stores encrypted personal information, keyed for individual users. The host of an encrypted data vault cannot see plaintext data. The data can only be decrypted on users' devices.

Installing the Credential Playground with Git

The Credential Playground is available on Bloom’s Github.

GitHub - hellobloom/bloom-credential-playground

First, install Node if you don't already have it.

Clone the repository and install dependencies.

git clone git@github.com:hellobloom/bloom-credential-playground.git
cd bloom-credential-playground
npm install

Run the interactive CLI. In interactive mode you can take advantage of the autocompletion and suggested argument features.

bin/ts-start.sh interactive

1. Account Creation

First, you will need to use the account subcommand to create a local account.

bin/ts-start.sh account create --email subject@test.com --name "John Doe"

You can optionally specify the --privateKey to use your own private key.

Create a second account to play the part of the credential issuer.

bin/ts-start.sh account create --email issuer@test.com --name "Issuer Company"

2. Credential Issuance

Now that you have two accounts, you can issue a credential from account 2 to account 1.

The sample commands in this doc use sample data from SG-Verify.

bin/ts-start.sh issuance create --type ndi --subjectId "subject@test.com" --issuerId "issuer@test.com"

In this example, credentials are extracted from the raw data in src/issuers/default/ndi.ts and formatted into the Selective Disclosure Merkle Tree format. This format gets stored on the client. Users can compute Verifiable Credentials and Verifiable Presentations when they wish to share the data with a third party.

Specifying a Source File

You can specify raw data from a file path by including the src field.

bin/ts-start.sh issuance create --type ndi --subjectId "subject@test.com" --issuerId "issuer@test.com" --src "src/issuers/default/ndi-sample.json"

Encrypting the Credential Components

The Selective Disclosure Merkle Tree object is encrypted and stored with the subject. In order to test this, include the --encrypt flag to encrypt the credential components for the subject using their AES key.

bin/ts-start.sh issuance create --type ndi --subjectId "subject@test.com" --issuerId "issuer@test.com" --encrypt

Inspect the encrypted cyphertext with the inspect command.

bin/ts-start.sh issuance inspect --id 1 --cyphertext

Decrypt the cyphertext with the --decrypt flag.

bin/ts-start.sh issuance inspect --id 1 --decrypt

3. Sharing

Verifiable Credentials are computed based on the Selective Disclosure Merkle Tree at the time that a subject chooses to share data with a third party. You can preview what a Verifiable Credential looks like using the share preview command.

bin/ts-start.sh share preview --id 1 --type income

This command prints the formatted credential, computed from the Selective Disclosure Merkle Tree.

Next, you can format credentials into a Verifiable Presentation for sharing.

bin/ts-start.sh share share --id 1 --type income

Share Kit enables you to request credentials from Bloom users. You can share credentials directly from the CLI with a deployed Share Kit service. Integrate with share-kit request data JSON. In this example we are sending data to the Bloom Starter demo app.

bin/ts-start.sh share share --id 1 --r JSON_COPIED_WHEN_CLICKING_QR

4. Validation

Verify Kit provides utilities to verify the integrity of the shared Verifiable Presentation and perform all of the embedded proofs. The CLI imports Verify Kit and makes it available with the verify command.

bin/ts-start.sh verify verify --id 1

Run the above command with the verbose flag to see each verification logged.

bin/ts-start.sh verify verify --id 1 --verbose

✔ Presentation context is present
✔ Presentation type is correct
✔ Credential ID is present
✔ Credential type is valid option
✔ Issuer is valid address format
✔ Issuance date is valid RFC3339 format
✔ Subject is valid address format
✔ Credential data is present
✔ Authorization array is valid or omitted
✔ Credential subject passed validation
✔ Type string is present
✔ Created timestamp is valid RFC3339 format
✔ Creator is valid address format
✔ Valid data node version: batch
✔ Valid batch layer 2 hash format
✔ Valid batch attestation signature format
✔ Valid batch attestation signature
✔ Valid subject signature format
✔ Valid request nonce format
✔ Valid layer 2 hash format
✔ Valid root hash format
✔ Valid root hash nonce format
✔ Valid merkle proof position
✔ Valid merkle leaf data format
✔ Valid merkle proof position
✔ Valid merkle leaf data format
✔ Valid merkle proof position
✔ Valid merkle leaf data format
✔ Valid merkle proof position
✔ Valid merkle leaf data format
✔ Valid Merkle proof array
✔ Valid network stage
✔ Valid data node
✔ Valid attester address format
✔ Valid subject address format
✔ Verified data passed validation
✔ Merkle proof passed validation
✔ Credential proof passed validation
✔ Credential proof subject matches embedded subject
✔ Validated array of Verifiable Credentials
✔ Presentation type is present
✔ Presentation creaded date is valid RFC3339 format
✔ Creator is valid address format
✔ Nonce is present
✔ Domain is present
✔ Credential hash is valid format
✔ Validated presentation proof
✔ Embedded credential hash matches the computed credential hash
✔ Signature digest matches the computed credential hash
✔ Signature string is formatted correctly
✔ Signature matches the proof creator
✔ Token matches the proof nonce
Verified data of type income from subject 0xd0d45aac45bf6d33b0f6d7544522866d929f3125
Verified data: {"data":{"lastupdated":"2019-09-17","high":{"value":4999},"source":"2","classification":"C","low":{"value":4000}}}
Completed verification

Encrypted Data Storage

When you create an account, an AES encryption key is automatically generated. If you generated an account before this feature was available, you can either generate a new account or add an encryption key to an existing account.

bin/ts-start.sh account updateKey --account subject@bloom.co --type Encryption

Share Kit Integration

The CLI can communicate with any deployed Bloom Share Kit instance. In order to POST the signed Verifiable Presentation to a destination, specify the requestData field in the share command. The snippet below uses the JSON retrieved from a Share Kit QR code on https://bloom-starter-ndi.herokuapp.com.

bin/ts-start.sh share share --id 15 --requestData {"action":"request_attestation_data","token":"9a70cc32-dc86-471e-9b4a-1489e5064eaa","url":"https://bloom-starter-ndi.herokuapp.com/scan?share-kit-from=qr","org_logo_url":"https://bloom.co/favicon.png","org_name":"Bloom Starter","org_usage_policy_url":"https://bloom.co/legal/terms","org_privacy_policy_url":"https://bloom.co/legal/privacy","types":["email","full-name","address","phone","income"]}

Command Replay

The CLI also has the ability to replay recent commands while in interactive mode.

Extending the playground

It should be easy to add additional issuer types to the demo. See how it is done in src/issuers/ndi.ts and src/issuers/base.ts > loadData, getClaimNodes.

What's next for Bloom?

The Bloom Credential Playground demonstrates the power of the Bloom Protocol. The same technology is at the core of our consumer applications as well as our enterprise SDKs.

Download the Bloom App for Android or iOS to secure your identity and take back control of your data.

Get in touch with us to learn how to integrate our SDKs to reduce fraud in your app's signup process and enhance your users' data privacy. Bloom is fully compliant with GDPR, LGPD, and CCPA. Reach out to us at team@bloom.co for more information.

We're hiring!

We have opportunities for developers who want to become an expert in multiple rapidly growing fields, including DeFi, data privacy and fintech. All developers are remote and can work from anywhere. Our team meets throughout the year at off-sites, conferences, client meetings and weekly Zoom calls.

Check out our job postings here: https://angel.co/company/bloom-protocol/jobs