Re: using PDFs as a VC container...

Very interesting, Kostas!   Thanks for sharing.

I went to the repos below to see what you’ve done.  I peeked inside the PDFs and saw how you are storing data – while it works, it is definitely not a good approach.    What I didn’t see though is the actual source code for the hashing and embedding – because I am curious about the order of operations of those two operations since you couldn’t modify after hashing – yet that is what I see happening…

Thanks,
Leonard

From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Tuesday, October 20, 2020 at 11:42 AM
To: Credentials Community Group <public-credentials@w3.org>
Subject: using PDFs as a VC container...
Resent-From: <public-credentials@w3.org>
Resent-Date: Tuesday, October 20, 2020 at 11:40 AM


Hi all!

I would like to introduce the work that I have been involved with. I have been following the list/group for a while now and want to try to find the time to be more active   ... that, plus Leonard's presentation was a great opportunity/introduction :-)

TL;DR:
We have been using PDFs as a credentials' container and anchoring the document hashes on the blockchain. A blockchain proof (chainpointv2) is added in the PDF metadata which results in self-contained and self-verifiable PDF documents; the PDF is the only thing needed to view the credential and validate the credential*. There are open source validators that are trivial to use and/or host.

The longer version:
The University of Nicosia has been anchoring/issuing credentials (PDFs) for some of their courses on the Bitcoin blockchain since 2014. Back then the process was more manual/adhoc. In 2016 the solution was re-designed to (more or less) what we have today:

- several PDFs are hashed and merklized, merkle root is anchored in the blockchain (bitcoin is used but it is blockchain agnostic)
- merkle proofs, txid, etc. are stored in the respective PDF's metadata (using json format)
- PDFs can be disseminated/stored as they always were

Several companies already use PDFs so our solution fits into their workflows seamlessly. They had PDFs, they are anchored, and they still have PDFs**.

A meta-protocol was designed to encode the data stored in the blockchain in a way that allows on-chain issuing/validation and revocation of the credentials. The process is described in detail in: https://ieeexplore.ieee.org/document/8525400<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F8525400&data=04%7C01%7Clrosenth%40adobe.com%7C7bac216c99e241cfb83908d8750ec893%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388053646203751%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z835TZT9tqjvrveLAI0UywICCi1bNJ49NWQdvWufzTo%3D&reserved=0>
(I can share if requested... not sure if the above is accessible to all)

An open source implementation (with tools) can be found at: https://github.com/verifiable-pdfs/blockchain-certificates<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fverifiable-pdfs%2Fblockchain-certificates&data=04%7C01%7Clrosenth%40adobe.com%7C7bac216c99e241cfb83908d8750ec893%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388053646213710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rm%2Fukk81ADRmZOqJYQActSkZs6ATu4nvje9JRZr9lUE%3D&reserved=0>
Validators at: https://github.com/verifiable-pdfs/validator-widget<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fverifiable-pdfs%2Fvalidator-widget&data=04%7C01%7Clrosenth%40adobe.com%7C7bac216c99e241cfb83908d8750ec893%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388053646213710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=x1DpaWSspDEZ%2F7ACreYThYBclv%2FNkEpUBrfiFN%2BZfiE%3D&reserved=0>  and  https://github.com/verifiable-pdfs/blockchain-certificates-validation<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fverifiable-pdfs%2Fblockchain-certificates-validation&data=04%7C01%7Clrosenth%40adobe.com%7C7bac216c99e241cfb83908d8750ec893%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388053646223667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CSwWSh44Lfu3IKDkJPgVGDA2vFly%2FwfBOEXc2aDbTt4%3D&reserved=0>

From 2017 all of the credentials and diplomas issued by the University are issued using this platform. From 2019 the solution was commercialized (Block.co) to make it easier for potential clients (abstracting blockchain infrastructure, etc.). Several more clients/use cases came up rather than only educational credentials.

We have looked into this in the past but it was frozen. Now we are again in the process of preparing/designing for VC-compatibility. We already use json format so using the VC format would be straight-forward in itself.

However, I seem to be missing some parts, like how to formally define revocation mechanisms or how to formally include the blockchain proof. Is there a place where we can define our issuing / revocation mechanism so it can be reused/interoperable?

Also it would be of great interest to see how we can properly use XMP that Leonard mentioned in a more standardized way in our solution.

I would be happy to discuss further with anyone interested and thank you all for your time reading this.

Regards,
Kostas

* Not unlike VCs other than the fact that the 'presentation'-layer is the verifiable container itself.
** The solution can apply to any file that supports custom metadata.

--
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkkarasavvas&data=04%7C01%7Clrosenth%40adobe.com%7C7bac216c99e241cfb83908d8750ec893%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388053646233621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hD0ZgPP6KqtDQiQrJoS9koQ9DtY%2BR4DPUwI5M47tf98%3D&reserved=0>