Review vp-toolkit

[OR13]

https://github.com/rabobank-blockchain/vp-toolkit#flow

[rabomarnix]

Hi,

Thank you for taking the time to review our SSI flow.

Background

A while back we saw various identity protocols popping up. In a few PoC's we needed to use different protocols - so instead of hardcoding the protocol in the mobile wallet, we decided to make a flexible plugin system which allows developers to plug in the protocols they would like to support. This framework is called Universal Ledger Agent - but it's basically a small message bus, broadcasting message inside the application during runtime. More background info on our SSI journey here and a video here.

Plugins

We published ULA plugins for the mobile wallet conform the SSI flow as mentioned above, along with some standalone libraries to perform generic tasks. This is a list of libraries and plugins. We are going to test the integration with new Hyperledger Aries plugins soon, so both identity protocols are supported in one app.

Flow

The issuer shows a QR code containing an endpoint. This endpoint resolves to a ChallengeRequest object, simply stating what the issuer wants to do: Issue x amount of data points. The holder app then creates x amount of private keys (or derives them) and calculates the Ethereum addresses - one for each data point, and sends a map of predicate -> address back to the issuer. The issuer then includes the address in the right VC. This results in each credential having a new DID, not bound to one user DID because of GDPR uncertainties. Finally the issuer sumbits an Ethereum transaction for each address into the VcStatusRegistry smart contract. The issuer can revoke by removing the predicate address from the smart contract.

The verifier checks the cryptography and the smart contract if the entry is still there.

Drawbacks

• Our DID structure is did:eth:address and uses the deprecated eth namespace;
• We haven't switched to the ethr namespace and our code isn't yet involving a DID resolver. The public key used for VC/VP verification resides in the proof.verificationMethod field;
• Each data point becomes a new VerifiableCredential in order to maintain data minimalization. This makes correlation tougher, which makes some use cases (requiring correlation) more difficult. We might switch to a selective disclosure strategy using hashes;
• Our protocol has no interaction with data hubs yet;
• We can't prevent other people from scanning the QR code. We advise issuers to link the wallet during registration of a new account with a protocol like DidAuth;
• Some verifiers might require the identification of the person using the phone, this option is missing.