Re: using PDFs as a VC container... A cross-border trade perspective

Hi Kostas (and the CCG team),

This is interesting.

We are currently doing pilots and about to go live here in Australia with
digitally verifiable documents for cross border trade.  Initially
certificates of origin but very soon many other document types. We
currently use the Singapore Government Open Attestation protocol V2.  Like
you, they plan to make their V3 W3C VC compliant so we'll use that when
it's ready.  We currently issue both an open attestation file (read native
VC) and also a PDF with a QR link to a verifier that can show the user the
original notarised document and signed metadata.  It all works fine and the
PDF/QR is very important because, as you point out, so many processes in
cross border trade depend on humans looking at bits of paper.  Without a
verifiable PDF as a seamless transition from "original" paper docs to fully
digital native VCs there's really no practical way to jump the chasm.
However one issue with the Open attestation model is that the PDF is
embedded as an attachment into the OA json file rather than the other way
around (ie the credential embedded into the PDF).  This means that, if
there are a mix of human verifiers (who scan QR codes and look at results)
and machine verifiers (who read the open attestation) then both the PDF and
the OA need to be passed along the supply chain. I can foresee problems
with that because many intermediaries will not know what the oa.json is for
and will just attach the pdf. Of course we could just put the QR URL as
metadata into the PDF (and probably will short term) but that does leave
the possibility that a fake (wrong data) pdf includes a link to a real
(right data) OA.  The machine will read the OA and will most likely not try
to parse the PDF to verify it's the same as the retrieved OA.

which is a long way of saying - can we pull together, under W3C VC
governance, some kind of working group to look at blending your work from
university of nicosia with W3C VC and Singapore OA with a view to making a
protocol for "PDF as a wallet" or something similar?

It's probably worth mentioning a few things about cross border trade that
impose some key requirements on VCs that are not the same as the typical
issuer -> holder -> multiple verifiers model.  The Singapore OA model
addresses these issues very well which is why we use it in Australia.  W3C
VC makes some passing mention to some of them but not in the same detail as
OA.  These are

   1. That the holder may not be the presenter.  A trade document like a
   certificate of origin is issued to an exporter by an authorised body such
   as a chamber of commerce. The exporter will send it to the importer
   together with other trade docs like the invoice - sometimes via a freight
   forwarder in the exporting coutnry.  The importer will pass it to a customs
   agent in the importing country who will bundle it together with import
   regulatory docs for the importing customs authority - who is the verifier
   that matters.  So the credential has changed hands several times and there
   can be 2 or 3 hops between the holder/subject and the verifier. Therefore
   the credential needs to be self contained and not attached to a holders
   wallet.
   2. That commercially sensitive information may need to be redacted by
   the holder (not the issuer).  Some trade documents like bills of lading ,
   commercial invoices, and even certificates contain commercially sensitive
   information that the holder may want to redact before providing a
   verifiable version to a verifier. Most material I've seen on this from the
   W3C VC group assumes that the holder asks the presenter to provide a subset
   of claims in a signle credential that they can pass on (eg just give me a
   VC that says I'm over 18).  But in international trade, I dont think the
   holder of a Bill of Lading is going to go back to the issuer (ocean
   carrier) each time to prepare various subsets.  They'll need to do it
   themselves whilst still maintaining the proof.  Open attestation has a way
   to do this using merkle trees withing the document (ie each data element
   has a hash).  This will need to be maintained in a W3C VC and PDF version.
   3. That single credentials are not enough - a chain of trust is needed.
   Another key aspect of international trade is that the verifier in the
   importing jurisdiction (often a regulator) will not want to know/need to
   understand the various complexities of delegated authority in the exporting
   jurisdiction and so the exporting regulator needs to provide a trust
   anchor.  To make this rater obstuse assertion real - there are several
   hundred "authorised officers" of food health certificates (called e-phyto
   certs) in Australia.  They are authorised by the federal department of
   agriculture.  As an importing regulator, I cannot trust an ephyto VC issued
   by "john smith" who just claims to be authorised.  I'll need an
   additonal VC from the department of agriculture that attests that john
   smith is an authorised officer.  Basically the importing regulators just
   want to know that the exporting regulatar says a document is valid and
   issued by an authorised party.  This can be achieved via "oracle as issuer"
   model (our current implementation), or embedded credentials model
   (supported by OA), or a linked credentials model (using some kind of
   hashlink - probably the ideal end state).  Again, a fundamentally important
   requirement but too many different and potentially non-interoperable ways
   of doing it.

I'd be interested in finding a way forward with PDF-as-carrier of VCs that
still meets these cross-border trade requirements.

kind regards,
steve

On Wed, 21 Oct 2020 at 02:43, 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
>
>

-- 
Steve Capell