To indy or not to indy?

Paul Bastian(Bundesdruckerei), Christian Bormann(Bosch), Michael Schäfer(Bosch)

• only talking about the indy network (indy-node/indy-plenum)
• Anoncreds/DIDComm are independant from indy (misconception!)
  • this document does not discuss AnonCreds/DIDComm (out of scope)

Requirements and needs?

• regulatory safeness
• longterm commitment & active developer community/contributions
• technical stability and scalability
• but: network is just an enabler/tool
  • business cases rely mostly on higher level functionality
  • DIDComm and AnonCreds as important building blocks independant of Layer 1

Status Quo : Indy Network & Consensus

Pros

1. Efficient signature scheme for node consensus & State proof: Check validity of provided information as client (via efficient aggregated bls signatures)
   • this property is really important for scalability and trust relations and currently missing in other DLT
2. Role / Permission based / configurable during runtime (via config ledger)
3. Plenum (with own RBFT implementation)
4. Purely for identities – no tokens involved

Cons

1. currently not many active contributors & missing political support
2. Throughput bottleneck (observer concept & implementation required for production)
3. BLS is new crypto (regarding regulated use cases)
4. Purely for identities –> no smartcontracts and requires parallel setup for payment

Path forward

Alternative 1

• indy gets political support
• indy contribution is driven by the IDunion SCE
• commitment of the IDunion partners
• fix immanent problems for production (e.g. observer pattern)
• possible roadmap:
  • finalizing did:indy
  • build concepts and integrate observer pattern
  • build concepts and integrate deletion/tomb stoning
  • maintenance work
  • set up production network

Alternative 2a

• commitment to an existing (permissioned) network
  • e.g. EBSI
• add desired features to new network (mostly agent side)
  • e.g. DIDComm, AnonCreds support
• initially additional effort with few benefits, long-term probably less effort
  • adaption of existing use cases
• EBSI is currently a technical inferior solution and is very likely subject to change
• possible roadmap:
  • start with evm-based EBSI (did:ethr?)
  • optional : build concepts to improve EBSI (BLS/state proof/roles?)
  • build concepts and integrate deletion
  • build concepts to integrate Aries/DIDComm/AnonCreds
  • integration into aries frameworks
  • integration into current pilots

Alternative 2b

• commitment to building a new network
• design new network with given requirements from scratch/re-using existing components (e.g. ethereum/tendermint/cosmos)
• risk/reward ratio?
  • integrate experiences from current solutions
  • better programming languages
• possible roadmap:
  • did method/specification
  • start with cosmos/tendermint
  • build role concept
  • integrate BLS/State-proofs
  • build concepts and integrate deletion
  • client libs(like indy-vdr)
  • integration into aries frameworks
  • integration into current pilots
  • set up production network

Alternative 2c

• use TrustChain as VDR from one of the IDunion partners
• TrustChain needs political support
• strong focus on HL aries
• risk/reward ratio
  • same focus like indy but learned from mistakes
  • already solved scalability and GDPR problems
  • Open Source and "made in Germany" (gets support by politicans for sovereign solution)
  • no implementation for Anoncreds yet but for VC already
  • further investigation neccessary
• roadmap:
  • intergrate Anoncreds when standards are finalized
  • get support from BSI for regulated/relevant use cases

Alternative 3

• do not use DLT as Verifiable Data Registry
• use did:web(every issuer hosting his keys on his own webserver), did:keri
• many unanswered questions as well - research necessary
  • less SSI centric - verifier contacts issuer directly (escpecially for revocation)
  • trust framework & governance

Next Steps

• who takes the decision?
• discussion with EBSI guys?
• separate workshop?