[MINUTES] VCWG Spec Refinement 2025-10-29

Here's a summary of the VCWG Spec Refinement meeting:
Meeting Summary

*Meeting Title:* VCWG Spec Refinement - 2025/10/29 10:58 EDT

*Attendees:* Beckett Zundel, Benjamin Young, Brent Zundel, Dave Lehn, Dave
Longley, Dmitri Zagidulin, Hendry Poh, Hiroyuki Sano, Isaac Koh, Ivan
Herman, Manu Sporny, Phil Archer, Phillip Long, Ted Thibodeau Jr, Will
Abramson

*Summary:*

The meeting focused on the render method specification. The primary
activities included reviewing pull requests, discussing open issues, and
planning future work.

*Topics Covered:*

   - *Review of Pull Requests:*
      - Fix leftover render property to be render method (approved,
      awaiting merge).
      - Open at a station embedded renderer (rename) (approved, awaiting
      merge with issue marker).
      - First public working draft archival (administrative, rebase
      required).
      - OCA bundle render method (discussion on scope and unification of
      render methods).
   - *Discussion of Issues:*
      - Publish context file for render method (creation of contexts).
      - Specify usage type and display preference for a list view
      credential (display in lists).
      - Phone home mitigation (security concerns and embedding vs. linking).
      - Rendering of compound linked credentials (considerations for
      compound credentials).
      - Multilingual layout (internationalization).
      - Functional operation (templating language and operations).
      - Web-based render suite.
   - *Administrative Items:*
      - W3C boilerplate and code of conduct.
      - Upcoming TAC meeting and impact on meeting schedule.
      - Context file versioning.

*Key Points:*

   - The group reviewed and approved several pull requests, with some
   awaiting final merge after addressing specific comments or completing
   administrative steps.
   - Discussions revolved around the scope of the render method spec,
   particularly regarding the potential for an explosion of render methods and
   the need for unification and parameterization.
   - There was a consensus on the need to address internationalization and
   security concerns (specifically, phone-home mitigation) in the render
   method specification.
   - The group discussed the challenges and considerations for templating
   languages within the render method context, including the need for
   stability and security.
   - The next meeting will be in four weeks due to TAC.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2025-10-29.md

HTML:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2025-10-29.html

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-vcwg-spec-refinement-2025-10-29.mp4
*VCWG Spec Refinement - 2025/10/29 10:58 EDT - Transcript* *Attendees*

Beckett Zundel, Benjamin Young, Brent Zundel, Dave Lehn, Dave Longley,
Dmitri Zagidulin, Hendry Poh, Hiroyuki Sano, Isaac Koh, Ivan Herman, Manu
Sporny, Phil Archer, Phillip Long, Ted Thibodeau Jr, Will Abramson
*Transcript*

Ivan Herman: That's why it's only the two of us.

Beckett Zundel: Apparently, I'm logged in as my son.

Beckett Zundel: Let me log out and log back in. See if I can change that.
Be right back.

Hendry Poh: Hey there. Hi

Manu Sporny: Hey Dmitri, I think you are up to run the meeting today
because it's on render method. I put our agenda on the screen. but over to

Dmitri Zagidulin: All give me just a second. you get to a computer and
we'll, …

Ivan Herman: Thank you.

Dmitri Zagidulin: I'll get to it.

Ivan Herman: Thank you.

Dmitri Zagidulin: All right. So, welcome everyone to the weekly render
method all. So, let's see, Mon, do we usually go through the W3C boiler
plate on these calls?
00:05:00

Brent Zundel: Yes, please.

Manu Sporny: It's up to you. I don't think we need to …

Brent Zundel: I would like that it be done, please.

Manu Sporny: since we're Okay. All right.

Dmitri Zagidulin: Right.

Dmitri Zagidulin: These hold on. So this is part of the working group, so
these call we are under the W3C code of conduct. calls are open to anyone.
But in order to contribute you must be a member of the W3C and the
verifiable credentials working group.

Dmitri Zagidulin: If you are not a member of the working group, please
raise your hand. we'll help you join and sort out the IP requirement
details and I believe transcript of these meetings will be available at the
usual places on GitHub. All right. So, let's open up the render method
specification and let's first call let's go through pull request if any and
issues to get an overview get a sense of what's going to be on our plate in
the coming weeks.

Dmitri Zagidulin: So, I'm going to share screen.

Dmitri Zagidulin: Yes, I go ahead.

Ivan Herman: Yeah, maybe before we go into the details just to report back
the first public working draft will be published tomorrow.

Ivan Herman: All the procedure etc. I want thank you for being involved.

Dmitri Zagidulin:

Dmitri Zagidulin: Got it. All right,…

Ivan Herman: and sometime during the day our web master is on essentially
European timeline.

Ivan Herman: So I presume for many of you when you wake up then it will be
already published.

Dmitri Zagidulin: sounds good. I pasted the link to the spec repo here in
Zoom chat and I forget. So, I know that the transcription is done
automatically. Do we still use IRC for these calls or just Zoom Go ahead,
Mono. Got it.

