igree: enhancing digital experiences with user-friendly self-sovereign identity
We started igree to facilitate personal data interaction between people and organisations. We’ll explain here why igree is needed and what solution we propose.
Many people have encountered the privacy-breaking activities of large corporations. One moment you are browsing the internet for a new pair of shoes, and just thirty seconds later you open Facebook and see an advertisement for the same shoes you were looking at just a moment ago. Seems a bit odd, right? One of the reasons this happens, is that we accept both Facebook and Google’s terms and conditions, likely without reading the 100-page document full of legal jargon. Once you click on the ‘Accept’ button, you implicitly provide consent for Google to use your data and sell it to third parties.
A lack of privacy is one of the example problems we face in the digital world. Next to privacy infringement, our personal data is scattered across large corporate databases. These silos form an interesting ‘honeypot’ for adversaries. The rightful owners of these data are not in control, and have no means to prevent a data leak from happening. Users of Yahoo, Adult Friend Finder, Anthem Blue Cross and Equifax have experienced the dire consequences of this paradigm.
The European Union has recognised the risks and challenges the digital world brings with it and the need to protect the privacy and security of natural persons. Therefore, the General Data Protection Regulation (GDPR) has been introduced to protect the fundamental rights and freedoms of natural persons, in particular with regards to the processing of personal data. It is expected that additional legislation will be introduced over the next few years, such as the ePrivacy directive.
What needs to change
At igree, we firmly believe a rigorous change is needed in the digital identity landscape. There are several problems with current identity management practices. Data leaks seem to be everyday business. Identity theft is becoming a larger problem every year. Authentication, particularly on the web, is a user experience disaster due to the plethora of usernames and passwords people must remember. Opt-in by default is too often the standard to ‘acquire’ consent. Personal data is being sold by ‘data brokers’ to everyone willing to pay the price, without the owners of the personal data knowing about it. Instead of “if it’s free, you’re the product”, we should move towards “you get rewarded if you choose to be the product”.
Instead of companies managing personal data in their own silos, end-users will store their own data in personal ‘hubs’. You can compare the functionality of a hub with Google Drive, Microsoft OneDrive, or Dropbox. However, the data in your personal hub will be private, securely encrypted and fully under your control. Of course, companies still want to use certain personal data for their business purposes. However, we believe that individuals should be in control of their data. They should be able to grant access to other entities based on informed decisions. As not all intentions are bad, companies can create a reputable way of data collection and processing by empowering their users.
Self-sovereign identity; say what?
A sovereign is a ‘supreme ruler’. Within the digital identity community, there is a growing belief that people should be their own sovereign. Thus, self-sovereign identity envisions that people are in sole control over their own digital identities. They must be able to create digital versions of themselves without limitations, which can’t be revoked by any authority. Data sharing must only happen on the terms of the individual. Moreover, people should always have access to their digital footprint.
However, self-sovereign identity does not imply that people are completely independent from other entities. In our view, the main technical artefacts to realise self-sovereign identity are ‘decentralised identifiers’ and ‘verifiable credentials’.
A decentralised identifier, short DID, is an identifier which resolves to a DID document, short DDO. In contrast to other types of identifiers, a DID is:
- A permanent identifier which never needs to change
- A globally resolvable identifier
- A cryptographically verifiable identifier
- A decentralised identifier with no need for a centralised authority
A verifiable credential essentially consists out of a set of statements about an entity, often issued by another entity. An example of a statement is ‘John‘s birthdate is 01/01/1980’’, or ‘Jane’s bank account number is 123456’. A claim becomes verifiable — in the sense that another entity, a verifier, can verify that a given credential has not been tampered with by the holder — when the issuer cryptographically signs the credential. As one might imagine, the possible use cases for verifiable credentials are endless. A standard for verifiable credentials is being built by the W3C. They also provide a few examples of use cases for verifiable credentials, such as reusable KYC, address verification, or claiming insurance.
The role of blockchain technology
If you look up ‘self-sovereign identity’, many of the initiatives use some form of blockchain technology. A blockchain’s distributed ledger is essentially a shared database, on which consensus of its state is reached between two or more nodes. The state of the ledger is replicated among all its participants. There are multiple variants of distributed ledger technology, the most notable configurations are a public, consortium, or private ledger. In most scenarios, a public distributed ledger is permissionless, which means that anyone can read the ledger and participate in the consensus mechanism. A consortium ledger is either public or private, but permissioned. On a permissioned distributed ledger, only appointed nodes can participate in the consensus mechanism. Lastly, a private ledger is always permissioned, where only selected participants can read the ledger and participate in the consensus mechanism.
In the context of self-sovereign identity, you will most often encounter public or consortium distributed ledgers. Two notable companies using these configurations are uPort and Sovrin. uPort operates on the public Ethereum network, while Sovrin operates on a consortium network based on Hyperledger Indy. While there are many differences between these networks, they share a common trait; a decentralised public key infrastructure. This enables the users of the network to generate DIDs, which form the basis of their digital identities.
Blockchain technology provides a number of interesting features, where immutability of its data is perhaps the most well-known. For identity management, immutability might seem like an undesirable feature. Our digital identities and its attributes change all the time; we grow older, we change our phone numbers, or we might move into a new home. However, the immutability of a blockchain is a strong feature if correctly used. It provides every entity a single view of events regarding their identities. For example, the National Food Safety Consortium might publish a food safety certification of Bob’s Pancake Restaurant on a certain date. A year later a revocation proof is published on the blockchain. Anyone who can read the data can now prove the validity of Bob’s food safety certificate at both dates.
This leads us to another important aspect of blockchain technology in combination with self-sovereign identity. Private personal information must never be put on a blockchain, in any form! Not would this be undesirable due to the public nature of the distributed ledger, putting personal data on a shared database would break multiple laws — such as the GDPR. Instead of recording private personal data on a blockchain, we should only record public information which can’t identify an individual.
The proposition of igree
With igree, end-users can dynamically control which of their connections have access to specified sets of data. igree operates on the uPort protocol, which lets you create DIDs, anchored on the Ethereum blockchain. While the ultimate goal of igree is to deliver user-friendly self-sovereign identity management to all, we are starting with a Consent & Information Sharing service.
With our service, both organisations and individuals are able to manage their consent and information sharing preferences and configuration. Organisations can configure their services and business purposes, based on which they can request their connections for consent or inform their connections of their data processing. Individuals receive these requests on their mobile application. They can then explicitly, informed and freely choose whether or not to consent to share data for specific business purposes! For business purposes where consent of the individual is not needed, the individuals are still shown what data is being processed and for what purpose. This puts individuals in control, informs them, and helps organisations comply with GDPR regulations.
Putting individuals in control of their data also benefits organisations. In the web application, an organisation can call upon an audit trail of so called “consent receipts”. A consent receipt is essentially a digital text file which describes the data processing activities of an individual and if the individual has provided or denied consent. For each business purpose where consent forms the legal basis to process data, the individual inputs a preference. These consent receipts are cryptographically signed by the individual’s mobile phone, thus we can be sure that every consent receipt came from the person it was sent to. Not only does an organisation have real-time insight in consent preferences, the collection of all consent receipts ever received form a solid audit trail.
So how can an organisation manage this with igree?
igree is a web application for organisations to manage their Consent & Information Sharing configuration. We created three main features: service and business purpose configuration, relations configuration and a message trail. For now, we configured igree as standalone software as a service. In the future we will also provide an integrated version which can be connected with various CRM packages.
The standalone version lets you import a copy of your connection’s contact information (name, email address, and optionally an internal identifier). This will be the starting point of your connections configuration. The next step is to connect with your connections via igree. You can send connection requests via email. After importing your connections and inviting them to connect with igree, you can configure your services and business purposes by using our user-friendly interface. For a sports club using igree, an example service might be club membership. Various business purposes can be added to this service. For example, putting member photos on the club website, or sending a monthly newsletter. For each of these business purposes, you can detail which data attributes are being processed — in the above example this will likely consist out of photo’s, names, and email addresses. Next, connections and services are brought together by configuring groups. Each group consists of a set of connections and services. For a sports club, two groups could be “adult members” and “members under 16”. The adult group likely has other services than the underage group. After your configuration is properly setup, which should only take a few hours for standalone usage, you are ready to send Consent & Information Sharing requests to your customers!
For more information regarding self-sovereign identity, consent management & information sharing, or related matters, please visit our website, or email us at firstname.lastname@example.org