Response to Blockchain & Blockcerts Critiques from Privacy Researcher


#1

A few days ago, I presented about the Blockcerts open standard at the Blockchain in Education conference in Groningen, The Netherlands. One of the conference attendees, Dr. Jaap-Henk Hoekman, a privacy researcher at Radboud University Nijmegen, wrote a blog post in which he presented several criticisms of blockchain technologies in general and the Blockcerts open standard specifically. These criticisms reflect some misunderstandings, so I thought I’d take a minute to respond to them individually.

  1. In his post, Dr. Hoekman invokes a Learning Machine keynote presentation in which I mentioned that the issuer software we have built generates analytics about credential sharing and verification. He writes, “one of the keynotes suggested that also uses, i.e. verifications, of credentials could be logged on the blockchain.” From his perspective, this represents a “privacy nightmare.”

That is a misunderstanding. The Learning Machine software tracks shares and verifications of certificates so that issuers can see analytics about how the credentials they have issued are being used. However, none of these events are logged on a blockchain, and these analytics are for internal issuer use only. They are a policy-making and alumni-relations tool for institutions, which already know when individuals request credential verification from them, but are unable to visualize this data in a user-friendly way.

  1. Dr. Hoekman also writes that “blockchain adds a middleman” because “Creating credentials (and perhaps even using them) is modelled as a transaction for which a significant fee needs to be paid.”

While it’s true that there are fees associated with writing transactions to a blockchain, these fees are actually quite small, especially when compared with the costs of printing paper records. Of course, any electronic records management system will also cost money, whether it’s built in-house or licensed from a software vendor. That is in part why the Blockcerts standard is free and open source: so any University can build their own applications for issuing credentials to the blockchain right now without licensing anything from a vendor. They would pay only for employee time and labor, as well as the small mining fees that it costs to log any transaction on a blockchain network.

Also, the implication that using credentials issued as Blockcerts costs money is incorrect. As the Learning Machine presentations noted, the Blockcerts Wallet (available for iOS and Android) is completely free for recipients, and verification operations are all free and vendor- and issuer-independent as well. Today, many issuing institutions and software vendors charge money for people to receive, access, and verify their records. Blockcerts does away with these fees. The issuing institution can, of course, decide that they want to continue to charge recipients. But that is a decision up to the issuing institution, not Blockcerts or Learning Machine.

  1. Dr. Hoekman believes that Attribute-Based Credentials (ABC’s) are a better solution for anchoring data than blockchains. He writes, “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.”

That’s fine, but you then have to trust the issuer (a centralized authority) to maintain an accurate record of all of their transaction hashes–and to be around as long as people need to verify them. If the issuer ever disappears, loses their records, or falsifies transaction order, verification will fail or be inaccurate. The beauty of blockchains is that the chain of hashes is decided by distributed consensus, so human error, mistrust, and deception cannot interfere with the integrity of the ledger. This mechanism also allows the blockchain ledger to outlast issuing institutions, providing verifiability even if the issuer no longer maintains their records.

  1. Dr. Hoekman describes some advantages for ABC’s which he believes Blockcerts do not possess, like recipient ownership and selective disclosure of data.

The advantages Dr. Hoekman describes for ABC’s are advantages of Blockcerts as well. Blockcerts are also stored (and owned!) directly by the individual, and data minimization (selective disclosure) can be built into the standard using Merkle trees. See the Blockcerts FAQ.

  1. Dr. Hoekman also describes what he calls a “semantic problem” with blockchains: “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?” He then responds: “This seems hard to solve using technology. Blockchains do not help here.”

This is right. The social meaning of a credential is not a problem blockchains were designed to solve, and therefore cannot be considered a “problem with blockchains.” All blockchains do is ensure the integrity of a transaction. What the document content means is a social question that requires human discretion. You can read Learning Machine’s essay on the differences between social and technology standards here.

  1. Dr. Hoekman’s last criticism of blockchains regards the difficulty of proving the identities of the parties to a transaction. He writes, “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.”

