Discuss PDF rendering expectations.

[BigBlueHat]

#49 proposes removing the current pdf-mustache approach to "rendering PDFs" from the current specification text with the plan to lean on the new "sandboxed HTML" approach. However, it's not clear from either the past or the proposed future what the expected rendering / experience might be.

Is the expectation that a PDF will be displayed within the Wallet/Renderer UX? or offered for download? or sent to a printer? or all of the above?

In recent tests, the sandboxed iframe environment prevents many of the approaches typically used to do "HTML to PDF". For example html2pdf.js completely fails due to being unable to clone HTML within a sandboxed iframe.

That said, other options exist for doing PDF creation in JavaScript, they just avoid HTML (and therefore HTML-based templates). For example, pdfmake uses a JSON structure to create PDFs. See the pdfmake playground for examples of what's possible there.

I've got some demo code in progress for using pdfmake, however, because the sandboxed iframe cannot create another iframe within itself--nor use <embed>, <object>, etc. the browser-based PDF renderers cannot be used to render the application/pdf that's generated. It can, however, be linked do as a download.

Consequently, to fully display a PDF generated from within the sandboxed iframe, the sandboxed iframe would need to send back (via postMessage) the generated application/pdf and allow the Wallet/Renderer to do the display. However, doing that "voids the warranty" of the sandbox a bit because PDFs may contain server-side communication and make network requests.

Which brings me back to the main question around expectations of display/experience with PDFs in Wallets/Renderers.

[iherman]

This was discussed during the vcwg meeting on 19 May 2026.

View the transcript

Discuss PDF rendering expectations. · Issue #53 · w3c/vc-render-method · GitHub

Benjamin_Young: There might be some chance that those are library limitations.

Benjamin_Young: but it does point to a number of things that are not possible in the sandbox. So then I pivoted a little and explored a library called PDF make which is really just a JSON format for laying out a PDF and that also tripped over or fell over because I can make the PDF but I was no longer able to display it. I had the data for it. they could give me a data URL or a blob which I could put into an anchor tag with the download attribute and you could click it and download your thing and it would view in whatever the native viewer on your computer or phone might be.

Benjamin_Young: But the wallet renderer would not be able to display that. because you're not able to use embed or…

Ivan_Herman: Oops. Okay.

Benjamin_Young: object tags, those old guys. and you're also not able to just have a sub iframe inside the sandboxed iframe that has application PDF as its media type and the browser know what to do with that complains about origin problems and all kinds of stuff.

Benjamin_Young: mostly that centers around the use of SRC doc or source dock on the parent iframe in this case which then left it at the only option then to display it by the renderer is to somehow send that data out of the sandbox up to the thing doing the rendering and then let it sort of shell out to the browser or make a new iframe with just PDF in it or whatever. So in that sense display seems off the table within the sandbox unless we're okay with messaging the PDF data up a layer which is to the layer which already has the VC in total but PDFs themselves can also contain JavaScript and all kinds of other scary things.

Benjamin_Young: So it's worth considering that space. But what can happen now at least with the PDF make approach is that we can make download buttons if that's even wanted. So some of this is what affordances were people expecting a renderer to be able to provide in and around PDFs and then measuring that against what's actually possible and what holes we might have to punch in the sandbox to do any of them. That's it.

Manu_Sporny: Thank you, Benjamin.

Dmitri_Zagidulin: Benjamin, thank you so much for doing this work. this is amazing. This is exactly what's needed for us to sort this speaking for myself and my team and my use cases, the main affordance I would like to see is not display but the download. and yes I realize that posting back the sort of resulting PDF for the outer client to make a PDF out of it quoteunquote votes the warranty as you put it.

Dmitri_Zagidulin: But I think that's within our threat model because the main trust sort of pillar there is still trust in any case I would be content with just the download. I don't know if other people have display expectations, but I do think we can just posting back the message and rendering the PDF outside of the iframe would still allow us to have to display in the next step. Just passing it to a regular displayer. But over to you

Manu_Sporny: Thanks I guess my so let's get down to kind of like what are the I'm hearing the concrete options are within the iframe we provide a download button and then you can download as PDF or download as SVG as The other option is that we allow a post message or I forget what it's called back to the parent iframe that is effectively the raw content the raw content of the SVG as generated through whatever program is running inside the downsides there being that may be a dangerous object. and it may be that the thing using the render method really needs to be careful about what it does with that data.

Manu_Sporny: So, for example, in our threat model, as Demetri mentioned, we might say hey, it's really dangerous to just include this in a parent iframe that has network access…

Manu_Sporny: because it may do start doing some crazy stuff, are those the two general options that we have on the table? over to you, Benjamin.

