- From: Kostas Karasavvas <kkarasavvas@gmail.com>
- Date: Mon, 9 Nov 2020 12:25:02 +0200
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: Bill Claxton <williamc@itr8.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <CABE6yHttvP+LFK3KAhfbzZup0p86jsPzdBqaJpwr_pA0WEtDGg@mail.gmail.com>
Hi Leonard, Bill, Steve, and all, > How do you assure that what’s in the layout matches the JSON data? > Have I misunderstood? Does someone have a solution that can ensure that PDF rendered data is the same as PDF attached metadata ? This is what we do. - Issuers have (or produce) PDFs. They add whatever metadata they want into the PDF (these are the machine-readable part of the PDF). - We hash the PDFs and anchor them on the blockchain. This is what guarantees that the PDF (presentation) plus the machine-readable data (content) are identical and tamper-proof. - During validation the user sees the original PDF plus the metadata plus the verification details. (the PDF can of course be viewed with any PDF viewer). This works very well for several use cases with minimum overhead for them. What we want is now to "VC-fy" the structure that is embedded in the PDF. Embedding a VC in a standardized way is the first step of this process and thus our interest in this. Kostas On Sun, Nov 8, 2020 at 5:08 PM 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> > > > > -- Konstantinos A. Karasavvas Software Architect, Blockchain Engineer, Researcher, Educator https://twitter.com/kkarasavvas
Received on Monday, 9 November 2020 10:25:27 UTC