---
# System prepended metadata

title: To indy or not to indy?

---

# 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?