One particular initiative mentioned several times was Blockcerts. Its stated goal: to allow people to issue credentials to the blockchain and to allow other people to verify such credentials. So that people own their own credentials, and have control over who they show them to. Also, the goal is to avoid single points of failure: once a credential is issued to you, you should always be able to prove its possession to others. (Actually, the *real* goal is totally different: to reduce credential fraud when credential issuers are compromised. See further below.)

All very laudable goals indeed. However, you don’t need a blockchain for that. In fact credentials can reliably be used without a blockchain. In fact, blockcerts introduces two problems: *lack of privacy*, and adding *dependency of (another) intermediary*.

All credentials managed through Blockcerts are public. To be clear: they are not stored on the blockchain directly, but a hash of them is (which binds the credential to its issuer and the time it was issued). The credential itself is signed by the issuer, which makes it authentic and binds it its owner. In itself this does not appear to create a big privacy problem, compared to standard PKI certificates. However, one of the keynotes suggested that also uses, i.e. verifications, of credentials could be logged on the blockchain. That information could subsequently be used to make e.g. policy decisions on employability: which academic credentials lead to the best employment opportunities? This is a privacy nightmare.

Moreover, the use of a blockchain adds a middleman, a party on which you (need to) rely for the continuous use of the credentials you own. Creating credentials (and perhaps even using them) is modelled as a transaction for which a significant fee needs to be paid. Moreover, what would happen to all credentials once issued to some blockchain, if that blockchain ceases to operate? The raw blockchain data is of course still available and maintains its blockchain structure. Yet the integrity-preserving features of the blockchain disappear as soon as it is no longer actively used.

To be clear, standard certificates in a public key infrastructure (PKI) suffer from many problems too. Those should be avoided as well. However, so called *attribute based credentials* (ABCs) have been invented some fifteen years ago to overcome these problems. ABCs offer self-sovereign identity management, with superior privacy and availability properties.

In essence, ABCs allows users to obtain credentials from issuers, that express that the owner of the credential has certain attributes. For example that they have a certain high school diploma, with the final grades obtained for the courses. Such a credential is issued by the school, as this is the (only!) institute that can vouch for the veracity of these attributes. Users store these credentials locally, and can make backups if desired. This guarantees availability.

Credentials can subsequently be used to prove possession of certain attributes to relying parties (employers, secondary stages of education). ABCs implement this in a privacy friendly manner, and implements *selective disclosure* which allows you to show the grade you obtained for science, while hiding the grade for math. Even better, ABCs implement *unlinkability*: the issuer does not see where the credential is used, and even a relying party will not be able to see whether a single user is using his or her credential many times with the same relying party. This guarantees a superior level of privacy, compared to the blockchain certificates of Blockcerts. For more information, see our work in this area.

So what made people think that a blockchain would be useful in the context of credentials? That’s revocation. Or rather: to prevent abuse of the credential infrastructure when an issuer is compromised. If the issuer private key, with which it signs its credentials, is stolen the adversary can sign credentials of its choosing and even backdate them, giving them a date before the issuer reported the compromise (and changed its key). When all credentials that are issued are also recorded on a blockchain, the order in which they were issued is fixed. In this case the adversary can no longer backdate credentials when it gets hold of the issuer private key. Provided everyone that verifies a credential checks the revocation status of the issuer key, and checks the blockchain to insure that the credential was indeed issued before the key was compromised. This works as advertised, but using a blockchain is overkill: you don’t need global consensus on the order in which *all* credentials of *all* issuers were issued. All you need is that each issuer keeps a list of all issued credentials in a *local* immutable record (using a simple hash-chain, for example) against which a verifier can check the status of a credential.

Anyway, the real problem of using credentials in education is semantic in nature. For example: what does a credential like “The Frysian University of Franeker certifies that John Doe successfully completed the master programme on Cow Management” actually mean? What guarantees does it give regarding the qualifications of John Doe? This seems hard to solve using technology. Blockchains do not help here.

