[MINUTES] VCWG Spec Refinement 2026-01-07

VCWG Spec Refinement Summary - 2026/01/07

*Meeting Date:* 2026/01/07 *Time:* 11:00 EST *Attendees:* Benjamin Young,
Brent Zundel, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Ivan Herman,
Kevin Dean, Manu Sporny, Michael Jones, Phil Archer, Phillip Long, Ted
Thibodeau Jr, Vasileios Konstantinou, Will Abramson
Meeting Topics and Key Points:

   -

   *Meeting Recording and Transcription Notification:*
   - Brent Zundel initiated the meeting by announcing the automated
      transcription and recording of the meeting, as per W3C process
guidelines.
      - The transcript will be retained as meeting minutes and archived
      indefinitely on W3C servers.
      - Consent was sought from attendees, with no objections raised.
      - A discussion ensued regarding the implications of a single
      individual being able to halt the transcription process and the
need for a
      process that doesn't unduly disrupt meeting operations.
      - The audio recording is intended to be deleted after minutes are
      published, to align with traditional meeting minute practices.
   -

   *Pull Request Review (Render Method):*
   - *OCA bundle render method:* This PR is currently blocked due to
      conflicts and the pending introduction of a unified templated
parameterized
      render method. Awaiting input from Patrick.
      - *Introduce render method for untlated renderings:* This PR has
      requested changes from Dave Longley and minor editor requests from Ted
      Thibodeau Jr. It was noted that this might be closed or
refactored based on
      the upcoming HTML rendering method discussion.
      - *Cardlike display of wallets (Draft):* This PR, developed by Nate,
      proposes a simple card-like layout for displaying credential information.
      It aims to provide a summary layout that is separate from more
graphically
      intensive render methods, with considerations for
internationalization and
      accessibility.
      - *PR 41 (Mustache Specification Reference):* This PR proposes
      referencing the Mustache specification directly instead of copying the
      string replacement algorithm. Concerns were raised by Ivan
Herman regarding
      the stability of the referenced URL. Manu Sporny suggested that the
      upcoming HTML rendering method discussion might resolve the need to
      refactor Mustache.
   -

   *HTML Render Method Proposal:*
   - Manu Sporny and Dave Longley presented a proposal for an HTML-based
      templated rendering mechanism.
      - The core idea is to leverage HTML and JavaScript within a sandboxed
      iframe with Content Security Policy (CSP) directives to create a
secure and
      versatile rendering environment.
      - *Key Benefits:*
         - HTML is programmable, interactive, responsive, and has good
         accessibility and internationalization stories.
         - Sandboxing mechanisms are broadly deployed across modern
         browsers, preventing privacy concerns like tracking and
wallet location
         identification.
         - Allows for arbitrary templating mechanisms (e.g., SVG, PDF,
         audio, animation) to be used within the sandbox.
         - Potentially unifies existing render methods like SVG, PDF,
         OpenAttestation, and Singapore-based mechanisms.
      - *Technical Details and Considerations:*
         - The HTML document and associated JavaScript must be
         self-contained and baked into the source document, as external network
         communication is blocked by default.
         - Tools like Webpack can be used for bundling JavaScript and
         templating engines.
         - Warnings about VC size and the implications of remote linking
         will be necessary in the specification.
         - The sandbox attribute on iframes and CSP directives are key to
         achieving the desired security.
      - *Impact on Existing Render Methods:* This proposal could lead to
      the deprecation or removal of several existing render method drafts.
      - *Discussion Points:*
         - *Print to PDF Use Case:* Dmitri Zagidulin inquired about the
         method's ability to handle print-to-PDF scenarios without requiring a
         separate browser rendering engine. Dave Longley clarified
that while the
         mechanism requires an HTML environment, it can facilitate
passing data for
         PDF generation or linking to downloadable PDF files.
         - *NFC Render Method:* Dave Longley reminded the group of existing
         simpler render cases like NFC transmission, which do not
involve visual or
         audio output.
         - *Linked VCs:* Phil Archer asked if a rendered VC within a
         sandboxed iframe could contain a clickable hyperlink. It was
confirmed that
         by default, navigation is disabled in the sandbox, but this can be
         configured via CSP directives.
         - *VC Size and Linking:* The trade-off between embedding VCs
         directly and linking to them was discussed, considering size
constraints
         and parsing limitations on mobile platforms. Both embedded and linked
         methods will need to be supported.
         - *Rendering Environment:* Manu Sporny questioned environments
         that would require rendering without an HTML engine,
suggesting most modern
         devices have access to webkit or equivalent rendering capabilities.
      - *Next Steps:* The group expressed enthusiasm for the proposal and
      anticipates seeing a pull request for the HTML render method.
   -

   *Closing:*
   - Phil Archer thanked Dave Longley, Manu Sporny, and Benjamin Young for
      their work on the HTML render method proposal.
      - The next meeting will be a full working group meeting.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2026-01-07.md

