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

Hi Kostas 

You are of course quite correct that the special requirements should be independent of whether the VC is PDF embedded or not 

I don’t think they are contradictory to VC, they are more like profiles or use cases that need a bit more detailed specification 

Kind regards 

Steven Capell
Mob: 0410 437854

> On 21 Oct 2020, at 10:52 pm, Kostas Karasavvas <kkarasavvas@gmail.com> wrote:
> 
> 
> Hi Steve,
> 
> I am all in for a more formal PDF-as-container/carrier. I would distinguish between two separate issues:
> 
> 1) How to store the VC in the PDF (nice to have a common way of doing it)
> 2) How to extend VCs to meet up the specific requirements. VC is quite open and flexible. Indeed, we would need to extend it in certain aspects to accommodate our mechanics. Wouldn't that be the case for your specific requirements you mentioned or do some of them contradict the VC spec.? 
> 
> Regards,
> Kostas
> 
> 
>> On Wed, Oct 21, 2020 at 1:19 AM steve capell <steve.capell@gmail.com> wrote:
>> 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
>> 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.
>> 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.
>> 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
>> 
> 
> 
> -- 
> Konstantinos A. Karasavvas
> Software Architect, Blockchain Engineer, Researcher, Educator
> https://twitter.com/kkarasavvas