Searching for (a Digital) Identity

How far can a Blockchain identity system go without a cryptographic challenge?

To continue the inspection of University of Melbourne's Bitcoin Blockchain identity system, let me recap an article of mine from a year ago. 3 type of identity on Blockchain To save readers time, I summarise here the 3 types of identity systems:

Type I - Proof of Existence: "There exists a Janina Lowisz, the proof is on the Blockchain." (She is the ambassador of the world citizen project which I referred to in the former article, so I'll continue using the example here.)

Type II - Authentication: "She is Janina Lowisz, and she can prove it to you by answering your cryptographic challenge, which is verifiable with Blockchain evidence."

Type III - Authorisation: "She can prove 3 things. First, there is a person named Janina Lowisz, by referring to the proof on the Blockchain. Second, she is indeed the said Janina Lowisz, by that she was able to answer your cryptographic challenge. Third, she is authorised to enter this building, by producing the building's manager's signature on her Blockchain evidence, which was given to her previously. In fact, she just did all three in one go by swiping her card. Now, let her pass." Digital signature and prevention of double-spending are higher level functions that I won't indulge here.

In my previous post, I mentioned that the University of Melbourne project didn't use Merkle tree, which is but a small missing feature. This time I will address a serious issue: it is a Type I system.

Type I Blockchain identity system was the status quo of 2016. However, in any commercial production environment, usually a type II or type III is required. Borrowing the example from that article, a passport system would be a Type II, a VISA being Type III. The production environment of border policing requires Type III.

As of 2017, it's reasonable to expect new identity solutions to be at least type II.

A type I system requires the 2nd piece of evidence outside of the system. For example:
"There exists a Janina Lowisz, a Master of Science." must be combined with the following evidence: a driver licence which says Janina Lowisz (identity token), held by her (physical ownership of the said token). And that is the case with Melbourne University's Blockchain student record system.

Type I systems can't prevent cases like Shyam Acharya. He practiced as a doctor in New South Wales, not more than 10km from my house, for more than a decade, using someone else's identity ("There exists a Janina Lowisz..."). He was caught in the last months and was found assuming the identity of another real doctor, whose name I respectfully do not mention.

The key symbole on the upper right cornor is likely a hash of a public key. If it is the intended design, before the expiration she should be able to answer challenge with its corrisponding private key.

To cheat Type I system, some people do not even need to go that far to assume the identity of someone else as Shyam did - they only need to have a common name. Every James Smith can claim a degree in any university and find enough evidence to support his claim, and they are many - there are 38,313 of them in the U.S. alone.

To upgrade from Type I to Type II, two things must happen:
1. The identity owner must have a key.
2. The validator must challenge him or her.

Is the technical partner of the University of Melbourne project, blockcert, too lame to throw this one-two punch? Apparently not. Proving of ownership was discussed publicly on their forum, and the software authors expressed interest to fix this. I hope they do it soon, but it didn't answer the question why such feature should be added, instead of having it built-in to begin with. Type I systems have already been built, there is no reason to experiment the same thing again.

In 2016, there is a new trend among banks to test various Blockchain technologies. Such tests are done many times, often only to proof points which are well known in the Blockchain community. I recall a publicly published experiment report which stated that after a costly experimentation they have learned Ethereum is a Blockchain system where each participating node has the full copy of transactions including those irrelevant (not initiated on that node). One can acquire such knowledge by only reading Ethereum whitepaper. Many "consultants" earned their reputation and income by summarising that whitepaper and claim them to be newly discovered experimental results.

Can we blame blockcert for taking advantage of the ignorance of its customers and bill for an improvement item, when it ought to be done at the outset? Probably not, because there is another reason for inaction: how do we physically allow a cryptographic challenge to happen?
In my following posts, I will provide an overview of how such cryptographic challenge can be implemented, but in short, QR code is the best way to go. It is already the standard in the Bitcoin world, but only a few well-informed people know that it is also the standard practice of many Chinese well known services. If you visit taobao.com, Alipay, or WeChat's online version, such popular Chinese online websites often offer two ways to log in. Scan a QR code on your mobile or type-in password.

Is it possible?

Scanning QR code to login has become so common in China, that my aged parents never remembered their WeChat password. It works because their key is stored on their WeChat and Alipay apps. Passwords is optional even if the user loses his phone. When my mother replaced her phone, WeChat replaced the key by a protocol which requires user's friends to assert her identity collaboratively. (Alipay users still can't enjoy that feature.)
But this common use case has not successfully extended to the west.

Now that QR code can't be used, what about NFC? In Australia, both Mastercard and VISA use NFC for cryptographic challenges, using the key embedded in the credit cards. VISA's implementation is buggy and got cracked by renowned Australian security expert Peter Fillmore. However, NFC remains viable, if correctly implemented it is an effective method. It can be wired up with Blockchain.

But it suffers from a considerable disadvantage - it can't work remotely, and that renders it impractical over the Internet.

That being said, even if blockcert have a type II or type III system in mind, there isn't a readily accepted user interface for it to adopt.
Unless we're talking about the Chinese market.