Re: Requirements for PDF as container for VC's

Seems to me that the ISCC model might have some relevance.

Adrian

On Sun, Nov 8, 2020 at 3:11 PM Steve Capell <steve.capell@gmail.com> wrote:

> As you all probably already know, the Singapore govt open attestation
> framework has a nice way of separating an issuer defined tenderer from the
> vc payload - which ensures the human viewer and machine reader always see
> the same data
>
> Of course the problem is that the verifier needs a link to the rendered
> view and that is often a QR on a PDF. But in that case there is no
> guarantee that the data on the PDF page is the same as the data in the
> linked VC - other than a human “yep, they look the same” eyeball.
>
> I’m not a PDF expert but I note that even the EU / German e-invoicing
> franework seems to have the same problem.  The XML data is attached to the
> PDF as meta data but there’s nothing to guarantee that the values in the
> xml (eg amounts and bank details) are the same as what’s in the PDF view.
> That opens up rather obvious avenues for fraud.
>
> Have I misunderstood? Does someone have a solution that can ensure that
> PDF rendered data is the same as PDF attached metadata ?
>
> Steven Capell
> Mob: 0410 437854
>
> On 9 Nov 2020, at 2:08 am, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> 
>
> Bill, thanks for sharing.  I read your evaluation link and there is a lot
> of good stuff there.   However, I am surprised that your concerns about PDF
> are around layout and rendering – since in that case, PDF is a better
> solution since the layout is defined by the issuer and the renderer simply
> follows the rules of ISO 32000.  So there is never a question about the
> rendering not matching what the issuer desires.
>
>
>
> However, I think you have an item later on that is more relevant and we
> should consider the importance of:
>
> > How do you assure that what’s in the layout matches the JSON data?
>
>
>
> Although I would change that to not be the layout (since the layout, or
> what I would call presentation) but instead be the data presented.
>
>
>
> Leonard
>
>
>
> *From: *Bill Claxton <williamc@itr8.com>
> *Date: *Sunday, November 8, 2020 at 8:35 AM
> *To: *"public-credentials@w3.org" <public-credentials@w3.org>
> *Subject: *Re: Requirements for PDF as container for VC's
> *Resent-From: *<public-credentials@w3.org>
> *Resent-Date: *Sunday, November 8, 2020 at 8:32 AM
>
>
>
> Kostas, hi -
>
> We spoke recently about this and I'm following the thread to see what the
> community thinks.  Happy that you're getting lots of input.
>
> I thought you may want to review my recent article "Evaluating
> Decentralised Identity Projects
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwmclaxton.medium.com%2F&data=04%7C01%7Clrosenth%40adobe.com%7C8b191c01f36c46a0247108d883eb1dab%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637404393127925177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JhI7Zxcn924hZ8imOQmWM1pzKvA5mmaADJxwJ5TDy8A%3D&reserved=0>".
> It's a sort of reviewer's guide for decentralised identity apps.  In
> particular, I would draw your attention to the point: "Have you separated
> layout from the rendering application, so that 3rd-parties (including
> verifiers) can render your certs?"  I intend to write a follow up about
> presentation layer and mention PDF encapsulation as an alternative, but one
> I am not much in favor of, for the reasons we discussed.
>
> *PS - For anyone else reading this thread, I was a PDF evangelist back in
> the early days of v4 and v5.  I am familiar with the encapsulation methods
> and indeed used them for a National Archives project in Singapore.*
>
> Regards, Bill Claxton (williamc@itr8.com)
> Facebook, Skype, MSN, Yahoo, Twitter, Flickr or Gmail: wmclaxton
> Voice, Text or Whatsapp: +65-9012-4327
>
> On 11/8/2020 5:17 PM, Kostas Karasavvas wrote:
>
> Hi Leonard,
>
>
>
> Thanks for initiating this. I have been thinking of this as well.
>
>
>
> On Sun, Nov 8, 2020 at 3:23 AM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
> Kicking off some discussions here – I’d like to start by putting down what
> I think are some “primary” requirements for the use of PDF in this
> context.  Am I missing anything?  Do you disagree with any of these?
> Feedback welcome!!
>
>
>
> *## Requirements*
>
>
>
> - Shall store the VC in native JSON-LD (w/optional compression)
>
> - VC should be in an easily accessible location (for both reading &
> writing)
>
>
>
> Agree. And JSON-LD is what we intend to use. There could also be a
> 'serialization/type' option to specify the serialization to accommodate
> other use cases (XML? CBOR-LD?), if need be.
>
>
>
> - Should require no language changes to PDF (except "metadata"-like
> values)
>
>     - implies compatibility with both PDF 1.7 and 2.0
>
>
>
> Agree. I assume that PDF 1.7 implies compatibility with older versions as
> well?
>
>
>
> - Shall be usable in conjunction with standard PDF Signing/Certification
>
>
>
> Makes sense. I have questions here wrt the PDF spec and how signing is
> happening (the 'hole' in the file approach) but these are for later.
>
>
>
> Regards,
>
> Kostas
>
>
>
>
>
>
>
> Leonard
>
>
>
>
> --
>
> Konstantinos A. Karasavvas
>
> Software Architect, Blockchain Engineer, Researcher, Educator
>
> https://twitter.com/kkarasavvas
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkkarasavvas&data=04%7C01%7Clrosenth%40adobe.com%7C8b191c01f36c46a0247108d883eb1dab%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637404393127935172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=osHV0RiHUGkEebCgZia1URKwp6I%2FntL0IdN0EgeWQMk%3D&reserved=0>
>
>
>
>