HTML:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2026-01-07.html

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2026-01-07.mp4
*VCWG Spec Refinement - 2026/01/07 11:00 EST - Transcript* *Attendees*

Benjamin Young, Brent Zundel, Dave Longley, Dmitri Zagidulin, Elaine
Wooton, Ivan Herman, Kevin Dean, Manu Sporny, Michael Jones, Phil Archer,
Phillip Long, Ted Thibodeau Jr, Vasileios Konstantinou, Will Abramson
*Transcript*

Michael Jones: Just

Phil Archer: could be running the meeting today.

Manu Sporny: I think this is the render method call,…

Phil Archer: I think this is the

Manu Sporny: right? Dimmitri is up today.

Dmitri Zagidulin: I thought it was the other one. my apologies, but we
happy to dive into render method.

Brent Zundel: I'm pretty sure the last one was confidence method and so if
my recollection serves today would be render method as So I have one small
piece of business that needs to be taken care of today and…

Dmitri Zagidulin: Excellent. then let us dive in.

Brent Zundel: any day that we proceed with meetings with this format. as
folks may know, I am the chair of the process CG. And as such, I have had
far more time to dedicate to pouring through the process than most people
should ever have to spend time pouring through the process. and there is a
very clear bit from the process about recording and auto transcription of
meetings which is what we're doing with these. and so this is to announce
that we intend at the start of this meeting to do an auto transcription.

Brent Zundel: The purpose of this transcription is to serve as a record of
the discussion primarily for the working group to have at its fingertips.
how is the transcript being retained? I believe it's being retained as
meeting minutes. Is that right?

Ivan Herman: Is that correct? You mean the minutes?

Brent Zundel: And how long will these meeting minutes be held until the
heat death of the universe because the W3C will stand that long? Yes, the
minutes will be around archived.
00:05:00

Ivan Herman: They are archived with the rest of the working group minutes
at GitHub.

Brent Zundel: All is there anyone here who withholds consent for retaining
this automated transcript?

Brent Zundel: Okay, I'm not hearing anyone withholding auto transcription
can proceed and apologies for future meetings…

Brent Zundel: which also should have this happen at the beginning of every
single one of them. Yay. Yeah.

Dmitri Zagidulin: Wait a question.

Dmitri Zagidulin: Go ahead.

Brent Zundel: No, no, go ahead.

Dmitri Zagidulin: Somebody I think it was just echo. So, a question. you
said we need to warn about this or…

Dmitri Zagidulin: flag this at the beginning of every call. Is that what
your last comment was?

Brent Zundel: Yep. Yeah.

Dmitri Zagidulin: So add these meetings are recorded etc.

Dmitri Zagidulin: Got it.

Brent Zundel: I mean and basically just say an automatic transcription of
this meeting will be held indefinitely at a W3C namespace if there's
anybody who objects to that and if anybody objects then we can't do the
auto transcription according to the current process that we're operating
on. So I'm on it.

Manu Sporny: Yeah, I don't want to go into process things. I just a note
for maybe the process CG. I think it should be an option for the working
group to continue and that party to not say anything or for the working
group to say that sorry this is the way we operate. my concern here is that
you can have one person throw off the entirety of the meeting,…

Manu Sporny: I think that's for later. Today, we don't have that problem,
but I'm concerned about what happens if you have a random individual show
up and then, say that stop the working group from being able to operate as
it normally does. That's it.

Brent Zundel: I agree with that concern.

Brent Zundel: This little bit has been part of a much larger conversation
that's been happening. This comes up in the AB meeting all the freaking
time. there are people who feel deeply and very strongly about this and I'm
hesitant to believe that it could ever be changed too much. But I will
certainly I mean as problems arise, please let us know. If you're things
completely got derailed, we have to fix this. Please let us know so that we
have those data points.

Michael Jones: Brent, people feel strongly about what?

Brent Zundel: People feel very strongly about their words being
autotranscribed and…

Phillip Long: Thank you.

Michael Jones: Okay.

Brent Zundel: the usually accompanying inability to say don't scribe this
next part.

Brent Zundel: Iman, you got your hand up.

Ivan Herman: Yes. I mean to clarify one thing…

Ivan Herman: but that's a question to money. The audio recording itself is
not stored. Is that correct?

Manu Sporny: It's stored on the CCG servers, but we can change that.

Manu Sporny: So, it's deleted

Ivan Herman: Because…

Ivan Herman: if we do that, if we delete the audio once the minutes are
published on wherever it is published,…

Phillip Long: Oops.

Ivan Herman: then the whole situation is not much different from any other
meeting minutes that we have. people can ask to have some things deleted or
changed if that's creates a problem for them. That's also true for the
minis that we produce with the traditional

