W3C home > Mailing lists > Public > public-credentials@w3.org > November 2020

Re: Requirements for PDF as container for VC's

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Mon, 9 Nov 2020 00:18:11 +0000
To: Steve Capell <steve.capell@gmail.com>
CC: Adrian Gropper <agropper@healthurl.com>, Bill Claxton <williamc@itr8.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Message-ID: <361A33C6-5CBB-4419-B66A-6DA1533DFE54@adobe.com>
It’s not even a license issue, however, Steven – it’s about the forward compatibility of a “standard” based on a single specific implementation – which is really a conglomeration of multiple implementations (eg. Tika + PyImage + …_).  If any one of them changes their implementation – even to fix a bug – it could end up producing a different ISCC for the exact same asset.  And that would be bad…

That’s why the ISO committee is working to get the algorithm(s) standardized instead of the implementation.


From: Steve Capell <steve.capell@gmail.com>
Date: Sunday, November 8, 2020 at 5:22 PM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Adrian Gropper <agropper@healthurl.com>, Bill Claxton <williamc@itr8.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Requirements for PDF as container for VC's

Thanks Adrian

Once I realised you were referencing https://iscc.codes/concept/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiscc.codes%2Fconcept%2F&data=04%7C01%7Clrosenth%40adobe.com%7Ca9054b952f0541142ae208d88434b8a5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637404709257919953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bkSnM%2FfaPYnwcJSfP%2BH1jdYDGtq72Vrp4MHqi9fuVAc%3D&reserved=0> and not https://www.iscc-system.org/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iscc-system.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7Ca9054b952f0541142ae208d88434b8a5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637404709257919953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6mZfvh%2BdMJJH1bNAxM4%2BVCsbkPQ3FvNelnlovWawDpM%3D&reserved=0> then I found some very interesting references

It’ll take some detailed reading and digestive juices to get my head around it - but it does seem to hit the problem spot

But, to Leonard’s point, open source <> open IP so I’d also like to dig a bit about who is behind the work and what the license CC BY-NC-SA 4.0 License  actually means

Steven Capell
Mob: 0410 437854

On 9 Nov 2020, at 8:49 am, Leonard Rosenthol <lrosenth@adobe.com> wrote:
Conceptually – yes, Adrian.

The problem is that today ISCC is based on a very specific implementation rather than being defined as a general set of algorithms.  This is one area where the ISO committee is working with the folks behind ISCC to address, since an open standard can’t be created on a single implementation (even if that implementation is open source).


From: Adrian Gropper <agropper@healthurl.com>
Date: Sunday, November 8, 2020 at 4:37 PM
To: Steve Capell <steve.capell@gmail.com>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Bill Claxton <williamc@itr8.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Requirements for PDF as container for VC's

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


On Sun, Nov 8, 2020 at 3:11 PM Steve Capell <steve.capell@gmail.com<mailto: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<mailto: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.


From: Bill Claxton <williamc@itr8.com<mailto:williamc@itr8.com>>
Date: Sunday, November 8, 2020 at 8:35 AM
To: "public-credentials@w3.org<mailto:public-credentials@w3.org>" <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Requirements for PDF as container for VC's
Resent-From: <public-credentials@w3.org<mailto: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%7Ca9054b952f0541142ae208d88434b8a5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637404709257919953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m8nmp8N%2FynwQ764wUbguTQarsHfh%2BUusFF6bDfZbl60%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<mailto: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<mailto: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.



Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator

Received on Monday, 9 November 2020 00:18:28 UTC

This archive was generated by hypermail 2.4.0 : Monday, 9 November 2020 00:18:29 UTC