Manu Sporny: No, just this meeting. and anything put in the chat will be
lost. but it's useful to share things. full transcription, full video
recording will exist. so if you screen share,…

Dmitri Zagidulin: Got it.

Manu Sporny: all of that stuff will be there. We don't have the capability
to link to issues yet. So if we discuss an issue and…

Manu Sporny: we decide to go a particular path we will have to make sure
that we put…

Ivan Herman: That is Thank you.

Manu Sporny: what we like just notes about what we discussed into the issue.

Dmitri Zagidulin: Understood.

Dmitri Zagidulin: That sounds good. All right. So, …

Ted Thibodeau Jr: Sorry, just quickly the chat says that messages are being
recorded with the call.

Dmitri Zagidulin: yeah, go ahead.

Ted Thibodeau Jr: Does that mean it will be seen when you review the video
or…

Ted Thibodeau Jr: they're completely lost.

Manu Sporny: they're completely lost.

Ted Thibodeau Jr: Okay.

Manu Sporny: They will exist on Google Meet for 30 days and then they will
be deleted. It is a software, if someone wants to volunteer to write the
software to copy them over it,…

Manu Sporny: inter leave that's where we are.

Ted Thibodeau Jr: That's fair.

Ted Thibodeau Jr: I will suggest adding a note for future calls that are
handled this way to pin a message in the chat that says they're not being
recorded with the call even…

Ted Thibodeau Jr: though it said so or that they are being recorded but
they'll be gone after 30 days. Whatever makes sense just…

Brent Zundel: I think that's interesting.

Ted Thibodeau Jr: because people reading this are going to get the wrong
message.

Brent Zundel: Mike Mine says messages are deleted when the call ends.

Brent Zundel: So I think it's interesting we have different messages in the
chat.

Ted Thibodeau Jr: Fascinating. Okay.

Manu Sporny: Yeah, I

Manu Sporny: can't do that, because Google Meet doesn't allow me to pin
messages across meetings. We can restate it at the beginning of every call,
but the easier thing might be to just write the software to copy the chat
transcript over. I would imagine it would only take about four hours to do,
but …

Ivan Herman: create this funny feedback loop here.

Manu Sporny: everyone's busy.

Ted Thibodeau Jr: I hear you.

Ted Thibodeau Jr: It's all right. Thanks,
00:10:00

Dmitri Zagidulin: All right.

Dmitri Zagidulin: So, yeah. apologies for infinite screen here. All right.
So, let's switch over to if there's no other sort of administrative items,
let's switch over to the poll requests and go through them and then we'll
do the issues afterwards. So, first up, the oldest one, we've got fix
leftover render property to be render method. So, it's just a fairly old
typo. Back when it was called render, this should be a fairly
uncontroversial pull request. So, I approved it. Go ahead and add your
approvals and we'll merge it after the usual approval period. Okay.

Dmitri Zagidulin: Yeah, looks like we've got three approvals there.

Ivan Herman: If I sorry.

Dmitri Zagidulin: And remind me in the VC working group, it's a 7-day or
14-day approval period waiting period.

Manu Sporny: It's at seven.

Dmitri Zagidulin: Go ahead. All right. So, we should be able to pull to
approve it to merge it rather by the time the next weekly call rolls
around. So, next up we have a PR by Isaac about the open at a station
embedded renderer. We even have diagrams and everything. It's very
exciting. I'm assuming that the diagrams name. So this one should be fairly
straightforward. It's just a straight rename.

Dmitri Zagidulin: so this does bring up the I see. So the render method
property itself is part of the VC data model version two context. But the
additional properties of the individual render method those will be at that
context URL and I assume we don't have any ambitions to roll up the
commonly used fields into a main render method context.

Dmitri Zagidulin: Go ahead.

Manu Sporny: I think we do. it's one of the things we need to discuss in
the group.

Dmitri Zagidulin: Yeah. Okay.

Manu Sporny: I will get into this in issue processing but I think my
expectations are which I expect to be not aligned with others quite yet is
that we would fold all the render method properties and classes and all
that kind of stuff into a v2.1 JSONLDD context so that people don't have to
pull in other contexts to be able to use the render method and…

Dmitri Zagidulin: Okay.

Manu Sporny: confidence method and any of the other extensions that we're
going to do. so I think my review comments on this it's totally fine.

Manu Sporny: And we can definitely let's merge this in because it has been
changed. The implementation has been changed but we need to chat with Henry
who's on the call today and some of the other folks that are using the
embedded renderer to see if they would be okay with that. So I think we
should add an issue marker saying that it's a conversation we need to have.

Manu Sporny: I think we should open an issue saying that to make sure we
don't forget about the conversation. And then other than that, the PR looks
good to me.

Dmitri Zagidulin: All right,…

Dmitri Zagidulin: let's do that. So, let's open an issue. I'm assuming
Publish context file for render method. So, I wonder if do we want to reuse
this one? Okay. Okay.