<Ivan_Herman> +1 to Dmitri (not display but to download)

Benjamin_Young: Yeah, I think more or…

Benjamin_Young: less. But I think one note before we dig in a little is we need to keep SVG out of this conversation. It's not related in it's its own thing and renders fine in a sandbox iframe. PDF is the only thing in question here. and you could make any other file format downloadable just by setting it as the href of an anchor tag with the downloading is again not the problem.

Benjamin_Young: If we say that we're going to use post message and send back the raw data of the PDF then which is fine and we can explain that in a threat model. I think we will also want to constrain that post message to not be able to do anything else but PDFs because that threat vector is pretty identical to just rendering the HTML directly in a non-sandbox iframe. So, maybe the PDF display thing in your browser is a safer box than a wide open iframe.

Benjamin_Young: I don't know. Somebody would have to have to compare but it is a thing that if we're allowing more as originally conceived and I think written in the spec so far, at least the example the post message function is only used with to send back the word ready and that's it. and we're having to state that and constrain that so that you're not sending back more stuff that the renderer might do the wrong thing upon receiving it. So this changes that punches a good 8 and 1 half by 11 hole in the post message channel. and when we do that we need to think hard about why we're bothering with this sandbox.

Benjamin_Young: which might be we're only using post message for application PDF in this very constrained way and here's how we're going to further constrain the post message to not let other stuff through that hole …

<Dmitri_Zagidulin> displaying the Download button within the iframe is a big ask, since there's no way the iframe (or the issuer) knows what the UI/CSS expectations of the outer client is

Ivan_Herman: It's good.

<Phillip_Long> sending it back to the parent iFrame sounds bad to me.

Benjamin_Young: but it is an implementation thing we need to think through more than saying yeah this is a danger because it's the danger we just said we were avoiding by using sandboxes that's

<Dmitri_Zagidulin> not parent iframe, parent client. (like, the wallet)

Manu_Sporny: Plus one of that. So Benjamin, could we maybe the next steps here are for you to concretely propose those two approaches so that we can have detailed discussion on the next call. Would that work show us what the interface might look like? that gets the stuff out of there and then show us what would have to be done for the download links and then it feels like SVG is somewhat I'd like us to talk about the SVG thing as well…

<Phillip_Long> Thanks for the correction @Dmitri

Manu_Sporny: because it's important to Demetri and…

Benjamin_Young: I can yeah it's not related at all.

Manu_Sporny: I'm trying to figure out how Hey,

Benjamin_Young: I can work up examples, but SVGs live happy as clams and sandbox iframes and are safer to use in there because they could also have JavaScript in them just like any markup in a browser can, but it would be in the same constraints inside the sandbox. So unless there's some printing of them that you're wanting that maybe an iframe can't do, which I don't know if it can or not.

Benjamin_Young: I have not yet explored printing which is part of why I wanted to have this discussion but I did again I can work up an example but the experience so far is that SVGs are much simpler to work with and…

Benjamin_Young: and they don't require external viewers is the biggest difference I think that's

Manu_Sporny: Got it.

Manu_Sporny: I can think of a use case, but we can take that offline. Go ahead, Dmitri. You might be muted, Dimmitri.

Dmitri_Zagidulin: And just to be super clear, the download inside the iframe is a non-starter. because there's no way for the issuer inside their suggested display thing to know the the buttons of the client, what the outer environment looks like.

Benjamin_Young: the frame provides the button. that's the difference.

Benjamin_Young: So the thing you're rendering is a button that says download your PDF or whatever. How…

Dmitri_Zagidulin: That's my point though.

Dmitri_Zagidulin: The iframe doesn't have enough information. The outer client does.

Benjamin_Young: how would it not have enough information? So if I can render HTML, I can render an anchor tag that looks like a button that says download on it. and you click it and you get a download and the surrounding web page doesn't know anything that is well depends on…

Dmitri_Zagidulin: Yes, but it'll be unstyled.

Dmitri_Zagidulin: the issuer when issuing doesn't understand what styling requirements the outer environment will have. That's the main problem. That's why it's a nonsparter.

Benjamin_Young: who you talk to that's a thousand% true of this approach with render method unless we want to spec some ability for the wallet to inform UX inside the render method. But then I think that's exactly not why we're doing this for issuers to have full control over a little box in…

<Dave_Longley> if you want consistent theming, use a "data view" (aka json-card) render method

Benjamin_Young: which they can do stuff.

<Dmitri_Zagidulin> doesn't help, yeah

Dmitri_Zagidulin: Exactly.

Dmitri_Zagidulin: Of the display.

Benjamin_Young: So if no…

---