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 
.
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: add import validater by bonn1112 · Pull Request #24 · blockchain-certificates/cert-schema · GitHub.
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:
- 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.
- 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.
- 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.