Manu Sporny: Yeah, I think that'll this one about folding it in or a
different context. We would need to do both. or I think so this one is
about creating a new one just for render methods in case somebody wants to
mix in render method stuff with a V1.1,…

Dmitri Zagidulin: Okay. Yep. Got it.

Manu Sporny: thing. again that's an open issue should we allow that or…

Dmitri Zagidulin: Got it. Yeah. and…

Manu Sporny: or should we just nudge everyone to just upgrade? or should we
basically be like, if you have something if you're using 111 and can't move
off of 11 one but want to use render method, here's how you do it.
00:15:00

Dmitri Zagidulin: and we could Got it.

Manu Sporny: I think it'll be a part of this conversation,…

Dmitri Zagidulin: Yeah. All right.

Manu Sporny: but it'll make the issue kind of, …

Manu Sporny: a big issue to discuss.

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: Got it. So let's open a new issue for All and how would
you recommend we phrase it?

Dmitri Zagidulin: So sort of roll up integrate the…

Manu Sporny: in integrate.

Manu Sporny: Yeah. Or Go ahead, Demetri. render method property and…

Dmitri Zagidulin: what though the known.

Manu Sporny: classes into vcdmv2.1 context. Yep.

Dmitri Zagidulin: So wait, so to the main context. Got it. All right. into
the VCVM2.1 context.

Dmitri Zagidulin: Go ahead.

Ivan Herman: I am always there to annoy people with this.

Ivan Herman: It's not only the context, it's the whole vocabulary I
presume. So there are number of terms that are in the vocabulary under that
name space and…

Ivan Herman: we are talking about extending the vocabulary. The context is
just a transformation engine. story to be pedantic.

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: All right. so we've mentioned several different things.
one is to address compatibility with the VC data model 1.1 which probably
the easiest thing will be to do a standalone context. We could even mark it
as render method VC1 or VC1.1 so that hopefully causes less confusion with
implementers.

Dmitri Zagidulin: At the same time, we always want to encourage people to
upgrade, but I recognize there's a number of implementations out there that
are still going to be at 1.1, right? So, ensure render method compatibility
with the CDM 1.1.

Dmitri Zagidulin: So is the property itself in the context.

Manu Sporny: Yeah, in and…

Manu Sporny: 2.0. I forgot 2.0's doesn't have it. Yes, but all the other
stuff is not and so you wouldn't be able to use

Dmitri Zagidulin: I see. So all right I'll make those two separate issues.
Easiest thing to do would be to publish a standalone context file for the
CDM 1.1 includes the render method property itself as well as the known
classes and their properties for use with one. Okay.

Dmitri Zagidulin: Secondly, create a combined render method context or VCDM
2.0.

Dmitri Zagidulin: Wait,…

Ivan Herman: to number one render method is already the…

Dmitri Zagidulin: So render method I think Manu also mentioned 2.0. So
render method property itself isn't go ahead.

Ivan Herman: how should I say the term itself and the class itself is part
of the DCDM 2.0 zero as of now that we had a separate subsection in the
vocabulary for the reserved terms and this is there what we are talking
about is the additional properties and possibly additional classes that we
will define for specific render methods or…

Ivan Herman: or what is common in specific render methods those will go to
VCDM 2.1 I presume not 2.0 2.0
00:20:00

Ivan Herman: It always is closed.

Dmitri Zagidulin: Right. So 2.0 is closed.

Dmitri Zagidulin: But just with 1.1, we could define an external standalone
context that people can just drop in and…

Ivan Herman: We can define external property but we should not do that
because Yeah.

Dmitri Zagidulin: use with 1.1 and 2.0. Okay. Yeah.

Ivan Herman: What…

Dmitri Zagidulin: Is over the top.

Ivan Herman: I'm always worried when we concentrate on the context in this
respect because we are talking about a namespace that we populate with
properties and that's what we have done with 2.0.

Ivan Herman: We are of course fine extending the property so sorry the name
space with new things but the extension for all those is part of the 2.1
work but I have the impression that going to all these details right now in
the issue description is a bit over the top I mean we are not solving all
the issues we are just raising

Dmitri Zagidulin: Okay, very good point. let's see include the render
method property and all classes in the future vCDM2.1. Okay. Let's start
with there. yeah, and I wanted to do a C also. So,

Dmitri Zagidulin: Okay, go back to

Phil Archer: So Demetri just say here on this kind of thing is there is
value in having stable context files or anything else that you can refer to
and they immutable. but I think that this work and other work that the
group is doing is likely over time to add new terms whether it's about
random method or anything else. and so we can use the method that I pinched
entirely from W3C when I set this up at our reference repository to have a
stable URL that always points to the latest version of whatever it is and…

Phil Archer: then versioned or dated URLs that point to immutable things.

Phil Archer: So that I'll add this in future, but some kind of super
combined single context file if that's what you want or if you need the
breakdown if you need the immutable versions that refer to 1.1 or whatever
is the URL for that. Yeah.

