Re: Requirements for PDF as container for VC's

In light of this conversation, are there any good SDKs for building thes
PDFs?
Right now we are building PDFs, but basically through images(read puppeteer
crawling ssr) with a web rendered page. To make the view a bit more
flexible for us.
But I would be keen to embed the VC info as well.
ᐧ

On Wed, Nov 11, 2020 at 5:11 PM Kostas Karasavvas <kkarasavvas@gmail.com>
wrote:

> Indeed, we also make use of this; i.e. the ability to create the final
> PDFs from a PDF template (form) and the metadata. The latter is used to
> populate the PDFs but we also embed them for future machine-readable
> reference.
>
> On Tue, Nov 10, 2020 at 2:50 PM Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
>> I just want to correct one thing here…
>>
>>
>>
>> > When Steve made that statement it is likely a comparison to PDF with
>> metadata where it is impossible for the metadata to reflect the data
>> represented on the PDF even if the issuer of the PDF wants to.
>>
>> >It lacks the functionality to merge data and view into a rendered view
>> like in OA.
>>
>> >
>>
>> Given a 100% compliant PDF processor, this is **NOT TRUE**.   PDF
>> support the same ECMAScript (aka JavaScript) language, with an extended
>> DOM, as used by the Open Web.  It also supports interactive form fields.
>> The combination of those two technology can be used to “merge data into a
>> rendered view”.
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *"Raymond YEH (GOVTECH)" <Raymond_YEH@tech.gov.sg>
>> *Date: *Monday, November 9, 2020 at 1:29 AM
>> *To: *Bill Claxton <williamc@itr8.com>, Steve Capell <
>> steve.capell@gmail.com>
>> *Cc: *Leonard Rosenthol <lrosenth@adobe.com>, Adrian Gropper <
>> agropper@healthurl.com>, "public-credentials@w3.org" <
>> public-credentials@w3.org>, "Sin Yong LOH (IMDA)" <
>> LOH_Sin_Yong@imda.gov.sg>, "Maillet LAURENT (GOVTECH)" <
>> Maillet_LAURENT@tech.gov.sg>
>> *Subject: *RE: Requirements for PDF as container for VC's
>>
>>
>>
>> Bill Claxton,
>>
>>
>>
>> From your question there seemed to be two ongoing concerns:
>>
>>    1. Misrepresentation of information on the document
>>    2. Inability for parties to negotiate on the verifiable credentials
>>
>>
>>
>> *Misrepresentation of information on the document*
>>
>> The framework allows the issuer to render the a human friendly webview
>> directly from underlying data. It certainly does not prevent one creating a
>> view that is a poor representation of the underlying *data if they are
>> incompetent of fraudulent. *
>>
>>
>>
>> The very nature of allowing a renderer to present a different view to the
>> human is an abstraction of the underlying data to the end user. This is so
>> that the end user, who may not be comfortable with JSON, does not need to
>> interact with the raw data directly.
>>
>>
>>
>> However, as you have pointed out correctly, there is room for incompetent
>> or fraudulent parties to misrepresent that data.
>>
>>
>>
>> Taking your example further, one incompetent or fraudulent party could
>> even issue a certificate in such manner:
>>
>>    - The renderer is hard-coded to display 4.0 GPA
>>    - The document has a `gpa` field showing 3.9
>>    - The document has a PDF attached to it showing someone else’s
>>    certificate with 3.8 GPA
>>    - The transcript’s test results sum up to 3.7 GPA
>>
>> Here you see a document that cannot even seemed to agree with itself what
>> GPA the student has. I implore you to ask the question if this is a problem
>> of the framework or simply because of a few problems unrelated to the
>> choice of document framework:
>>
>>    - Bad inputs
>>    - Bad controls
>>    - Data replication
>>
>> If the additional level of abstraction is *still* a concern and that the
>> viewing party does not need a rendered version of the document, one could
>> use a “headless” client for processing and interacting with the document
>> without ever passing the document through the renderer.
>>
>>
>>
>> Here I want to establish that:
>>
>>    1. The end user has a choice of using a human readable view or a
>>    headless program to perform the processing
>>    2. The OA document format does not forbid raw document processing as
>>    you would with other types of VC
>>    3. The problem with bad document likely lies with incompetent or
>>    fraudulent issuers
>>
>>
>>
>> When Steve made that statement it is likely a comparison to PDF with
>> metadata where it is impossible for the metadata to reflect the data
>> represented on the PDF even if the issuer of the PDF wants to. It lacks the
>> functionality to merge data and view into a rendered view like in OA.
>>
>>
>>
>> *Inability for parties to negotiate on the verifiable credentials*
>>
>> The document framework is a way to structure data and is not concerned if
>> the content in it is factually correct.
>>
>> Parties are free to negotiate through other channels on the content of
>> the document.
>>
>>
>>
>> As the document does not become publicly available and searchable, the
>> issuing party cannot force the receiving party to submit that incorrect
>> document if the receiving party do not wish to. The receiving party can
>> also approach the issuing party to reissue the document should they have
>> dispute on its content.
>>
>>
>>
>> I think your example cites the SkillsFuture implementation of the
>> facilities to store and route documents to the citizens directly. Document
>> routing and negotiation are not part of the document framework, please do
>> not confuse the document with the business processes around the document.
>>
>>
>>
>> ---
>>
>>
>>
>>
>>
>>
>> This Email is filed in GovTech DRMS
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrms.in.tech.gov.sg%2F%3Fxmail-id%3Ddccd597f-b8e5-4b43-916d-3692c22c8810&data=04%7C01%7Clrosenth%40adobe.com%7C60be6ae4b63d42892cc108d88478dad5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637405001904838484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9ONLNnHLFZjXVfi2ZD9wnJ0qjOUMIs3ayTZleMH%2Bv3M%3D&reserved=0>
>> [3S-id=dccd597f-b8e5-4b43-916d-3692c22c8810:a0a98837]
>>
>>
>> *From:* Bill Claxton <williamc@itr8.com>
>> *Sent:* Monday, 9 November 2020 11:56 AM
>> *To:* Steve Capell <steve.capell@gmail.com>
>> *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; Adrian Gropper <
>> agropper@healthurl.com>; public-credentials@w3.org; Raymond YEH
>> (GOVTECH) <Raymond_YEH@tech.gov.sg>; Sin Yong LOH (IMDA) <
>> LOH_Sin_Yong@imda.gov.sg>
>> *Subject:* Re: Requirements for PDF as container for VC's
>>
>>
>>
>> Steve,
>>
>> I think we should take this outside of the w3 group rather than inviting
>> SG govt team to defend their work in this forum.  And if I'm not wrong,
>> they would need to accept the public disclosure rules, before commenting.
>>
>> As we are both implementers of OpenAttestation, there are better forums.
>>
>> *PS - I am not attacking the OpenAttestation framework, simply pointing
>> out that relying parties need to be cautious in what they trust.  Also, I
>> need to register my williamc@nextid.com <williamc@nextid.com> email address
>> with this forum, rather than using my other company's email.*
>>
>> Regards, Bill Claxton (williamc@itr8.com)
>> Facebook, Skype, MSN, Yahoo, Twitter, Flickr or Gmail: wmclaxton
>> Voice, Text or Whatsapp: +65-9012-4327
>>
>> On 11/9/2020 11:45 AM, Steve Capell wrote:
>>
>> Hi bill
>>
>>
>>
>> Thanks for that comment.  Copying the Singapore tech lead in my response
>>
>>
>>
>> I think I disagree with you because I can’t see how the renderer can show
>> anything except what is in the credential because there is no other source
>> of claim data
>>
>>
>>
>> Raymond be able to offer a more specific response
>>
>> Steven Capell
>>
>> Mob: 0410 437854
>>
>>
>>
>>
>> On 9 Nov 2020, at 2:32 pm, Bill Claxton <williamc@itr8.com>
>> <williamc@itr8.com> wrote:
>>
>> Following...
>>
>> TL;DR - if you don't know the verification process, beware of what you
>> trust.
>>
>> 1.  I agree with Adrian that "the machine representation [must be] the
>> basis of trust".
>>
>> 2.  I disagree with Steve's assertion: "the Singapore govt open
>> attestation framework... ensures the human viewer and machine reader always
>> see the same data".  This is not true and is in fact a weakness of their
>> verification mechanism.  They do not display the claims made in the JSON
>> document so the relying party will not know if the visual and machine
>> representation tally.
>>
>> For example: the displayed presentation of a student degree could include
>> mention of 'deans list' which is not supported by the certificate data or
>> worse, it may state a 4.0 GPA when the certificate data indicates only a
>> 3.8.  The relying party would not notice this unless they inspected the
>> credential manually.  Furthermore, they is also a weakness is their
>> issuance process in which individuals receive credentials in their wallet
>> (ie- the Skills Passport) without confirming accuracy of the data (the
>> recipient is never asked).  This opens the possibility of repudiation by
>> the recipient in the case they are wrongly awarded a job or a grant on the
>> basis of their 4.0 GPA and being on the dean's list, when the credential
>> itself indicates otherwise.
>>
>> This is all off-topic for whether PDFs make a good container for VCs, but
>> I thought I should point out these important considerations regarding the
>> relationship between the issued credential and its visual representation.
>>
>> Regards, Bill Claxton (williamc@itr8.com)
>> Facebook, Skype, MSN, Yahoo, Twitter, Flickr or Gmail: wmclaxton
>> Voice, Text or Whatsapp: +65-9012-4327
>>
>> On 11/9/2020 9:26 AM, Steve Capell wrote:
>>
>> So - after all that I think I’ve talked myself out of the idea of PDF as
>> a VC container and I’m back to the idea of PDFs contained in VCs that are
>> referenced by a QR on the PDF
>>
>>
>>
>> There will be some that note the circular reference here.  It’s managed
>> on the oracle as issuer side
>>
>> - for low volume issue, the user uploads their PDF and we present a UI to
>> position a generated QR and then they download the PDF with QR and use it
>> as normal
>>
>> - for high volume issue, the calling system first asks our API for the
>> link URL / QR, then generates their own PDF before giving it back to us
>> together with structured metadata
>>
>>
>>
>> I can’t think of a better way to handle this enormously complex millions
>> of stakeholders change management process ..
>>
>> Steven Capell
>>
>> Mob: 0410 437854
>>
>>
>>
>>
>> On 9 Nov 2020, at 12:20 pm, Steve Capell <steve.capell@gmail.com>
>> <steve.capell@gmail.com> wrote:
>>
>> I should add that, at present, we don’t embed the VC in the PDF - it’s
>> actually the other way around
>>
>> - submitter provides data + PDF to oracle (issuer) who creates the VC and
>> stores it as an encrypted file at a public (but unguessable) location :
>> repository/uuid.json
>>
>> - url plus secret key for decrypting the vc is embedded in the QR that
>> goes on the PDF.  Theory is that if you are given the PDF with its data
>> then you have rights to the digital version at the end of the QR link
>>
>> - so we finish up with a PDF + QR that is the thing that is shared around
>> but isn’t actually the authoritative VC. The PDF is really just the key to
>> get the VC
>>
>>
>>
>> Because there are so many hops and stakeholders in the supply chain, we
>> can’t really Assume (at this stage in vc adoption maturity) that people
>> will know what to do with a native digital vc.  So verification works for
>> either humans (immature or low volume verifiers) or machines (mature or
>> high volume verifiers) as follows
>>
>> - humans just scan the QR and get taken to a verifier site that they
>> trust (typically the exporting country regulator).  The site is a hosted
>> verifier and gets the referenced VC (secret key in QR remember), validates
>> it, And also presents the originally notarised metadata and PDF - asking
>> the human to confirm that they one they are holding is the same as what the
>> verifier is showing them
>>
>> - the machine verifier is typically the importing regulator but could be
>> any other high volume user along the way such as a bank.  The holder
>> (presenter is maybe a better word) loads then PDF with QR to the verifier
>> website such as a national trade single window.  The website extracts the
>> QR , retrieves the VC, validates the VC, consumes VC metadata, checks that
>> the hash of the presented PDF is the same as the hash of the Attached PDF
>> in the VC
>>
>>
>>
>> It may seem a bit clunky but the overriding issue is human change
>> management.  Even a small economy will produce around 100 million cross
>> border VCs in a year - each one going to any one of nearly 200 countries
>> and potentially being touched by dozens of different roles.  Count the
>> number of exporters and importers around the world and the possible
>> combinations of specific entities across that 100m consignments is also in
>> the 100’s of millions.  There’s no practical way to engage them all up
>> front to change their normal business practice
>>
>>
>>
>> So we like PDF as the carrier of the secret key and link and we like
>> oracle issued VCs as the thing they link to - because this combination
>> seems like the only practical way to take a first step to transform world
>> trade
>>
>>
>>
>> Hope that makes sense.  Happy to hear alternative suggestions
>>
>>
>>
>> Steven Capell
>>
>> Mob: 0410 437854
>>
>>
>>
>>
>> On 9 Nov 2020, at 11:52 am, steve capell <steve.capell@gmail.com>
>> <steve.capell@gmail.com> wrote:
>>
>> thanks Leonard,
>>
>>
>>
>> >Same way you protect the VC itself – Sign it!
>>
>>
>>
>> Except that, in our use case, the VC issuer is the "oracle" (Exporting
>> Government Authority) that the verifier (Importing Government Authority)
>> trusts.  But the PDF is created by some other party in the exporting
>> jurisdiction.  So, even if they sign it, the signing identity won't match
>> the VC issuer identity.  Basically the verifier can check that it is signed
>> and that the signature is valid - but it doesnt really help because the
>> verifier doesnt know the PDF creator.
>>
>>
>>
>> We are using the oracle as issuer VC model because to do otherwise would
>> impose more complexity on both the regulated community in the exporting
>> jurisdiction and on the verifier - to follow and confirm the trust chain
>> via a set of linked / embedded VCs.  This is a better future state but
>> seems too much of a leap to start with.
>>
>>
>>
>> AS for not putting verification data on the human consumable form, that
>> also imposes too much of a leap for such a diverse set of stakeholders in
>> the internaitonal supply chain.
>>
>>
>>
>> Thinking about it, I think the best way is for the oracle as issuer
>> (exporting government) to notarise the PDF and include the hash of the pdf
>> attachment in the VC.  then the verifier can just confirm that the hash of
>> the PDF they are holding is the same as the hash of the PDF that the oracle
>> notarised.
>>
>>
>>
>> no?
>>
>>
>>
>>
>>
>> On Mon, 9 Nov 2020 at 11:24, Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>> > In the ideal world there are no PDFs that you need to trust, there is
>> only data that the machine you trust can verify
>>
>> >
>>
>> You and I live in different ideal worlds 😊.
>>
>>
>>
>>
>>
>> > The attack vector that I’m trying to figure out a simple way to
>> mitigate is where Malik manipulates the PDF rendered information without
>> touching the (linked or embedded) VC
>>
>> >
>>
>> Same way you protect the VC itself – Sign it!   Apply a standard DigSig
>> to the PDF – most likely one that is PAdES compliant for better acceptance
>> world-wide.
>>
>>
>>
>> The other thing to consider is how technology/approaches such as the
>> Content Authenticity Initiative (https://contentauthenticity.org/
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcontentauthenticity.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C60be6ae4b63d42892cc108d88478dad5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637405001904838484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4aKR2KXGA28AwKk5A25CFMd570noyhyBQ0qqlcZ63JQ%3D&reserved=0>)
>> can also be applied here to establish provenance of the document and its
>> content throughout its lifecycle.
>>
>>
>>
>>
>>
>> > The community “learns” that a QR on a PDF means it is verifiable and
>> when you see a green tick on scanning the QR, you look no further
>>
>> >
>>
>> Yes, this is why standards such as PAdES Part 6 are very clear about *
>> *not** putting any form of validation information in the content of the
>> page.  Too easy for forge.
>>
>>
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Steve Capell <steve.capell@gmail.com>
>> *Date: *Sunday, November 8, 2020 at 5:40 PM
>> *To: *Adrian Gropper <agropper@healthurl.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
>>
>>
>>
>> Yes I think the machine version has to be the basis of trust.  In the
>> ideal world there are no PDFs that you need to trust, there is only data
>> that the machine you trust can verify
>>
>>
>>
>> The attack vector that I’m trying to figure out a simple way to mitigate
>> is where Malik manipulates the PDF rendered information without touching
>> the (linked or embedded) VC. Let’s say the VCs are a certificate of origin
>> and a commercial invoice.  These documents can change hands many times
>> between issuer and verifier.  Manufacturer, exporter, forwarder, carrier,
>> financial service provider, bank, insurer, importer, customs agent,
>> regulator - just a sampling of parties, any one of which could be Malik
>>
>>
>>
>> Today, there is only paper and people may verify the bit of paper by
>> calling up the issuer.  A time consuming and expensive process
>>
>>
>>
>> In the end state, machines that people Trust algorithmically verify the
>> VC data.  Much better.
>>
>>
>>
>> It’s the intermediate state that worries me.  Sometimes people look at
>> the paper (PDF) version of the data supposedly in the vc and sometimes
>> machines verify the vc.  The community “learns” that a QR on a PDF means it
>> is verifiable and when you see a green tick on scanning the QR, you look no
>> further.  This is the danger window.  And a few spectacular attacks could
>> kill the whole VC framework in an industry sector
>>
>> Steven Capell
>>
>> Mob: 0410 437854
>>
>>
>>
>> On 9 Nov 2020, at 9:14 am, Adrian Gropper <agropper@healthurl.com> wrote:
>>
>> 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%7C60be6ae4b63d42892cc108d88478dad5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637405001904838484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mu47HpIeJ8nIaGRVUdDuesjpFFN5xrFCi3DhKpRn6Cg%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%7C60be6ae4b63d42892cc108d88478dad5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637405001904848437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lq9vGeOHFi38zndwIFpz8AgriFhK%2F2NX0cBMeQDtZrQ%3D&reserved=0>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Steve Capell
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Konstantinos A. Karasavvas
> Software Architect, Blockchain Engineer, Researcher, Educator
> https://twitter.com/kkarasavvas
>


-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io