Brent Zundel: I suspect that the pressure in and allow automatic
transcription is going to increase because the tools are getting much
better and scribing is miserable.

Brent Zundel: And it'll be interesting to see how the holdouts against that
respond. So if problems arise, please let us know because there are people…

Dmitri Zagidulin: Thank you.

Brent Zundel: who are like no this needs to change in the process. So at
the moment though if we could spend 30 seconds at the beginning of each
call and say there's going to be an automated transcription the recording
from this is going to be deleted but there's not an automated transcription
that will persist as the notes. Is there anybody who objects? If you have
that at the beginning of each call, then we're covered by the process. And
as problems arise, let us know.
00:10:00

Dmitri Zagidulin: And just to clarify the option of saying if you object
drop off is not a good option, right?

Brent Zundel: It's I mean,…

Brent Zundel: if someone is a paid member of the W3C who has joined the
group, they have a right to attend the meetings.

Dmitri Zagidulin: Right. Got it.

Brent Zundel: And so It doesn't really work to say sorry you can't come.

Dmitri Zagidulin: Yep. Understood. Just wanted to check.

Brent Zundel: Yeah. Yeah.

Dmitri Zagidulin: Yep. Thank you so much,…

Brent Zundel: And now I'm going to be quiet because I'm not in charge of
leading this meeting.

Dmitri Zagidulin: Brent. All welcome everybody to what is hopefully going
to be regularly weekly spec improvement meeting.

Phillip Long: What's up?

Dmitri Zagidulin: This is the render method half of the call. This meeting
is going to be transcribed and the transcription is going to be stored on
W3C servers. So if you object, let us know. I'm just practicing. All right.

Dmitri Zagidulin: So I suspect a lot of us after the sort of holiday break
need to refresh our memories on what all is going on with render method. So
let us start with the poll requests and then we'll do issue processing.
I'll share my screen. Go ahead, Mano. Okay,…

Manu Sporny: Just a real quick agenda request. we have done some work on
HTML render method and we'd like to report out to the group on that because
we think it might impact a number of the issues. so after PR processing
just an agenda plus please on HTML render method.

Dmitri Zagidulin: All right, so we'll take a look at the PRs there.

Dmitri Zagidulin: there aren't that are actionable today and then we'll go
to the HTML render method. Thanks, All sharing screen. Here we go. Okay.
So, we have Several of these we discussed during the last call. So, let's
start with this one. this is an older one about the OCA bundle render
method.

Dmitri Zagidulin: I think during the last call we mentioned that one
there's conflicts but two we're hoping to introduce a unified templated
parameterized render method that this one may need to be revisited. So,
we're waiting on the OCA bundle by Patrick, who I don't think is here on
this call. next up, we have introduce render method for untlated
renderings. so, we have some requested changes from Dave Longley.

Dmitri Zagidulin: We have a couple of minor editor requests from tall TED.
which looks like may have been reminder to everyone take another look at VC
render method 38 and give your thumbs up or change requests. let's see.
We're in the special topic all channel.

Dmitri Zagidulin: So, I'm just going to press I'm going to paste on IRC the
URL to this pull request 38…

Phillip Long: We are not.

Dmitri Zagidulin: unless we're not using IRC for these calls. in that case,
I will post these into Zoom. All right. So, any questions about the render
method for untlated renderings,…

Manu Sporny: I think we're going to close this one based on…

Dmitri Zagidulin: right? Okay.

Manu Sporny: but that's a part of this upcoming discussion I think just a
heads

Dmitri Zagidulin: Okay. Great. Understood. Yeah.

Dmitri Zagidulin: So we have a couple of PRs that will need to be closed or
refactored based on All right. So this is 38. Okay, let's move on to the
next one. cardlike display of wallets. that this one's a draft. so it's not
ready for review yet. Otto, Let's see. I'm not sure if is on this call, but
are there any questions about this one? Go ahead, Mono.
00:15:00

Manu Sporny: No questions. This came about again as a discussion of this
other item on HTML rendering. the Nate put together a proposal. I think
this comes from kind of the education community about just a really simple
card like layout that doesn't have any rich graphics or anything. are the
names and here are the properties that the issuer of a credential would
like to be able to be displayed in a very simple row based layout.

Manu Sporny: you're seeing a lot of digital wallets do this kind of thing
in a variety of different ways and guess as to what information should be
shown and so this is I think Nate's attempt to create a summary layout for
a credential. so that's what this PR is about. There's some questions
around internationalization, accessibility, and that sort of thing that
we'll need to talk through there. But, I think the expectation is that this
render method would be separate from the other more graphically intensive,
render methods. That's it.

Dmitri Zagidulin: Got it. And we discussed it during the previous call last
month and mentioned that it needs some refactoring and then we'll revisit
it. Dave, I did you have your hand up? All next up, we have a recent PR,
I'm not recognizing by All and this one's a fairly straightforward one. it
references the mustache specification instead of copying the …