Dmitri Zagidulin: Right. So right with of course the caveat that so I know
traditionally in the RDF world version has been frowned upon…

Dmitri Zagidulin: but these days specifically with the advent of data
integrity the recommendation flips you whenever making breaking changes or…

Phil Archer: Yeah.

Dmitri Zagidulin: really any changes you must version the updating the
context messes with the signatures and leads to developer unfriendly errors
that are really difficult to diagnose. so go ahead whoever's on the queue.

Manu Sporny: Plus one to what Dimmitri said. the problem, Phil, with links
to the latest thing is people ship it into production and then blame us
that we change the context when they should have known better, but they
don't know better and we have given up on them ever knowing better, It
keeps happening. And so what we tend to I think the current strategy is we
do release candidates. So we'll do 1 RC1. So version one release candidate
one and then if we need to add anything inevitably that happens then we do
a V1 RC3.

Manu Sporny: and we just go up in number until we get to candidate wreck
where we're pretty sure or really towards the end of candidate wreck and
that's when we lock in v1 and so I would suggest we follow that approach
meaning the vocabulary this is a different debate right whether the
vocabulary should be versioned or not but I think we have not been
versioning the vocabulary we've just been like helping people like this is
the hash for the vocabulary at the point of time that this spec was
published. If you really care go back and get history and find the right
hash for the vocabulary at that time if you're doing some kind of reasoning
stuff which I don't think hardly anybody's doing right now with the stuff
we're doing.
00:25:00

Manu Sporny: So vocabulary stuff aside, if we're just talking about JSONLDD
context, I think the suggestion is do release candidates throughout this
entire development process until pretty much the end of candidate wreck and
then we lock it in and we never change it,…

Manu Sporny: And the same thing with release We never change release
candidates because what we have found is someone will inevitably ship it to
production and then make a huge stink about how could we change it and…

Manu Sporny: it's kind of like we were in development that's why it
changed. so,

Phil Archer: No, I'm not going to argue against people…

Phil Archer: who know better than me. And I tell you what you're saying,
And Dmitri, thank you. I suppose I'm just thinking I know that if you
therefore have to put in three or four or five links to different context
files, that's a pain if you're starting from scratch.

Dmitri Zagidulin: All right.

Dmitri Zagidulin: Don't forget though that now especially with the digest
mechanism being part of the VC data model itself the immutability gets
machine enforced right so for those verifiable credentials that do include
the digest hash of the context files which I believe is recommended by the
spec the moment you change anything in the context that digest is going to
fail.

Phil Archer: Yeah, of course.

Dmitri Zagidulin: So yeah.

Phil Archer: Of course.

Dmitri Zagidulin: So basically now we cannot mess with it too much. All
Going back to the queue. go ahead.

Manu Sporny: No, I just took myself off the queue.

Dmitri Zagidulin: No. Q's So going back to the open edation embedded
renderer rename. we opened a tracking issue to deal itself. I don't know if
you still want the blocking requested changes there or…

Dmitri Zagidulin: we should approve it so that we can merge this thing
meanwhile and then come back to it. Go ahead.

Manu Sporny: Yeah. No,…

Manu Sporny: let's not merge it. we should open an issue marker that refers
to the new issue that was raised.

Dmitri Zagidulin: Okay.

Manu Sporny: And let's this has a very complex picture in it. We need to
start doing accessible descriptions of the images.

Dmitri Zagidulin: …

Manu Sporny: the…

Dmitri Zagidulin: I got it.

Manu Sporny: because it always falls to somebody else at the end. So if
you're going to put a picture in the spec, you need to describe it in
detail. The good news here is that LLMs are really good at describing
pictures in accessible ways if you give them enough context. I've started
doing it and the output's pretty good. so that can get folks, started on it.

Manu Sporny: So Henry, I think just some guidance to Isaac is just to,…

Manu Sporny: address those two issues. hopefully it's not a lot of work to
do either one of

Dmitri Zagidulin: Agreed. Ivan,…

Dmitri Zagidulin: go ahead.

Ivan Herman: Yeah, just a side issue here.

Ivan Herman: Let's not merge anything until we are not published. Then we
have not set up a kidna. Now publishing will be done tomorrow morning.

Dmitri Zagidulin: All right,…

Ivan Herman: I think I have seen that money you have already created the
Akidna file but I presume you have to activate it and then we can do all
these things but until then let's hold off the merge buttons sorry that's
just an administrative thing

Dmitri Zagidulin: copy that. agreed. Yeah. All right. So, won't copy until
a kidna.

Dmitri Zagidulin:

Ivan Herman: until tomorrow.

Dmitri Zagidulin: Won't merge until got All so, we're good with this issue.
going back to the PRs, we have the first publish working draft archival. I
don't think we need to do anything with that.

Ivan Herman: That's just an administrative thing. There is this habitu in
the group that we set up a separate folder with subfolders on the archival
on the first public draft etc.