The Blockcerts Wallet will solve this problem. Its private key can be used to countersign any Blockcert (say, a diploma or an ID) to prove that I am who I say I am and that I own the document being presented. See the last question in the Blockcerts FAQ.

Moreover, the Blockcerts approach to identity is platform-agnostic; Blockcerts can be integrated with any identity solution, allowing software vendors and issuing institutions maximum flexibility with how they link transactions to social and digital identities.

I hope this response provided some helpful clarifications. We welcome further questions and comments about the Blockcerts open standard and blockchain technologies in general at the Blockcerts Community Forum.


#2

It’s interesting that he focuses on blockchain for identity management, which Blockcerts doesn’t even do.

However, DIDs, which can improve the ability of individuals to own/control their identity, will feature blockchain-based method specs. If Dr. Jaap-Henk Hoekman sees your response, I hope he also checks out the DID spec.


#3

Great discussion.

I’m there during the presentation of Blockcerts and it was very clear for me: scope, proposition and design.

This a clear example on how hard is explain scope of blockchain-based solution with a etereogenous audience.

Blockchain need to be cooked before serving :slight_smile:


#4

I really appreciate dr. Smolenski’s extensive response to my blog post. Please allow me to reply to the issues she raises, and argue why I still believe the use of blockchain in identity management is (mostly) ridiculous.

  1. First let me apologise for misunderstanding how the tracking of credential verifications work, by assuming that they would be logged on the blockchain. However, if

“Learning Machine software tracks shares and verifications of certificates so that issuers can see analytics about how the credentials they have issued are being used”

this still creates a privacy nightmare that any reasonably privacy friendly credential system (like attribute based credentials) aims to avoid. I strongly believe that the issuer of a credential has no business knowing how and when its credentials are being used. A property nicely provided by the classic, paper based, credentials by the way.

  1. My argument that the “blockchain adds a middleman” is not only based on the observation that a significant fee needs to be paid for adding the credential to the blockchain, but also on the observation that the same blockchain is an essential part in the verification process. (I did not in any way imply that using credentials issues as Blockcerts would cost money.) As I explain in detail in my blog post, this means this blockchain must remain in active use.
    To be fair, Dr. Smolenski pointed this out during her presentation at the symposium, but dismissed any concerns about this based on a strong belief that Bitcoin (and its blockchain) is here to stay. Let’s just say I’m more sceptical about that.

  2. I do not believe that “Attribute-Based Credentials (ABC’s) are a better solution for anchoring data than blockchains”. I believe ABCs have superior privacy and availability properties over Blockcerts. This makes them the preferred way to implement self-sovereign identity.

