Re: using PDFs as a VC container...

Thank you Orie for the feedback and comments! Also, thank you to everyone
that has sent me private messages, I will reply to all soon.

Please see comments below.

On Tue, Oct 20, 2020 at 6:52 PM Orie Steele <orie@transmute.industries>
wrote:

> This is awesome!
>
> Regarding revocation, see:
>
> - https://github.com/digitalbazaar/vc-revocation-list
> - https://w3c-ccg.github.io/vc-status-rl-2020/
>
> Here is an example, using did:web
> https://did.actor/#alice-didwebdidactoralice
>
>
Great stuff. I will look into https://w3c-ccg.github.io/vc-status-rl-2020/ in
more detail. I expected that revocationListCredential would be an array for
redundancy. Is there a reason why it isn't?

We currently do revocation on-chain so we'll need to investigate this
further. Maybe creating something similar to vc-status-rl-2020 that
captures our mechanism.

What is the process of creating such a document (e.g.
https://w3c-ccg.github.io/vc-status-rl-2020/). Is it supposed to be stored
somewhere globally (e.g. under the VC spec) so that people can easily find
them?


> I have experimented with generating DIDs and VCs as pdfs...
>
>
You mean placing the whole VC (json) as a QR code image in the PDF (visible
part)?  That is of interest to us as well.


> Using data matrix / compressed qr codes so they can also be converted back
> and forth to paper.
>

What do you mean with "converted back and forth to paper"?


> I've been waiting for CBOR-LD to mature, since the compression of VCs is
> one of the major limiting factors for QR Code based transports.
>
>
What is the minimum size that you would like to encode as a QR code?


> I imagine this would also help with storing the data in pdf files as well.
>
>
Indeed, it would.

Thank you again for your feedback!
Kostas





> Regards,
>
> OS
>
>
> On Tue, Oct 20, 2020 at 10:42 AM Kostas Karasavvas <kkarasavvas@gmail.com>
> wrote:
>
>>
>> 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
>> (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
>> Validators at: https://github.com/verifiable-pdfs/validator-widget  and
>> https://github.com/verifiable-pdfs/blockchain-certificates-validation
>>
>> 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
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>


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