Ivan Herman: that was not done for this repository when I created the first
public working draft.
00:30:00

Ivan Herman: I have copied that. So we have the same structure as in all
the others. I haven't touched the core file.

Dmitri Zagidulin: I see all of the Got it.

Ivan Herman: So it's just copies. So this one actually could be merged
right away. It doesn't bother anything.

Dmitri Zagidulin:

Dmitri Zagidulin: Got it. the only other thing is do you mind resolving the
conflict?

Ivan Herman: I have no idea what happened. I just copied whatever you guys
gave me.

Dmitri Zagidulin: There could have been some sort of activity since just
rebase it basically.

Ivan Herman: I'm always scared to death by rebates.

Dmitri Zagidulin:

Dmitri Zagidulin: No, don't be scared. it's especially on this kind of spec
work, right? it's not like we have five different teams working on
simultaneous features that Yeah.

Ivan Herman: I have very bad experiences with rebasing.

Dmitri Zagidulin: Yeah. understood.

Ivan Herman: I will try but

Dmitri Zagidulin: Understood. I'm happy to hop on a screen share call with
you if anything goes wrong. help debug, etc. Okay, so this thing's ready to
go. Just needs rebased. next up we have PR from Patrick about the OCA
bundle render method. That's very exciting. Patrick adds his W3C ID as
well. That's good. We have go ahead.

Manu Sporny: This is part of a longer conversation. I think it's great that
Patrick added we need to discuss this. We are seeing an explosion of render
methods that are incompatible with one another and we are getting ready to
ship what five six different ways of doing effectively the same thing. So I
want to make sure that we have a discussion around what the scope of this
spec should be for version 10 before we start just providing a bunch of
alternatives.

Dmitri Zagidulin: Okay. So, does that capture what you said as a review
comment?

Manu Sporny: Yes, thanks. I put that as a review comment as well. So yeah,…

Dmitri Zagidulin: Okay, Great. So, I don't need to add Fantastic.

Manu Sporny: there you go. Yep.

Dmitri Zagidulin: Yep, I see it. go ahead, Benjamin. I've approached

Benjamin Young: Yeah, mono is the concern that the feature set is redundant
because that's going to be true of every render method suite or whatever
we're calling them now. they're all going to do the same thing. So I don't
know if this spec is ultimately going to just frame an extension model or
not. Go ahead.

Manu Sporny: couple of things that you mentioned. So one the spec has to
frame an extension model as the base. That's the core thing the spec needs
to do.

Dmitri Zagidulin: Go.

Manu Sporny: And then on top of it, we need to specify potentially a couple
of concrete things because we always get our hand slapped by the tag if we
don't have at least one concrete thing. Yes, Brent as a part of this it
could be a render method registry. which brings tears to my eyes and not in
a good way.

Manu Sporny: and then the other part of this is that we have things so not
every render method is going to duplicate the other one. So we still have
to talk about render to wireless, render to braille, render to audio,
render to those things. Those things are not duplicative of each other,
right? the render to a visual format might be duplicative, but then there's
render to HTML, and now we've got two different render to HTML mechanisms.
that's the thing I'm concerned about is that, I don't quite understand what
the differences are between and this is I'm ignorant of. I have not had a
chance to understand the differences between OCA bundle and the embedded
renderer in the PDF version and the SVG version.

Manu Sporny: So I think we need to understand what are we scoping for
version 10 because OCA nor embedded nor the PDF renderer stuff. Each one of
those is a massive amount of work because we need test suites, we need
multiple implementers, we need to explore every single nook and cranny of
the space and we need to as a group I think figure out what are we trying
to do in version 10? because this could turn into everybody wanting to
bring their renderer method into the spec and we've get tons of duplication
and that results in tons of duplicated work. that's my concern is that I
think we need to talk about this. This should have started out as an issue.
I appreciate Patrick doing a PR. I know he's very involved with this work. …
00:35:00

Manu Sporny: but we need to talk about it.

Manu Sporny: I don't want us to just merge without a discussion.

Dmitri Zagidulin: So I agree with you mono the other thing that strikes me
is that some of these fields right pretty much all the methods will want
something like these will every method is going to need a name every method
is going to need a digest optionally version all this stuff right So in
addition to reconciling incompatible methods, I think we can just go a long
way towards making render methods similar to…

Dmitri Zagidulin: how our data integrity suites are just parameterized, So
that we have just one suite structure and then the differences. Ivan, go
ahead.

Ivan Herman: Yeah, I think that's the way I understood the earlier
discussion about the vocabulary extension is that these terms and…

Ivan Herman: there might be some others are expected to be used by almost
all rendering methods or most of them let's say and they should be
standardized. there should be part of our core vocabulary. It's our job to
find those five, six, 10, 15, god knows how many, hopefully not 15, terms
that we think are important and standardize them.

Ivan Herman: and then render methods can compete on additional things and
the way they create their user interface or god knows but this should be
standardized in my and…

