Wink

Most digital identity systems only weakly link identifiers to the actual identity of users. They fail to provide the levels of assurance needed for full digital identity management because the identification and the user are not tightly coupled. For instance, a credit card number may be linked to one individual, but others can still use it to make credit card purchases — with or without permission. The owner of the card can deny responsibility for the transaction, but not stop the transaction itself. Unauthorized use of a credit card is thus a problem both for the owner of the card (due to unwanted purchases) and to merchants (because of the risk of a chargeback). This situation would be much less likely to happen if, for example, the user of a credit card had to scan his or her iris to make a purchase using it.

In addition to providing a stronger link to identity, a biometrics-based identity blockchain also has the potential to connect people in different countries. Nations use different identification methods — such as the Social Security number in the US — and not everyone even has an identification number. However, everyone has biometric data, and they are the same in every country.

Furthermore, the purpose of user verification is to specify another party, not to hold personally identifiable information. Blockchain technology serves this purpose by providing an objective history of identity verification. Once a claim is stored on a blockchain, you use the blockchain repetitively as a substitute of identifiable information. For example, suppose Joe Smith is given the identifier X1Z874 on the blockchain. Identification is only concerned with ensuring that every transaction using ID X1Z874 refers to the same person (Joe Smith). His name doesn’t need to be used, thereby ensuring secure identity without violating privacy.

In this proposal, I will describe how private keys can be generated securely from biometric data, how the private key can be used on a blockchain to store verification information, and the general economics of the blockchain.

Indesigning this blockchain, my objective was to strongly connect the actual identity of a user to his digital identity. One inherent limitation of a blockchain is that its usefulness is subject to that of the information placed upon it. For example, if a verifier claims that a user is a US citizen, a blockchain can store that claim objectively, but the claim itself may or may not be accurate. As a result, the blockchain is only as good as the subjective claims it contains. The goal was to design a blockchain providing a useful objective history of subjective claims.

Identity is among the most sensitive of data, so it is essential that leaks be prevented. Accordingly, I propose to use private keys that can be regenerated on an as-needed basis. I suggest using an algorithm that generates a string deterministically using biometric data as the key.

In the proposed system, a private key is generated from a combination of user biometric data and the secret key of the biometric scanner used. The intent is to demonstrate the ownership of a certain device and biometric data with the private key and strongly link the private key with an actual identity.

Verification history is stored on a blockchain and points to a verifier that can hold the raw data that was used for the verification. Verifiers could contain personally identifiable information (PII) and many types of objects, including verifiable claims for a given identity (e.g., proof of age). PII should never be stored publicly in a form anyone can read.

There are three main participants in an identification service, each of which has a different objective in transactions that the service enables. The first is a requestor who wants to verify a certain individual’s identity sufficiently and accurately. The identification level required by a requestor differs depending on the purpose. The second party is a user whose identity is being verified. A user wants to prove his identity as easily as possible while maintaining as much privacy as possible. And finally, the third participant is a verifier, who assesses the user and confirms the identity of the individual. A verifier needs to maintain credibility while making verification as simple as possible.

Identification is a subjective claim of a verifier made based on the information provided by a user. Therefore, the claim is only as valuable as the credibility of the claimer. While a blockchain can hold the history of claims objectively, the value of the history is limited by the value of the claims.

Most importantly, a requestor needs to know if a certain user is strongly linked to his or her address. For example, a Bitcoin account is shareable by giving the account’s secret key to another person. A user may link his actual identity strongly to his blockchain account by using a biometric scanning device that generates a secret key only when it is given a biometric reading by the user. The security and accuracy of the device will correlate to the trustworthiness of the user. If a user uses a device that is generally not accepted by requestors, his blockchain account will be useless. Therefore, it is in the user’s interest to use the currently most recognized biometrics scanning device. A device manufacturer will need to maintain competitiveness by continuously developing devices that improve in terms of accuracy, security, and cost.

Once a user is using a device acceptable to a counterparty, the counterparty may request more verification. The user will need to get verified by a verifier. More requestors will accept certain verifiers’ claims if they are more credible, and more users will use the verifier if the verification step is easier and safer. Since verifiers are rewarded for each verification they provide, it is in their interest to maintain their credibility and improve usability to increase earnings.

The verification history is stored on the network as an encrypted message indicating when a user was verified, for what, and by whom. A user can then reuse this verification history later for other transactions. For example, verification may say: “John got his nationality as a US citizen verified last Tuesday by US border control using his scanned copy of a passport.” A user can provide a password to decrypt the history for a requestor. If the verifier of a verification history is credible, and the history is recent enough, a requestor may accept the history as a substitute for a new verification, reducing effort and safeguarding the privacy of the user.

Please refer to Wink whitepaper for details.