Re: Putting pdf data into VCs - cross border trade use case

Hi Kristina,

We currently use the https://openattestation.com/ framework which, although
not strictly W3C VC compliant, is very similar.  It's from Singapore
government and I gather they plan the next release to be fully VC compliant.

We have the same issue that cross border trade has literally centuries of
entrenched paper based processes and so a switch to digital trust via VCs
needs to cross the bridge slowly from original signed & sealed paper docs
to native digital credentials.  PDF representations are fundamental to that.

Our current implementation is actually the reverse

   - The PDF is embedded in the VC and then stored an encrypted file at a
   public un-guessable end point.
   - The decryption key is embedded in a QR on the PDF so that anyone given
   the PDF can verify it against the original.  there is a renderer linked to
   the issuer/doc type so that the verifier sees the retevent view for the
   given credential type.
   - The VC is signed and hashed and the hash is written by the issuer to
   ethereum using a DNS based mechanism to trace identity of the
   ethereum public key to the dns of the issuer - so the verifier can be
   confident of the issuer ID.

It all works pretty well and helps with a couple of constraints that are
important for cross-border trade (maybe less so for other domains)

   - The first is that the holder/presenter is almost always not the
   subject.  That's because a verifiable document like a certificate of origin
   is issued by some authorised party in the exporting country (eg a chamber
   of commerce) and is given to the exporter (who may be the subject).  But
   then the exporter sends it to the importer who then gives it to a customs
   broker who then presents it to the importing customs authority who is the
   verifier.  So there is no direct relationship between the subject (the
   exporter) and the verifier (the importing country regulator).  This means
   that the same VC changes hands several times and so needs ot be
   self-contained and not linked to the subject's digital wallet or DID.
   - The second is that the exporting country often has complex delegated
   authority schemes about who they authorise to issue what kind of
   certificate.  But the importing regulator cannot be expected to know about
   that and really can only trust an attestation from the exporting
   regulator.  So the system needs to embed the trust chain from issuer to the
   authority that has accredited the issuer.  We currently do that using an
   "oracle as issuer" (ie exporting government is the issuer even though they
   have delegated rights to some entity in the country).  We could also do it
   via linked credentials - but that's a bit more tricky.

Anyhow - short story is we do rely on PDFs to communicate VCs but we have a
problem because we issue have to issue two versions

   1. The actual open attestation json doc that contains the PDF - this is
   for machine verifiers that can verify natively against entereum/dns.
   2. The PDF with QR that links to a hosted verifier site (usually the
   issuer domain) - this is for human verifiers that scan the QR.

It would be interesting to have an option to embed the VC in the PDF so
that all those parties in the supply chain just have to exchange the PDF
and not have to pass along both because they cant be sure whether the next
hop will me a machine or human verifier.

Will be watching this thread and any ensuing W3C standards work with
interest.

kind regards,


On Tue, 3 Nov 2020 at 12:42, Kristina Yasuda <Kristina.Yasuda@microsoft.com>
wrote:

> Hi all, Kostas, Adrian,
>
> Thank you very much for the responses! Was insightful to find out that
> pdf as a container is a usecase not limited to education sector.
>
> I agree that displaying metadata makes more sense than reproducing a pdf
> from a VC. With decentralized storages, storing files while putting encryption
> protection was one of the challenges.
>
> This raises an intersting question on how to integrate VCs with existing
> data formats (pdf being one) - which to use as a container: VC or existing
> data format. One option would not be interoperate with another..
>
> Kindest Regards,
> Kristina
>
> ------------------------------
> *差出人:* Adrian Gropper <agropper@healthurl.com>
> *送信日時:* 2020年10月30日 2:46
> *宛先:* Kostas Karasavvas <kkarasavvas@gmail.com>
> *CC:* Kristina Yasuda <Kristina.Yasuda@microsoft.com>; W3C Credentials CG
> (Public List) <public-credentials@w3.org>; Zhen Chien Chia <
> zhchia@microsoft.com>
> *件名:* Re: Putting pdf data into VCs
>
> The healthcare use-case is around prescriptions:
> https://w3c.github.io/did-use-cases/#prescriptions
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fdid-use-cases%2F%23prescriptions&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cfa70a06ed411487cb4c808d87c3291af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395903942187568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PLUcmqfZQfUExYO%2B1ZEJVyilAHEcXXYQK9m30daDS3A%3D&reserved=0>
>
> ePrescribing is a major market with tremendous privacy and public health
> issues and a lot of traffic as well. The current ePrescribing  system in
> the US is inferior to the paper system it replaced.
>
>    - It reduces, if not effectively eliminating, the patient's ability to
>    shop around.
>    - It has also led to a federation that excludes many innovative
>    digital health records solutions.
>    - The network that manages prescriptions (SureScripts) is opaque and
>    inaccessible to patients
>    - SureScripts restraint of trade practices is under investigation by
>    the Federal Government.
>    - SureScripts is, in effect, the identity provider for 330 Million
>    people and is now marketing itself as a data broker beyond just
>    prescriptions.
>    - ePrescribing of controlled substances (EPCS) is a major application
>    in itself and needs strong, Federal-grade credentials and non-repudiable
>    signatures.
>
> PDF-based ePrescriptions could be designed to fix all of the above. The
> Free / libre HIE of One Trustee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhieofone.com%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cfa70a06ed411487cb4c808d87c3291af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395903942197561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BtHb7JtIBpbp8qa2mpouQjK7AONNMggJOG3bZn84dTY%3D&reserved=0>
> project uses ePrescribing as a core demonstration. We need help adopting
> the SSI standards including VC, non-repudiable signatures, and timestamps.
>
> Adrian
>
> On Thu, Oct 29, 2020 at 5:57 AM Kostas Karasavvas <kkarasavvas@gmail.com>
> wrote:
>
> Hi Kristina / all,
>
> First off, to my knowledge there is no standardized way to do this.
>
> Indeed this is different from using the PDFs as the container. This is
> something we have been thinking and although I don't have any answers, here
> are my thoughts.
>
> 1) The institutions that provide the PDFs could also provide the
> machine-readable metadata (this is what we optionally do with the PDF
> container as well). There are decentralized storage solutions that won't
> introduce a centralized PoF (with the assumption that the storage solution
> is self-sustainable to guarantee long-term usage) so the pointer idea could
> be feasible without compromising decentralization. Although less practical,
> several such solutions could be combined for an even more resilient
> solution. We have frozen investigations on this though. Did not seem that
> important for the clients.
>
> 2) Yes, this can be done but the PDF won't be identical to the PDF that
> the institutions provide unless they are constructed in an identical way.
> This is not practical since each institution uses their own methods for
> that and a lot just scan the physical degrees!  If they are not identical I
> don't see the point of creating the PDF in the first place. Why not display
> the metadata in HTML?
>
> That is one of the reasons we opted for the PDF as a container. It
> represented a digital version of their physical degrees; and a lot of these
> institutions were issuing the PDF degrees anyway. The physical degrees
> typically have several mechanisms to secure the document validity (like
> holograms). For the digital version we anchor it into a blockchain. When
> validating the PDF you will see the PDF (identical to the physical one) and
> the blockchain verification details. This approach has the benefit that the
> integrity of the exact PDF document that the institution has created is
> becoming tamperproof. The issuing institutions do what they always did wrt
> storing/disseminating their certificates (with potential improvements).
>
> We add certain information into the PDF to achieve this. The PDF itself
> (the visual representation) becomes a self-verifiable document and while we
> currently use an adhoc json format we do intend to move towards VCs. The
> idea is that a (universal) VC wallet would look for the VC in the metadata
> of the PDF and validate it accordingly.
>
> Finally, what one could also do is include a base64 (or equiv.) of the
> whole PDF inside the VC. Thus, VC is the container and a specific visual
> representation is attached. I believe this beats the purpose of having a
> PDF in the first place but I would be open to counter arguments. Maybe it
> will work in your use case but from my experience that would be contrary to
> the workflow that these institutions typically have.
>
> Hope the above are of some help,
> Kostas
>
>
>
> On Wed, Oct 28, 2020 at 9:03 PM Kristina Yasuda <
> Kristina.Yasuda@microsoft.com> wrote:
>
> Hi all!
>
> Many educational institutions issue credentials (transcripts, graduation
> certificates, etc.) in pdf format, and we have faced an question of how to
> create VCs using claims in pdfs. Reaching out to the community is anyone
> has faced a similar issue and if there are standardized way/best
> practices to:
> 1) put data from pdfs into VCs while keeping integrity without relian on
> centralized party? One option could be storing pdf files in
> centralized/decentralized servers and including a pointer to a file in a
> VC, but that would introduce a certain level of centralization.
> 2)  to reconstruct pdfs from claims in VCs?
>
> For example Modeling Educational Verifiable Credentials report (
> https://w3c-ccg.github.io/vc-ed-models/#biblio-obs-are-vcs
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fvc-ed-models%2F%23biblio-obs-are-vcs&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cfa70a06ed411487cb4c808d87c3291af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395903942197561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zH2EnH8OPUW6m2bFKXkif1pl%2F9E1eCyCN2FffaXXIK8%3D&reserved=0>
> ) in section 1.5.3.1 shows the example of including pdf format in a VC,
> but how can the verifier reproduce a pdf record from the set of values in
> payload.data?
>
> This is a little different from using pdfs as a container, rather
> including information from pdfs into VCs.
>
> Thank you very much!
> Kristina
>
>
>
> --
> Konstantinos A. Karasavvas
> Software Architect, Blockchain Engineer, Researcher, Educator
> https://twitter.com/kkarasavvas
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkkarasavvas&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Cfa70a06ed411487cb4c808d87c3291af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395903942207558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g40BnUQeXVcIrKzHaCiAViHN%2BazwGB3MGfpOEsF80MA%3D&reserved=0>
>
>

-- 
Steve Capell