Dmitri Zagidulin: Agreed.

Ivan Herman: to be clear I am here talking about myself and…

Dmitri Zagidulin: Understood.

Ivan Herman: not at W3C. Yeah.

Dmitri Zagidulin: Understood. Phil, go ahead.

Phil Archer: I'm concerned and…

Phil Archer: again I'm always being careful when I speak in these meetings
but I can't help it. I'm concerned that this idea of a high level medium
type that somehow is different from whether it's actually the media type
and then going down and down. the web is based on a well set of media types
that gets extended by a definfined method. And if I have a client that
understands SVG, I can ingest the SVG. If I understand HTML, I can do that.
I shouldn't need to worry about whether it's that kind of ST SVG or that
kind of HTML. I agree with Ivan that really it's about the content that
goes in it.

Phil Archer: Yes, but I could provide my own HTML that renders those
particular terms.

Phil Archer: And I really don't think we should have a separate medium type
that says visual or audio or tactile. that's what the media type does.

Dmitri Zagidulin: Wait,…

Dmitri Zagidulin: so we were talking about slightly different things,
right? I'm not sure anybody's proposing a separate media type.

Phil Archer: Sorry, I was looking at being in the chat. Sorry, Demetri. I
was looking at his

Dmitri Zagidulin:

Dmitri Zagidulin: No, no, that totally okay. But I think it's more that we
have categories. we have a broad categories for the kind of render method
specs we're going to have. we have a broad category of we need to be able
to use render method as a cross modality mechanism right so from text to
visual to audio etc. secondly, we need to be able to use render method as
part of the internationalization mechanism. issuers will want to lay out
their credential displayed differently for different languages. And then
thirdly, we have just straight up different these are the codes.

Dmitri Zagidulin: how to translate it to PDF. This is specifically for the
overlay project this number 30 which has specific semantic concerns. So
there are going to be differences. I think the main point is just first
we'll want to unify the common fields parameterize…
00:40:00

Dmitri Zagidulin: if possible and then leave the remainder and hopefully
there won't be much of a remainder to the individual methods. So, I think
we're all in violent agreement. Go ahead, Ivan.

Ivan Herman: Yeah, I think the only point is I very much sympathize with…

Ivan Herman: what Phil is saying that I think we will have modalities that
I don't think have a media type like haptic braille. I mean, that doesn't
work with the media type model, I'm afraid.

Dmitri Zagidulin: Got it. So I know that I think CSS but anyways go ahead.

Dave Longley: Yeah, I think we're just going to have to figure out this
tension between…

Dmitri Zagidulin: Next one you

Dave Longley: if you have, for example, an HTML renderer, ideally that HTML
renderer can handle these different types of medium, visual, audio, haptic,
whatever it might be, based on, whatever's in that HTML. So there's a
tension in knowing what kind of rendering you're going to get out of
something that renders to HTML versus going to some other format and So
it's sort of like these two things are happening in parallel.

Dave Longley: We've got these different media types, but some of them may
support accessibility better in different ways or render in different ways
and we've got to sort that out.

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: And in fact, Yeah. So, from the W3C page on tactile
versus braille, we could possibly reuse, this notion of CSS media groups,
which straight up have, four sensory types of visual, audio, speech, and
tactile. I do wonder how audio and speech are different, but it's not the
point. so right, so there is an existing mechanism in CSS to handle this
distinction that we could possibly reuse. All a quick time check. We got 17
minutes left. right.

Dmitri Zagidulin: So we're going to leave this PR to start the discussion
on how to unify and parameterize these different extensions classes
whatever the term we end up using these different extension methods. This
seems like a good topic to dive into in our next call in two All lastly,
Yeah. So, those are the four pull requests. let's take a quick look at the
issues while we're here. Again, going in reverse chrono. we have the
overlay capture bundle which is different. no.

Dmitri Zagidulin: Yeah yeah yeah yeah yeah yeah yeah yeah yeah.

Manu Sporny: No, it is. I totally did not realize he opened an issue on it.
So, that's good.

Dmitri Zagidulin: Primarily so here we go. References issue 15. Okay. Yeah.
So, that's good. We can continue the discussion on that issue 15, and I see
Patrick is even All right. Publish context file. We briefly talked about
that. specify usage type and display preference for a list view credential.
Yes.

Dmitri Zagidulin: So yeah, so that's actually a further category and this
came up as part of an IW a couple of sessions ago where not only do we want
to be able to specify how to render a credential in full detail mode, a lot
of use cases might want to specify how to display the credential as part of
a list.

Dmitri Zagidulin: so either a small card or this has a similar mechanism in
the digital credential API where it's the browser or the operating system
itself that renders the credential and I believe it has something like name
and the icon for the issuer or something like that basically standardized
fields. We're gonna need to be able to offer a similar mechanism that says
whenever you're doing a minimal rendering as part of a list or part of a
browser Chrome, this is how you want it to look. These are the fields that
you want to use and on. comment by Manu hand over. Yep. Yep. Yep. Yeah.
00:45:00

