Hi Justin,
Sorry for the delay – this post just came to my attention today. These are great questions, and we wanted to give you a quick answer, so @downie and I worked together to write up detailed responses. Please let us know if we missed any parts of your questions; these are excellent discussion points.
Checking the issuing organization during verification (now and roadmap)
If checking the issuing organization is solely (I might be wrong) based on checking the input address of a transaction and matching it with the address specified on the Blockchain certificate, how does it stop someone from creating a transaction later in time, creating a Blockchain certificate, and claiming that the transaction and the issuing address belong to a specific organization? (MIT for example?). As an employer I wouldn’t be able to figure out due to Bitcoin’s anonymity.
The premise (first sentence) isn’t correct; here’s how it works. The input address of the transaction is cross-checked against the issuer’s URL identifier, which is embedded in the certificate. This is step 1 of the Linked Data Signatures Signature Verification Algorithm (section 7.2):
7.2 Signature Verification Algorithm
Step 1: Get the public key by dereferencing its URL identifier in the signature node of the default graph of signed document. Confirm that the linked data document that describes the public key specifies its owner and that its owner’s URL identifier can be dereferenced to reveal a bi-directional link back to the key. Ensure that the key’s owner is a trusted entity before proceeding to the next step.
Note that, at face value, this presents centralization, availability, and longevity concerns (what if the issuer site is temporarily or permanently unavailable?) First let me unpack these, and provide context about how this will be addressed. (Later we’ll explore threats such as a compromised issuer site.)
Relying on an issuer-hosted URL puts a burden on the issuer to ensure this identifier page is available. Failing to do so compromises the certificate’s longevity. This is an issue we raise in our documentation, and we strongly advise issuers to use permanent URLs, but this is only a very short term mitigation. We describe this for example in this post.
The next phase in our roadmap replaces this form of identification with Decentralized Identifiers (DIDs), which address not only the availability concern, but also our concerns more broadly about the issuer as a SPOF and centralization point. See the DID Specification draft and the DID primer for a friendlier introduction.
Note that the group behind JSON-LD signature suites is the same one that’s drafting the DID specification, and this exact scenario is one of many DIDs are meant to address. That group is the W3C Credentials CG (Kim is co-chair).
Also note: many DID method specifications rely on a blockchain, and expanding on the longevity concerns, we are thinking through scenarios such as blockchains becoming obsolete (which can actually be mitigated through cross-chain transactions).
Detecting fraudulent issuances
But this also means that the insider can also create an authentic document, which is basically game over.
This is actually an argument for public blockchains; as any transactions against a known set of keys you are monitoring are immediately evident. Address monitoring makes it easier to detect an insider issuing a fraudulent certificate.
Verification and Trust
No one needs to store the hash
If you trust the institution, how is storing the hash of the certificate in the institution’s database, and comparing it with the hash of the uploaded document any less secure?
It’s not stored in the institution’s database, or anywhere. JSON-LD signatures and verification avoid the need to store the hash separately. Both signing and verification canonicalize the document (minus the signature) to ensure a consistent hash. Any attempts to tamper with the content will cause it to fail validation. See the RDF Dataset Normalization standard for details.
Combining the hash with the merkle proof (in the signature section) results in a merkle root which is compared against the value in the blockchain transaction record. This is the JSON-LD signature suite called Merkle Proof Signature Suite 2017,
Who do I need to trust to perform verification?
The short answer is you don’t need to trust anyone, and it’s expected that high-stakes verifiers will use a more hardened approach than used in lightweight demonstration verifiers.
The details break down into 2 aspects: where the verifier service is running and how blockchain transaction lookups are performed (for the certificate hash and, soon, DID record).
Looking up Blockchain transactions
As mentioned in cert-verifier-js README, relying on a blockchain API enables client-side transaction lookup and is a useful way to demonstrate Blockcerts verification without intensive hardware/deployment requirements.
But using a blockchain transaction lookup service is effectively putting trust into that service, but that service could be compromised in a number of ways.
The most secure approach is to run a blockchain node and look up the transaction directly. This requires machine resources that may not be feasible in all deployments. In between there are options such as lightweight verifying nodes. At minimum, an approach that rules out some attack vectors is to check multiple services to see if they agree (as enabled by cert-verfier-js).
Where the service runs
This is similar to the above (blockchain tx lookup) range of options. The simplest way to run the verification service is also the least secure – that is to the cert-web-component with in-browser verification. In a world of trustworthy people, this is by far the most convenient way to display and verify certificates. In the eye of a hacker, it’s trivial to alter/inject code to verify false documents.
However, the verifier service does not have to run in-browser. The most secure option is to run the verification service in an isolated network environment (with access to the local blockchain node, as described above).
I think we hit everything. Please let us know if you have any questions.
Thanks,
Kim and @downie