Another, slightly related, problem is credential binding: how can I be sure that the John Doe standing in front of me is the same John Doe mentioned in the credential? This is a general problem in identity management, for which I have not seen any satisfactory solutions yet.

Thanks for sharing this valuable insight. I totally agree that blockchains will only make things harder. Unfortunately the blockchain evangelists seem to be adverse to any critical thinking. A striking example is the fact that the organizers of the conference where you gave this talk go full speed ahead with the following project (sorry for the non-Dutch speakers):

I agree that attribute-based credentials provide superior privacy properties. I considered the difficulties regarding revocation / revocation checks as the biggest obstacle for mainstream adoption. I was delighted when I discovered 5 minutes ago that you recently published a paper that solves this issue (I have not yet been able to read it though). This breakthrough makes it harder to argue why you should do id mgt with a blockchain.

Always good to have critical observations, really appreciated your blog. I agree that blockchain has no use in identity management (in it’s strict definition), but how do you view it in the light of identity attributes / self sovereigned identity ?
Sharing authentic attributes, in an immutable ledger, with consensus rules, over borders of organisations etc., creating some level of trust can’t be complete nonsense.

If you read my post carefully you’ll find that my point is that attribute based credentials by themselves provide a superior platform for self-sovereign identity (even across organisational borders, even though that’s indeed not mentioned explicitly in the post). The blockchain does not any trust at all. The trust is provided by the issuers and the trustworthiness of their processes for issuing credentials.

Hello! I gave the presentations on behalf of Learning Machine and Blockcerts at the Blockchain in Education conference in Groningen to which Dr. Hoemkan refers in this blog post. For those interested, I have written a response to Dr. Hoekman’s criticisms of blockchains and Blockcerts for the Blockcerts Community Forum:

But here are some more thoughts concerning the more interesting, philosophical parts of your blog article:

You state the question: What does a certain credential actually mean?

I think the correct answer to this is to rephrase the question to

What does a certain credential actually mean _to you_ ?
I think this should be observer-dependent.
Just like distinct employers place different value on varying snippets in a Curriculum Vitae.

Just like when I tell you you should absolutely listen to the wonderful Post-Rock band ‘God is an Astronaut’ you might not do it, but if a close friend said it, you would.
Or maybe you still wouldn’t, because you don’t like that kind of music at all.

In the end, a ‘credential’ is just a claim made by some party, just like anything else that we do not directly perceive ourselves in reality.

How these claims should be assessed really varies from situation to situation, and from context to context.

As such, I am relatively reluctant to see this particular field become automated. It is wonderful to give a semantic meaning to a credential so it becomes easier to (humanly!) _assess_ one.
But I do not think we would like a world in which some computer system somewhere has decided that something is not allowed, without anyone knowing why: We enter the territory of Kafka’s ‘Der Prozess’ right there.

—

As for knowing if the John Doe in front of you is the same one mentioned in the credential:

One can of course define the notion of ‘Perfect Forward Identity’ in which I can (dis)prove (in other words: authenticate) that you are the same person/entity I’ve seen before by performing an exchange of secrets only known to us two, once we have shared such a secret.

Of course, that notion is relatively worthless if you’re coming to me with a credential issued by some other party, because afore-mentioned procedure is unable to prove if the person standing in front of me is the same person that received the credential from the other party.

There is a weird roundabout way of proving this, but this would entail prior contact between issuer and (potential) Verifier:

1. Subject exchanges secrets with Issuer, therefore they are now mutually able to prove each other’s identity going forward.
2. Subject exchanges secrets with Verifier, therefore they are now mutually able to prove each other’s identity going forward.
3. Verifier exchanges secrets with Issuer, therefore they are now mutually able to prove each other’s identity going forward.
4. Verifier gives Issuer a query ‘q’, encrypted in such a way that Subject is able to decrypt it.
5. Subject asks Issuer to give out certificate.
5a. Issuer gives Subject the encrypted query ‘q’.
5b. Subject computes answer to query ‘q’, encrypts it with so that only Verifier can read it, and gives it back to Issuer.
5c. Issuer finishes making the certificate, and signs it.
6. Now, Verifier can check the validity of the answer to ‘q’.