Dmitri Zagidulin: So, I'm definitely interested in continuing this. So,
we'll come back to this one section on phone hall mitigation. So one of the
things that has been brought up as a sort of not criticism but a concern of
render method is of course our old friend the phone home concern which is
shared by the status method shared by revocation schema and others. Right?

Dmitri Zagidulin: So, we do want to be able to add a security concerns
section to the render method spec where we mention it we mention the
mitigations and so on.

Dmitri Zagidulin: Come on.

Manu Sporny: plus one did this.

Dmitri Zagidulin: Go ahead.

Manu Sporny: I'm wondering if it's ready for PR. it just for someone to
attempt

Dmitri Zagidulin: So I think and I realize I should probably break this out
into two different issues. let's see let's see I think that this should be
at least two different sections and two different PRs. we should have a
section on embedding versus linking and then separately the phone home
section, right? Because there are other reasons to embed aside from phone
home mitigation such as if you want your credential to work offline. so I
agreed about ready for PR. Let's see.

Dmitri Zagidulin: we have a ready for PR label? We do. This is exciting.
So, discuss on call. this is ready for initial PRs would likely be helpful
to separate into at least two to linking versus embedding effect on offline
accessibility and separately phone all medications. Okay. Excellent.

Dmitri Zagidulin: rendering of compound linked credentials. So in the VC
world we have a category of these compound credentials again modeled either
as embedding or linking in the embedding camp we have CLRV2 in the
education space which stands for comprehensive learner record version two
and it's basically a way to use a verifiable credential as a big container
in which multiple o

Dmitri Zagidulin: other standalone VCs are stuffed. and then of course
wallet and ver verifier and other software implementers need to be able to
display these monstrosities. so that's the case with CLRV2. it's also
something that my team is encountering in the resume standard. these
résumés being big compound documents that include other verifiable
credentials skill assertions, employment VCs and so on and so forth. And so
this compounds the display problem.

Dmitri Zagidulin: So it would be great to be able to say whether this adds
any additional considerations to the render method because on the one hand
you absolutely can lay out the whole thing in create an HTML render
template from it and just use that but it might also be interesting to have
a composable template. Go ahead, Phil. I am about it.
00:50:00

Phil Archer: Sorry, I was clicking buttons and trying to find something and
I clicked So, this is interesting because it actually touches on another
conversation I've been having offline because I'm preparing for TAC in a
Sidebar, none of these meetings in two weeks time because it's TAC. and
it's interesting that it's my colleague Paul that's brought this up. So, in
our case at GS1, our credentials are linked one to other cases around
international trade and so on where one credential on its own really
doesn't amount to a hill of beans it needs to be part of a set and…

Dmitri Zagidulin: Mhm. Right.

Phil Archer: often you need them to be linked together so I think this is
going to come up this kind of issue that you're discussing here in terms of
how to present them there's lated issue which is how to verify a set rather
than one and that I think is going to come up in the verified issue work
that we may or may not be doing in a possible new charter. so there are
lots of things going on here besides simple ren or simple isn't the word,
sorry. Besides just rendering,…

Dmitri Zagidulin: Yeah. and I suspect rendering will be also affect So all
right.

Phil Archer: Of course. Yes. Absolutely. Yes. Yes.

Dmitri Zagidulin: So good issue. We'll come back to next up, right? So this
one I think could be ready for PR.

Dmitri Zagidulin: So this is my request of if we're going to use render
method as an additional aid to our internationalization mechanism which I
think we should or we straight up have a use case in the education world
where one diploma is used by a multilingual u university and they want to
lay it out differently in the language in addition to just string
translation right the layout is affected by the language so we could
provide an example for that mon go ahead …

Manu Sporny: Yes, plus one to this. there is another issue 26. That's a
dupe. I would like to close this issue in favor of issue 26 primarily…

Dmitri Zagidulin: Okay. Yeah.

Manu Sporny: because issue 26 was raised by MOSIP. And for those that don't
know, they have issued a 100 million verifiable credentials over the last
year, and they're on track to do the same amount, if not more this year.
and they issue their credentials using render method in English Hindi Tamil
and a variety of different things. So they're at the tip of the spear
trying to get this stuff done.

Manu Sporny: So this to me feels like one of the things we definitely have
to tackle and we've pulled the internationalization folks into issue 26 as
well and given them a heads up like help we need to make sure we do this
the right way.

Manu Sporny: It's got all kinds of ramifications for accessibility as yeah,
plus this is one of those things we've got to solve and ideally sooner than
later because they deploy first and ask questions later and when they
deploy it's, tens of millions of things. that's it.

Dmitri Zagidulin: Excellent. Okay.

Dmitri Zagidulin: Closing this one. and Since I'm fully open, I feel
impunity to do this. and we'll discuss it in issue 26. Functional
operation. that's a tricky topic. so this is a topic that every templating
language ha has to deal with at some point or another, right? So if any of
you have done web application that template templating language like
handlebar, erb mustache and a number of work alikes. The first step is you
embed rendering of variable substitutions and then inevitably operations
come into mind.