Dmitri Zagidulin: mustache string replacement algorithm.

Dmitri Zagidulin: So this one hopefully is not very controversial. we'll
request 41. please take a look. we've got go ahead Ivan.

Ivan Herman: Yeah, I hope it's not controversial.

Ivan Herman: The question has always been on these kind of things whether
the document that we refer to is stable enough to be normatively referred
to. I don't know. I have seen mustache for many years.

Ivan Herman: So I would think it's stable but a reference to a GitHub.io
URL is not necessarily a good sign.

Dmitri Zagidulin: So that's a very good point and…

Dmitri Zagidulin: normally I think if this was a specification I completely
agree with you.

Dmitri Zagidulin: My only hesitation is that we're essentially in the land
of media type specific processing, right? We're essentially saying process
this according to the media type and if it happens to be the mustache one,
then do whatever mustache. So I'm not sure that when referring to specific
processing, we require that media type to be spec stable. but let's I think
Mona go ahead.

Manu Sporny: Yeah, just noting something that Dave said in chat. I think
the upcoming HTML rendering method discussion might get rid of this concern
of having to ref mustache while still being able to support mustache and a
variety of other templating engines.

Dmitri Zagidulin: Got it. Okay.

Dmitri Zagidulin: but question mano if what about Ivan's concern that do

Manu Sporny: If we have to mustache, it's stable, Avon. And I'm fairly
confident that we can find a way to ref it properly.

Manu Sporny: I agree with you that the GitHub link is problematic, but
mustache has been stable for a long time. And Yeah.

Ivan Herman: Yeah, that's…

Ivan Herman: what I would expect that we need to defend this industry in a
way.

Manu Sporny: I'm saying we won't have to defend this if the proposal we're
about to make sees any kind of adoption by the working group.

Ivan Herman: Okay, we will come back to that if necessary.

Dmitri Zagidulin: pause for leaving comments. maybe brought up the fact
that it's addressed seeded by the HTML.
00:20:00

Dmitri Zagidulin: all Okay. So I think that those are all of the new action
to be taken PRs. So let's talk about the HTML proposal especially since
it's seems to be touching on a lot of these open PRs. o over to you Dave
and Mono.

Manu Sporny: Yeah, thanks Dave, I don't know if we I think pulling up the
source code would probably be starting. So let me start but with kind of a
high level thinking around this. Apologies. Don't have a document. Don't
have a PR. but wanted to pass this by the group before we put in the
effort. okay so we have in the group and in the community had multiple
requests for some kind of HTML templated rendering mechanism. and there are
a lot of arguments for why HTML right it's fully programmable. It can be
interactive. It's responsive to layout. it has a good accessibility and
internationalization story all these things are benefits.

Manu Sporny: the main argument against it and I am one of the people that
was very opposed to it until recently was that we don't have enough control
over sandboxing meaning that there are things you can do to escape the
sandbox and what that means is that you can then start tracking people and
figuring out what credentials they're showing and figuring out where
wallets exist in the world and all kinds of really terrible things from a
privacy perspective. more recently we've run a series of experiments and
found out that that is incorrect. So, Dimmitri, you were right. I was
wrong. there are combinations of sandboxing mechanisms that you can use on
an HTML iframe through the sandbox feature that are broadly deployed across
every single modern browser.

Manu Sporny: and are available to us if we want to use it. So basically
what we can do is we can have an HTML document with an active programming
environment which means that JavaScript's enabled. We can turn off all
external network communication to that sandbox. So it can't reach out and
ping back or report on, the display. So it's just this fully contained
rendering engine. and with just HTML and JavaScript the person that is
deploying that that verifiable credential can use any templating mechanism
they want. They can render to SVG if they They can render to PDF if they
want. They can support audio. They can support animation.

Manu Sporny: they can support all these crazy things that L supports in a
fully sandbox mode. the remaining concerns are resource usage and things
like that. and you can constrain those things as well. this capability
exists on Android, Windows, Linux, Brave, Chrome, Chromium, Safari, every
modern platform that is probably going to try and display a visual
verifiable credential. so it's a revisit of this assertion that we can't
sandbox we can sandbox and as a result of that it may be that we can unify
all of these things.
00:25:00

Manu Sporny: so if we're able to do this, we can get rid of SVG render
method, we can get rid of PDF render method, we can unify the open
addestation render methods, and we can unify the Singapore based mechanism
because that's HTML based as so, let me pause there. Dave, did I miss
anything high level? And then I'd like to just get a reaction from the
working group on is this path worth pursuing through a PR or do people have
remaining concerns?

Dave Longley: Just to respond I don't think you missed anything high level.
There are some lower level details around sandboxing and other technologies
that have to be used to accomplish this goal but we can get into those
details as needed later.

