[MINUTES] VCWG Spec Refinement 2026-02-18

VCWG Spec Refinement Meeting Summary - 2026/02/18

*Meeting Summary:*

The VCWG spec refinement meeting on February 18, 2026, focused on
processing outstanding pull requests and discussing proposed changes to the
specification. A significant portion of the meeting was dedicated to the
"HTML rendering method" PR, which was ultimately merged after extensive
discussion on its implementation, security implications, and potential
renaming. Other topics included the process for handling contributions from
non-members, the introduction of a devcontainer.json for better developer
experience, and an initial discussion on an "AI Comprehension Render
Method."

*Topics Covered:*

   - *Processing Outstanding Pull Requests:*
      - Discussion and eventual merge of PR #41 regarding the mustache
      algorithm reference.
      - Significant discussion and eventual merge of the "HTML rendering
      method" PR.
      - Discussion and merge of the devcontainer.json PR for code spaces
      preview.
   - *Contributor Agreement and IPR:*
      - Clarification of the process for accepting PRs from individuals not
      formally part of the working group.
      - Decision to have Phil Archer reach out to Sebastian (the author of
      PR #41) to clarify his status and encourage him to join the working group
      or apply as an invited expert.
      - Discussion on GitHub's new feature to restrict pull requests to
      contributors and its potential implications for the group's workflow.
   - *"HTML Rendering Method" Discussion:*
      - Debate on whether to merge the PR immediately, given potential
      future superseding by the "HTML render method" (later proposed to be
      renamed "sandbox iframe method").
      - Agreement to merge the PR chronologically, treating it as a valid
      implementation until explicitly superseded through a formal process.
      - Discussion on the security implications of rendering HTML and the
      importance of the iframe sandbox mechanism.
      - Extensive debate on renaming the "HTML rendering method" to
      "sandbox iframe method" or a similar variant to accurately
reflect its core
      security feature.
      - Agreement to merge the PR and continue refining it, with feedback
      to be raised as separate issues.
   - *Developer Experience (devcontainer.json):*
      - Introduction and merging of a devcontainer.json file to streamline
      in-browser editing of specifications using GitHub Code Spaces, enabling
      live previews.
   - *Future Render Method Discussions:*
      - Proposal to rename the "HTML rendering method" to "sandbox iframe
      method" to emphasize security.
      - Consideration of future HTML-based rendering methods and their
      potential impact on naming conventions.
      - Initial discussion on an "AI Comprehension Render Method" and
      "Credential Analysis" proposed by Patrick St-Louis.
   - *W3C Process and Policy:*
      - Discussion on the general policy of requiring contributors to be
      members of the working group due to IPR agreements.
      - Consideration of GitHub's contributor restrictions as a mechanism
      to enforce membership.
      - Debate on whether the specification should be overly normative
      regarding web security best practices versus relying on general web
      security principles.

*Key Points Made:*

   - *Contribution Policy:* The preferred route for contributions is for
   individuals to be members of the working group to ensure adherence to IPR
   agreements. Non-members contributing via PRs require careful review and
   potentially a formal process to join as members or invited experts.
   - *PR Handling:* PRs should generally be processed chronologically. The
   existence of potential future superseding work should not prevent the
   merging of ready PRs, especially if they represent current implementations
   or market interest.
   - *"HTML Rendering Method" Security and Naming:* The core security
   feature of this method is the use of a sandboxed iframe. Renaming it to
   reflect this is crucial to avoid misinterpretations and to highlight the
   security measures employed.
   - *Developer Experience:* Streamlining the contribution process through
   tools like devcontainer.json can significantly improve developer
   engagement and encourage more contributions.
   - *Specification Normativity:* While specifications should be normative,
   there's a balance to be struck between defining precise methods and
   allowing for alternative implementations that achieve the same outcome,
   particularly concerning general web security best practices.
   - *Future Directions:* The group is open to exploring new render
   methods, including those involving AI for credential comprehension and
   analysis, which could offer significant value.
   - *Issue Management:* Long-running PRs are discouraged. Feedback and
   issues identified during PR review should be raised as separate, actionable
   issues for better management and resolution.

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

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

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2026-02-18.mp4
*VCWG Spec Refinement - 2026/02/18 10:56 EST - Transcript* *Attendees*

Benjamin Young, Brent Zundel, Dave Longley, Dmitri Zagidulin, Elaine
Wooton, Hiroyuki Sano, Ivan Herman, Kevin Dean, Nathan Rao, Parth Bhatt,
Patrick St-Louis, Phil Archer, Ted Thibodeau Jr, Vasilis Konstantinou
*Transcript*

Phil Archer: It's all very quiet. I'm guessing that is it from memory I
might have this wrong.

Phil Archer: Is it random method this week?

Benjamin Young: Yeah, that's…

Benjamin Young: what Brent had said on another call.

Phil Archer: Yeah. Right.

Dmitri Zagidulin: All right, sounds good. Shall we jump into it then?

Phil Archer: Yeah. Sounds like it.

Dmitri Zagidulin: All right, welcome everyone to the weekly etc render
method task for as usual, we're gonna process some of the outstanding poll
requests first and then go through issue processing. Before we start, does
anybody else have pressing concerns, things to add to the agenda? All
right. In that case, I'm going to share my screen.
00:05:00

Ivan Herman: So sorry I think we have to go through the pans of recording.

Dmitri Zagidulin: Yeah. yeah. That's So, this meeting is recorded, I
believe. we are as always under the W3C code of conduct and, under the W3C
IPR agreement. If you haven't signed it and you're not a member of the
group, please raise your hand, say something in chat, and we'll sort it
out. I don't mean to press record or anything like that, right? It's
handled automatically. Yeah. All right. Okay.

Dmitri Zagidulin: So couple of things. let's start with the lowhanging
fruit. We have this R by executive. I'm not sure what call name is, but
it's fairly minor PR. Just references mustache instead of sort of spelling
out the algorithm. it has two approvals. This is 41. Here it is in chat.
Folks want to take a look. But essentially it's got app No objections. Does
anybody have any objection currently? Otherwise we'll merge it.

Dmitri Zagidulin: Yes. Go ahead.

Dave Longley: I don't have any objection to merging it,…

Dave Longley: but I do note that I expect the other PRs on the HTML
rendering method to sort of u supersede it, but that's totally fine.

Dmitri Zagidulin: So I guess my process question is what is there any
preferred method?

Dmitri Zagidulin: Do we merge this one now and then just it'll be
superseded by Do we say overtaken by events? what Phil or others what do
you think

Phil Archer: I just want to give you some background on…

Phil Archer: who Executive is. I know him he's from a company called EECC.
which is part owned by GS1 Germany. and his company is actually the one
building our issuance wallet and solution. so I do know him. when I'm
trying to work out wearing my chair hat whether he's signed the IP
agreement, the contributor agreement because that's important in terms of
accepting PR requests from people so pull requests from people who haven't.
I think in this case for the reasons already discussed I don't think it's
an issue.

Phil Archer: but we should in general be careful about accepting pull
requests from people who are not usually on these calls. And I don't think
he's technically a member of the group. I could be wrong on that, so yes,
the fact that I know him isn't enough.

Dmitri Zagidulin: Right. Understood. that's a very good point. I see Ivan's
on the queue.

Dmitri Zagidulin: Go ahead.

Ivan Herman: So my feeling is that there has been this claim several times
that the HTML rendering method will make this one and…

Ivan Herman: some others oate. I think we should give credit to the authors
of the HTML render method in the sense that let's work on that. Let's see
whether it can be merged and when it can be merged then we will have to
prove that their statement is correct and…

Ivan Herman: then we can decide on this one and then we can decide on the
rendering methods which are already in the docume Just adding to the
document with the sort of feeling and knowledge that in two weeks we will
take it out looks funny to me.

Dmitri Zagidulin: I do have a process question,…

Dmitri Zagidulin: but Benjamin's on the queue. Go ahead, Benjamin.

Benjamin Young: Yeah, if this one passes the RPI IPR muster, I would merge
it. and I don't think we should assume that just because there's a possible
displacing thing in the HTML renderer method that this shouldn't go in the
meantime because people are clearly already implementing it, etc. and until
we're certain that the two do displace each other and that there's consent
in the market to go this direction being the HTML render method that it's
best to leave them both in process.
00:10:00

Benjamin Young: Having worked on both of them I don't want to just throw
the mustache one out until we're certain the group is ready. That's it.

Dmitri Zagidulin: And…

Dmitri Zagidulin: I agree with you that I don't think there's clear
consensus that the framebased method, the sandbox iframe necessarily
supersedes this one. I think the two can coexist side by side. okay,
Patrick, go ahead.

Patrick St-Louis: Yeah, I just wanted to maybe share my opinion about the
very simple question of do we merge this if there's subsequent change. I
would probably treat PRs in chronological order and whichever ones are
ready first have precedence on what comes after because otherwise if
someone has worked on a PR and then someone else started a new PR after you
don't want to invalidate the work previously and it should be always sort
of taken into account and if it so happens that it gets overwritten at a
later stage that's another

Patrick St-Louis: discussion to be had, but I think chronological order,
whichever one is ready for it should be merged. otherwise, you're kind of
going back and forth between maybe the evolution of the project and you
want to keep it consistently chronological.

Dmitri Zagidulin: That's a very good point. this is a spec under active
work. There's going to be a lot of changes. I do think that trying to guess
which supersedes what is going to invite chaos. So I'm inclined to say yes,…

Dmitri Zagidulin: let's merge it barring the IPR question. But Benjamin, go
ahead. You're on the queue.

Benjamin Young: Yeah, I just want to double down on that …

Benjamin Young: if we are removing any of the ones already in the spec,
those need to have their own discussions, need to be proposed as issues,
etc. So, I don't ever want us to see …

Benjamin Young: there's a PR pending, so we can chuck out all the past work
because it might displace it like we should push forward on HTML render
method.

Dmitri Zagidulin: Agreed.

Benjamin Young: I'm likely going to be the one to do the work that says
this is how you would do the mustache stuff, etc. and then we discuss it.
If there's consensus, we take out the mustache one or not. Right? that's
what consensus is about.

Benjamin Young: That's all. Thanks.

Dmitri Zagidulin: Thank you so much. Wholly agreed. All right. Phil and
Ivan, if you can confirm that, Sebastian is part of the working group.

Phil Archer: No, he's not a member of the working group.

Dmitri Zagidulin:

Dmitri Zagidulin: Not a member.

Phil Archer: But I think there is a way to say or…

Dmitri Zagidulin:

Dmitri Zagidulin: Okay, great. Ivan or…

Phil Archer: is there a disclaimer somewhere that says if you contribute
then you are subject to the IP? I should know this. I don't. Elvan. Yeah.
Help help us out here.

Ivan Herman: I don't know.

Dmitri Zagidulin: Iv Yeah. Sorry.

Ivan Herman: I don't know either. there is something…

Ivan Herman: but I don't know from the top of my head. But isn't it simpler
if we contact them or you contact them if them feel whether they simply
join the working group? Sure.

Phil Archer: Yeah. …

Phil Archer: I've got a conflict of interest here because if I say he's
GS1, which he's not quite, then I'm breaking the GS1 rules, which I don't
want to do.

Phil Archer: I'm certainly convinced of his expertise. Crank it. We're
spending money with him to build our system for God's sake. So, yeah, we
got faith in, But I'm trying to be neutral about this and if we received an
invited expert application from him,…

Phil Archer: then I would have to recuse myself from that because Right.

Ivan Herman: that's fine…

Ivan Herman: but Brent and I can make a decision on the invited experty
position if he comes in and I understand that you will be outside of that
decision that's fine but at least that should happen I think it creates a
unclear precedent if we take people from outside the working group and the
invited expert is there for the cases…

Ivan Herman: where the person or the company for some reason cannot join
W3C as a member that's exactly why we have a number of invited experts on
this group already so that's not unheard Yeah,
00:15:00

Phil Archer: …

Phil Archer: for clarity, the request to me is I write to Sebastian and say
bit of a problem merging your PR. simply because your status is not clear
with respect to IPR. basically please join the working group. here's the
invited expert route if you want to but please understand that I will not
be involved in processing this as I would be for other people.

Ivan Herman: That sounds perfect to me.

Phil Archer: Okay then I'll do that. Thank you.

Dmitri Zagidulin: All right, sounds good. And okay and just for my own
education the general policy is only members of the group can contribute
right because that means they signed the IPR agreement and so on we don't
see Understood.

Dmitri Zagidulin:

Ivan Herman: That's the preferred way, mean there is some complicated way
if somebody comes in and contribute then they have to go out and sign some
papers etc which is administratively almost the same thing as joining the
group as invited expert but don't mean sorry it's minuteed anyway anyway so
yeah the preferred route is that the person joins in some way or

Dmitri Zagidulin: Got And Kevin, you're on the queue.

Kevin Dean: I would certainly support the idea or say that the preference
is that a contributor should be a member of the group. But if there is a
change that either is so simple and obvious that it should be made or…

Dmitri Zagidulin: great question, Ivon.

Kevin Dean: has the support of somebody else who is a member of the group.
Would it be sufficient for somebody…

Kevin Dean: who is a member to add a comment essentially sponsoring the
change and allowing the change to go through?

Ivan Herman: So the mechanism at the moment is…

Ivan Herman: if somebody puts in a PR or some substantive thing into the
system by GitHub, then I get a notification and I get a request on telling
the system that it is not a substantial addition and therefore it's not So
if somebody comes in with a comment as you say Kevin and this is clearly
not something that is IPR problematic then I automatically acknowledge the
PR and it goes through and no problem there.

Ivan Herman: To be honest, I don't remember having seen this PR.

Ivan Herman: I was wondering When was that submitted?

Dmitri Zagidulin: on early January.

Dmitri Zagidulin: So this is January 2nd. Devin

Kevin Dean: as some of you may have seen in the Slack channel, there has
been a recent change to GitHub where it's possible now to restrict pull
requests to contributors only. So it may be worth considering that we add
as contributors anybody who is a member of the group and that will
automatically block and therefore encourage people to join if they wish to
submit a change. so then we can come into these discussions knowing that
everybody who has submitted a PR is a full member…

Kevin Dean: because they are a contributor. It's the new setting in GitHub.

Dmitri Zagidulin: That would be pretty amazing and…

Dmitri Zagidulin: helpful. Ivon, is that something that you might be able
to do?

Ivan Herman: The problem I have is that we have a very high number of
members in the working group.

Ivan Herman: Many of whom are there as lurkers so to say and I have to do
that manually for each of them. I believe I cannot make a kind of an
overall general statement.

Ivan Herman: I believe

Kevin Dean: I don't think it would be necessary to add everybody…

Dmitri Zagidulin: It does seem

Kevin Dean: because as we all know there are a number of us and I certainly
have been guilty of it who are just listeners in a group and don't actively
participate. so if somebody wishes to submit a PR then it simply becomes a
request to Yvon whoever else to add as a contributor and…
00:20:00

Kevin Dean: then the checks can be made so we can still enforce the
restriction and keep the workload on Avon as light as possible.

Ivan Herman: To be a little bit administrative,…

Ivan Herman: I think this is something that the working group has to decide
and that's something that I would prefer first to discuss with F and Brent
and then it's a working group decision. It's not here.

Dmitri Zagidulin: Agreed. And in fact,…

Dmitri Zagidulin: this sounds like something that's a great candidate for
W3C in general, a high leverage thing since the MV ship application has a
GitHub field. This seems eminently automatable. but is a little bit out
outside of our u scope especially of this working group and task force. So
that's the objections. I'm going to let's just take the easiest next step
which is Phil will reach out to Sebastian.

Dmitri Zagidulin: hopefully we can just get him as invited expert otherwise
we'll proceed with the other mechanism mentioned which is somebody will
sponsor or…

Dmitri Zagidulin: something such okay so Benjamin go ahead

Benjamin Young: Yeah, I'm fine with your plan for the PR,…

Benjamin Young: but I wanted to counter the proposal of limiting poll
requests. I think it's putting up fences where we should have gates. I
think folks putting in PRs expresses that there's interest and desire to
participate in the working group. or they're doing it on behalf of folks
like GS1. and that only keeping it to our little enclave of people who are
already members prevents us from ever knowing that there are other people
who are interested in participating in a working group. So, I think it's
the wrong way around.

Benjamin Young: We should leave it open. I think we should have a better
understanding of what's required clearly this last 15 minutes of
discussions about IPR agreements and stuff shows that we as a working group
don't understand it and it could be streamlined. and likely these kind of
things should be handled outside of call time. but I would push super hard
against putting up more fences.

Benjamin Young: I don't think the world needs more fences and I think a
gate here this one is working just fine to say thank you for the PR here's
one more thing you have to click please do that and by the way we'd love
you to join the working group and contribute in more ways so that thanks

Dmitri Zagidulin: Thank you so much in that case we'll move on because it
is a broader discussion than just this test course. All right. So I'm going
to leave this comment us So we'll come back to the ongoing discussion of
the HTML render method. Another one that we can hopefully resolve quickly
is from Benjamin Ben about the preview in code spaces.

Dmitri Zagidulin: So advice from the group about this. This seems good to
me. I don't know, Benjamin, if you want to show us what this actually looks
like the code space create or what? Yeah,…

Benjamin Young: Yeah, I'm happy to do a demo…

Benjamin Young: if we want, but I can explain where it comes from. we Yeah,…

Dmitri Zagidulin: please at least give us some background.

Benjamin Young: So, there's another PR that's kind of related. I don't know
if I connected them. it's in the CCG repo, I think, on the website. Let me
see if I can find it. that one just sort of got automerged because it's a
website page. give me a second. I'm getting a link for it.

Benjamin Young: Essentially, I created a contributing page that talks about
how to do in browser editing of the specifications using GitHub code
spaces. And a good third of the description of how to do that was the steps
to add the necessary things to preview the port forwarding and this live
server add-on and whatever that were needed to wire up previews into code
spaces after you started a code space. So this devcontainer.json just
streamlines that. Nobody has to use it.

Benjamin Young: but once it's there, if you start a code space, you already
get the live preview stuff turned on and you can just click the go live
button in the bottom right corner and you get a preview of the respect HTML
fully rendered. so you end up basically with VS Code running in your
browser in one tab and the live preview that auto refreshes as you change
stuff in another tab. So it's super useful for folks wanting to contribute
who don't want to download VS code or node or whatever we might have in the
repository that they can just essentially go to the code button and create
a code space and then they get a more advanced editing environment with a
preview and things like that. So that's the story line.
00:25:00

Dmitri Zagidulin: Right. …

Benjamin Young: I can click through what that looks like. if you all want
to see

Dmitri Zagidulin:

Dmitri Zagidulin: thanks Benjamin. So, I'm given that this is a pretty
harmless and out of the way that doesn't require anything of anyone. I'm
inclined to just merge any other objections from the group and do folks
want to see what the psych this preview actually looks like with this live
editing otherwise we'll move on. Not hearing Contributing detail link in
chat. All right. Sounds good. so let's merge this. If we have time at the
end of the call, we can circle back on this and

Dmitri Zagidulin: Okay, let us come back to the saga of our HTML render
method which I'm actually would like to propose that we rename to sandbox
iframe method because that's the important load code bearing part of this,…

Ivan Herman: Everything to

Dmitri Zagidulin: not the fact that it's HTML.

Dmitri Zagidulin: But Ivon Benjamin, do you want to walk us through the
sort of the latest in the conversation? All right, Benjamin.

Benjamin Young: Yeah. Yeah.

Benjamin Young: I continue to process all the different threads and I may
not have gotten them all. but I made some changes last night which I think
addresses the bulk of them. this current draft does incorporate the
algorithm approach and spells that out more. clarifies some language about
the different components at use. I stopped saying shim code and now it says
wrapper code and we can bike shed that if folks want to.

Benjamin Young: and large the functionality is identical. I haven't seen
this response from Avon and this one and probably any of the other ones
that I've missed. It'd be great to have them as separate issues and to get
the bulk of this merged so that we can move on because it's already getting
hairy because essentially each person that comments has a whole new thread
of issues and they're intermixed and out of sync and it's just long lived
PRs or some circle of hell. so it would be great to merge it and move
forward. it's 2.2.4. Yep.

Benjamin Young: So, the bulk of it hasn't changed meaningfully. It's just
been corrected language. I can talk through this weird looking chart if
people want to see it.

Dmitri Zagidulin: First of all,…

Dmitri Zagidulin: thank you for adding the chart. I think that was one of
the requests earlier. Looks great. before asking you to talk through it do
first of all here's the preview link in chat. I completely agree with you
that we do not want to encourage longunning PRs good feedback on the
comments should be opened as separate issues. So any objections to us
proceeding in this direction in general? So merging the PR continuing to
refine it. So I'm seeing a plus one from Dave in chat. Anyone else?
00:30:00

Dmitri Zagidulin: A glad film.

Phil Archer: I have no objection at all. I think that's the right thing to
do. but I wonder is there a way to merge it without triggering a kidner to
immediately publish it in space because I think that as Benjamin set out
there's a lot of changes here and…

Phil Archer: we do need to sort of review it in bite-sized chunks. and part
of me thinks, yeah, do you know what? It would be good not necessarily to
immediately make the next public working draft.

Ivan Herman: The only way to do it is to explicitly switch off in the
repository the Akidna script.

Ivan Herman: But I am tempted to say I would prefer not.

Phil Archer: Then it was just a suggestion. Okay. Thanks,

Dmitri Zagidulin: So just for my own education, currently it's set up that
with every PR akid updates it updates the public working draft link.

Ivan Herman: Yes. …

Dmitri Zagidulin: Did I understand correctly?

Ivan Herman: every merge of a PR triggers the kidnap publication.

Dmitri Zagidulin: That seems fine…

Ivan Herman: So yes, the official working draft on PR will become the one
that you merge.

Dmitri Zagidulin: since it's exactly like looking at Maine. So I'm seems
fine to me. Benjamin, go ahead.

Benjamin Young: Yeah, I was just wondering if Phil could speak more to the
concern there of it being on TR space.

Benjamin Young: I'm happy to give it more time to be discussed as a concept
or…

Dmitri Zagidulin: Okay. Okay.

Benjamin Young: approach. I just didn't want to keep having issues as Okay.

Phil Archer: I don't want to hold this up.

Phil Archer: I don't want to ask whether No, no, not at all. it is clearly
right to merge this as soon as possible. Absolutely. Total out of support.
It was just that I think there is at least a perceived difference between
what's published on the w3.orgtr /tr space which is and then there's the
latest editor's draft and the way it's set up is they are in sync every day
I think if you make multiple merges in one day…

Ivan Herman: No, no, no.

Phil Archer: then only the document only then it only gets updated once a
day something like that but no it gets it every time but it's the same date
so it gets overwritten or whatever anyway it doesn't matter the important
thing is that it's set up

Phil Archer: There is no distinction between the latest editor's draft and
what's in TR space. And I was just raising the question,…

Phil Archer: I'm happy to shut up and stop wasting everyone's time, whether
there is actually a distinction that we could keep, but let's not worry
about it.

Dmitri Zagidulin: All right,…

Dmitri Zagidulin: sounds good. and again, much with the other conversation,
this seems like a broader group policy not just for the task force. All
right. any other comments, questions, objections before we merge this?
Going once, goes twice. Thank you everyone and thank you so much Benjamin
for all your hard work on this. this is great. so I haven't opened an issue
proposing the Okay, so merging this PR. I haven't opened an issue proposing
a rename, but just as an informal straw poll, I'm curious what people on
the call think.

Dmitri Zagidulin: is there any objections or other are people happy with
the current HTML render method Would there be any support to renaming this
to sandbox iframe render suite? Go ahead, Ivon.

Ivan Herman: So the question for me is do we expect to have other render
methods which are HTML based because if the answer is yes then obviously
this has to be renamed and I don't know the answer to that. But the
previous discussion with mustache being used seems to say that there might
be other render methods…

Ivan Herman: which are essentially HTML based in which case I agree with
you would be treated and the name would be changed.

Dmitri Zagidulin: So this is an excellent question in general whether any
other HTML based rendering methods are needed from sort of task force lead
hat off as an implement.
00:35:00

Dmitri Zagidulin: I do think that this iframe approach is a fantastic idea
and I will be implementing it but it also doesn't address the export to use
case that we have in our mobile app. and so I foresee implementing both a
template based HTML and then an iframe based one and Benjamin not from the
browser from a mobile app. So specifically while the I frame method allows
the wrapper authors to put up their own controls buttons such as export to
PDF.

Dmitri Zagidulin: What it doesn't allow is for the application designers to
provide those buttons and trigger the interplay between exporting printing
and so between the iframe and the outer wrapping application. All comment
from Dave in chat that if we have other HTML methods then that would be the
time to rename such as to HTML sandbox. and again I do think we should
underline the fact that we are specifically relying on the I frame
mechanism to sandbox this rather than anything else.

Dmitri Zagidulin: So I see several people in the queue. Phil and then
Benjamin. Go ahead. Right.

Phil Archer: I think you're absolutely right,…

Phil Archer: Dimmitri, to raise this. I think just calling it the HTML
method because everybody else, I'm lazy. I don't read stuff unless I have
to. I would think, great. I can just do it in HTML." and I wouldn't get to
the point that I've got to put it in an iframe and use the sandbox and
everything else. And we know that until very recently there was a strong
push against talking about HTML rendering for all the security reasons. So
the application of the iframe sandbox is actually crucial to unlocking this.

Phil Archer: And so I think it's useful for the naming as exactly as you
say Demetri specify we mean sandbox iframe…

Phil Archer: then it's okay general HTML we don't want to see. So I think
you're right.

Dmitri Zagidulin: Thanks. Makes sense. Benjamin and…

Benjamin Young: Yeah, I'm not a huge fan of the hyphenation in the name.

Dmitri Zagidulin: then Patrick.

Benjamin Young: But I would support something like an iframe render method
versus sandbox iframe, but I also get what's desired to be signaled there.
but thank you for raising the concern. I think it's worth doing.

Benjamin Young: I think one of the things those that I've discussed this
approach with have not been certain about is whether or not especially as
you mentioned Demetri in a mobile app with a web view what is the sort of I
framing experience in those environments are they a bunch of little web
views that are acting like iframes or…

Dmitri Zagidulin: right?

Benjamin Young: the language of the spec Are they a host page in a web view
that then has iframes? and I frankly don't know enough about the strategies
available there to speak to that, but I think I frame render method at
present would send the right signals.

Benjamin Young: I think maybe the concern there is that the word I frame is
a pariah and people freak out about it. because they feel like it's a
security vortex. but this is 2026 and we have all these extra little words
we can stick on the word iframe and suddenly it's a bit safer. which is I
think…

Dmitri Zagidulin: Let's see.

Benjamin Young: why you were saying rename it the sandbox I frame to dispel
the spooks that go with the word iframe. so I think we can bike s*** it and
come up with another name. I agree that HTML is probably too broad but I
the thinking behind saying that way was that it was targeted at template
authors like what they would provide is HTML.

Benjamin Young: So calling it the JavaScript render method would not be
clear because you're still using the holy trinity of the web JavaScript and
CSS in concert. not just HTML, but if you lead with HTML,…
00:40:00

Benjamin Young: they know the other two go along. So I don't know, it's
tangled. I think I would vote for just iframe personally. but again, I
paint my bike shed orange, so that's it.

Dmitri Zagidulin: Excellent.

Dmitri Zagidulin: Yeah, we can definitely back share the details on a
separate issue, Patrick. And then Dave.

Patrick St-Louis: Yeah. Right. Just I'm not fully convinced in putting I
frame as the forefront of a render method. I frame for me is just a strong
recommendation of how to render this in your app securely. because at the
end of the day this is a HTMLbased template right that's meant to be
rendered with HTML code and we can decide that it's the most secure way we
thought to do this and highly recommend this but this seems to me like it's
not really part of the render method it's just how you would display this
on a website

Patrick St-Louis: And as far as I know, the I frame component is not in the
template is what goes in the I frame or…

Patrick St-Louis: could go in the iframe, but if someone wants to render
this as a standalone web page, it's also their possibility. so that would
be my contribution

Dmitri Zagidulin: That's really interesting.

Dmitri Zagidulin: I think I didn't understand it as such from my reading. I
frame is the only way this method works. So I need to come back to it.
Dave, you're up next.

Dave Longley: Yeah, I agree a lot with Patrick's perspective. I wouldn't
want us to be too hasty. I wouldn't want us to pin it to iframes. The fact
that our spec might end up saying here is a way to do this securely is
different from and this is a fundamental part of how you might ever use an
HTML template and the other bits that we specify. there might be other
elements for which There might be other elements for which this might work
in the future and a spec update would be simpler than having to rename
everything.

Dave Longley: So I would be worried that we would go a little bit too far.
it's clearly an HTML template render method. The one other component that
makes sense to me is talking about it as a sandbox. that's a useful signal
to someone who would be interested in using the method or implementing it
is that it's about HTML templates that are going to be rendered in a
sandbox environment. I think getting into the really specific details that
we might put in our spec that and where the language around that might be
open to you can do it this way or this other way but this way will work if
you can come up with something equivalent that's also okay which might work
in different mobile environments or with different tools. I think that's a
better direction to

Dmitri Zagidulin: Just to be very pedantic, there is no actual template
involved like this is a live full-on HTML page that you're passing a
verifiable credential to,…

Dmitri Zagidulin: this is not a classical mustache type template. But go
ahead,…

Benjamin Young: I yeah,…

Dmitri Zagidulin: Benjamin.

Benjamin Young: I can speak to that. you're technically passing in an HTML
fragment that you could just pass in HTML and CSS and show that you could
just have an H1 tag that says this could be a credential and some CSS that
makes that blue that's obviously pointless and doesn't have any
functionality.

Benjamin Young: So you would also then ship a script tag inside that HTML
fragment which the browser will render when the wrapper code formerly known
as the shim code is run in the iframe. Then that JavaScript has access to
the data block that contains the VC. if you want to bring up that wonky
looking chart, I'm happy to say things about it. so the template author is
providing HTML in which there is a script tag that then does stuff with the
data it has access to by manipulating that HTML DOM inside the iframe and
the iframe is sandboxed so that the JavaScript provided by the template
author cannot do anything else.

Benjamin Young: it can play in that DOM that it has but it cannot
communicate with the network. It cannot show alert popups. It whatever.
Can't poke at the wallet or figure out what wallet it's inside of and since
it cannot disrupt the UX of outside the cannot communicate to the network,
the belief is that it's safe to use, hence the sandbox terminology. so yeah
on the left the rectangle the HTML CSS and JavaScript template that is all
contained in essentially an HTML fragment. And if you're all at all
familiar with Vue.js's single file component approach to the world,…
00:45:00

Dmitri Zagidulin: Oops. Thanks, Dave.

Benjamin Young: it feels very similar to that.

Benjamin Young: you're writing, a div or whatever that has a script tag
inside of it that has a style tag inside of it. And then that is injected
into the wrapper code that sets up other CSP metatags inside of the iframe
which is itself restricted. and we can look at code if that would help but
that's it.

Dave Longley: So, I put this in the chat, but I just wanted to say it out
loud. There's every expect whatever template language you want will be used
within the HTML fragment. So the expectation is for a lot of use cases you
will build an HTML fragment that has for example mustache and a mustache
renderer inside of your fragment and that will get built and do essentially
what was done with the mustache rendering method before but it will execute
inside of the sandbox instead.

Dmitri Zagidulin: I see.

Benjamin Young: And the biggest distinction there with what Dave's talking
about is that you're going to ship your template engine with your template
in this approach. So the HTML CSS JavaScript template would not only
contain your mustache template curly braces,…

Dmitri Zagidulin: Right. Right.

Benjamin Young: it's also going to contain mustache.js full stop embedded
into that HTML so that it can be rendered which then lets you do whatever
the heck you want.

Benjamin Young: You can do liquid, you can do nunchucks, you can do
anything you can run in JavaScript inside a sandbox iframe you can then do
here. It does mean that your template code that is the HTML JavaScript and
CSS is going to grow as you do that. So if you're going to ship liquid JS
it's be one size. If you ship mustache it's going to be another size. if
you decide you're going to bring in all of Tailwind's CSS capabilities,
you're going to have to Tailwind into that. but it then also means you've
got everything you need to render the way you want to render in that space.
So, great power and responsibility and all that.

Dmitri Zagidulin: The other thing Ivon, I see you in the queue. The next
thing after this thread wraps up that I want to talk about is this notion
of including the full VC versus a key value map of just JSON properties.
But go ahead. Go on.

Dmitri Zagidulin:

Ivan Herman: Yeah, I am a little bit bothered by the discussion the way it
goes…

Ivan Herman: because some way or other the specification has to normatively
say what the requirements are in terms of security etc. So by saying yeah
it can be done in an frame but it can be done outside an frame etc. we get
into a very loose situation which is not what you expect from a
specification.

Ivan Herman: So if we say you can do it outside an frame, it's fine with
me. But then we have to normatively define what must happen, what
protections must occur, what are the things that must not be done,…

Ivan Herman: etc. That's a way to go, but it's not the way it is written
now.

Dmitri Zagidulin: I agree.

Dmitri Zagidulin: Patrick and then Benjamin

Patrick St-Louis: So related to that,…

Patrick St-Louis: I was going to mention something else, but related to
that, for me, when I see the spec, there's always the line between what we
want, the spec to talk about the credentials, how to use them, what to do
with them. And then there's I want to call it just a general web security.
we're talking here about a script that's going to inject data in a web
page. There are already plenty of security resource on how to do this
securely.
00:50:00

Patrick St-Louis: because if we want to cover every single scenario how
people should and should not do I think that's a slip slippery slope and to
hover being over normative for a lot of things and there should be a line
where it's being cut of how to safely handle the credential the data the
privacy aspect but this doesn't trump on just general security best
practice, right?

Patrick St-Louis: script injection is something that every website needs to
take care of regardless of if its this credential rendering aspect doesn't
take precedence over the foundations for a secure internet right I'm
thinking about the OWAS for example they have plenty of things that you
will need to be taken into account when building software so I'm just
wondering how far should the normative text go around handling what your
web application does with the features being put forward? and something
like this like a template that you will generate and inject in a website.

Patrick St-Louis: if we want to be very normative and set strict guidelines
I think then we should include iframe and close the box at that say we have
very strict guidelines about using secured sandboxed iframe and this is
that if you do something outside of this it's at your own risk the spec
told you normatively not to do this but whether we do that or not that's I
think a decision that needs to be actively taken

Patrick St-Louis: because in the VC API we had many discussion around that
we're talking about API web exchange requests the rest of the web security
that exists today still applies to that right it's not because we defined a
new protocol for exchanging credentials that you can all of a sudden forget
about web best practices and for me injecting right a script that there's
data that you push you potentially not know in advance what it's going to
be that falls into just when security at this point. So that's kind of what
I wanted to highlight.

Patrick St-Louis: and my second point, if we have time, probably not
because we're running late, but there is a render method that's been on my
mind for some time, and I just realized I never mentioned it to this group,
and I wanted to initiate a discussion about AI and credential analysis and
credential comprehension and so on.

Dmitri Zagidulin: Interesting. Yeah,…

Dmitri Zagidulin: I'd love to hear your thoughts there. if we have a couple
minutes. Benjamin, you're up next.

Benjamin Young: So I think practically speaking for …

Benjamin Young: what is in the specification right now currently called
HTML render method I would like to lean 100% on this is a sandboxed iframe
approach and that's it spec it that way. You're going to need an iframe and
you're going to need this wrapping code and this is how it's going to work.

Benjamin Young: Longlay's mentioned, or do it like an iframe, right? I
don't know that I don't know specwise how to do that. other than in a call
out of node of some kind of like if you can provide all of what a sandbox
iframe provides in terms of a safe space to put some HTML, JavaScript, and
CSS and let it do what it's going to do, then great, do that. But I don't
know how to specify that and would need assistance from anybody who has
access to other environments where they can provide something exactly
matching a sandbox iframe which might be a web view but I don't know how
performant that's going to be.

Benjamin Young: I don't know how restrictive web views can be when used in
an Android app or whatever. so somebody building mobile apps that is
willing to juggle one or more web views for these credentials would need to
come alongside and say this is how we're going to do it this way. but I can
specify the iframe side with the CSB bits and those seem fraught enough.
but if that's okay with the group, I would like to proceed that direction.
probably provide more explanatory code about templating engines and what
that would look like if you were to pro provide those. we also have a
couple playgrounds in process for testing this stuff out and I can put more
examples in those so we can look at them together.
00:55:00

Benjamin Young: but again, if the scope's going to just widen to do it like
an iframe, then somebody who knows what that would even be. I could use
help from that person because I'm not certain that we can just say do it
like an iframe and the tag or anybody else is going to be satisfied. That's
it.

Dmitri Zagidulin: So I agree with you and…

Dmitri Zagidulin:

Dmitri Zagidulin: I would certainly like to see it move in that direction.
But let's hear from Dave, who I think has concerns about that.

Dave Longley: My first comment would be let's not get too far ahead of
ourselves.

Dave Longley: So we've just got the baseline for this render method. let's
iterate on it. Let's see where it goes. we should definitely fully specify
exactly how to do it with an iframe. but there are a lot of other specs
that have been worked on that that provide detailed normative algorithms
that also have the statement as long as your outputs are the same, you can
use a different algorithm and we should give ourselves time and space to
explore having that kind of language in the spec. especially if as Benjamin
says other people show up and they say hey I was able to do this with a web
view and I did it in this other way. we don't want to close the door to
that kind of innovation but we do want to say this is one way to do it. It
will work this way. We're going to get interoperable implementations on
that and test on that.

Dave Longley: but we also don't want to make this method so restrictive so
that if somebody comes in while that work is going on or after that work is
coming on, we can't do a 1.1 that maybe provides more details on this other
method but doesn't prevent them from using the other method in the near
term. We also don't want everyone to have to go make entirely new render
methods with different types on them when everything will potentially work
the same way in the future just with different implementations.

Dmitri Zagidulin: All right. So, we are nearing the top of the hour. Our
next steps are okay. We've merged this pull request. had a good discussion
about possible renaming. I agree with you, Dave, that we should continue
working on this and see how far we can take it. for the next call in two
weeks or whatever, I'd love to So, please make sure to reopen the issues
you had in the PR as separate issues, the comments that you had in the PR
as separate issues. I'll open a possible renaming discussion so we can
continue that conversation there.

Dmitri Zagidulin: I also want to on the next call come back to the OCA
bundle render method and see if there's any then overlap between the two
such as in the way that we specify which fields are being passed to the
template. So I want to come back to OCA bundle because I do think it's an
important method as well and not necessarily superseded by the HTML one.
I'm also really curious about I think it was Patrick what you said about AI
if you want to say a few words about it in the next couple of minutes just
so that we can start thinking about it.

Patrick St-Louis: For sure I can share my thoughts. So this initially
something I thought in the context. So for those who are aware about the
work item. It's a sort of international Europeanled supply chain framework
based on W3C verifiable credentials. So it's like an extension of
verifiable credential. and the broad the larger I don't know how I call it
for this is international right so the amount of different jurisdiction
that going to be involved and work with the same thing the more information
will get lost in translation.

Patrick St-Louis: my initial thought was this idea of having something
called an AI comprehension render method which is a way to provide a
credential I don't want to get into privacy discussion for now but let's
assume a credential that has public information in it such as a public
mining permit and with out external context provided
01:00:00

Patrick St-Louis: head and see if we can get meaningful information from
that credential in a human text format such as what is this how can it be
used and how could it benefit me as an individual right and it's been very
interesting to see just based on these UNP credential how much information
can be derived from a wellformed credential semantically and this goes
really well with JSON LD and just the way that with W3C credential all
different nodes in the credential can relate to others. There's some very
interesting things that can be discovered. The second part which is
something I an idea later which is maybe a more advanced feature but in the
same vein is a credential analysis.

Patrick St-Louis: so you take a credential and you want to get an output
whether it's a text or something to display that focus on specific patterns
of the credentials right so there's many ways that you could interpret a
credential so that the first way is sort of a generic is how can I use it
is this a semantically sound credential the second one is now that I know
what this is a bit how can I interact with this credential and basically
ask questions to this credential, right? And get some answers back. So,
these are kind of the two veins of my idea here.

Dmitri Zagidulin: All And we are at the top of the hour. thank you
everyone. Patrick, this sounds intriguing. I'd love to hear more either as
an issue or if you want to put together a quick slide deck and do a
presentation to the group. I think others might be interested in that as
All right. Thanks everyone. Cheers.

Phil Archer: Cheers everyone. Bye-bye.
Meeting ended after 01:02:47 👋

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