Dmitri Zagidulin: We want to be able to call to do arithmetic to be able to
call functions inside the template and it always leads to security
considerations complexity. So this is that but for our render method for
example having to convert ISO format. Go ahead.
00:55:00

Manu Sporny: Yeah, plus one. I've got an issue also in here about is MVP?
what is the minimum we can do and feel good about it. and this is one of
the things that I think needs to be in there. We hit this issue regularly
and you hit it way sooner than you think. dates that's the very first thing
and…

Dmitri Zagidulin: All right. Excuse.

Manu Sporny: we're like, Many people do not know how to read an ISO8 88
8601 or XML datetime right so we need to convert those into readable values
and that's where you need a language like this there are challenges here
ideally we pick one templating language across as many different textbased
formats as we can muster ideally the scripting language that we adopt is
the same as

Manu Sporny: across all of those things so people don't have to have
multiple different script execution environments and then of course as you
mentioned Dimmitri the whole security part of it is really really difficult
I

Dmitri Zagidulin: So as a brief sort of lightly hopeful push back is I
don't suppose there's any chance we can postpone dealing with this for as
long as possible specifically right all of these operations can be done in
soft code rather how to put it no I suppose even with dates I take that
back. We will have to tackle this especially for dates. So that's an MVP I
think date display and localizing it is something that everybody
understands. Everybody's come into the pain point. So okay.

Dmitri Zagidulin: So next steps do an overview of the popular templating
languages and list there capabilities with the hope of choosing a popular
one. that's a super set. All right. we are almost out of time. web- based
render suite. That's interesting.

Manu Sporny: We've got oaks on the queue.

Dmitri Zagidulin: We got folks on the queue. go ahead, Ivan.

Ivan Herman: So here is the point where I have to put on my W3C hat.
Unfortunately, we have to be very careful that whatever we refer to here as
a language and a template language should be how should I say stable enough
and there are more formal description…

Ivan Herman: what that means to be able to refer to it normatively. that
kind of thing can become very difficult because when you say popular that
might mean it's popular today and maybe next year and…

Dmitri Zagidulin: You're right.

Ivan Herman: in two years it disappears. So it is not only popular it is
stable and really stable so that we can refer it from a former
specification and that's not obvious that these things may be in
contradiction with one another.

Dmitri Zagidulin: You're right.

Ivan Herman: From my top of my head,…

Dmitri Zagidulin: I'm sorry. my net cut out for just a second. Do you know
of any templating language that is a standard? I don't know of any.

Ivan Herman: it would be too easy to be three if I had a response. No, I
don't.

Dmitri Zagidulin: Right. Right. Right.

Ivan Herman: I mean I know that we have used mustache in I don't remember
which spec in the past. So that seemed to be at that point relatively
stable but I don't remember how powerful it is for example in terms of this
operation and functions there I don't remember simply I know I think it was
from the CSV to RDF standard or…

Dmitri Zagidulin: Yeah, I see.

Ivan Herman: somewhere someplace like that we used

Ivan Herman: Eight. Yeah.

Dmitri Zagidulin: I see.

Dmitri Zagidulin: Benjamin and then, we should wrap up because we're at the
top of the hour.

Benjamin Young: Yeah. …

Benjamin Young: mustache is great for what it is, but it's super limited.

Benjamin Young: So, I think a big part of the conversation is about finding
something more powerful, but not too powerful. That's it.

Dmitri Zagidulin: Yep.

Dmitri Zagidulin: So here we might need to stretch the concept of what's
stable or not because I don't think any templating language is in W3C and
ITF and the usual SDOS's. So may have to be generous with what's stable or
not.
01:00:00

Dmitri Zagidulin: Okay, excellent discussions everyone. Thank you. see you
again in two weeks for more rendering methods.

Phil Archer: Dimmitri, two weeks is TAC.

Dmitri Zagidulin: Excitement. good point.

Phil Archer: Are you going to have this call in the middle of the night in
Japan Right.

Dmitri Zagidulin: Two weeks is TAC. no, I would rather not honestly. I mean
I do want to participate in TAC sessions but we should probably u call in
four weeks which gives us plenty of time to do async work on issues.

Brent Zundel: We also do have on the agenda for Tback a working session
that includes render methods. So, excellent

Dmitri Zagidulin: Then I take it back. So I will see you in two weeks on
that session right there.

Ivan Herman: Right.

Phil Archer: And with the time zone is the same time anyway.

Dmitri Zagidulin: Thanks everyone.

Phil Archer: It's always the middle of someone's night, right?

Dmitri Zagidulin: Right, right, right. Yeah, sadly. all right. Thanks
everyone. Cheers. See you in two weeks at Tback. Bye.
Meeting ended after 01:01:47 👋

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

Received on Wednesday, 29 October 2025 22:08:36 UTC