Dmitri Zagidulin: …

Phil Archer: Do you have an example to hand?

Dmitri Zagidulin: this is all No,…

Phil Archer: Dei, I should have put my hand. I'm sorry.

Dmitri Zagidulin: no, please go ahead.

Dave Longley: Actually yes and…

Dave Longley: I can go ahead and put into chat some test code that we've
been running if this is for the highly technical people. the second link is
the GitHub pages for the first link which is a repository that has the
source code in it. So anyone who wants to look at source code can look at
that first link and the second link shows you a simple technical demo with
a button. If you press that button The rendering is just in JSON. that
rendering could have displayed anything at all. but it's a tactical dev
demo.

Dave Longley: So, it's just showing that the credential in JSON and it's
demonstrating a sandbox plus CSP protected display of a verifiable
credential.

Dave Longley: If you open up the console in Chrome or whatever browser you
have, there's also some stuff that's printing out that's demonstrating that
network connections are blocked. And Monu is going to present that.

Dmitri Zagidulin: Thanks Dave.

Dmitri Zagidulin: This is all music to my ears. since I do think that this
is incredibly useful. content security policy directive does what it says
on the tin. Excellent.

Dmitri Zagidulin: So I think the question and I suspect the rest of the
folks on the call have is so what should be our next steps on this? does
anybody want to okay we have two sort of big ticket items. one is to
propose a templated parameterized render method based on this and then the
other one I guess there's a procedural question of we should give guidance
of when implementing this method put it behind an iframe with the CSP
directive where does the implementation guidance belong can we put it in
the spec or does it necessarily need to be in a implementation head. So
that's a question to the group. Hi Evan.

Dmitri Zagidulin: Go ahead.

Ivan Herman: So I think that it depends on the sizes of course…

Ivan Herman: but at first hand I would think that putting implementation
guide into the spec is acceptable unless it becomes very complicated and
convoluted. But if it's acceptably simple, let's put it this way, then I
think part of the spec is perfectly fine. but that's also a style of spec
writing. There are some people who do not like that and want the spec to be
as unreadable as possible because it should be reverse code, but that's not
me. I also had a question when I originally pushed do I understand well
that if we go that way then this makes money you said something like that
this makes all the current rendering method drafts…

Ivan Herman: which are in the spec essentially taken out. So the spec would
be the HTML rendering method with all the details and BS and whistles will
stop.

Dmitri Zagidulin: So I see mono in the queue.

Dmitri Zagidulin: But I'll jump in to interrupt and say all the proposed
methods except possibly for the overlay mechanism which is its own syntax.
00:30:00

Dmitri Zagidulin: But go ahead. Mono

Manu Sporny: Yeah, I think we do it in two passes. The first one is to just
define this thing we're talking about today and then the second pass is to
see if it provides equivalent functionality to the other render methods in
there. I think potentially we will end up there. of meaning there's no
reason to have different ways of doing HTML rendering because we know
because this mechanism does all of them. I'll also make a quick comment
Dmitri on what you said about we would define a templated thing.

Manu Sporny: we would not have to define any templated anything at this
point because the iframe the HTML rendering engine is running in a sandbox
thing you can run arbitrary JavaScript which means that you can choose
whichever templating language works for you. So we' say We don't have to
say it's a network subset of mustache. we don't have to say it's handlebars
anything else like that. you can actually put the template engine in the
actual source doc itself and use whatever templating mechanism you want.
which means for the OCA thing you can put an OCA engine into the HTML
document. you could use JavaScript as your templating language.

Manu Sporny: it allows you to use the tooling that you want to use. and as
long as that tooling runs on top of HTML and JavaScript which almost all
tooling does today we don't have to specify any of this in the spec right
meaning that's totally out of scope for the spec. It simplifies the spec by
a huge amount and it prevents us from having to have months-long
discussions around what subset of mustache are we going to use and so on
and so forth. he stopped

Dmitri Zagidulin: Go ahead, Benjamin. I think you're up next on the queue.

Ivan Herman: Benjamin open.

Benjamin Young: and double muted. Sorry, guys.

Dmitri Zagidulin: No worries.

Benjamin Young: Yeah, I was just going to point out to highlight the last
thing that Monu was talking about that people need to be aware that you're
shipping an h a self-contained HTML file with whatever JavaScript you need
in it to do whatever rendering you're going to do. So that HTML file
because it's in a sandboxed CSP container cannot do network request is not
going to go get libraries from somewhere. So this HTML app that you're
getting that's going to do the rendering can use mustache handlebars
whatever but it's got to have all of that baked into it.

Benjamin Young: So if your mental model was I have a web page and it's
going to use links and script tags that have src values like that's not
this environment. This environment is like everything is inlined into a
single HTML file and then stuck in the source doc value of an iframe to
keep it self-contained.

Benjamin Young: So that is an architectural thing that I hope everybody's
caught up with mentally. That's it.

