Skip to main content

· 2 min read
Wayne Wee

We recently released support for revocation of DID signed documents through an Online Certificate Status Protocol (OCSP) responder which would allow for the revocation of documents without the need to deploy a document store. Prior to this release, revocation of documents was only possible through the deployment of a document store which is costly.

The solution works by first deploying an API where an administrator can insert or remove entries from a database containing a list of revoked certificate identifiers. Then, when creating a raw document, the revocation type must be specified as OCSP_RESPONDER and location as the url of the API. When this document is submitted for verification, a query is sent to the online responder and an additional check is conducted to find out if a document has been revoked or not.

OCSP

The ADR containing our exploration of possible solutions to the problem of costly revocation and our proposed implementation can be found here.

We also released a reference implementation of the OCSP responder using AWS Serverless. You may refer here for a guide on its implementation.

We also added a section in our documentation website under Verfiable Document > DID > Revoking Documents (OCSP) with steps on how to create a OCSP-revokable document.

This solution requires minimally:

· 2 min read
Laurent Maillet

We added support for penpal v5 in decentralized-renderer-react-components v3.5.0. You can check the changes in the pull request.

For many months, our library was stuck using Penpal v4 due to a lack of compatibility between Penapl v4 and Penpal v5. To make it short, it's not possible to have a verifier using Penpal v4 with a renderer using Penpal v5, and vice-versa.

This version doesn't bring new interfaces or new options. As an integrator, the new version is unnoticeable, but it's important to note what's going on under the hood.

  • FrameConnector (the main component used by verifiers to connect to a renderer) tries to establish a connection using both Penpal v4 and Penpal v5 in parallel. It means the verifiers will support both Penpal v4 and v5. Unless you know exactly which renderer your verifier will call, verifiers must keep backward compatibility with renderer using Penpal v4.
  • FramedDocumentRenderer (the main component to establish a connection with a verifier) will always use Penpal v5. It's safer this way to directly decide to move on with a specific version of Penpal because it's easier to know which version you will need to establish the connection (as a user, you have more control). In any case, if you need your renderer to keep using Penpal v4, feel free to downgrade or to fork our library.