I offered an alternative, local, implementation of the only real functionality offered by Blockcerts (namely the ability to record the order in which credentials were issued so an adversary cannot backdate credentials if he obtains the issuer’s private key). To be honest, I do not believe this backdating problem to be a serious problem in practice, as the current standard response is to revoke all credentials ever issued under the compromised key. Having a proper signing key hierarchy, with a strongly protected root key which is long lived and which signs short lived keys that sign the actual credentials, ensures that the number of credentials to revoke in this case is small.

  1. Blockcerts do not have the same advantages that ABCs have. Blockcerts are linkable. ABCs are unlinkable. And selective disclosure (in the context of ABCs) means that the owner of a single ABC can decide to reveal only a subset of the attributes in that single credential. This is something different than the ability to select a subset of full credentials to show. For ‘ordinary’ credentials this distinction is merely semantic (one could just 'issue credentials that contain a single attribute), but for unlinkable credentials (like ABCs) selective disclosure is an important property. If credentials are unlinkable it actually requires a bit more work to prove that two different credentials belong to the same person, which is necessary to prove statements like “I am Dutch and have a CS degree” that contain more than one attribute. Selective disclosure makes this process more efficient.

  2. I am happy to see we at least agree on the “semantic” problem with credentials (not blockchains).

  3. Credential binding is a hard problem that is not solved with the Blockcerts wallet (just as it is not solved for ABCs by having them stored on a smartcard or in a ABC Wallet on a smartphone). The problem is that whoever controls the smartcard or smartphone controls the credentials stored within them. Additional protection with say a PIN code does not work, as this PIN code can be observed or even given away (in cases where the credential owner is happy to share his or her credentials with a friend). This is in no way a critique of Blockcerts. It’s a general problem, caused by the fact that the interface between the physical and virtual world is weak, unclear, and therefore hard to secure.

P.S.: My last name is spelled Hoepman. But this is a mistake even many fellow Dutch people make :wink:


#5

Dr. Hoepman,

Thank you for this dialogue. I believe the best part of airing these concerns publicly is that is allows everyone to reach greater clarity and attempt to clarify misunderstandings. After, reading your blog post and answers here, it sounds like everyone’s values are very much aligned. Let me respond to a few themes for the sake of clarity:

Linking and Analytics
Blockcerts allows for a wide variety of configuration. Many issuers believe they co-own the credentials they issue, and also want to provide them in a convenient format. This results in issuers hosting the credential, so that it can be more conveniently shared via URL. Note that this does not define Blockcerts, as they don’t need to be hosted. The standard simply allows for it and provides a web-viewer for consistent rendering. That viewer can potentially send analytics back to the issuer, as do all other credentialing solutions. But if the file is shared directly or printed out, no analytics can be retrieved.

Blockchain Longevity
Blockcerts is intended to write to many blockchains, as the principle of decentralized storage is more durable than having a single point of failure. Schools close all the time and few are able to survive the conditions of war. See Smolenski’s post about the Syrian refugee crisis. In addition to the inherent promise of decentralization, the Bitcoin Blockchain has an impressive track record of never being hacked for the last 10 years. This is a promising start for a durable infrastructure. How long is long enough?

It sounds like Blockcerts can be configured to operate just like your ABC credentials. It’s important to remember that Blockcerts is not a product, or a single way of doing things, but rather a standard that aims to facilitate various approaches in an interoperable way.


#6

First and foremost, I want to thank Jaap-Henk Hoepman for his wonderful presentation and blog article, and I want to thank Nathalie Smolenski for clarifying some misconceptions about Blockcerts.

It is absolutely wonderful to have such clear, detailed, open and public discussion :slight_smile: .


a) Clarification about ‘phone wallets’

I know this is only tangential to the point you were making in your response post, but I wanted to reply to it. Also because this came up during your presentation but I did not want to press it then, for fear of diverging the Q/A-session:

I’d like to point out that a mobile wallet that incorporates a Blockchain is only ever a ‘lite wallet’ , which means that trust needs to be placed in intermediaries, as downloading and maintaining a Blockchain on your phone itself is both an intensive time and space consuming operation (measured in hours and gigabytes).

Then there is also the fact that your own Blockcerts Private Key is part of this application, and as you mentioned in your talk, this is stored unencrypted on the device; you’ll only need to enter your passphrase during key generation.
Phones are inherently insecure:

  • because of their software stack (which focuses on ease-of-use over security),
  • because of people’s lack of understanding or willingness to secure their phone properly (For example, many people use a swipe-shape password, which I can instantly remember and reproduce when shoulder-surfing),
  • and because they are a lot easier to physically steal or get hold of in a social engineering attack.

So I think that this is a design decision that seriously needs to be reconsidered.


b) About tracking the usage of credentials

I wholeheartedly agree with this. Thus I like the ‘open standard’ aspect of Blockcerts, but not the peripheral analytical service you want to provide as LearnMachines.
Of course, this is a personal opinion and nothing is stopping anyone from creating a system that scrapes websites to look for references to certain data snippets you can understand, regardless of what I think about it.


c) About storing only hashes

If I remember correctly, one of the core ideas of Blockcerts was to make sure your certificates would not be lost when you lose all your possesions (as long as you still remember the passphrase to re-generate you private key). However, since the only thing that Blockcerts stores are 1-way hashes of your certificates, you’ll still have a problem unless you’ve taken extra measures to back up (digital versions of) your certificates somewhere. A hash cannot prove something by and of itself, it misses the entropy to do so.


