Revised 2017/11/02 11:32AM PST to update title and clarify role of Open Badge baking
Blockcerts viewers, and how to customize
Blockcerts’ open source certificate viewers display certain fields by default – certificate title, description, image representing the accomplishment, etc. These fields are assumed to be in a certificate because they are required by Open Badges or Blockcerts schemas.
Clearly we want this display to be able to vary across devices; i.e. we want the certificate to look one way in a browser and another way in a mobile wallet. The Blockcerts viewers already do this, but the display elements are the same.
Issuers often want to customize how their certificates are displayed, and they can do that today by extending the open source Blockcerts libraries; in fact, cert-viewer makes it easy for an issuer to customize their display through Flask Themes. This is more work with a certificate wallet, but still doable since these are open source.
Additional certificate view options arise because the certificate field set is not fixed: Open Badges provides an extension mechanism (which Blockcerts uses itself) allowing the issuer to add custom fields (e.g. geographical information) to the certificate content. In fact, it’s expected that a given issuer will create different types of certificates depending on the accomplishment type, each of which may require a different set off custom fields. It’s also expected that the issuer will want these variations reflected in the views.
Badge baking to “freeze” a display
Open Badges has a standard way of preserving the issuer’s desired display through the process of “baking”, which embeds the certificate as metadata in an image file (png or svg). The Blockcerts issuer doesn’t bake badges by default, but it is supported through the obi-baking open source library.
There are a couple of problems with relying on this method, which can be addressed (as described later). For now, the relevant problem is – does this suffice for optimizing across different devices? Or if not, would it suffice to have different baked images for different form factors? If so, this is a much simpler solution, but still has a critical integrity factor that would need to be addressed. Let’s work up to that
Thinking beyond a single issuer
Customizing displays in the manner I describe above is easily doable if we focus on a single issuer, but the management and integrity of these custom displays presents complexities when we focus on the broader ecosystem.
A critical part of the Open Badge and Blockcerts ecosystem is the ability to accept/exchange/verify certificates, independent of the issuer/origin. This is supported and well understood from a certificate content perspective.
But focusing on display, how can issuers ensure their desired display is preserved in general? They can control the display in their own branded mobile wallet, certificate web sites, etc, but what does it look like in another Blockcerts viewer?
Another question arises: can a malicious party entice people to use a misleading certificate viewer for social engineering attacks? Maybe this party adds new fields to the display, removes others, so that the viewer in no way reflects the certificate content. During verification, we check the certificate content against the value on the blockchain, but how does a casual viewer know that what they see displayed accurately reflects the certificate content without looking at the full json certificate?
Revisiting the badge baking option, the baked image (content) isn’t part of the signed/hashed payload, so in theory it can be tampered with to show a misleading badge.
Important clarification for those inclined to skim
I skim a lot myself, so I want to make very clear:
Tampering with the certificate content would be caught during verification, and it would fail verification!
The questions raised here apply only to display of the certificate – specifically the human aspects raised in the next section.
Reducing these concerns to simple questions, requirements, and nice-to-haves
Question 1: how does an issuer ensure their design is preserved across viewers?
Question 2: how do we reduce social engineering attacks by helping humans know the view accurately represents the content? I.e. without forcing them to look at the fill certificate json
The answer is easy if the issuer fixes a display, and embeds it in the certificate. But let’s add some other desirable features:
- can be displayed on a variety of devices (mobile, browser, …)
- future-proof and flexible (i.e. not hard-coded to current technologies)
Some options that have been considered include:
- per above, embed a display template or image in the certificate
- problem: size of the certificate, especially if targeting different devices
- problem: possible longevity issues (e.g dated templating technique)
- baking badges, but including ensuring integrity of the display through signing, chained claims
- reference (as linked data) a display template in the certificate
- problem: this display template can be altered after issuance and that wouldn’t be detected during verification
- display certification: Open Badges already has a certification process to ensure an OB certified viewer is compliant.
- problem: in theory the view could be tampered with after certification
- problem: having a certification authority – even in display – is a centralization point we’d like to avoid - embed a hash of the “blessed” display artifact (template or binary hash)
- advantage: allows the integrity to be established and causes less size bloat
- problem: management of these external artifacts, i.e what if they disappear
- (punting the problem / wishful thinking) over time issuers converge on a well-known set of schemas and corresponding display templates
Note that we don’t necessarily need to meet all the constraints, i.e. it’s possible a single “blessed” view to be accessible from a wider set of device-specific views. This is a pattern with “see the original PDF” links embedded in web sites.
It’s important to start thinking through these display concerns to establish good patterns for issuers before it becomes a problem.