Dmitri Zagidulin: Thanks. Dave,…

Dmitri Zagidulin: go ahead.

Dave Longley: Yeah, that's right.

Dave Longley: And this matches how a lot of people ultimately end up
deploying applications as bundles of things, but they do need to keep in
mind that no external connections or calls calls out will be possible. but
I want to be responsive to Ivon's comment around whether or not the entire
spec would only now be about an HTML render method. I don't think that's
true. the first obvious exception that comes to mind is this JSON card
summary rendering method that would not use HTML. And I think it's
important for us to also have the ability to provide something that can
output some simple sum summary card rendering thing for systems that do not
necessarily have HTML or that want to have control over their own display
and user experience in their application at least for certain interfaces.
So I think we would have at least those two things.

Dmitri Zagidulin: Thanks Dave. Phil and then Ivan and…

Phil Archer: Thanks.

Dmitri Zagidulin: I think I was on the queue after Phil.

Phillip Long: It's easy.

Phil Archer: Sorry.

Dmitri Zagidulin: Go ahead.

Phil Archer:

Phil Archer: I'm being very slow. might be help to catch up, but we're
talking about so this single HTML document, would it be linked from the VC
or embedded in the VC? And I'm getting confused with the use of an iframe
which is inherently not part of the page you're looking at. And where does
the thing come in that says no, there's a sandbox, you can't do anything.
So that Philillip's question becomes relevant about linking to other
things. I think we're talking about the rendering being sandbox, not the VC
itself. So, the VC could still link to other VCs.
00:35:00

Phil Archer: I'm just trying to get my head around where this stuff is, and
I probably need to spend time and not waste everyone else's time as I look
at it. But it feels right, but I'm just trying to get my head around it as
a simple web developer.

Dmitri Zagidulin: No, I think these are all excellent questions.

Dmitri Zagidulin: I can address some of them and…

Dmitri Zagidulin: be curious to hear about the others, but let's get Ivan
on the queue.

Ivan Herman: Yeah, I agree. These are good questions. So don't say that.
coming back to what Benjamin said, does it mean that plainly speaking all
the JavaScript must be part of the HTML file itself in a script tag or do
we have some sort of a bundling packaging mechanism that allows the scripts
to be put in their separate files and something

Ivan Herman:

Ivan Herman: because some of these scripts might be huge.

Dmitri Zagidulin: also excellent question.

Ivan Herman: So it might be very difficult to maintain something that
requires that to be part of the HTML file.

Dmitri Zagidulin: Okay, so couple of things. one to quickly address Phil's
question about embedded versus linked. So I think for all of these render
methods, we're going to need we're going to need to support fetch this
template from the net alternately validate the hash digest read it fully
embedded from this verifiable credential since it's signed over and then
process it.

Dmitri Zagidulin: the two methods have a fundamental trade-off. Some use
cases and implementers methods to be embedded will support only embedded
methods for various security and offline reasons. others must be able to
support linked methods due for example size constraints on the verifiable
credential. which to remind folks once a verifiable credential gets over a
certain size it not only can't be stored in a QR code most VCs won't be
able to store in a QR code unless they're incredibly minimal but more
importantly the parsing of them basically crashes mobile platforms. So we
do have a soft size limit on implementation of credentials.

Dmitri Zagidulin: So to summarize for all of these methods, we're always
going to have to be able to support both embedded and linked methods. the
thing that I wanted to bring up, the reason I got on the queue is if I'm
understanding what Manu and Benjamin are saying correctly, the template
substitution will have been already done at issuing point. So that aside
from embedded and linked that there's two basic categories of these render
method and it's essentially compiled at issue time and compiled at display
time.

Dmitri Zagidulin: and those are again two sort of fundamental trade-off use
cases and I believe the thing that is being proposed here only handles one
of those the template substitution things are compiled at issue time. and
so first let me go to the queue and ask is that a correct interpretation?
I've got mono

Manu Sporny: No that's not correct. It supports both. the way this
rendering mechanism works is you can pass the VC in with a subset of fields
to the HTML system which then receives the VC whatever parts you want to
send to it and then it can pull values out and do template substitution
with it. or you can not use a template and just hardcode everything and
embed it. so it supports both mechanisms and we'll go into the exact way
you accomplish that which gets to the other plus one to everything that you
were saying up until that point that was all correct. So we support remote
linking to HTML documents.
00:40:00

Manu Sporny: We support embedding it. the remote linking has digest
multibase hashes and all that kind of stuff. plus one to that. Phil you
also asked and again there's nothing for you to read yet, Phil. So don't
worry about Yeah.

Phil Archer: Okay. Yeah.