d) About reliable timestamping: You really don’t need a Blockchain for this

One point that Natalie Smolenski fails to address, is the fact that a hash-chain (providing reliable timestamping) can be stored without problems on any other decentralized datastore. It is perfectly possible to build such a system on top of e.g. Kademlia.

In fact, one of the main uses of a Distributed Hash Table right now, BitTorrent, uses it in exactly this way: The DHT is used to exchange what IP-addresses are currently online and providing a certain file, and the DHT-key of the most up-to-date information is propagated through the network between all already-connected parties.

If people would like, I could to write out a crude Kademlia-based scenario to show how it could be used to propagate certificate-hash-chains.

This would also allow revocation information to be passed around inside the peer-to-peer network. Right now, it seems (according to my interpretation of the information here; I found it not very clear) that Blockcert’s revocation mechanism looks for a list provided at the specified URI in JSON-format. Furthermore, it is stated that ‘The Blockcerts schema allows other implementations of revocation, depending on the implementations allowed by the blockchain, and domain/issuer appropriateness.’, which means that this is an area that is explicitly not standardized, which feels like a missed opportunity because it will lead to mismatches between software of issuers and validators, resulting either in errors or in nobody actually bothering with using any other implementations than using a call over HTTP.
Calls over HTTP are a very bad approach for this, because h stops working when the issuer goes offline! Also, nothing prevents the issuer from altering the list of revocations based on who requested the verification!

[EDIT]: it seems that discussion is already going on about this: https://github.com/blockchain-certificates/cert-schema/issues/24.
Interesting is that Blockcerts v1 had an approach where revocation was part of the blockchain, and that the main reason that it was moved out was to solve the ‘UXTO bloat concern’. It seems this change was thus made because of a chosen technical solution (a Blockchain), rather than because it would fit the problem domain better.
[/end of edit]


So, to summarize:

  1. A service like Blockcerts does not need a Blockchain to perform timestamping. Therefore, it does not need a blockchain at all. I would urge you to consider alternatives.
  2. Storing just hashes means that you can still lose your certificates. Therefore, as Jaap Henk Hoepman pointed out, the only advantage that Blockcerts gives over the current situation is making it harder to issue (and/or backdate) fake certificates. Using a different decentralized datastore where space is cheaper would allow you to store an encrypted version of the certificate (or at least its computer-readable representation) as a whole.
  3. Please reconsider your approach to storing private keys on phones.

The current version of Blockcerts is somewhat attractive for issuing organizations (But this has nothing to do with the use of the Blockchain!).
However, it is not attractive at all for the individual since it does not change the situation for them (loss of phone = loss of certificates).

I certainly believe that having a digital standard for certificate issuing is a great step forward. I do not think that the current version of Blockcerts is the correct approach, however.


#7

This is an extremely interesting conversation. I was at Groningen as well and I thought Natalie’s presentation was very well delivered. I also picked up on some of the aspects noted by Dr Hoepman and have followed this thread closely.

From a privacy/correlation perspective, I think it is useful to compare how people use a printed paper degree qualification with a Blockcerts-designed digital version. Once I have my paper qualification, I can use it anywhere I want and the issuer has no idea to whom I am proving my qualifications (nor should they). Just because is it possible to track usage with a digital version doesn’t mean you should do so.

An alternative approach is not to register proof of the qualification on a ledger, but instead to give it to the recipient as a digitally signed verifiable claim. The individual attributes in the verifiable claim will be signed by private keys of the issuer, the public keys of which are stored on a ledger in a fashion that ensures the verifier is always able to confirm that the key being used is the current one (chronological ordering required) and is in control of the issuer (immutability required).

I’m glad to see that Blockcerts is participating in the W3C Verifiable Claims taskforce and also the W3C Decentralised Identifier group (full disclosure, my company Evernym wrote the Decentralised Identifier (DID) spec) as these two standards form the basis for a more privacy respecting solution.

