Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
108 lines (83 sloc) 4.91 KB

Verifiable Credential playground-museum

In order to test our verifiable credential software, we need a playground-museum of claims (a test suite of collected claims) that implementations can clearly succeed or fail against. One of our main goals is to be neutral on all current candidates in use, and be able to showcase some interoperability.

We want this service to be a collection point, viewing point and playground for community VCs out there. We aim to make it possible to understand how others have generated credentials, get a better understanding of interopability, and recommend libraries that are compliant with the specification.

This will be both an informative draft and a specification on what will be built over 5 phases, if time allows for it.

Existing playgrounds

Specs, Docs

The museum

Data has to be collected from the community, so this draft initates the collecting of VCs in two ways:

Examples we are curious about

  • Graph VC's
  • Real usecase VC's
  • User facing VC's
  • VC's used between machines

Already existing examples

The playground

For the playground to work intitially, and without any interopability protocol or library, we need to build a bridge between the VCs that we have been made aware of.

Existing libraries

General purpose bitcoin client
DID Method specific

Execution phases

Phase 1


  • Collect VCs made as JSON-LD with LD-Proofs, that this community is curious about
  • Collect VCs made as JSON-LD with LD-Signatures, that this community is curious about
  • Collect VCs made as JSON with JWT, that this community is curious about
  • Collect VCs made as JSON-LD with JWT, that this community is curious about

Playground initiation

  • Start a code template for the playground so collaboration can grow.
  • Get it hosted openly so it is easy for developers to improve the playground.

Phase 2

Viewing VCs

  • Create a flexible way to view the VCs in the museum.
  • Look at integrating with Satyrn (an all-Javascript Jupyter-like single-page workspace) for a better playground.

Understand the verification processs of VCs

  • Start mapping the libraries that are being used to verify VCs.
  • Specify a version 1.0 playground that can show interopability progress.

Initiate a comparison table

Phase 3

Verifying the simplest VCs

  • Programatically verify the VC examples that are collected.
  • Build out the interopability solution for the examples.

Build a feedback loop

  • Develop a feedback view for the different simple VCs. This feedback loop includes:
    • Which VC-spec versions does this comply with?
    • Deprecated?
    • Are these fields connected with an open-world model?
    • Tested on libraries [X,Y,Z]
    • Decoding all text
    • Signatures valid
  • Add possibilities to tweak the VCs for different feedback. This could mean trying a different context, or encoding differently, or siging with a different key available in the DIDdoc.

Phase 4

Initiate interop transportation examples

  • Proof of concept integration of an SSI method with the playground, to be able to experiment with transportation methods.

Phase 5

Graphing out data collected

  • Are there related claims so we can explore synergies?

Questions that are still not clear

  • What is the recommended encoding of an LD-Proof for transmission? (pretty clear with JWT)
  • What are the best transmission methods?
You can’t perform that action at this time.