W3C home > Mailing lists > Public > public-credentials@w3.org > November 2020

Re: using PDFs as a VC container...

From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Mon, 2 Nov 2020 10:46:30 +0200
Message-ID: <CABE6yHt6jKBta2Yjv+Vsche3BAem96M8Ff18p_hOvH=+F_PTXw@mail.gmail.com>
To: Kim Hamilton <kimdhamilton@gmail.com>
Cc: Maarten Boender <mboender@sphereon.com>, Leonard Rosenthol <lrosenth@adobe.com>, Credentials Community Group <public-credentials@w3.org>
Thank you Kim (and all that answered),

I have another meeting half an hour later so if we talk about this in the
beginning of the meeting I can make it.

Kostas


On Sun, Nov 1, 2020 at 8:57 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:

> Hi Kostas (and all),
> The instructions for proposing a CCG work item are here:
> https://w3c-ccg.github.io/propose_work_item.html
>
> If you're able to attend the VC-EDU meeting tomorrow, we can discuss
> possible scope, etc. Note that the US had its daylight savings shift, so
> tomorrow's meeting is 4pm GMT, 5pm CET. (As least we'll have a few months
> of stability...)
> https://www.timeanddate.com/worldclock/converter.html?iso=20201102T160000&p1=tz_pt&p2=tz_et&p3=tz_gmt&p4=tz_cet
>
> Thanks,
> Kim
>
> On Fri, Oct 23, 2020 at 2:17 PM Maarten Boender <mboender@sphereon.com>
> wrote:
>
>> Kostas, Leonard, & group,
>>
>>
>>
>> We’re happy and motivated to help.
>>
>>
>>
>> We have a background in document processing and working with PDFs. We
>> already have services/APIs that are already converting, stamping and
>> signing PDFs.
>>
>>
>>
>> And we’re building tech around DIDs, VCs, etc., for products and
>> projects, also in Education. This will be a good extension to have.
>>
>>
>>
>> Best Regards,
>>
>> Maarten Boender | Sphereon.com
>>
>> [image: signature_2086378322]
>>
>>
>>
>> *From: *Kostas Karasavvas <kkarasavvas@gmail.com>
>> *Date: *Wednesday, 21 October 2020 at 16:31
>> *To: *Leonard Rosenthol <lrosenth@adobe.com>
>> *Cc: *Credentials Community Group <public-credentials@w3.org>
>> *Subject: *Re: using PDFs as a VC container...
>> *Resent from: *<public-credentials@w3.org>
>> *Resent date: *Wednesday, 21 October 2020 at 16:30
>>
>>
>>
>>
>>
>> Thank you for the paper. That might allow anchoring PDF signed documents
>> as well. I will look into it in more detail !
>>
>>
>>
>> Wrt "a standard approach for where/how to embed the VCs in the PDFs".. is
>> there something initiated on that already?  What would the next step be?
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Oct 21, 2020 at 4:03 PM Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>> Thanks – that helps!
>>
>>
>>
>> The iText library that you are using is fully capable of manipulating XMP
>> and doing embedding and other techniques that I showed in my presentation.
>> I haven’t looked at the state of Python PDF libraries in a while so I don’t
>> know offhand which (if any) are XMP capable – though given that it has been
>> part of PDF for almost 20 years and is now mandated for PDF 2.0 – I would
>> hope they do!
>>
>>
>>
>> The approach you are using for hashing & verifying (with the post-hash
>> addition and then removal) won’t work long term.  It happens to work with
>> the tools that you are using – but it’s actually not a guarantee from a
>> file format perspective.   The standard approach for embedding a signature
>> into the thing you are signing (not just PDF but other formats) is a two
>> pass approach involving the use of a “hole” in the file.  This is how PDF
>> signatures have worked for 20+ years now.   Here is a good paper about it -
>> https://www.adobe.com/devnet-docs/etk_deprecated/tools/DigSig/Acrobat_DigitalSignatures_in_PDF.pdf
>>
>>
>>
>> And yes, I agree that we need to come up with a standard approach for
>> where/how to embed the VCs in the PDFs, how the signing & verification
>> process works, etc.   Looking forward to it.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Kostas Karasavvas <kkarasavvas@gmail.com>
>> *Date: *Wednesday, October 21, 2020 at 3:26 AM
>> *To: *Leonard Rosenthol <lrosenth@adobe.com>
>> *Cc: *Credentials Community Group <public-credentials@w3.org>
>> *Subject: *Re: using PDFs as a VC container...
>>
>>
>>
>> Hi Leonard and thank you for the comments!
>>
>>
>>
>> Please see inline.
>>
>>
>>
>> On Tue, Oct 20, 2020 at 9:13 PM Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>> 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.
>>
>>
>>
>> This is something that we would like to investigate further. Ideally, it
>> would be improved as part of the VC-compatibility update that we want.
>>
>>
>>
>> Your knowledge would be very helpful on this. What approach would you
>> recommend?
>>
>>
>>
>> And any python and JS libraries that can help insert/remove the metadata
>> with the recommend 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…
>>
>>
>>
>>
>>
>> Check
>> https://github.com/verifiable-pdfs/blockchain-certificates/blob/5159a38d320280ab46092ab56450028435aaf6cb/blockchain_certificates/issue_certificates.py#L78
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fverifiable-pdfs%2Fblockchain-certificates%2Fblob%2F5159a38d320280ab46092ab56450028435aaf6cb%2Fblockchain_certificates%2Fissue_certificates.py%23L78&data=04%7C01%7Clrosenth%40adobe.com%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093934005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QMluLJxeGvd0GYcNN4EUAg4cVLR%2FxalLm7G9rhvKsCM%3D&reserved=0>
>>
>>
>>
>> The documents are hashed and then their merkle root is constructed. The
>> proof is inserted into the PDF at the end. During validation the proof is
>> removed first, and then the document is hashed again to get the original
>> hash that was anchored into the blockchain.
>>
>>
>>
>> We had thought of several alternative approaches but this seemed to be
>> the best one.
>>
>>
>>
>> I see a lot of common ground. If it is of interest to you I would be
>> happy to discuss further or even collaborate on this if it makes sense.
>>
>>
>>
>> Thanks again for the feedback!
>>
>> Kostas
>>
>>
>>
>>
>>
>> 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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093944000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vh7Whif%2B5RCZq5AvEs5dmI68V2kFi8l%2F3M7ztZEBkOU%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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093944000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CWWrkf%2FMyjbsWgyg2bjs%2Bc9EzPZ7CuGfYbh0IcRukLk%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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093953999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hjPFeYBqaCj1UNpho%2B0WZxNrH3XfC%2FtVAlBPhtzuCrQ%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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093953999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cqq10SygqaGtlbk0kneOXujNmlc0eCZBWE2ZLcbB%2FXE%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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093963991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rZyucVKx%2FjqWxcKZZyU6F%2FrAHP0UpYyf7NdloVZs8p4%3D&reserved=0>
>>
>>
>>
>>
>>
>>
>> --
>>
>> 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%7C5c0d311ec8564d3ab9b808d87592ab9e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637388620093963991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rZyucVKx%2FjqWxcKZZyU6F%2FrAHP0UpYyf7NdloVZs8p4%3D&reserved=0>
>>
>>
>>
>>
>> --
>>
>> Konstantinos A. Karasavvas
>>
>> Software Architect, Blockchain Engineer, Researcher, Educator
>>
>> https://twitter.com/kkarasavvas
>>
>

-- 
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas

image001.png
(image/png attachment: image001.png)

Received on Monday, 2 November 2020 08:47:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 2 November 2020 08:47:01 UTC