Using a combination of DIDs and Verifiable Claims, many of the privacy issues highlighted by Dr Hoepman can be neatly resolved. Additionally, DIDs can enable verification of who issued the claim, to whom it was issued, and that it is unchanged, without requiring any link back to the issuer. It is also possible to separate revocation checking from the issuer as well by utilising a ledger-held cryptographic accumulator-based revocation registry.

This enables total separation of the issuer and the verifier/relying party preventing undesirable correlation/linking/tracking.

Add in the ability to do selective disclosure and even zero-knowledge proofs, and things get even better, especially if standardised and open source.

I am encouraged to see Blockcerts are looking at other ledgers at the moment. I haven’t seen mention of Sovrin which is understandable as it is relatively new - I’ll chat to Natalie about that next week. Those interested particularly in privacy aspects may want to take a look at this “What Goes On The Ledger” white paper.

I wholeheartedly concur that having a standard for digital qualifications is highly desirable and commend the work done to date.


#8

I’ve also done the analysis and agree with you that there is still a misconception of what blockcerts actually solves. In essence, I like to describe it as getting rid of an invisible fourth party (certificate authority) that is actually different from the issuing authority. PKI never really solved this problem, although they claim they do.


#9

Thank you for the thorough response Dr. Hoepman. I appreciate the time you’ve taken to review what we’ve published.

I’d like to start with a partial response, starting with privacy concerns, and I’ll add more responses as I get time through the day. Forgive the heavy footnoting/linking, but this will allow me to be more precise.

We are in the process of evolving the next generation schema as a Verifiable Claim, allowing us to more seamlessly integrate with this ecosystem. Claims can be bundled as attributes on an Identity Profile, which is closer to the model you describe.

Associated Linked Data Signature Suites are critical to the privacy and security aspects, including the following in-progress suites:

In general, there is strong alignment between Blockcerts and W3C Verifiable Claims and Credentials Community Groups (I am co-chair of the latter), and many of the hard problems you’ve raised are ones we’re attempting to tackle in the Credentials CG as part of our work items. One of these – Data Minimization and Selective Disclosure – we expect to start in earnest at this coming Rebooting Web of Trust. As an unsolicited sales pitch, it would be great to have your involvement, either as part of RWoT or the Credentials CG in general. We are fortunate to have security and privacy researchers in that group, but we would appreciate more.

Thank you again. More later,
Kim


#10

Thank you so much for your thoughtful feedback. I do have to start by clearing up an important misstatement

Please note: the above claim is incorrect. The mnemonic phrase is stored encrypted on the device in its secure storage

That out of the way, here are some more responses I hope clarify the design and approach.

The Blockcerts wallet uses the key generation components of a hierarchic deterministic/mnemonic code wallet, responsible for key generation and certificate storage. The wallet never needs to talk to a blockchain except for one optional feature, which is the in-app verification feature. This talks to blockchain APIs for the recipient’s convenience, but there are many ways to export the Blockcert and verify externally. In fact, it is assumed verifiers would verify independently.

This is a “yes and”. This is important for users to be aware of. Realistically, mobile phones are being relied on for storing secure information, and in the developing world, it is sometimes the only option. I think your argument can be redirected into leaning into approaches to make the phone a more secure platform.

For example, uPort’s use of phone (and ethereum blockchain) to enable decentralized identity management.

We encourage recipients to make backups of their certificates. The wallet has an export feature to make this easier. Additionally, storage in IPFS is an option.

The problem is availability; it requires infrastructure to support this. Ours and other efforts are relying on blockchain as a utility, where the cost of issuing is small relative to maintaining this infrastructure.

Another project taking a similar approach (for the same reasons) is b_verify being developed at MIT’s DCI.

A separate note on revocation: Our current version uses the Open Badges standard of https hosted revocation lists, but this can be extended into an on-chain approach. We are prototyping some on-chain revocation approaches; some design notes are in the ‘revocation’ repo; but it’s very preliminary.

Thank you again for taking a close look; I look forward to continuing the discussion.

Best,
Kim


#11

A quick thank you to all participants in this discussion, just reading and trying to understand, learning a lot :slight_smile: