Re: using PDFs as a VC container...

On Wed, Oct 21, 2020 at 2:00 AM Kostas Karasavvas <kkarasavvas@gmail.com>
wrote:

> 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?
>

Yes, you should describe your revocation mechanism in a spec, so that
people can implement it themselves, otherwise it's just another vendor
specific revocation system, I'd recommend doing so in the W3C CCG or some
other IPR protected space, so that other companies can safely contribute
and assist.


>
>> 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"?
>

meaning you can generate the PDF with the VC or DID Private Keys => print
it, scan it, print it, scan it => recover VC and DID Private Keys
(essentially treating the PDF like any other image of a QR Code).

This leaves off the potential advantages of using the PDF digital format
though, so it's probably not a perfect solution for all use cases.


>
>
>> 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?
>

The problem with QR Codes is the maximum size... so either the VC is small,
or you must use the QR Code and a network connection, or multiple QR Codes
to work around the maxsize.


>
>
>> 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
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>