Sovrin vs UportHow does their underlying blockchain technology differ?
Both Uport and Sovrin leverage blockchain technology and are open-source. Their implementation and guiding principles are different though, and this first becomes clear in the different blockchain flavour being used. Uport uses a so-called public permissionless blockchain platform called Ethereum, while Sovrin uses a so-called public permissioned blockchain. Contrary to what many people think, the “public” part does not necessarily have anything to do with privacy. Rather, it means that anyone is able to use the ledger. The permissioned vs permissionless part is more of a governance question. In simple terms, it can be seen as whether you can “own” a part of the network or not. In a permissionless platform like Ethereum, anyone can download a node and help maintain the network. As a result, that person can take part in the platform’s governance, by doing proof of work or proof of stake. In a permissioned network, such a thing is not possible and only a select few assigned trustees have a say in the governance of the platform.
In other words, Ethereum-based Uport is more decentralized than Sovrin and the ledger is more censorship resistant. The fact that users can run their own node in Ethereum means they are not dependent on third party nodes, further improving censorship resistance. In Sovrin, the platform’s stewards could collaborate to block a certain user and since the user is unable to run a Sovrin node, they would have no way of preventing that. This open character makes Uport more accessible and inclusive. The downside is that its base technology, Ethereum, is more of a grey area when it comes to law and regulation. Thus, it is less likely to be accepted for government applications. Another downside is that a permissionless network might split if several parties within the community disagree about the future of the platform. We have seen this in the past. This split results in two chains with an identical history. In a cryptocurrency application, this means a user would have two coins instead of one. While there are certain risks involved, this mostly results in some extra speculation. For identity it might be a little more catastrophic, since this can potentially result in a duplicate identity that could be abused.
How do Uport and Sovrin’s provability claims and data minimisation stack up?
A digital identity must be reliable and provable. The challenge with SSI, is to do this while showing as little information as possible (data minimisation). Uport enables users to download an app to create an identity. This app holds the private key that can be used to sign attestations and share these with others. Uport identities are capable of signing attestations about other identities using a smart contract. Attestations of claims are then published on the blockchain, increasing the trustworthiness of the claims. Note that sensitive information, including claims, is not stored directly on the blockchain. Only the attestation itself and a decentralized identifier (DID) is stored. A DID is a new standard, where each service requires a unique identifier to prevent correlation. Without it, hackers could potentially deduce personal data by analysing the history of the blockchain. Uport’s relatively simple and effective way of signing claims, makes them easy to look up and verify, or prove. The use of DIDs in Uport also makes the use of claims more secure and supports data minimisation. However, Uport does have shortcomings in this regard, as we will explore below.
Sovrin does things differently. It has built its own blockchain (Hyperledger Indy) with data minimization in mind. Being a permissioned network, Hyperledger Indy is much more restrictive as a platform compared to Uport, resulting in a higher degree of data minimisation. There are no native apps and currencies for users to use where transactions could be correlated. In addition, Sovrin has the option to use agents that act on behalf of the user. An agent is basically a piece of software that facilitates interactions using one or more Sovrin user identities. This opens up some new ways of doing authentication. An agent has the ability to set up its own virtual communication network for each different situation, using a unique identifier (DID). Only the agents that share this unique identifier know which identity owner it is associated with. For all other agents, these identifiers are meaningless. Besides agents, Sovrin uses zero knowledge proof (ZKP) to enable selective disclosure of claims. Claims themselves are not stored on the blockchain, but rather on the user’s phone . ZKP is a cryptographic method that can be used to share sensitive information without revealing any details of that information. All of this shows that data minimisation was carefully considered at Sovrin.
Uport, by contrast, has some issues with data minimisation. On Ethereum, every transaction being made by the user can be found using a block explorer and can possibly be correlated. These correlations can be used to deduce sensitive data about the user. Uport partly solved this problem by creating a new account for each app being used. However, since Uport is built on Ethereum, it often requires the native currency, Ether, to be used in many of the apps. If a user funds multiple accounts from the same wallet, these different accounts could be correlated. Uport is aware of his problem and takes this very seriously, but as of this moment, it does not completely meet data minimisation criteria.
Sovrin’s agents offer more flexibility and possibilities than the more bare-bone applications offered by Uport. However, Sovrin’s set up is not without problems. First of all, agents that act on behalf of the user might have legal consequences. There are currently no guarantees the agents function as intended. Therefore, claims in Sovrin do not meet the “provable” criteria. Another problem is that schemas and credential definitions are created largely by market parties, leaving more room for malicious code to enter the system. Sovrin’s documentation does not clearly state what kinds of subject identifiers are being used, especially when using agents. Let’s turn to IRMA, which offers a different approach to SSI.
IRMA: SSI without blockchain
Unlike Uport and Sovrin, IRMA does not use a blockchain. However, it bears many similarities to both platforms. It stores claims on the user’s phone using an app. Attestations are signed and can be retrieved online. Like Sovrin, IRMA also uses zero knowledge proofs to disclose as little information as possible. Using the issuer’s digital signature, the user can prove that the claim is valid and is even notified about the attributes a verifier is trying to read. When the user feels a verifier is trying to read too many attributes, they can refuse. The IRMA app stores the attributes the verifier asked for. Users can then leverage this information to file a complaint when they see a verifier asked for unnecessary info.
In short, IRMA meets both the requirements of provability and data minimisation. Just like in Sovrin and Uport, the user is in control of their own data. There is, however, one feature that IRMA is missing compared to blockchain-based Uport and Sovrin: persistence. Persistence is the property that identities must be long lived. The blockchain guarantees that the data that verifies authentications and attestations of claims being made can’t get lost, even when a user loses their phone. The blockchain, in this case, makes sure that the identity is persistent (long lived). There are some centralized solutions that have a backup system in place. In IRMA’s case, this becomes either the user’s responsibility or the responsibility of a centralized party.
While technically out of scope as far as SSI properties go, we want to briefly address the matter of revocation, since this is an important property in practice. Sometimes it is required for a credential to become invalid. The default way for credentials to become invalid is for them to expire. The same happens, for instance, to your passport after 5-10 years. In certain cases, it is required to revoke a credential before the expiration date. For instance, when a person is caught driving under the influence and their license must be revoked. Uport and Sovrin have a built-in revocation functionality which uses a smart contract, where issuers can retract certain credentials. This is done by giving every credential a revocation identifier, so the smart contract knows which credential to revoke.
IRMA, on the other hand, only allows users to revoke their credentials in case of theft or the loss of their phone. Revocation is done using a keyshare server.The disadvantage is that a keyshare server is a single point of failure. It can fail during a hack, a natural disaster or due to purposeful censorship. Because issuers can’t revoke credentials themselves, credentials have short expiration dates. To address this, IRMA automatically renews credentials when the user is online, but this is not an elegant solution.
Blockchain seems to be a good foundation to build Self-sovereign Identity solutions. Our analyses show that, on average, blockchain solutions meet more SSI requirements than non-blockchain variants. This is because the whole foundation of blockchain is already based on the fact that there should be no central administrator and that every user of the system is in control of their own wallet. The immutability and distributed character of blockchain helps with both the persistence and interoperability of the identity. Smart contracts in blockchain can help issuers revoke credentials when necessary. IRMA is an exception that shows that you can meet most criteria without blockchain. An advantage of a non-blockchain system is that it is easier to satisfy the data minimisation property, though Sovrin shows that it is possible to preserve privacy even while using a blockchain. We therefore conclude that blockchain is a good foundation for building SSI, but not a necessity.