Product Focus

Key Differentiator: NextCert offers customers the most flexible certificates issuance solution and it achieves this flexibility by being product-focused with a strong underlying architectural framework.

NextID has competitors in the local market which are service-focused. They rebuilt their solution for each new customer requirement. This is not scalable. Right from the beginning, NextID has focused on creating a great product known as NextCert™, the world's must trusted and flexible certificate issuance service.

NextCert is comprised of 3 core modules: Issuer, Viewer and Verifier. Each of these shares some features in common, such as a certificate renderer. The renderer is responsible for display of certificates, in much the same manner as Acrobat and other products render a PDF document.

Certificate Rendering

There are two ways in which the display of certificates can be invoked:

• pass by reference (PBR) - this is used when someone clicks on a link to view a certificate and the link contains a certificate id (the reference) used to lookup and then retrieve the certificate data

• pass by object (PBO) - this is used when the Issuer or Verifier displays a certificate; since it already has the certificate (the object), it does not need to perform any lookup

This is what a certificate link looks like: https://certificates.nextid.com/certificate?id=1131eca9-6b39-4de5-b74a-cf9831eaf289 The behavior of this URL is to open a NextCert Viewer and display the requested certificate. By adding another parameter which is an application key, a requester can obtain the certificate data without invoking any display.

At present, the lookup is trivial. From the URL we already know which server instance is hosting the certificate. We simply form a database query using the id parameter to retrieve the certificate data. But suppose our certificates were hosted in a decentralized file system such as the Interplanetary File System (IPFS)? To cater for just this situation, we plan to move the lookup functionality into a standalone service which would function similarly to a URL shortener like Tinyurl or Bitly. So think of lookup as a separate back-end service we use to handle link (and QR code) requests.

Certificate Layering

We talk about certificates as if they were a single document. In fact there are three layers which come together in each certificate:

• Schema - This is the underlying data structure coded in JSON LD. Each business use case requires different types of data to be reflected in the certificate. The data fields, whether they are required or can be null and the enumeration of allowed values are defined in the schema.

• Layout - This is the visual presentation coded in HTML and CSS, which defines what is shown when a certificate is displayed in a browser. The layout supports handle-bar tags for the placement of dynamic data on the certificate. Of course the renderer takes care of performing substitution of dynamic data. Layout is the same for all certificates in a batch.

• Data - This is the instance data which is coded in JSON. The data is unique for each certificate and it is machine readable, which makes verification possible. The document structure follows the W3C Verifiable Credentials data format. The storage location of the schema and the layout are defined in each certificate, which ties together the three layers.