The Interledger Community 🌱: Juan Caballero

SourceCheck — Final Grant Report for Imprimatur Project

Juan Caballero — Wed, 19 May 2021 06:23:42 +0000

SourceCheck — Grant Report for Imprimatur Project

Project Update

Our project involved a lot of unexpected complexities and surprise limitations to the frameworks and tooling we stitched together, but we're proud to have released an end-to-end prototype covering all the areas we set out to cover, and all of it open-source and reusable by the greater community.

We've got a live demo here but note that you will need a Credible wallet to log in (explained below). You can email us for an APK file or build your own using the build instructions here.

Progress on objectives

Our objectives, ranked by importance, with an explanation of our results:

✅✅Embed authenticity and royalty-transparency in a long-lived, portable, vendor-agnostic Verifiable Credential
- 👍 Our prototype used a simple JSON-LD schema to express only the most basic authenticity statement (SourceCheck witnessed this publisher signing this exact version of this work) and a simplified royalty statement on the "honor system"
- 🧠 We look forward to modeling more granular or interoperable authenticity statements and royalty obligations in the standards community over the life of this project
- 👎 In principle, the VCs our prototype generates could be stored in a standards-conformant SSI wallet, represented elsewhere, consumed elsewhere... but testing this principle and experimenting with issuing these credentials to the end-user's Credible wallet had to be descoped in the interest of time!
✅✅Embed this verifiable credential in a tamperproof "repackaged" PDF enabling WMS payment endpoints and triggers
- 👍 Our prototype includes a custom PDF reader that checks for the VC mentioned above and, if detected and its signatures verified, reads the WMS endpoint and passes it to the browser's enabled WMS extension to pay for the content it contains.
- 💪 THIS IS HUGE: a decentralized and end-to-end verifiable identity/provenance mechanism to vouchsafe WMS relationships! Forget Know Your Customer (KYC)-- this is Know Your Content Creator (KYCC)😎
- 🧠 The PDF viewer is a little idiosyncratic but we're proud of the DevOps gymnastics it took to render it server-side. This work might be a reusable or inspirational starting point for many other PDF-WMS projects, so we put it in a separate github repo. The functionality can be previewed here (requires authenticated session).
- 👎 We were dismayed at the complexity of PDFs' existing data model, tamperproofing and signing mechanism, and layering-- fully integrating VCs into the PDF with existing tooling would take 10X the budget and time frame of this grant. We are applying to European Open Source grants to continue the work and reimplement it in a more production-grade, PDF-native way, machine-code, bare metal, warts and all!
✅✅Incorporate SSI "under the hood" in signup flow and backend so that publishers can seamlessly "sign" their content with a Decentralized Identifier (even if they don't know what that is)
- 👍 Our prototype used Spruce's DIDKit to handle all the signing and SSI logistics on the issuer/verifier end; close reading of our repo will show that we install it via the NPM package manager for node.js. As for the publisher interface, we used the Strapi framework for a readymade backend, and inherited its user account model.
- 💪 Our extension of Strapi requires an SSI wallet to sign up for an account-- and in the process, stores the DID controlled by said wallet discretely in the metadata of that account. This way, all future sign-ins are password-free, and all publication events are automatically signed by "confirmation" on the wallet app; sneaky stuff!
- 🧠 We pick all our tools and dependencies carefully, and we think Strapi will get more use in coming years. Hopefully open-sourcing our SSI-Strapi integration is useful to future developers, so we also made a separate github repo for that code, as well as a dockerized container of the whole back-end.
- 👎 We were dismayed at the complexity of PDFs' existing data model, tamperproofing and signing mechanism, and layering-- fully integrating VCs into the PDF with existing tooling would take 10X the budget and time frame of this grant. We are applying to European Open Source grants to continue the work and reimplement it in a more production-grade, PDF-native way, machine-code, bare metal, warts and all!
✅❎Support multiple SSI wallets
- 👍 Our prototype integrated the Credible mobile wallet by Spruce, which our research led us to believe was the most standards-conformant and interchangeable with other wallets that follow the W3C standards closely. We feel we have an upgrade path to add support to future wallets, so if you want to work with us to support your wallet, reach out!
- 👎 It was a huge lift incorporating one mobile wallet into our authentication flow and signing flow and incorporating SSI on the backend-- we simply ran out of time to incorporate an alternate mobile app, or for that matter, even Spruce's web-extension version of Credible. We would love to have focused more on SSI in this project, but the space is still young, with all the documentation-gaps and testing burdens that entails.
- 🚀 We were very involved with the standardization process of SSI wallets across the W3C-CCG and DIF, where we invite all interested parties to come participate and move the needle forward!
✅❎Support multiple payment rails - WMS + some other direct-payment alternative
- 👍 WMS works as documented and expected! We hope more infrastructural players will enter the market and offer more variations to experiment with and grow the range of guarantees and business models.
- 👎 We had to scale back our ambitions on enabling other forms of direct payment-- for now.
- 🚀 Our ambition after delivering this prototype is returning to the original idea of "honor system" payments rather than WMS-powered "low paywalls". Given recent developments in the identity-proofing and NFT markets, it seems that the Rebase Protocol that Spruce has been experimenting with in the NFT space could be very useful for low-fee direct microdonations, and we look forward to contributing to the nascent standardization of Rebase in the W3C.

Key activities

Perhaps we bit off more than we could chew, but we spent about 1/3 of our budgeted technical time on research, planning, and design, and 2/3 working up until the very last minute on the prototype, including open-sourcing and documenting it all to be not just intelligible and perusable but reusable and composable.

Communications and marketing

We actually chose to defer much of our marketing efforts until after a prototype was developed (i.e., in the coming month or two), and we will be using the bulk of that portion of our budget to document what we've done rather than do conventional marketing for our future publishing platform.

What’s next?

All of the marketing and business time we allocated ended up being used for feasibility of next steps, which mostly hinge on finding grants or infrastructure partners to extend these contexts to their payment and/or identity and/or publication infrastructures. As for payment infrastructures, we are most interested in returning to the original "honor box" content of providing various kinds of provenance and identity assurance to direct donations and [voluntary, post facto] micropayments from content consumer to content creator via direct cryptocurrency or fiat channels. We are pausing our WMS research until there is more competition between wallet and infrastructure providers and more optionality around revenue-sharing, but continuing to advance the verifiable revenue-sharing transparency mechanism we prototyped in this project in the meantime.

If you represent a payment, identity, wallet, or publication infrastructure provider who wants to reach out about grant or partnership opportunities, please contact juan at sourcecheck dot org directly.

What community support would benefit your project?

It might sound trite, but bug reports and feature reports can be just as useful as pull requests and code donations! Feedback on the prototype is warmly welcome.

Relevant links/resources (optional

Main prototype repo (GitHub)
High-level Architecture overview (on WMS Grant for the Web blog)
More detailed technical Architecture overview
Project changelog (includes short- and medium-term feature roadmap/wishlist-- PRs accepted!)

Progress Report from Team SourceCheck.org

Juan Caballero — Fri, 26 Feb 2021 18:20:07 +0000

Our project was very technologically ambitious, and we bit off a lot stitching together various open-source solutions to create a kind of publishing "platform" with WMS and SSI capabilities. Architecting and planning took considerable research and experimentation, but we committed to a plan 1Jan and are more than halfway to a working end-to-end prototype. What follows below is a detailed overview of the architecture we landed on, which might be overkill for non-technical readers.

API / Backend Server

To build a full-featured content API would beyond of the scope of this project; our goal instead was to identify the best open-source components that could be combined to meet all our functional requirements:

REST API to be consumed by client app
Content type customization to support our specific needs
Content ownership and ACL to allow simultaneous utilization of the app by different publishers
Extensible through plugin architecture to support authentication using SSI (more on that bellow)

We chose Strapi as our base for the backend development and have been finding it quite straightforward and full-featured.

UI / Front End app

The front-end of this platform will be of utmost importance in launching this project as a hosted platform some day, but for now, in the spirit of the GftW grant, we are trying to prototype a minimum viable project, maximizing for reusable open-source functionality. As such, we are focusing first on the main goal of our intended future front-end is to allow publishers to upload their publications as PDF files, define royalty structures for each piece of content, and digitally sign both in a portable, binding way: verifiable credentials. These can be downloaded by publishers as receipts, are embedded in the final PDF publication, and can be consumed and processed by customized PDF readers. Our front-end currently includes one such custom PDF reader, but our modular architecture allows upgrading or swapping out any given element.

Our frontend requirements for now are:

Server Side Rendering (SSR): custom metadata for each page to allow content-level web monetization hooks and, some day, content-level royalty structures for monetization
Single Page Application functionality whenever possible
Convenience of modern web application libraries and frameworks
Possibility to render PDFs without allowing download and printing, to allow for a "WMS Paywall" in-browser without having to establish a direct payment or subscription.

We have decided to develop the frontend app using Next.js.

As "stretch goals", more likely to be addressed after the grant period, we want to support multiple payment systems and publication channels for these signed, authenticated publications. Some day, we want to make these royalty schemes codified in the publications consumable by payment systems to allow micropayments and/or automated/smart-contract payments.

Authentication and Infrastructure for portable signatures

The main feature of our project is to add a provenance layer to the publications in a both machine-readable and human-readable way; in other words, encoding into each publication verifiable information about who who created the content and who published it. This is a deep-rooted problem in all web publication, but it is also a structural problem particularly felt in the web monetization community, where fraud is a real concern and disputed originality could even open the door to liability action for lost income! We also consider our work a "down payment" on the long-term goal of not just transparent but verifiable distribution of direct payments between the various parties contributing to content. While most WM use-cases focus on small-scale productions and individual creators, we see real potential for bringing WM to non-profit newsrooms, chapbook presses, academic journals, and many other places where large teams of creators and collaborators do collective, rather than individual, work. These contexts require a more complex licensing and payment model than simple direct payments!

We have advocated for the maximally standards-driven, open-source implementation we could find of Self-Sovereign Identity technology as the infrastructure for handling the these identities and high-value signatures. We are using a backend library called DIDkit and the mobile wallet Credible, both developed by Spruce Systems (USA).

The user can sign up for an "account" with our app using the identity wallet rather than a username/password, and they receive a verifiable credential as "receipt" after confirming her/his email and login to the application using a so-called "verifiable presentation" (i.e., a proof of possession of unique credential). In addition to authenticating with this app, content and royalty structures are both signed with cryptographic material stored securely in the app (in most cases, in the phone's OS-layer keystore). We have developed a Strapi plugin that handles SSI authentication in the backend and integrates with Strapi's built-in ACL system. This plug-in also renders QR codes in the frontend to be scanned by the identity wallet. The triangular synchronisation between the backend, the frontend, and the wallet is achieved using Socket.io

Current status

At time of writing, we have most the the architectural components developed and integrated. The user interface is still very much in progress and requires some improvements to be feature complete as a prototype. We still need to implement the code that will embed provenance data into the PDF files, and decide on/design a prototype-grade schema for storing the authorship information and royalties in the document. Our plan after the grant is to refine this schema in alignment with ongoing digital content provenance structures such as the Adobe-led Content Authenticity Initiative and/or the Open Content Certification Protocol (OCCP)(https://posth.me/occp/).

Imprimatur (SourceCheck.org)

Juan Caballero — Wed, 02 Dec 2020 11:34:25 +0000

We are prototyping a lightweight e-publication system that cryptographically binds each secure publication to its provenance and payment information. An electronic book, a magazine, or a comic can be published in a secure digital form (essentially, a "fancy PDF") containing information about its authorship and authenticity, and optionally also information about revenue-shares or other royalty or non-profit commitments. The “self-sovereign” identifiers used to literally and figuratively “sign” the works can be public or private or somewhere in between, at the discretion of the parties involved. These options include various kinds of notarization, indexing, and discovery methods for different kinds of publications (including Rebase networks and traditional DOI databases). The resulting publications can be sold conventionally or “previewed” using a WMS plug-in, offering a third option between paywalls and completely free access.