Self-Sovereign Identity Challenges and Solutions
Are We Who We Say We Are?
Michael V Khalsa, Visionary and Technical Lead
A cornerstone of digital interaction is the requirement to validate we-are-who-we-say we-are. Today this responsibility lays with our governments and leading tech companies whom have brought forth scalable solutions to power the growth of our digital selves. The speed at which the digital identity market is growing together with the latest technological innovations such as blockchain have strengthened the awareness that our current solutions are, although scalable, not adequate to guarantee the protection of our identities from abuse in its broadest sense. Challenges within the current approach are slowly ripping apart the fabric of the digital ecosystem, such as data breaches, identity theft, and abuse of targeted marketing.
The powerlessness experienced in these breaches, is making us aware that we need to take back control of our personal information, with clear political backing from regulation such as Europe’s GDPR laws and California’s similar AB 375 law. Together with the damage done to corporations, both reputational and financial, everyone (except the crooks) is eager to find solutions.
Let’s walk through a common example to see how the government network can help to solve the issues with full compliance, while returning control of identity to the end user.
Signing an Online Petition, while remaining anonymous
At first this might sound like an oxymoron, as signing a petition means that we are willing to stand up for something we believe in. However there are a number of reasons why we might refrain from signing a petition even if it shares our beliefs due to potential negative backlashes. Examples are:
- Recently large corporations have attempted to subpoena all of the personal information of the signers of popular partitions for possibly hostile reasons (Example: Avaaz vs Monsanto),
- Backlash from Governments, a concern not only valid in the third world, (Example: the public statements of intention from the White House and Trump Administration),
- Negative reception from our community. (Example: LGBT communities in countries where being part of these communities is still a criminal offense)
- In a corporate or educational setting, were we fear the reception amongst our colleagues and superiors. Anonymous petitioning can provide a realistic representation of our stances. (Example: today the loudest and most powerful voices have the most influence in important and controversial subjects)
To make a petition legitimate, it must be verified that each person signing it:
- Can only sign once
- Is within the jurisdiction that the petition applies
Currently, the only way to acquire legitimacy is to attach personal information of each signee, possibly including their name, date of birth, signature date, IP address, physical address or region, email address, and government id such as a driver’s license number. These details are then cross-referenced in a database making sure there are no duplicates within a verifiable process. All of this information is centrally stored. Some petition services may store all of our information in a profile, which if breached can reveal correlation with other petitions signed.
In addition, when presenting the petition, at least some of our personal details are included with the petition. This means that our identity can be stored by additional parties, and possibly used without our awareness.
To create an alternative, we need to be able to sign a petition with a proxy which reveals no personal information and cannot be correlated against other petitions we may have signed, nor with other uses of our identity. The option to include our name or other details would be our personal choice.
The party accepting the petition would need to verify that each proxy belongs to a real person meeting the requirements to be eligible to sign the petition, and no one person signs with multiple proxies.
The process has to be easy to use and for the accepting party to verify.
Example: Alice has created a petition at her local university to show support for a student online voting platform for referendums. The staff like the idea, yet want a clear favourable indication from the students, and thus challenged her to get 1000 signatures from enrolled students. If successful the university will implement this next generation technology into all its many services and departments. Bob, always the critic, also liked the idea because he was suspicious that someone in the IT department was messing with the voting of his most liked proposals.
Let’s map out the flow of how this could work:
A common denominator for all the students, is that each student owns a smartphone or has access to a computer. Personal cell phone ownership or access to a computer is almost universal - even in refugee camps and many third world countries. Our interface into establishing and using a Self-Sovereign identity should be primarily mobile friendly.
While the Government Network will have its own mobile apps, it will also provide an API and development kit; which allows many of its services to be used by other apps. The university decided to add an ‘Identity’ section to the university app. When visited for the first time, there are two buttons (along with some available help if needed):
- Create a New Identity Relationship with the University
- Use this Device with an Existing Identity
Bob clicks on ‘Create a New Identity’. After a confirmation screen, Bob is asked to touch his finger to the fingerprint reader, or look at the phone, and voila - he has established a new encrypted peer-to-peer channel with the university.
Beyond the scenes his phone creates a new ‘decentralized identity identifier’ (did) on the device and saves the encrypted private key locally using the biometric authentication. The identifier does not contain any personal information and looks something like this: 'did:govnet:123456789abcdefghi'. The university also created a 'did' just for this relationship in what is called a pairwise set of identifiers. each party did a behind the scenes check that they indeed own the identifiers they created (through a peer-to-peer encrypted challenge that can only be answered correctly if the owner of a did has the private key) . It is important to note that we did not ask any service to create an identifier for him to avoid their potential access to the private key, which stays with Bob.
Bob's phone connected to the Government Network API, and registered the ‘did’ onto a blockchain along with its public key, as well as an end-point, which is a way for the university to find Bob for further communication (or a software proxy - more on that later). The public blockchain now becomes a place where anyone (or any device) can look up the public key for Bob from just his identifier. This look up process we call 'discovery'.
When two parties want an encrypted information exchange, their software supplies the other with their identifiers, which is then used to look up the public keys. If not already connected, the initiating party the contact also looks up the end-point for the other. The app on each side encrypts their communication with the public key of the other party, which only the other party can encrypt with their private key (kept on their local device). This allows what we call encrypted 'peer-to-peer' communication without middlemen.
If Bob already created a DID on a different platform, perhaps at a pilot program at the DMV. There is no need to create a new one - The Government Network works with what is called ‘universal discovery’. The W3C standard schemas for DID's' include a code that says which blockchain the identifier is ‘anchored’ to. However, for the sake of the article, let continue with a brand-new identity.
A couple seconds after clicking the 'create new identity', Bob’s phone reports back that his identity has been created, and asks if he would like to add some more information. He elects to add his name, birthdate, a couple email addresses, and his gender. There are several important points we should be aware of:
- None of this information is stored on the blockchain.
- These are ‘self-claims’, no one has validated that what Bob says is true.
Why is the information not stored on the blockchain?
First, to store this information, on the blockchain would fail GDPR requirements, even if encrypted, because a blockchain is immutable. If someone gained Bob’s private key and made it public, the information would be available to anyone, forever, which is against GDPR regulations and is a significant security concern. Bob does not have the ability to tell the blockchain to forget his information, which is also against GDPR requirements, and finally, it is possible that in the future private keys could be reverse engineered.
Where is it stored and How?
The solution is to store it off-chain in a private ledger, simultaneously making also make the identity blockchain itself faster and more scalable. The private ledger could exist only on Bob’s phone, however this could prove to be an inconvenience when Bob loses his phone, or wants to use different device. The Government Network is an agency that Bob can elect to use to store the private ledger on his behalf allowing it to be used by several devices.
Because of interoperability standards being applied, another agency could also be used. An agency cannot see the specific encrypted information being stored. At any time, Bob can remove his ledger from being stored by the government network, and /or move it to another agency of his choosing through an automated process. This is not just a customer convenience, but a requirement of the GDPR regulations, to ensure that an individual actually does own their identity information. It also gives a way for Bob to remove all of his personal information, should he desire to do so.
The end-point associated with the DID typically points to an online service (also called an agent), such as the Government Network. The service acts as a proxy and connects to other relevant agents in a peer-to-peer relationship under the control of each party as to what information, or derivatives, can be shared. The service keeps all of Bob's identity information synched on his devices, as well as a backup if desired.
Built into the app are buttons to create verifiable claims for Bob's email addresses, and a button to ask the university to issue a ‘claim’ that Bob really is an enrolled student. Whenever any party connects to another party, the software first verifies that they are who they say they are through an encrypted exchange signed by each other’s private keys.
Email address verification is a service offered by The Government Network, who will then issue a claim of authenticity that becomes part of Bob's verified identity. No information is recorded on the blockchain revealing what the email addresses actually are, and the government network does not store the email addresses after the claim issuance is complete (or canceled).
Behind the scenes, a new pairwise identity relationship is established with The Government Network. The email verification service asks permission for each of Bob's unverified email addresses, which he supplies and approves. Bob then receives two emails for each address, a number of hours apart (as a security precaution). He clicks the verification link on each email, after which he receives the claims in his app. It is important to note the the claims are not finalized until Bob accepts them, keeping with the principal that he is in control of all aspects of his identity.
There are a couple options as to how the claim issuance process to verify that Bob is a university student could be implemented. One way is that Bob would have to go to a counter, show his face, along with some documents, which would satisfy the university, upon which they would issue the claim. Another approach, is that the university already knows Bob’s email address, which can allow the process to be fully online and automated. In this case, the university elected the second approach, knowing that they have an easy recourse to revoke a claim if needed.
The University is a Trusted Claim Issuer.
Part of the process of becoming a claim issuer is that the university has published onto the blockchain a ‘schema’ for each type of claim they will issue. The schema defines what type of information is involved with the claim, for example: the students name, student id, social security number, birth date, country of birth, date of enrollment, and if currently enrolled. Anyone can look up this schema and determine what type of atomic information they may want to request from the identity holder who processes such a claim. To make the process more universal, commonly used schemas are being developed for specific use cases, such as a university student claim. These can be extended to include additional custom information.
Part of the GDPR requirements is that only the necessary amount of information may be requested from an identity holder, so for example the only thing a retailer selling discounted products to students needs to know is if the buyer is a currently enrolled student. In this case a request for information will only be a yes/no answer to the question (what is called a predicate proof) and not all of the information in the claim.
The university software service and Bob’s software service start an automated peer to peer validation that they both are-who-they-say they-are. Next the university software service needs Bob to supply a verified email address that is the same as what they have on record. The request shows in his app within a second or two. Bob's app arranges the proof, and Bob approves it. If Bob did not first complete the email verification process, he does so, before clicking the accept button. To make things less chatty, Bob could enable local permissions on his side to automatically grant requests from the university for certain types of information, which is logged in his ledger should he want to view it in the future.
Now that the university is satisfied that this really is the one and only Bob, it issues the claim, which Bob then accepts.
Behind the scenes, his software verifies that the claim came from the university. A receipt of this transaction, containing what type of information, not the information itself that was shared between each party is stored in the private ledger of each. A hash of this is stored on the identity blockchain which can prove permission was granted to use the information shared by each party. No one else can make any sense of it, yet the hash of the document being stored on the blockchain, combined with the receipt privately stored is a legal proof of permission.
Because Bob's name is also in the claim issued by the university, he can use this attribute within the claim to verify his name for anyone who wants to know. A verifiable claim, particularly if issued by an authority that is trusted by many people is much stronger than a self claim. Bob may add additional verifiable claims issued by other parties, for example for his driving license. Most people would consider a proof issued by such an authority as a stronger claim, and this would be given priority in a proof.
Building these relationships is what we call the web of trust. The whole process of defining claim schemas, issuing them, and validating them can be done by anyone; that is it is not under centralized control. Furthermore, the verification process does not involve contacting the issuing authority. Rather, a check is done on the blockchain to make sure the claim has not been revoked. Again, the blockchain does not store the actual claim, rather it anchors the public keys to verify signing, and if the claim is revoked, this is also stored via an identifier.
If this was not the case, then identity correlations could be built up resulting in a leaking of privacy. As an example, if a claim from the university is used to validate your age, the university itself does not know of this usage.
Through a web of trust, the validity of claim issuers is built upon, and while a name can be faked, an identifier cannot because of the immutable nature of the blockchain and its trust mechanisms. This allows a way for people to build up an identity from scratch, such as a refugee, while also allowing a quick entrance from claims issued by trusted authorities such as a driving license issuer.
Either party can revoke a claim at any time. Bob might become a rebel and assert that his association with the university was a past mistake, in which case it is within his right to remove the claim of association from his identity. Likewise, Bob may have graduated with honors, and the university revokes his standing as a currently enrolled student, however grants him a new claim of his accomplishment.
Bob, now a fan of self-sovereign identities, and seeing this is the way of the future, decides to create a claim schema for his future wife, and attests that she is the best in the world, which she accepts and hopefully neither party ever revokes.
Alice in her enthusiasm, hinted that he should vote for her student identity platform to become accepted throughout the schools many facilities and departments. Bob goes to the correct page of the university’s website, sees a QR code on the proposal, scans it, confirms a button on his phone, and checks ‘Yes’ on his vote.
Behind the scenes the petition-vote is using a service offered by The Goverment Network to ensure anonymity and uniqueness. To guarantee that Bob is not signing the petition from multiple identity relationships he created, the service request permission from Bob for his student ID to store while the petition remains open. Also requested is his gender, and years of enrollment with a promise not to store these The service first hashes his student is, and then checks that Bob has not already signed using the student ID. If he has, then he is politely informed that not allowed to sign a second time.
This service ensures anonymity from the university. The result is immediately recorded on a governance blockchain optimized for these kind of potential high bandwidth transactions, along with pseudo-anonymous information such as gender and number of years enrolled for statistical analyses later. A hashed proxy reference is also recorded, and Bob receives a receipt with this proxy reference combined with his approval of the request for his student ID (not the ID itself). No one else can decipher who a particular vote is referenced to, other than it is legit and backed by verifiable open code that the service uses. If Bob keeps his receipt, he can elect to show it as proof should he ever want to.
There are several ways and options for voting, petition, and polling services that can be implemented depending on the requirements and level of privacy needed.
The university has a way to ensure that Bob only voted once, where the vote remains anonymous. Bob can view the validity of the vote on an immutable blockchain. And with that we have a happy ending.
Michael V Khalsa