Trustchain comparison eidas
HackMD: https://hackmd.io/RKrehPFYTNyNf1zt5abU2g
Laws
- Digital Europe Programme (DIGITAL) is the current umbrella digital transformation funding programme
- eIDAS regulation came in 2014 for EU (and subsequently a UK version on leaving EU) providing legal weight for digital identity services; Trustchain would need alignment with these regulations
Scopes
- EBSI is the overall framework for blockchain, DIDs, VCs and APIs.
- ESSIF aim to facilitate a DID generation system and protocols for the exchange of VCs belonging to IDs in such a way that they are compliant and facilitated with eIDAS regulation
Wallets
- eID aims to provide a wallet framework to so that authorities store VCs with a DID
- EBSI develops APIs compliant with eIDAS for system interactions but not wallets themselves
Blockchains
- EBSI currently will make use of a Proof-of-Authority Hyperledger Besu IBFT 2.0 blockchain where nodes are maintained by authorities in member states and writing to the blockchain permissioned by Trusted Accreditation Organizations (TAIs) with blocks only made by the validator nodes
Trust and validation
- ESSIF and Trustchain have similar proposals and usecases for DID exchanges with similar actors (Trusted Accreditation Organisations = root trust + dDIDs with sufficient permissions, LE = dDIDs with less permissions, Natural persons may be incorporated )
Differential costs between EBSI and Trustchain
- Trust is assigned similarly between EBSI and Trustchain and the costs there will be dependent on respective outsourcing of responsibilities to actors (e.g. who makes the wallet software)
- The key difference is that EBP/EBSI must maintain a secured and trusted validator nodes and query (Remote Procedure Call, RPC) nodes for a functioning blockchain (estimated £0.003 per transaction, see calculation below) but the actual transaction cost is nil. Trustchain does not need to finance a blockchain and nodes for querying (IPFS and bitcoin blockchain are maintained robustly without new infrastructure) but must finance ION transactions (ION quote as low as $0.01 per transaction but will depend on bitcoin transaction cost)
- 2014: eIDAS regulations specifying legal requirements on digital exchanges under EU law
- 2016: UK leave EU and incorporates own regulation
- 2018: The European Blockchain Services Infrastructure (EBSI) is a project of the European Blockchain Partnership (EBP) comprising of 29 countries (all EU members states, Norway and Lichtensein) and the EU Commission.
- 2019: eIDAS bridge, prototype implementation of eIDAS seal provision on VC exchanges
- 2021-2027: Digital Europe Programme (DIGITAL) is a programme of EU funding (€7.5 billion) that aims to accelerate digital transformation across Europe.
- 2023: eIDAS-2
- "a major update meaning that each EU Member State must make a digital 'wallet' available to every citizen who wants one"
- "banks and telcos, will have to accept it as proof of certain personal attributes"
- Aims to motivate the market to use eID if demand from citizens, expediting the use of eID.
Digital Europe Programme (DIGITAL) is a programme of EU funding (€7.5 billion) that aims to accelerate digital transformation of public administrations across Europe and help upskill them. DIGITAL provides funding in five key areas: supercomputing, artificial intelligence, cybersecurity, advanced digital skills, and ensuring a wide use of digital technologies across the economy and society, including the building blocks.
Building blocks These are being referred to within the DIGITAL programme as:
A Building Block is an open and reusable digital solution.
The current five mentioned are:
- eDelivery: exchange electronic data and documents in an interoperable and secure way
- eID: offer services capable of electronically identifying users across Europe
- Once Only Principle: reduce administrative burden for individuals and businesses
- eSignature: create and verify electronic, paperless signatures
- eInvoicing: send and receive electronic invoices with automated processing, in line with the European standard
eID is a building block of the DIGITAL programme for European citizens providing IDs between member states such that it is inter-operable and seamless.
It allows citizens to authenticate themselves by using their national eIDs and connecting with their Identity Provider (IdP) from their country. An example:
- A citizen requests an on-line service in another Member State.
- The citizen is requested to authenticate themselves by the on-line service.
- The citizen chooses to authenticate with an eIDAS eID (from their Member State).
- Authentication request is sent to the citizen’s country for authentication, through the eIDAS network, to the citizen’s Identity Provider (IdP) where authentication takes place).
- The authentication result is returned to the service provider. Authentication is complete and the citizen can proceed with accessing the service.
The eID are therefore state-issued digital identities that are usable across EU states/services that operating gateways that accept the ID. The gateways are delivered by eIDAS-Node. These identity are not self-sovereign and do not involve a blockchain.
It has three specific components currently:
- eIDAS eID Profile: technical specifications posted here will help Member States to develop their own eIDAS-compliant implementation
- eIDAS regulation: the EU wide laws
- eIDAS-Node: information on running an eID node
European Blockchain Partnership (EBP) comprise 29 countries (all EU members states, Norway and Lichtensein) and the EU Commission was set-up in 2018 to develop European wide blockchain solutions.
The European Blockchain Services Infrastructure (EBSI) is a network of distributed blockchain nodes across Europe. EBSI is one part of the DIGITAL programme. EBSI does not plan to build a wallet; the wallet is expected from private sector software, member state and EU-led initiatives. EBSI is the first EU-wide blockchain infrastructure. EBSI is designed as a market-friendly ecosystem based on open standards and a transparent governance model. It will comply with EU regulations GDPR and eIDAS. EBSI has a set of Core Services APIs for interaction between parties and the blockchain: Business app, Wallet, Wallet Library, DID Registry API, DID Authentication API, VC API, ID Hub API, VP API, TSR API, TIR API
ESSIF is a sub-initiaive of EBSI focussing on the Self-Sovereign Identity aspect. Self-sovereign identity is specifically means that:
- User must be central to the administration of his/her digital identity
- User must have ability to use an identity across multiple locations
ESSIF will be compatible with the eIDAS/eID technologies and facilitated through EBSI.
Some useful slides from an SSI meet-up webinar.
The EBSI nodes composing the network support multiple protocols (pluggable protocols) and a full set of APIs. The main protocols supported at the moment are Hyperledger Besu (with IBFT 2.0 consensus) and Fabric. Description for in besu:
Besu implements the IBFT 2.0 proof of authority (PoA) consensus protocol. IBFT 2.0 is supported for existing private networks, but QBFT is the recommended enterprise-grade consensus protocol for private networks. In IBFT 2.0 networks, approved accounts, known as validators, validate transactions and blocks. Validators take turns to create the next block. Before inserting the block onto the chain, a super-majority (greater than 66%) of validators must first sign the block. Existing validators propose and vote to add or remove validators. You can create a private network using IBFT.
Further explanation of IBFT is available here but can be summarised as follows:
- The blockchain is maintained by a set of validator nodes
- These nodes take it in turns to begin a new block
- Transactions are submitted to network and added to the block
- Once a supermajority (2/3) of validators agree on the block, it's added and locked
- Therefore the system is tolerant to 1/3 failing validator nodes and at least 4 nodes are required to ensure fault tolerance and functionality
Key point: Validator nodes must be trusted and therefore are on at least the same level of trust as a Trusted Accreditation organisations (e.g. dDID issuers in Trustchain). Robustness to a validator node becoming corrupted could be attained by validator nodes being spread out among different member states?
Extensive documentation for EBSI v2 is here
An illustrated use-case for person, legal entity and registration authorities using DIDs and interacting with the blockchain.
Table of roles:
| Role | Description |
|---|---|
| Issuer | This term refers to a party that creates and issues Verifiable Credentials (e.g. Verifiable IDs or Verifiable Attestations) to Holders. |
| Holder | This term refers to a party who is "holding" (or storing) Verifiable Credentials that have been issued to them by an Issuer. |
| Verifier | This term refers to a party who requests/verifies Verifiable Credentials (e.g. Verifiable IDs or Verifiable Attestations), such as to provide a service. |
| Relying Party | This term refers to a party who requires data / relies on Verifiable Credentials such as to provide a service. Usually this term used interchangeable with the term "Verifier". |
| ESSIF Onboarding Service (EOS) | This term refers to a function/service an organisation can perform to onboard Natural Persons and Legal Entities to the EBSI ESSIF ledger (DID Registry) if has the required authorization based on a classical identification means (that provide the required level of assurance as defined by relevant regulations) |
| Trusted Issuer (TI) | This term refers to an organisation that is authorised to issue certain types of VC (based on an accreditation by a TAO) and is listed in a relevant TIR. |
| Trusted Accreditation Organisation (TAO) | This term refers to an organisation authorised to accredit other entities to issue certain types of VCs and is listed in a relevant TAOR. |
EBSI based their credential schemas in the W3C verifiable credential standard and DID Document standard
Details of the specific DID API process can be found here.
Two helpful example usecases for registering DIDs for natural persons and Trusted Issuers
- Natural Person Onboards On ESSIF
- Register an ESSIF Onboarding Service (EOS) on the ESSIF Onboarding Service Registry
-
Who can write a DID to the ledger?
- Anyone that has received permission from Trusted Accreditation Organisations (TAIs). The blockchain itself proceeds through validator nodes using proof-of-authority to process valid transactions (they have permission and meet other necessary requirements to be valid)
-
Who verifies the identity of a DID? Who controls the ledger?
- Trusted Accreditation Organisations (TAIs) and authorised legal entities.
-
How does a party become a validator?
- Validator nodes can approve new validator nodes and remove current validator nodes
-
Who can/is required to run a blockchain node?
- Member states must run secure trusted validator nodes. Additional nodes that can query the hyperledger must also be run (RPC nodes) but these do not have the same level of trust and security required because they do not have permission to write.
- Who can become a Trusted Accreditation Organisation (TAI)?
-
How are DIDs onboarded?
- Similar process to Trustchain, examples of onboarding usecase
-
Revocation process described for EBSI v1 references software and here
-
API description and playground resolver (e.g. try resolving "did:ebsi:zub5ZZUfHLLptCduwEy8xRj"): the API library details for various components EBSI and the ESSIF can be used in this resolver tool to demonstrate the API input and outputs
- eID aims to provide a framework for wallets to manage and distribute VCs using DIDs with ESSIF and verified with the EBP blockchain. A worked example from V1 of eID with codebase.
- eID will aim to use EBSI/ESSIF infrastructure to produce/verify DID.
- The signature of the public institution in the interaction provides the eIDAS seal (legally binding the DID/ID transaction).
- Maintenance of DID/dDID integrity and trust network (both)
- Admin/maintenance of validator nodes (EBSI). How many validators are required to serve a country/Europe?
- Running of queryable blockchain nodes (EBSI). How many nodes are required to serve Europe?
- ION transactions (Trustchain)
- Software for writing and reading with ION (Trustchain?)
To estimate costs, we consider three components for EBSI and Trustchain:
- Transaction costs
- Query costs
- Developer costs
Required nodes
- We consider:
-
transactionsas writes or edits of keys committed to the blockchain by the validator node of the country (simplification as there may be filtering nodes) -
queriesas lookups in the blockchain handled by RPC nodes
-
- We consider a country around the size of the UK (67 million people)
- We assume that the both types of node have typical server loading of around 100 requests per second
- We assume that a person in society will perform around 5 transactions per year(to change/add/revoke a key) and 1 query per day (e.g. to check a VC for some reason, like buying alcohol)
- This leads to 335,229,452 transactions per year and 24,471,750,000 queries per year
- Given the above node interaction frequencies, if evenly spread out over a day, this is 775 per second for all RPC nodes and 11 per second for validator node
- The country needs around 8 RPC nodes and 1 validator node at these rates.
- If in fact the loading is much larger (e.g. everyone wants to buy alcohol between 5pm and 6pm, or add a key between 9am-10am), then the number of RPC nodes is 186 and validator nodes is 2.5 (although realistically it may only be possible to have a single validator node per country due to besu performance limits)
Costs
-
We assume that the validator nodes need:
- 10 experienced admin
- typical computer and electricity prices
- Total around £1m per year
-
We assume that the 186 RPC nodes need:
- 4 admin
- typical computer and electricity prices
- Total around £1.5m per year
-
With these total costs, dividing by the number of transactions we get:
- £0.003 per transaction
- £0.00006 per query
-
If we additionally assume that a developer team (which reasonably might be expected to Trustchain too) is required for software maintenance:
- E.g. 20 junior developers, 10 senior developers, 4 managers
- Total around £2m per year
-
We then estimate that:
- £0.00825 per transaction
- £0.00008 per query
- Trustchain relies on ION to write transactions to the bitcoin blockchain and it is suggested that costs can be £0.0082 ($0.01) per transaction
- Querying the blockchain would have no cost attached so would be effectively $0 per query as the current IPFS and blockchain nodes can be used without cost
For the same number of transaction this would give a total cost per year of around £2.7m excluding developers.
Similarities
- Both systems rely on some sort of issuer of trust for the DID
- Both need APIs and conformance with W3C
- Both will have some admin burden
Differences
- EBSI runs its own blockchain; Trustchain relies on other blockchain(s)
- EBSI does not make wallets but provides APIs; Trustchain may develop wallets and software to interact with ION
| Property | Definition | EBSI/ESSIF | Trustchain |
|---|---|---|---|
| Aim | Goal of the project | Framework for DID and VCs, integration with EBSI, compliance with eIDAS, functionality with eID | Software for natural persons and legal entities to provide DIDs and VCs without any new blockchain implementation. |
| Self-administration of identity | Individuals are able to issue their own DID | Yes | Yes |
| Consensus mechanism in blockchain | Mechanism by which blockchain operates | Hyperledger Besu IBFT 2.0, proof-of-authority (PoA), a set of trusted validator nodes commit transactions | Proof-of-work (PoW) with bitcoin via ION but can use any blockchain in priniciple with sidetree |
| Trust mechanism | Mechanism by which keys and identities are trusted | Validator nodes are trusted to be non-compromised. Actors become designated Trusted Accrediation Organizations (TAI) and Trusted Issuers that are responsible for assigning trust to keys. They will have reputational and legal responsibilities. | Actors become trusted through downstream trust transactions from the root. Reputation and legal action at stake in the signing a DID or VC |
| Permission to write | Who can write to ledger | Permissioned, only validator nodes write blocks but transactions can be submitted by all parties once authorised by upstream trusted authorities (TAIs and TIs) | Permissionless, but trust will only be identified if link to root trust |
| Nodes | The identity of all participating nodes is known | Yes, each member state runs known validator nodes | No, but identity is not required to run the blockchain |
| Robustness and security | Ability for blockchain to tolerate faults and security breaches | Yes, distrbuted across member states, but if > 1/3 validator nodes are compromised then the ledger is broken | Yes, bitcoin has been shown to be robust over time and highly costly to fraud due to PoW |
| Decentralized | No centralized store of the blockchain | Yes, insofar as member states run their own hyperledger nodes. No in the sense that the validator nodes are few and possessed by central authorities. | Yes, relies on the bitcoin blockchain |
| Scalable | Support for high-throughput and high number of nodes | Yes, but only tested up to 30 validators. Connection to hyperledger node required to query. | Yes, the trust network is held in the blockchain so essentially is limited by the ability to identify a path to root trust node. Any computer with Trustchain software could query the Trustchain. |
| Open | Open source code implementations | Yes, APIs all public and Hyperledger Besu IBFT 2.0 open source | Yes, planned |
| Sustainable | Energy efficiency | Energy use is proportional to the energy consumption of the nodes being run for validation and querying | Energy consumption is proportionate to the number of ION transations and the operation of querying the Trustchain |
| Interoperable | Based upon standards and technical specifications (i.e. eIDAS compliant) | Yes, a principle of the EBSI design | Yes, can be agnostic to key specifications |
| Issuers of DIDs | Who and how are DIDs issued | Anyone but needs registration authority to incorporate into blockchain | Anyone, but ability to issue dDIDs is a flexible parameter to be specified |
| Revokation mechanisms | How are DIDs revoked | Revokation can be performed by natural persons, legal entities or registration authorities | Revokation can be anyone and will be automatically transitive downstream |
| Credential schemas | How are verifiable credentials implemented | EBSI based their credential schemas in the W3C verifiable credential standard and DID Document standard | W3C |
| Provision of VCs | Who provides verified credentials | Anyone with accredited DID | Anyone granted sufficient trust level in Trustchain |
| Central operational cost | Components that will drive the operational cost of the system | Running nodes, administration associated with maintaining trusted accrediters and issuers (registration authorities) | Cost of ION transactions, administration costs for authorizers of DIDs and issuers of VCs |