Manu Sporny: We're trying to figure out what we're going to write. but once
that's there, we'll put it out there. The other question that you had,
Phil, was around, the frame and how does that work and all that kind of
stuff. one of the challenges that we kept hitting when trying to create new
render methods is that exact same problem of mustache referencing it and
then figuring out what subset of it we're going to use and all that kind of
stuff. the nice thing about the HTML render method is it is already speced
as W3C specs and it has already been deployed out there and is in
production. So what's our point of reference for this? It's the HTML 5 spec
and how it works. There's a part of the HTML 5 spec that talks about
iframes and specifically sandbox mode for iframes.

Manu Sporny: So sandbox mode was put in for the ad networks so that the ad
networks couldn't sniff too much information about you. We are using that
feature to effectively shut down the entirety of the code's ability to
escape the sandbox. and so that's defined on the iframe element. That's why
I said You don't have to use an iframe. You can do, a bunch of different
other types of things to create the equivalent sandbox. But the easiest
thing for us to ref is to basically say do an do what sandbox mode with an
iframe does with with these content security policies applied. We ref all
the HTML 5spec, stuff to do that and we're done with our normative kind of
definitions there.

Manu Sporny: So that's why we keep saying iframe is because iframe has a
sandbox mode and that is the specific mechanism that we're using and we're
going to you can do anything you want to achieve that same effect but what
we expect most people to do is to effectively write the code that they've
longly linked to and has written and use that as the execution engine. what
that does is it creates this sandbox thing, and that sandbox takes an
input, the verifiable credential you want to send into it, with specific
fields. I think Dave, we allow filtering of the VC down to a subset of
fields, so you don't have to send the entire thing in.

Manu Sporny: and then the HTML engine gets that VC and then we'll do
whatever logic it needs to run to render it to the screen. Avon, you asked,
how does this bundling happen? All that kind of stuff. There are tools like
Webpack that do that already, right? So that build process to build all of
the JavaScript including template rendering engines and all that kind of
stuff into a package to inject it into the HTML already exist. it's common
tooling. and then the thing that is a result of the ability to do that is
you might have an HTML renderer template thing a file that is multiple megs
in size.

Manu Sporny: And so we're going to have to put in warnings into the
specification about keeping your VC size down by remote linking. And if
there is a remote link, then you may not want to download anything over
that type of guidance is stuff we can put into the specification. that's it.

Dmitri Zagidulin: Thanks, Benjamin and…

Dmitri Zagidulin: then Dave.

Benjamin Young: Yeah. I think…

Benjamin Young: if you think of this as the render method is providing the
runtime that receives some or all of a VC and then renders it via
JavaScript into HTML stuff that is displayed. You have the right mental
model. This is going to sound similar on to the web publication stuff Dave
and I were doing or many apps if you've come across any of the past webbby
attempts to have a constrained JavaScript and HTML engine that receives
some file and then does a thing. that's the foundational premise here. So
you can in effect do anything you want short of communicate with the
network. so the JavaScript receives a credential and then does whatever
it's going to do.
00:45:00

Dmitri Zagidulin: Thanks, Benjamin. Dave

Benjamin Young: So, just trying to continue to clarify what's being said.
Cheers.

Dave Longley: So, I put this into chat. I might be getting into too many
details here. U but just a quick overview. I think we're going to have some
basic interop things we'll need to put in the spec that just talk about how
to use standard browser JavaScript to to reduce the credential by the
fields that are specified in the render method. So this is selectively
disclosing the fields that will be displayed and then how to pass that
credential and the template from the render method into the iframe and then
getting a message back from the iframe that says it's ready for being
inserted into the DOM or displayed. so I think there's a couple little
places where we will talk about what someone who wanted to implement this
So anyone could plug in any HTML render method from an issuer would need to
do.

Dave Longley: so there's a few little points there that can go into the
spec that will cover

Dmitri Zagidulin: Thanks, Dave.

Dmitri Zagidulin: One second. my to start with so I really like this
approach and I think it's going to address several of the use cases. My
main concern about it is or I guess it's more of a question is does it
handle the print to PDF use case?

Dmitri Zagidulin: It sounds like it requires a browser rendering engine to
run the browser rendering engine and a JavaScript runtime. to process it
inside the iframe, it performs the template substitution. so my question is
more about let's say the use case that my team at DCC implements which is a
static HTML template perform the application code performs string
substitution and then converts that to PDF without firing up a separate
browser

Dmitri Zagidulin: a renderer and JavaScript runtime. So I see Dave on the
queue, so maybe you can address that.

Dave Longley: I don't know about that latter bit, but what I was on the
queue to say was using this mechanism, you can pass the VC in and a
template into this iframe and you can have the iframe perform whatever
templating you want to, whatever substitution you want to. You can have a
display PDF. You can also put print links from there.

Dave Longley: So you could download a PDF file or any other file format you
would want from this. So those are the affordances. I don't know if that
addresses your last comment which was because you were saying without
having another HTML environment but this whole method requires there to be
this HTML environment.

