Planning Issue - Create PDF from one or more shared credentials

[bmuramatsu]

Generate a PDF from one or more credentials a user has chosen to share. Include support for prefered credential display (e.g., PDF, PNG/JPEG/image, etc.)

[kayaelle]

@dmitrizagidulin & @jchartrand - let's discuss at next sprint meeting re: admin dashboard discussion.

[jchartrand]

Adding in some points made in Slack:

• We'd like to use the VC renderMethod property (https://w3c-ccg.github.io/vc-render-method/) to specify a hint for how to render the PDF
• We had thought the hint might specify a generic PDF template that the wallet could then populate with the specific credential data
• But there might not be a standard generic PDF templating system. If there isn't a standard templating system, then it might be better to have the issuer generate the PDF, otherwise the dynamic PDF generation would likely depend on specific code libraries that expect specific templates or use, which we want to avoid
• an alternative might be to have the issuer generate a single image (e.g, png) that pre-renders the entire credential (e.g., a diploma).
• We could then generate a PDF (using any library we like) that simply contains the single image.
• The image could also be used for other things like display in the wallet or VW+
• We likely want to include a QR for the VC on the PDF
• The QR could encode the VC directly, but better would be for the QR to point at a hosted copy of the VC (like a VerifierPlus hosted copy).
• Likely better for us to generate the QR in the wallet than for the issuer to pre-generate it and add it directly to the png (of the rendered credential). We would just put the QR somewhere in the PDF, maybe just below where we place the png.
• Dynamically generating the QR in the wallet is better because:
  • can use different storage options for the credential
  • can change the location of the stored credential at any time (and then re-generate the PDF and QR)
  • the issuer needn't pre-allocate storage for the credential which might be difficult for various reasons including the need to get use consent

[bmuramatsu]

Some quick reactions

• Having the issuer generate a PDF, I think is effectively the same as them generating a PNG. PDF would be better, and I'd argue should be our initial implementation, as it could include JSON and named fields so someone could reverse engineer the metadata more directly.
• If we require the use of VerifierPlus for this function, I think we need to add the ability to get the raw JSON of the credential from VerifierPlus. In my original view, this feature was to allow the wallet holder to share their credential with only the PDF (or PNG) being the intermediary and not an intermediary to another service (VerifierPlus). Or does the question below come into play?

Question: Do we always need something like VerifierPlus, or other external storage location, if we generate a PDF/PNG because the credential will almost always be bigger than what we can store in JSON encoded as a QR code?

[jchartrand]

@bmuramatsu

1. Some credentials can fit entirely in a QR. A degree, for example, should fit (assuming any images are urls and not embedded base64). But some credentials won't fit (CLR for example) and so, as you point out, need a hosted location to which the QR can point. We could potentially do something like calculate how big the credential is and then either encode it entirely in the QR or tell the user they need to host a copy.

2. If the wallet builds the PDF, we can still add the VC data to the PDF as metadata. And actually, I suppose we could add the entire VC to the metadata, including the proof, and a verifier like VerifierPlus could (if the PDF were uploaded to VerifierPlus) automatically look for the VC in the metadata. And likewise, the LCW could import VCs from such PDFs (if the PDF were somehow given to the wallet.) And maybe the location in the metadata is something that could somehow be standardized, maybe by talking to Adobe, or maybe just defacto standardized by telling everyone to always put the VC in the same place in the PDF metadata, or also asking if the VC spec might recommend always putting it there.

3. You are right that it might well be just as easy - and possibly even easier - for issuers to generate a PDF rather than an image.

One thing to note is that whether the issuer provides a PDF or an image, we still probably want to dynamically add the QR from the wallet. Because if the issuer adds it (at issuance time), that means they likely have to provide hosting for the credential, and:

• the issuer might not want to provide hosting for credentials.
• the issuer might require user consent before hosting a copy, and don't want the hassle/liability of dealing with consent (including keeping records of consent)
• the location of the hosted copy might change over time, and if the issuer issues the PDF then they'll have to reissue when the location changes, whereas with the LCW, the student can just change the location and regenerate without involving the issuer.
• the student may not want to use the issuer's hosting service

Note too that my guess is that some issuers won't provide either a png or a pdf, and so we might want a 'generic' PDF option that just transcribes metadata from the VC into the displayed PDF in some way (propertyName: propertyValue?), along with a QR. With a message like, "This data is reproduced from the verifiable credential, which itself is embedded in this credential" or something like that. And maybe (@dmitrizagidulin) this is where the renderMethod might specify which fields should be shown in the generated PDF, possibly also with things like display names to use for properties, which property to use as a header logo, or maybe the renderMethod itself specifies a url for a logo image, etc.?

[kayaelle]

Adding another thought - if the wallet prints the PDF based on a rendering suggestion by the institution, other wallets will be able to do this too.

[jchartrand]

@dmitrizagidulin

How feasible is it to have a renderMethod that describes a layout in terms of positioning and size, so like:

• for a letter sized page:
  • property issuer.name should have font size 14, should be centered vertically, and should be positioned 2 inches from the top of the page.
  • property.issue.image should be centered vertically and positioned 1 inch from the top of the page with image size 40X40
  • generated QR should be positioned 9inches from the top of the page and 6 inches from the left side of page.

And then a wallet could use whatever software they want to generate a PDF, or to generate a PNG, or even an html page.

I'm guessing the allowed instructions would have to be very constrained, but maybe that is okay for generating a basic PDF?

This approach would still leave issuers with the option of simply saying that the entire page should be taken up with a single image they provide that contains their pre-rendered credential display.

As an example of where someone has done something similar, this project takes a LaTeX typeset document and renders it to a PDF, all with javascript:

http://manuels.github.io/texlive.js/

Note that demo site worked for me in Firefox, but not Safari where although it seemed to generate the pdf, it didn't open it properly.

It would even be pretty cool to have a LaTeX renderMethod.

[kayaelle]

Plan for this issue:

1. Issuing system includes SVG/HTML template in renderMethod in the VC:

{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/14",
"validFrom": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"renderMethod": [{
"id": "https://example.edu/credentials/BachelorDegree.svg",
"body": "........"
"type": "SvgRenderingTemplate2023",
"name": "Portrait Mode",
"css3MediaQuery": "@media (orientation: portrait)",
"digestMultibase": "zQmAPdhyxzznFCwYxAp2dRerWC85Wg6wFl9G270iEu5h6JqW"
}]

}

2. LCW provides an option to “save as PDF” which can be shared using same options as current share. Note: discuss language translations for both LCW & PDF.

• If renderMethod present in credential, save as PDF uses this
• If no renderMethod, use a default template

Example javascript code that converts from SVG to PDF: https://codepen.io/eyaylagul/pen/XoNMYE

3. Next Phase - add share link as QR code to PDF
   Needs design planning

Issues to create:

• Create Sample/Default SVG Template

• Create example badge including renderMethod w/SVG template

• Save as PDF on LCW

• Research PDF libraries for react

[kayaelle]

Examples folder: https://github.com/digitalcredentials/docs/tree/main/credential-render-examples

[kayaelle]

Closing. This issue replaced with #519 & #518