Of course, in practice this is not very useful because it makes it impossible to add new verifiers without requiring re-creating certificates. Maybe it can be improved in some way.
—

As for the more physical answer: Does it matter if the man standing in front you is indeed John Doe? I’d be happy even if it were an impostor, as long as it has always been the impostor from the first time I met this person. In the end, I have social relationships with people, not with names.
And some people might call me naïve but I like to think that, speaking spiritually, once interaction becomes deep enough we connect with each-other’s souls, and not only with each-other’s socially constructed masks.

Thanks for your comments! Indeed, the interpretation of what a credential means depends on the interpreter. So yes, a better way would be to phrase the question as “What does a credential mean to you?”

Automated decision making on such credentials is indeed worrisome for this (and other reasons). I encourage anyone to read Cryptocurrency Might be a Path to Authoritarianism that Ian Bogost wrote in the Atlantic in May this year, to explore this line of reasoning further.

Regarding your last point: I am also a strong believer in TOFU (Trust On First Use). But that still does not solve the physical aspects of the credential binding problem. The cryptographic solution to ‘ensure’ that the person to which the credential was issued is the same person presenting the credential, is by binding the credential to a private key. The credential is issued to a particular private key (without disclosing that key; it stays securely within say a smart card of the owner) and that particular key is essential in the showing protocol of that credential. Compromise of that key breaks the binding. But that is also true for the complex protocol you describe.

It may be interesting to consider why the phenomenon ‘credential’ actually exists; at least this is where my train of thought brought me:

Without credentials, we’d live in a ‘zero knowledge’-kind of world. The only way to prove that you can do something, is by actually doing it. Usually, if you’ve done something in the very recent past (how recent ‘very recent’ is depends on the required task), this is a strong indication that you might be able to reproduce this in the near future. Of course, certain things might become suddenly (temporarily or permanently) impossible. Like writing, when you break your arm.
Also, certain kinds of things might look like skill, but actually only be sheer luck.

By creating a credential for such a skill, we are basically saying ‘the issuer of this credential knows from first-hand experience that this person was able to perform this skill at this set point in time’. But no, we can not issue credentials to persons, because of the identity/credential binding problem we’ve talked about before; they can be issued to cryptographic keys instead, but loss (or compromise) of these keys makes this system break down.

It might be interesting to note that ‘being able to enter the correct password to decrypt/sign this information’ is in itself a skill. (Which one could create another certificate for. Although at least at a glance, this feels relatively useless, because it is easy to demonstrate it directly. ^^’).

—

What would solve the identity/credential binding problem, is if there existed something like an ‘inverse passphrase’, in which not knowing it would give you access, because this makes it impossible to steal. But of course, since withholding information is something that both humans and networking computers can always do, such a concept might very well only exist theoretically.

The reason you want to use a Hashchain is to prevent backdating, but if the institution has full control over all the data they can easily manipulate it to still backdate certs? How does a Hashchain prevent corruption in the case of compromise?

What you’re describing is a permissioned chain with a Proof of Authority consensus algorithm. I encourage you to take a look at things like Kovan network, secret store from Parity or keep.network. There are many implementations of this, where someone like a certificate authority gets to issue new certificates on a chain and assign permissions to end-users to use the certificates to whatever arbitrary rules you set up (like the ones in your post).

“there is no consensus mechanism needed”

Consensus is about answering “how do I know this is the right hash?” and your answer was “the right one is the one published in NYT”, thus you have consensus as long as NYT publishes things correctly. That is by definition your consensus mechanism and without it you can’t guarantee that backdating won’t happen.

I still don’t believe there is any difference between a hashchain and a blockchain. A hashchain sounds like it’s a blockchain with one item in the block. Feel free to enlighten me if you have a better definition.