Skip to content

(archived) PoC of Decentralised Identity

Jump to bottom
Ross Tang edited this page Mar 19, 2021 · 1 revision

Background

There is a rising need for transaction privacy and individual privacy, for onchain transactions. The current identity and authentication model is a distributed authentication server, which in turn utilizes conventional (centralized Certificate Authority servers). That means, it follows the conventional user onboarding (or user registration approach). This is building multiple trees (web of trust); it is hard to ensure high degree transactional privacy. Each transaction are submitted via identiable X.509 certificate. Also, this implementationis an example-graded implementation. Consider that even we continue the development, the participant organization is unlikely to adopt. This conventional approach will remain an example for self-learning purpose. Hence, we need to figure out an ultimate desgin, and implementation.

Our Needs

A. Transaction privacy & individual privacy

Transaction privacy refers to the de-linking of ledger transaction from individual / identifable identity. Individual privacy refers to data protection from leaking PII. Notice that it shall require two mechanisims to address them. The transaction privacy needs to additionally address the issue of correlation risks. The additional requirement of individual privacy includes the "unintended sharing" of user's personal data.

B. Authentication

To be determined.

Motivation

The above privacy requirement shall intuitively direct me to Self-sovereign identity (SSI); or more specifically, pair-wise pseudo DID. Self-sovereign identity (SSI) is an approach to digital identity that puts technology users in control of their identities. However, the raised privacy via SSI is impactful, for example:

  • change to self-sovereign
  • change of trust model
  • implementation risk

On the other hands, the change of trust model, shall require altered implementation of prover (aka verifer); and edge systems. Not quite sure, given a limited time project. How much degree of requirement A, and B, can be fulfilled.

Task Objective

Conduct a 4-weeks PoC to:

  1. (DONE) Implement Basic constructs of "Verifiable Data Registry", e.g. DID, DID Document, Did Method, DID Resolver
  2. Evaluate external solution for Veriable Claim / attestion, Prover system, Edge agents. Candidates include Emailo's and Hyperledger Aries
  3. Figure out how the participating company can provide the Prover system.
  4. Require a fallback plan, if SSI is not continued; and above privacy requirement is not fulfilled.
  5. Optionally, assess how (un)likely Emailo's Corporate ID solution fulfill our requirement.

The output includes

  • PoC codes
  • (a) If continuing, give a subsequent development plan
  • (b) if inconclusive, give gap and impact analysis for further team discussion

Special Remarks:

  • This task does not include "authorization"
  • The PoC codes is not going to release; and is not assumed to be re-usable by sub-sequent development.
  • SSI is will be part of fabric-es shared library.
  • The PoC will only attempt to solve "privacy" and "authentication" problem. Other data protection orcybersecurity concern is out of scope. It will be a general purpose built, will not cater individual organisation requirement.

PROGRESS

Week 2 Summary:

  1. Confirmed the use of Decentralised Identity, is necessary, and viable. I will re-position the PoC, to pilot implementation.
  2. Will comply W3C standard as much as possible, even they are mostly "draft".
  3. Will reference Bitcoin (Ion), Sovrn, and uPort's implementation.
  4. No information from Emailo. Considering that (1) his license model is not determined, (2) project boundary issue, and (3) timeline not matched. Will not consider Emailo's solution. And, SSI approach is not so standardised, canNOT assume his is ready.
  5. Hyperledger Aries is solution for Layer 2, didComm. It is a depend of Hyperledger Indy. Will not use it. For the time being, we attempt uPort didComm.
  6. Mimic uport (etheruem) Did base layer, in term of method-specific-id.
  7. Basic functions of Verifiable Data Registry (with did-JWT) is complete. The PoC codes look good, and likely to be useful.

Week 3 Goal

  • (DONE) Next Week focus to enrich layer 1 functions, e.g. registrar and resolver, public / private DID
  • (NOT YET) will adopt pairwise Did
  • (NOT YET) implement Revoke registry
  • (NOT YET) registrar will require authentication (Need to some experiments)

Some comments on authentication:

  • Neither the password-authentication, nor publicly-authentication protocol (SSH) are considered.
  • Did-SIOP is not far far away from ready. But seems that OIDC is good stepping stone. The experiment will implement Auth0 OIDC at application tier; with no relationship with DID authentication. Fix the DID authentication later.

Below functions is layer 2/ 3. No solid idea, how to build it. Will be evaluated later.

  1. Exchange / peer to peer communication
  2. vc Issuer and Verifier API
  3. Auditable / Lifecycle based Credential store

Need more research. Sovrin network is good to reference, however, it is B2C. For example, Sovrin and Etherum assumes no registration. There are no B2B model suitable for our use case.

=== PoC Ended Here ===

The subsequent work will be replaced by another story, for actual implementation.

Clone this wiki locally