Dmitri Zagidulin: I see.

Dmitri Zagidulin: I So I think it may be obvious but just to state
explicitly. So this method will be able to cover a lot of the use cases but
we will need a couple of other render methods for the remaining use cases
that can't use an iframe and JavaScript runtime. let's see. Mono and then
Dave.

Manu Sporny: Possibly like that. That's what the summary card thing is
about. I am wondering and this is one of the questions that came up
internally. I think the response is if you are on an environment that wants
to print or render this tell us what environment doesn't have an HTML
engine today where you want to do that. Right?
00:50:00

Manu Sporny: And so I'm not talking about IoT devices. I'm saying you are
on something and you want it to print to PDF. what are you using that
doesn't have an HTML engine? Right? So if it's Android and iOS, you've got,
WebKit and iframe and you can instantiate So all mobile phones have that
today. If you're on a desktop, you've got again multiple, browser options
there. if you're on a Raspberry Pi, it's got multiple, rendering engines
that you can provide there. Multiple headless implementations, Chromium,
you can pull it in and run it in headless mode. So, if you're even on a
server, you've got these render environments.

Manu Sporny: so I think the question is if we hit a use case like that, we
need to hear from the person what device are you using where you need to do
this and it doesn't have access to a rendering engine, I think that should
be the first question we ask people, is name the environment that you're
really using in production that doesn't have access to a rendering
environment or an HTML engine. That's it.

Dave Longley: I also wanted to remind the group that we have at least one
other simple render case which is rendered to NFC that doesn't involve any
visual audio or anything. It's just transmission over NFC. So we do have
some very simple cases but I think if you bring in visual downloading files
anything of that sort I think everything the monu just said is a great way
to frame the conversation to ask where if you need to do these things where
is it that you need to do them where you don't have an HTML engine to
accomplish

Dmitri Zagidulin: Thanks, All do we have any other questions from folks? so
this sounds like a very useful method and I think we're all looking forward
to seeing the poll request. Any other questions? All right.

Phil Archer: Demetri, if I may just chuck in a thank you to Dave and…

Dmitri Zagidulin: Yeah, please go ahead. Likewise.

Phil Archer: Manu and Benjamin for working on this. This obviously sounds
very exciting and very valuable work that's moving us forward. So, thank
you for taking the time to do it.

Dmitri Zagidulin: thank you much. I do have a question about rendering this
as a list, but Vana, you're on the queue.

Manu Sporny: I speaking just reminded me that we didn't answer one of your
questions Phil which was what do you do with VCs that are linked from one
to the other I think right now you can take one of those VCs and put it
into the rendering engine. it may be that you could fully resolve a network
of VCs and send it into the rendering engine. I think that's work that
still needs to be explored. But I'm pretty confident that for the supply
chain use cases that GS1 is looking at and working on. I'm fairly certain
either the single VC itself can definitely be rendered and…

Phil Archer: Actually, just a thought on that.

Manu Sporny: I think we could even get to a network of VCs. but that's some
work that still needs to be done. That's it.

Phil Archer: If the rendered VC in the frame that is sandboxed contains a
hyperlink, can I click it or is that blocked?

Manu Sporny: It's blocked.

Phil Archer: It's blocked, right? Okay.

Dmitri Zagidulin: Wait, wait,…

Dmitri Zagidulin: wait. are you sure? because I think the sandbox is to the
JavaScript not to the resulting HTML. Safety.

Manu Sporny: I think you can turn things on and off in the sandbox through
the CSP directives and I think there's a way to allow that if I remember
correctly and this is going to be a discussion on the details right which
content security policies do we enforce by default do we allow people to
you allow links, things like that.

Dmitri Zagidulin: Dave, go ahead.

Dave Longley: Yeah, there are details…

Dave Longley: but by default navigation is disabled.

Phil Archer: Okay, thank you.

Dave Longley: So there are details we can work through as we look at it and
figure out what's okay, what's not okay, and what security privacy
considerations might

Dmitri Zagidulin: Got it. Okay. So, yeah, there's going to be several use
cases where, for example, you want to embed an image source into it where
you're going to links that will need to be openable, but it sounds like
that's toggled on the CSP level.
00:55:00

Dmitri Zagidulin: And thank you, Benjamin, for the documentation link. All
right, any other questions from the group? we're almost at the top of the
hour, so this is a great place to end.

Ivan Herman: confidence.

Dmitri Zagidulin: right, thanks everyone. I see you next week for content
for not got that for a Okay,…

Phil Archer: It's a full working group meeting next week.

Dmitri Zagidulin: it is a full working group. Okay, got it.

Phil Archer: Yeah. Yep.

Dmitri Zagidulin: right. Cheers.

Phil Archer: Thanks for Thanks. Thanks everyone.
Meeting ended after 00:56:50 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*