Re: Requirements for PDF as container for VC's

Agreed. See my previous email.

Indeed, signing the container is one way to do it. Coming from the
decentralized angle we opted to anchor it on an immutable ledger.

On Mon, Nov 9, 2020 at 2:17 AM Leonard Rosenthol <lrosenth@adobe.com> wrote:

> I agree with you that the machine readable version is the most logical
> source of source and have no objection to that.
>
>
>
> If the machine readable version is incorporated into the PDF – which is
> the idea (with PDF as container) – then there is no need to transform at
> all.  The machine readable version is extracted and verified.
> Secondarily, verification that the machine version == the human version
> would be a useful thing.
>
>
>
> Of course, this is why signing the entire container would also help since
> you could more easily detect tampering.
>
>
>
> Leonard
>
>
>
> *From: *Adrian Gropper <agropper@healthurl.com>
> *Date: *Sunday, November 8, 2020 at 5:14 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Steve Capell <steve.capell@gmail.com>, Bill Claxton <
> williamc@itr8.com>, "public-credentials@w3.org" <public-credentials@w3.org
> >
> *Subject: *Re: Requirements for PDF as container for VC's
>
>
>
> By analogy with DID resolution, I can't imagine how anything other than
> the machine representation could be the basis of trust. (trying to avoid
> the master language).
>
>
>
> It's then up to the verifier to confirm any human-consumable
> representation that is offered to them. They could send the PDF to a
> trusted resolver for confirmation or they could run a transform locally.
>
>
>
> If the issuer wants to sign the human-consumable representation, it should
> be up to them to use a transform they trust and they could really be
> signing just the machine readable version anyway because they trust their
> transformer.
>
>
>
> Can it be any other way?
>
>
>
> Adrian
>
>
>
> On Sun, Nov 8, 2020 at 3:52 PM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
> I realized after writing that my comment on #2 was not accessibility
> friendly.  It really should be “human consumable representation” since the
> content may be consumed in non-visible representations for the same purpose.
>
>
>
> Leonard
>
>
>
> *From: *Leonard Rosenthol <lrosenth@adobe.com>
> *Date: *Sunday, November 8, 2020 at 4:49 PM
> *To: *Steve Capell <steve.capell@gmail.com>
> *Cc: *Bill Claxton <williamc@itr8.com>, "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 4:48 PM
>
>
>
> Steven – we have to be careful to not to conflate issues…
>
>
>
> 1 – Can a machine determine if the data being used for presentation
> directly matches that used as “data”?   That problem can be solved by
> either have a single set of data that is used in both cases – though I am
> not aware of any situation where that is the case – in all cases there is a
> TRANSFORM from one to the other.  So if you aren’t using the same data,
> then you need a way to “connect the dots” so that it is clear what part of
> the presentation matches what part of the data.  PDF supports that using
> semantic tagging of content (as I showed in my presentation).
>
>
>
> 2 – Can a human determine if the data is correct?  Yes, by having a human
> visible representation the human verified that what they see is what they
> expect.
>
>
>
> 3 – Determine which representation – human or machine – is the “master”.
> In the eInvoicing standards of the EU, the machine readable XML is the
> master copy and the PDF presentation si just that – human readable
> presentation.  I would expect that in our VC cases the same would be true.
> No?
>
>
>
> Leonard
>
>
>
> *From: *Steve Capell <steve.capell@gmail.com>
> *Date: *Sunday, November 8, 2020 at 4:09 PM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Bill Claxton <williamc@itr8.com>, "public-credentials@w3.org" <
> public-credentials@w3.org>
> *Subject: *Re: Requirements for PDF as container for VC's
>
>
>
> 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%7Cdc9d966e1de54c55a4cc08d88433aef5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637404704804939426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VrYynGYyXN3TOkfZuwE6XFtMF6pfjgOx1jDt3kVsz04%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%7Cdc9d966e1de54c55a4cc08d88433aef5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637404704804939426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OlVqzZz7bDelIYEmukdh617td50AXnrW1i%2FY3TB3vQE%3D&reserved=0>
>
>
>
>
>

-- 
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas