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.