Meeting minutes
Transcription Announcement
Phil Archer: could be running the meeting today.
Manu Sporny: I think this is the render method call, right? Dimmitri is up today.
Dmitri Zagidulin: I thought it was the other one. My apologies, but we are happy to dive into render method.
Brent Zundel: Excellent. Then let us dive in. Any day that we proceed with meetings with this format, as folks may know, I am the chair of the process CG. And as such, I have had far more time to dedicate to pouring through the process than most people should ever have to spend time pouring through the process. And there is a very clear bit from the process about recording and auto-transcription of meetings, which is what we're doing with these. And so this is to announce that we intend at the start of this meeting to do an auto-transcription.
Brent Zundel: The purpose of this transcription is to serve as a record of the discussion primarily for the working group to have at its fingertips. How is the transcript being retained? I believe it's being retained as meeting minutes. Is that right?
Ivan Herman: Is that correct? You mean the minutes? Yes.
Brent Zundel: And how long will these meeting minutes be held until the heat death of the universe? Because the W3C will stand that long. Yes, the minutes will be archived.
Ivan Herman: They are archived with the rest of the working group minutes at GitHub.
Brent Zundel: All right. Is there anyone here who withholds consent for retaining this automated transcript?
Brent Zundel: Okay, I'm not hearing anyone withholding. Auto-transcription can proceed. And apologies for future meetings, which also should have this happen at the beginning of every single one of them. Yay. Yeah.
Dmitri Zagidulin: Wait, a question.
Dmitri Zagidulin: Go ahead.
Brent Zundel: No, no, go ahead.
Dmitri Zagidulin: Somebody, I think it was just echo. So, a question. You said we need to warn about this or...
Dmitri Zagidulin: flag this at the beginning of every call? Is that what your last comment was?
Brent Zundel: Yep. Yeah.
Dmitri Zagidulin: So add these meetings are recorded, etc.
Dmitri Zagidulin: Got it.
Brent Zundel: I mean, and basically just say, an automatic transcription of this meeting will be held indefinitely at a W3C namespace. If there's anybody who objects to that, then we can't do the auto-transcription according to the current process that we're operating on. So I'm on it.
Manu Sporny: Yeah, I don't want to go into process things. I just have a note for maybe the process CG. I think it should be an option for the working group to continue and that party to not say anything or for the working group to say, "Sorry, this is the way we operate." My concern here is that you can have one person throw off the entirety of the meeting. I think that's for later. Today, we don't have that problem, but I'm concerned about what happens if you have a random individual show up and then say that stop the working group from being able to operate as it normally does. That's it.
Brent Zundel: I agree with that concern.
Brent Zundel: This little bit has been part of a much larger conversation that's been happening. This comes up in the AB meeting all the freaking time. There are people who feel deeply and very strongly about this, and I'm hesitant to believe that it could ever be changed too much. But I will certainly, I mean, as problems arise, please let us know. If your things completely got derailed, we have to fix this. Please let us know so that we have those data points.
Michael Jones: Brent, people feel strongly about what?
Brent Zundel: People feel very strongly about their words being auto-transcribed and...
Phillip Long: Thank you.
Michael Jones: Okay.
Brent Zundel: ...the usually accompanying inability to say, "Don't scribe this next part."
Brent Zundel: Ivan, you got your hand up.
Ivan Herman: Yes. I mean, to clarify one thing, but that's a question to Manu. The audio recording itself is not stored. Is that correct?
Manu Sporny: It's stored on the CCG servers, but we can change that. So, it's deleted.
Ivan Herman: Because...
Ivan Herman: ...if we do that, if we delete the audio once the minutes are published on wherever it is published...
Phillip Long: Oops.
Ivan Herman: ...then the whole situation is not much different from any other meeting minutes that we have. People can ask to have some things deleted or changed if that creates a problem for them. That's also true for the minutes that we produce with the traditional means.
Brent Zundel: I suspect that the pressure to allow automatic transcription is going to increase because the tools are getting much better and scribing is miserable.
Brent Zundel: And it'll be interesting to see how the holdouts against that respond. So if problems arise, please let us know because there are people...
Dmitri Zagidulin: Thank you.
Brent Zundel: ...who are like, "No, this needs to change in the process." So at the moment, though, if we could spend 30 seconds at the beginning of each call and say, "There's going to be an automated transcription. The recording from this is going to be deleted, but there is not an automated transcription that will persist as the notes. Is there anybody who objects?" If you have that at the beginning of each call, then we're covered by the process. And as problems arise, let us know.
Dmitri Zagidulin: And just to clarify, the option of saying, "If you object, drop off," is not a good option, right?
Brent Zundel: It's, I mean,...
Brent Zundel: ...if someone is a paid member of the W3C who has joined the group, they have a right to attend the meetings.
Dmitri Zagidulin: Right. Got it.
Brent Zundel: And so, it doesn't really work to say, "Sorry, you can't come."
Dmitri Zagidulin: Yep. Understood. Just wanted to check.
Brent Zundel: Yeah. Yeah.
Dmitri Zagidulin: Yep. Thank you so much...
Brent Zundel: And now I'm going to be quiet because I'm not in charge of leading this meeting.
Pull Request Discussions
Dmitri Zagidulin: Brent. All, welcome everybody to what is hopefully going to be a regularly weekly spec improvement meeting.
Phillip Long: What's up?
Dmitri Zagidulin: This is the render method half of the call. This meeting is going to be transcribed and the transcription is going to be stored on W3C servers. So if you object, let us know. I'm just practicing. All right.
Dmitri Zagidulin: So I suspect a lot of us, after the sort of holiday break, need to refresh our memories on what all is going on with render method. So let us start with the pull requests and then we'll do issue processing. I'll share my screen. Go ahead, Manu.
Manu Sporny: Okay, just a real quick agenda request. We have done some work on HTML render method and we'd like to report out to the group on that because we think it might impact a number of the issues. So after PR processing, just an agenda plus please on HTML render method.
Dmitri Zagidulin: All right, so we'll take a look at the PRs there that aren't actionable today, and then we'll go to the HTML render method. Thanks. All right, sharing screen. Here we go. Okay. So, we have several of these. We discussed during the last call. So, let's start with this one. This is an older one about the OCA bundle render method.
Dmitri Zagidulin: I think during the last call we mentioned that one, there's conflicts, but two, we're hoping to introduce a unified templated parameterized render method, that this one may need to be revisited. So, we're waiting on the OCA bundle by Patrick, who I don't think is here on this call.
Dmitri Zagidulin: Next up, we have introduce render method for untlated renderings. So, we have some requested changes from Dave Longley. We have a couple of minor editor requests from Tall Ted, which looks like may have been a reminder to everyone to take another look at VC render method 38 and give your thumbs up or change requests. Let's see. We're in the special topic all channel.
Dmitri Zagidulin: So, I'm just going to press, I'm going to paste on IRC the URL to this pull request 38...
Phillip Long: We are not.
Dmitri Zagidulin: ...unless we're not using IRC for these calls. In that case, I will post these into Zoom. All right. So, any questions about the render method for untlated renderings,...
Manu Sporny: I think we're going to close this one based on...
Dmitri Zagidulin: Right? Okay.
Manu Sporny: ...but that's part of this upcoming discussion, I think, just a heads up.
Dmitri Zagidulin: Okay. Great. Understood. Yeah.
Dmitri Zagidulin: So we have a couple of PRs that will need to be closed or refactored based on...
Dmitri Zagidulin: All right. So this is 38. Okay. Let's move on to the next one. Cardlike display of wallets. This one's a draft, so it's not ready for review yet. Otto, let's see. I'm not sure if he's on this call, but are there any questions about this one? Go ahead, Manu.
Manu Sporny: No questions. This came about again as a discussion of this other item on HTML rendering. Nate put together a proposal. I think this comes from kind of the education community about just a really simple card-like layout that doesn't have any rich graphics or anything. Here are the names and here are the properties that the issuer of a credential would like to be able to be displayed in a very simple row-based layout.
Manu Sporny: You're seeing a lot of digital wallets do this kind of thing in a variety of different ways and guess as to what information should be shown. And so this is, I think, Nate's attempt to create a summary layout for a credential so that's what this PR is about. There's some questions around internationalization, accessibility, and that sort of thing that we'll need to talk through there. But, I think the expectation is that this render method would be separate from the other more graphically intensive render methods. That's it.
Dmitri Zagidulin: Got it. And we discussed it during the previous call last month and mentioned that it needs some refactoring and then we'll revisit it. Dave, did you have your hand up? All right. Next up, we have a recent PR. I'm not recognizing by All and this one's a fairly straightforward one. It references the mustache specification instead of copying the...
Dmitri Zagidulin: ...mustache string replacement algorithm.
Dmitri Zagidulin: So this one, hopefully, is not very controversial. We'll request 41. Please take a look. We've got. Go ahead, Ivan.
Ivan Herman: Yeah, I hope it's not controversial.
Ivan Herman: The question has always been on these kind of things whether the document that we refer to is stable enough to be normatively referred to. I don't know. I have seen mustache for many years.
Ivan Herman: So I would think it's stable, but a reference to a GitHub.io URL is not necessarily a good sign.
Dmitri Zagidulin: So that's a very good point and...
Dmitri Zagidulin: ...normally, I think if this was a specification, I completely agree with you.
Dmitri Zagidulin: My only hesitation is that we're essentially in the land of media type specific processing, right? We're essentially saying, "Process this according to the media type," and if it happens to be the mustache one, then do whatever mustache. So I'm not sure that when referring to specific processing, we require that media type to be spec stable. But let's, I think Manu, go ahead.
Manu Sporny: Yeah, just noting something that Dave said in chat. I think the upcoming HTML rendering method discussion might get rid of this concern of having to ref mustache while still being able to support mustache and a variety of other templating engines.
Dmitri Zagidulin: Got it. Okay.
Dmitri Zagidulin: But, question, Manu, if what about Ivan's concern that do...
Manu Sporny: If we have to mustache, it's stable, Ivan. And I'm fairly confident that we can find a way to ref it properly.
Manu Sporny: I agree with you that the GitHub link is problematic, but mustache has been stable for a long time. And, yeah.
Ivan Herman: Yeah, that's...
Ivan Herman: ...what I would expect that we need to defend this industry in a way.
Manu Sporny: I'm saying we won't have to defend this if the proposal we're about to make sees any kind of adoption by the working group.
Ivan Herman: Okay, we will come back to that if necessary.
Dmitri Zagidulin: Pause for leaving comments. Maybe brought up the fact that it's addressed by the HTML.
Dmitri Zagidulin: All right. Okay. So, I think that those are all of the new action to be taken PRs. So let's talk about the HTML proposal, especially since it seems to be touching on a lot of these open PRs. Over to you, Dave and Manu.
HTML Render Method Proposal
Manu Sporny: Yeah, thanks Dave. I don't know if we, I think pulling up the source code would probably be starting. So let me start with kind of a high-level thinking around this. Apologies, don't have a document, don't have a PR, but wanted to pass this by the group before we put in the effort. Okay, so we have in the group and in the community had multiple requests for some kind of HTML templated rendering mechanism. And there are a lot of arguments for why HTML, right? It's fully programmable, it can be interactive, it's responsive to layout, it has a good accessibility and internationalization story, all these things are benefits.
Manu Sporny: The main argument against it, and I am one of the people that was very opposed to it until recently, was that we don't have enough control over sandboxing, meaning that there are things you can do to escape the sandbox, and what that means is that you can then start tracking people and figuring out what credentials they're showing and figuring out where wallets exist in the world and all kinds of really terrible things from a privacy perspective. More recently, we've run a series of experiments and found out that that is incorrect. So, Dmitri, you were right, I was wrong. There are combinations of sandboxing mechanisms that you can use on an HTML iframe through the sandbox feature that are broadly deployed across every single modern browser.
Manu Sporny: And are available to us if we want to use it. So, basically, what we can do is we can have an HTML document with an active programming environment, which means that JavaScript is enabled. We can turn off all external network communication to that sandbox. So it can't reach out and ping back or report on the display. So it's just this fully contained rendering engine. And with just HTML and JavaScript, the person that is deploying that, that verifiable credential can use any templating mechanism they want. They can render to SVG if they want, they can render to PDF if they want, they can support audio, they can support animation.
Manu Sporny: They can support all these crazy things that HTML supports in a fully sandbox mode. The remaining concerns are resource usage and things like that. And you can constrain those things as well. This capability exists on Android, Windows, Linux, Brave, Chrome, Chromium, Safari, every modern platform that is probably going to try and display a visual verifiable credential.
Manu Sporny: So it's a revisit of this assertion that we can't sandbox. We can sandbox. And as a result of that, it may be that we can unify all of these things.
Manu Sporny: So if we're able to do this, we can get rid of SVG render method, we can get rid of PDF render method, we can unify the open attestations render methods, and we can unify the Singapore based mechanism because that's HTML based. So, let me pause there. Dave, did I miss anything high level? And then I'd like to just get a reaction from the working group on, is this path worth pursuing through a PR, or do people have remaining concerns?
Dave Longley: Just to respond, I don't think you missed anything high level. There are some lower level details around sandboxing and other technologies that have to be used to accomplish this goal, but we can get into those details as needed later.
Phil Archer: Do you have an example to hand?
Dmitri Zagidulin: This is all No,...
Phil Archer: Dave, I should have put my hand up. I'm sorry.
Dmitri Zagidulin: No, please go ahead.
Dave Longley: Actually yes, and...
Dave Longley: ...I can go ahead and put into chat some test code that we've been running. If this is for the highly technical people, the second link is the GitHub pages for the first link, which is a repository that has the source code in it. So anyone who wants to look at source code can look at that first link, and the second link shows you a simple technical demo with a button. If you press that button, the rendering is just in JSON. That rendering could have displayed anything at all, but it's a technical dev demo.
Dave Longley: So, it's just showing that the credential in JSON, and it's demonstrating a sandbox plus CSP protected display of a verifiable credential.
Dave Longley: If you open up the console in Chrome or whatever browser you have, there's also some stuff that's printing out that's demonstrating that network connections are blocked. And Manu is going to present that.
Dmitri Zagidulin: Thanks, Dave.
Dmitri Zagidulin: This is all music to my ears, since I do think that this is incredibly useful. Content Security Policy directive does what it says on the tin. Excellent.
Dmitri Zagidulin: So, I think the question, and I suspect the rest of the folks on the call have, is so what should be our next steps on this? Does anybody want to... Okay, we have two sort of big ticket items. One is to propose a templated parameterized render method based on this, and then the other, I guess, there's a procedural question of, should we give guidance of when implementing this method, put it behind an iframe with the CSP directive? Where does the implementation guidance belong? Can we put it in the spec, or does it necessarily need to be in an implementation guide? So that's a question to the group. Hi, Ivan.
Dmitri Zagidulin: Go ahead.
Ivan Herman: So, I think that it depends on the sizes, of course...
Ivan Herman: ...but at first hand, I would think that putting implementation guide into the spec is acceptable unless it becomes very complicated and convoluted. But if it's acceptably simple, let's put it this way, then I think part of the spec is perfectly fine. But that's also a style of spec writing. There are some people who do not like that and want the spec to be as unreadable as possible because it should be reverse code, but that's not me. I also had a question when I originally pushed, do I understand well that if we go that way, then this makes, Manu, you said something like that, this makes all the current rendering method drafts...
Ivan Herman: ...which are in the spec, essentially taken out? So the spec would be the HTML rendering method with all the details and bells and whistles, et cetera?
Dmitri Zagidulin: So, I see Manu in the queue.
Dmitri Zagidulin: But I'll jump in to interrupt and say, all the proposed methods except possibly for the overlay mechanism, which is its own syntax.
Dmitri Zagidulin: But go ahead, Manu.
Manu Sporny: Yeah, I think we do it in two passes. The first one is to just define this thing we're talking about today, and then the second pass is to see if it provides equivalent functionality to the other render methods in there. I think potentially we will end up there, meaning there's no reason to have different ways of doing HTML rendering because we know because this mechanism does all of them. I'll also make a quick comment, Dmitri, on what you said about we would define a templated thing.
Manu Sporny: We would not have to define any templated anything at this point because the iframe, the HTML rendering engine is running in a sandbox thing. You can run arbitrary JavaScript, which means that you can choose whichever templating language works for you. So we'd say, "We don't have to say it's a network subset of mustache." We don't have to say it's Handlebars, anything else like that. You can actually put the template engine in the actual source doc itself and use whatever templating mechanism you want. Which means for the OCA thing, you can put an OCA engine into the HTML document. You could use JavaScript as your templating language.
Manu Sporny: It allows you to use the tooling that you want to use. And as long as that tooling runs on top of HTML and JavaScript, which almost all tooling does today, we don't have to specify any of this in the spec, right? Meaning that's totally out of scope for the spec. It simplifies the spec by a huge amount and it prevents us from having to have month-long discussions around what subset of mustache are we going to use and so on and so forth. Done.
Dmitri Zagidulin: Go ahead, Benjamin. I think you're up next on the queue.
Ivan Herman: Benjamin, open.
Benjamin Young: And double muted. Sorry, guys.
Dmitri Zagidulin: No worries.
Benjamin Young: Yeah, I was just going to point out to highlight the last thing that Manu was talking about, that people need to be aware that you're shipping an H, a self-contained HTML file with whatever JavaScript you need in it to do whatever rendering you're going to do. So this HTML file, because it's in a sandboxed CSP container, cannot do network requests. It's not going to go get libraries from somewhere. So this HTML app that you're getting that's going to do the rendering can use mustache, handlebars, whatever, but it's got to have all of that baked into it.
Benjamin Young: So, if your mental model was, "I have a web page and it's going to use links and script tags that have SRC values," like that's not this environment. This environment is like everything is inlined into a single HTML file and then stuck in the source doc value of an iframe to keep it self-contained.
Benjamin Young: So that is an architectural thing that I hope everybody's caught up with mentally. That's it.
Dmitri Zagidulin: Thanks, Dave...
Dmitri Zagidulin: ...go ahead.
Dave Longley: Yeah, that's right.
Dave Longley: And this matches how a lot of people ultimately end up deploying applications as bundles of things, but they do need to keep in mind that no external connections or calls out will be possible. But I want to be responsive to Ivan's comment around whether or not the entire spec would only now be about an HTML render method. I don't think that's true. The first obvious exception that comes to mind is this JSON card summary rendering method, which would not use HTML. And I think it's important for us to also have the ability to provide something that can output some simple summary card rendering thing for systems that do not necessarily have HTML or that want to have control over their own display and user experience in their application, at least for certain interfaces. So I think we would have at least those two things.
Dmitri Zagidulin: Thanks, Dave. Phil and then Ivan and...
Phil Archer: Thanks.
Dmitri Zagidulin: ...I think I was on the queue after Phil.
Phillip Long: It's easy.
Phil Archer: Sorry.
Dmitri Zagidulin: Go ahead.
Phil Archer: I'm being very slow. Might be helpful to catch up, but we're talking about so this single HTML document, would it be linked from the VC or embedded in the VC? And I'm getting confused with the use of an iframe, which is inherently not part of the page you're looking at. And where does the thing come in that says, no, there's a sandbox, you can't do anything? So that Phillip's question becomes relevant about linking to other things. I think we're talking about the rendering being sandboxed, not the VC itself. So the VC could still link to other VCs.
Phil Archer: I'm just trying to get my head around where this stuff is, and I probably need to spend time and not waste everyone else's time as I look at it. But it feels right, but I'm just trying to get my head around it as a simple web developer.
Dmitri Zagidulin: No, I think these are all excellent questions.
Dmitri Zagidulin: I can address some of them and...
Dmitri Zagidulin: ...be curious to hear about the others, but let's get Ivan on the queue.
Ivan Herman: Yeah, I agree. These are good questions. So don't say that. Coming back to what Benjamin said, does it mean that, plainly speaking, all the JavaScript must be part of the HTML file itself in a script tag, or do we have some sort of a bundling packaging mechanism that allows the scripts to be put in their separate files and something...
Ivan Herman: ...because some of these scripts might be huge?
Dmitri Zagidulin: Also excellent question.
Ivan Herman: So it might be very difficult to maintain something that requires that to be part of the HTML file.
Dmitri Zagidulin: Okay, so a couple of things. One, to quickly address Phil's question about embedded versus linked. So, I think for all of these render methods, we're going to need, we're going to need to support fetching this template from the net, alternately validating the hash digest, reading it fully embedded from this verifiable credential since it's signed over, and then processing it.
Dmitri Zagidulin: The two methods have a fundamental trade-off. Some use cases and implementers methods to be embedded will support only embedded methods for various security and offline reasons. Others must be able to support linked methods due, for example, to size constraints on the verifiable credential. Which, to remind folks, once a verifiable credential gets over a certain size, it not only can't be stored in a QR code, most VCs won't be able to store in a QR code unless they're incredibly minimal, but more importantly, the parsing of them basically crashes mobile platforms. So we do have a soft size limit on implementation of credentials.
Dmitri Zagidulin: So to summarize, for all of these methods, we're always going to have to be able to support both embedded and linked methods. The thing that I wanted to bring up, the reason I got on the queue is, if I'm understanding what Manu and Benjamin are saying correctly, the template substitution will have been already done at the issuing point. So that aside from embedded and linked, there are two basic categories of these render methods, and it's essentially compiled at issue time and compiled at display time.
Dmitri Zagidulin: And those are again, two sort of fundamental trade-off use cases, and I believe the thing that is being proposed here only handles one of those, the template substitution things are compiled at issue time. And so, first, let me go to the queue and ask, is that a correct interpretation? I've got Manu.
Manu Sporny: No, that's not correct. It supports both. The way this rendering mechanism works is you can pass the VC in with a subset of fields to the HTML system, which then receives the VC, whatever parts you want to send to it, and then it can pull values out and do template substitution with it. Or you can not use a template and just hard code everything and embed it. So it supports both mechanisms and we'll go into the exact way you accomplish that, which gets to the other plus one to everything that you were saying up until that point, that was all correct. So we support remote linking to HTML documents.
Manu Sporny: We support embedding it. The remote linking has digest multibase hashes and all that kind of stuff. Plus one to that. Phil, you also asked, and again, there's nothing for you to read yet, Phil. So don't worry about it.
Phil Archer: Okay. Yeah.
Manu Sporny: We're trying to figure out what we're going to write. But once that's there, we'll put it out there. The other question that you had, Phil, was around the frame and how does that work and all that kind of stuff. One of the challenges that we kept hitting when trying to create new render methods is that exact same problem of mustache referencing it and then figuring out what subset of it we're going to use and all that kind of stuff. The nice thing about the HTML render method is it is already speced as W3C specs and it has already been deployed out there and is in production. So, what's our point of reference for this? It's the HTML 5 spec and how it works. There's a part of the HTML 5 spec that talks about iframes and specifically sandbox mode for iframes.
Manu Sporny: So sandbox mode was put in for the ad networks so that the ad networks couldn't sniff too much information about you. We are using that feature to effectively shut down the entirety of the code's ability to escape the sandbox. And so that's defined on the iframe element. That's why I said you don't have to use an iframe. You can do a bunch of different other types of things to create the equivalent sandbox. But the easiest thing for us to ref is to basically say, "Do what sandbox mode with an iframe does with these content security policies applied." We ref all the HTML 5 spec stuff to do that and we're done with our normative kind of definitions there.
Manu Sporny: So that's why we keep saying iframe is because iframe has a sandbox mode and that is the specific mechanism that we're using and we're going to, you can do anything you want to achieve that same effect, but what we expect most people to do is to effectively write the code that they've longly linked to and has written and use that as the execution engine. What that does is it creates this sandbox thing, and that sandbox takes an input, the verifiable credential you want to send into it, with specific fields. I think Dave, we allow filtering of the VC down to a subset of fields, so you don't have to send the entire thing in.
Manu Sporny: And then the HTML engine gets that VC and then we'll do whatever logic it needs to run to render it to the screen. Ivan, you asked, how does this bundling happen? All that kind of stuff. There are tools like Webpack that do that already, right? So that build process to build all of the JavaScript, including template rendering engines and all that kind of stuff into a package to inject it into the HTML already exists. It's common tooling. And then the thing that is a result of the ability to do that is you might have an HTML render template thing, a file that is multiple megs in size.
Manu Sporny: And so we're going to have to put in warnings into the specification about keeping your VC size down by remote linking. And if there is a remote link, then you may not want to download anything over that type of guidance, is stuff we can put into the specification. That's it.
Dmitri Zagidulin: Thanks, Benjamin and...
Dmitri Zagidulin: ...then Dave.
Benjamin Young: Yeah. I think...
Benjamin Young: ...if you think of this as the render method is providing the runtime that receives some or all of a VC and then renders it via JavaScript into HTML stuff that is displayed, you have the right mental model. This is going to sound similar to the web publication stuff Dave and I were doing or many apps if you've come across any of the past Webby attempts to have a constrained JavaScript and HTML engine that receives some file and then does a thing. That's the foundational premise here. So you can in effect do anything you want, short of communicating with the network. So the JavaScript receives a credential and then does whatever it's going to do.
Dmitri Zagidulin: Thanks, Benjamin. Dave.
Benjamin Young: So, just trying to continue to clarify what's being said. Cheers.
Dave Longley: So, I put this into chat. I might be getting into too many details here. Uh, but just a quick overview. I think we're going to have some basic interop things we'll need to put in the spec that just talk about how to use standard browser JavaScript to reduce the credential by the fields that are specified in the render method. So this is selectively disclosing the fields that will be displayed and then how to pass that credential and the template from the render method into the iframe and then getting a message back from the iframe that says it's ready for being inserted into the DOM or displayed. So I think there's a couple little places where we will talk about what someone who wanted to implement this, so anyone could plug in any HTML render method from an issuer would need to do.
Dave Longley: So there's a few little points there that can go into the spec that will cover.
Dmitri Zagidulin: Thanks, Dave.
Dmitri Zagidulin: One second. My to start with. So I really like this approach and I think it's going to address several of the use cases. My main concern about it is or I guess it's more of a question is, does it handle the print to PDF use case?
Dmitri Zagidulin: It sounds like it requires a browser rendering engine to run, the browser rendering engine and a JavaScript runtime to process it inside the iframe. It performs the template substitution. So my question is more about, let's say the use case that my team at DCC implements, which is a static HTML template, perform the application code performs string substitution, and then converts to PDF without firing up a separate browser...
Dmitri Zagidulin: ...renderer and JavaScript runtime. So, I see Dave on the queue, so maybe you can address that.
Dave Longley: I don't know about that latter bit, but what I was on the queue to say was, using this mechanism, you can pass the VC in and a template into this iframe, and you can have the iframe perform whatever templating you want to, whatever substitution you want to. You can have a display PDF. You can also put print links from there.
Dave Longley: So you could download a PDF file or any other file format you would want from this. So those are the affordances. I don't know if that addresses your last comment, which was because you were saying without having another HTML environment, but this whole method requires there to be this HTML environment.
Dmitri Zagidulin: I see.
Dmitri Zagidulin: So I think it may be obvious, but just to state explicitly. So this method will be able to cover a lot of the use cases, but we will need a couple of other render methods for the remaining use cases that can't use an iframe and JavaScript runtime. Let's see. Manu and then Dave.
Manu Sporny: Possibly like that. That's what the summary card thing is about. I am wondering, and this is one of the questions that came up internally, I think the response is, if you are on an environment that wants to print or render this, tell us what environment doesn't have an HTML engine today where you want to do that, right?
Manu Sporny: And so I'm not talking about IoT devices. I'm saying you are on something and you want it to print to PDF, what are you using that doesn't have an HTML engine? Right? So if it's Android and iOS, you've got WebKit and iframe, and you can instantiate. So all mobile phones have that today. If you're on a desktop, you've got again multiple browser options there. If you're on a Raspberry Pi, it's got multiple rendering engines that you can provide there, multiple headless implementations, Chromium, you can pull it in and run it in headless mode. So, if you're even on a server, you've got these render environments.
Manu Sporny: So I think the question is, if we hit a use case like that, we need to hear from the person, what device are you using where you need to do this, and it doesn't have access to a rendering engine. I think that should be the first question we ask people, is, "Name the environment that you're really using in production that doesn't have access to a rendering environment or an HTML engine." That's it.
Dave Longley: I also wanted to remind the group that we have at least one other simple render case, which is rendered to NFC, that doesn't involve any visual or audio or anything. It's just transmission over NFC. So we do have some very simple cases, but I think if you bring in visual downloading files, anything of that sort, I think everything that Manu just said is a great way to frame the conversation to ask, "Where, if you need to do these things, where is it that you need to do them where you don't have an HTML engine to accomplish?"
Dmitri Zagidulin: Thanks, All. Do we have any other questions from folks? So this sounds like a very useful method, and I think we're all looking forward to seeing the pull request. Any other questions? All right.
Phil Archer: Dmitri, if I may just chuck in a thank you to Dave and...
Dmitri Zagidulin: Yeah, please go ahead. Likewise.
Phil Archer: ...Manu and Benjamin for working on this. This obviously sounds very exciting and very valuable work that's moving us forward. So, thank you for taking the time to do it.
Dmitri Zagidulin: Thank you much. I do have a question about rendering this as a list, but Manu, you're on the queue.
Manu Sporny: I speaking just reminded me that we didn't answer one of your questions, Phil, which was, what do you do with VCs that are linked from one to the other? I think right now you can take one of those VCs and put it into the rendering engine. It may be that you could fully resolve a network of VCs and send it into the rendering engine. I think that's work that still needs to be explored. But I'm pretty confident that for the supply chain use cases that GS1 is looking at and working on, I'm fairly certain either the single VC itself can definitely be rendered and...
Phil Archer: Actually, just a thought on that.
Manu Sporny: I think we could even get to a network of VCs, but that's some work that still needs to be done. That's it.
Phil Archer: If the rendered VC in the frame that is sandboxed contains a hyperlink, can I click it or is that blocked?
Manu Sporny: It's blocked.
Phil Archer: It's blocked, right? Okay.
Dmitri Zagidulin: Wait, wait,...
Dmitri Zagidulin: ...wait. Are you sure? Because I think the sandbox is to the JavaScript, not to the resulting HTML. Safety.
Manu Sporny: I think you can turn things on and off in the sandbox through the CSP directives, and I think there's a way to allow that if I remember correctly. And this is going to be a discussion on the details, right, which content security policies do we enforce by default? Do we allow people to, do you allow links, things like that?
Dmitri Zagidulin: Dave, go ahead.
Dave Longley: Yeah, there are details...
Dave Longley: ...but by default, navigation is disabled.
Phil Archer: Okay, thank you.
Dave Longley: So there are details we can work through as we look at it and figure out what's okay, what's not okay, and what security privacy considerations might apply.
Dmitri Zagidulin: Got it. Okay. So, yeah, there's going to be several use cases where, for example, you want to embed an image source into it, where you're going to links that will need to be openable, but it sounds like that's toggled on the CSP level.
Dmitri Zagidulin: And thank you, Benjamin, for the documentation link. All right, any other questions from the group? We're almost at the top of the hour, so this is a great place to end.
Ivan Herman: Confidence.
Dmitri Zagidulin: Right. Thanks, everyone. I'll see you next week for content, for not, got that, for...
Phil Archer: It's a full working group meeting next week.
Dmitri Zagidulin: It is a full working group. Okay. Got it.
Phil Archer: Yeah. Yep.
Dmitri Zagidulin: Right. Cheers.
Phil Archer: Thanks for Thanks. Thanks, everyone.
Sandboxing and Security Considerations
Manu Sporny: The main argument against it, and I am one of the people that was very opposed to it until recently, was that we don't have enough control over sandboxing, meaning that there are things you can do to escape the sandbox, and what that means is that you can then start tracking people and figuring out what credentials they're showing and figuring out where wallets exist in the world and all kinds of really terrible things from a privacy perspective.
Manu Sporny: More recently, we've run a series of experiments and found out that that is incorrect. So, Dmitri, you were right, I was wrong. There are combinations of sandboxing mechanisms that you can use on an HTML iframe through the sandbox feature that are broadly deployed across every single modern browser.
Manu Sporny: And are available to us if we want to use it. So, basically, what we can do is we can have an HTML document with an active programming environment, which means that JavaScript is enabled. We can turn off all external network communication to that sandbox. So it can't reach out and ping back or report on the display. So it's just this fully contained rendering engine.
Benjamin Young: So, if your mental model was, "I have a web page and it's going to use links and script tags that have SRC values," like that's not this environment. This environment is like everything is inlined into a single HTML file and then stuck in the source doc value of an iframe to keep it self-contained.
Dave Longley: And this matches how a lot of people ultimately end up deploying applications as bundles of things, but they do need to keep in mind that no external connections or calls out will be possible.
Phil Archer: I'm just trying to get my head around where this stuff is, and I probably need to spend time and not waste everyone else's time as I look at it. But it feels right, but I'm just trying to get my head around it as a simple web developer.
Ivan Herman: Coming back to what Benjamin said, does it mean that, plainly speaking, all the JavaScript must be part of the HTML file itself in a script tag, or do we have some sort of a bundling packaging mechanism that allows the scripts to be put in their separate files and something...
Manu Sporny: So sandbox mode was put in for the ad networks so that the ad networks couldn't sniff too much information about you. We are using that feature to effectively shut down the entirety of the code's ability to escape the sandbox. And so that's defined on the iframe element. That's why I said you don't have to use an iframe. You can do a bunch of different other types of things to create the equivalent sandbox. But the easiest thing for us to ref is to basically say, "Do what sandbox mode with an iframe does with these content security policies applied."
Dmitri Zagidulin: Wait, wait,... wait. Are you sure? Because I think the sandbox is to the JavaScript, not to the resulting HTML. Safety.
Manu Sporny: I think you can turn things on and off in the sandbox through the CSP directives, and I think there's a way to allow that if I remember correctly. And this is going to be a discussion on the details, right, which content security policies do we enforce by default? Do we allow people to, do you allow links, things like that?
Dave Longley: Yeah, there are details, but by default, navigation is disabled.
Dmitri Zagidulin: So, yeah, there's going to be several use cases where, for example, you want to embed an image source into it, where you're going to links that will need to be openable, but it sounds like that's toggled on the CSP level.
Implementation Details
Dmitri Zagidulin: So, I think that those are all of the new action to be taken PRs. So let's talk about the HTML proposal, especially since it seems to be touching on a lot of these open PRs. Over to you, Dave and Manu.
Manu Sporny: Okay, so we have several of these. We discussed during the last call. So, let's start with this one. This is an older one about the OCA bundle render method. I think during the last call we mentioned that one, there's conflicts, but two, we're hoping to introduce a unified templated parameterized render method, that this one may need to be revisited. So, we're waiting on the OCA bundle by Patrick, who I don't think is here on this call.
Manu Sporny: Next up, we have introduce render method for untlated renderings. So, we have some requested changes from Dave Longley. We have a couple of minor editor requests from Tall Ted, which looks like may have been a reminder to everyone to take another look at VC render method 38 and give your thumbs up or change requests.
Manu Sporny: Let's see. We're in the special topic all channel. So, I'm just going to press, I'm going to paste on IRC the URL to this pull request 38...
Manu Sporny: ...unless we're not using IRC for these calls. In that case, I will post these into Zoom. All right. So, any questions about the render method for untlated renderings,...
Manu Sporny: I think we're going to close this one based on... but that's part of this upcoming discussion, I think, just a heads up.
Manu Sporny: Okay. Great. Understood. Yeah.
Manu Sporny: So we have a couple of PRs that will need to be closed or refactored based on...
Manu Sporny: All right. So this is 38. Okay. Let's move on to the next one. Cardlike display of wallets. This one's a draft, so it's not ready for review yet. Otto, let's see. I'm not sure if he's on this call, but are there any questions about this one?
Manu Sporny: No questions. This came about again as a discussion of this other item on HTML rendering. Nate put together a proposal. I think this comes from kind of the education community about just a really simple card-like layout that doesn't have any rich graphics or anything. Here are the names and here are the properties that the issuer of a credential would like to be able to be displayed in a very simple row-based layout.
Manu Sporny: You're seeing a lot of digital wallets do this kind of thing in a variety of different ways and guess as to what information should be shown. And so this is, I think, Nate's attempt to create a summary layout for a credential so that's what this PR is about. There's some questions around internationalization, accessibility, and that sort of thing that we'll need to talk through there. But, I think the expectation is that this render method would be separate from the other more graphically intensive render methods. That's it.
Manu Sporny: Next up, we have a recent PR. I'm not recognizing by All and this one's a fairly straightforward one. It references the mustache specification instead of copying the mustache string replacement algorithm.
Manu Sporny: So this one, hopefully, is not very controversial. We'll request 41. Please take a look. We've got.
Manu Sporny: If we have to mustache, it's stable, Ivan. And I'm fairly confident that we can find a way to ref it properly. I agree with you that the GitHub link is problematic, but mustache has been stable for a long time. And, yeah.
Manu Sporny: I'm saying we won't have to defend this if the proposal we're about to make sees any kind of adoption by the working group.
Manu Sporny: Yeah, thanks Dave. I don't know if we, I think pulling up the source code would probably be starting. So let me start with kind of a high-level thinking around this. Apologies, don't have a document, don't have a PR, but wanted to pass this by the group before we put in the effort. Okay, so we have in the group and in the community had multiple requests for some kind of HTML templated rendering mechanism. And there are a lot of arguments for why HTML, right? It's fully programmable, it can be interactive, it's responsive to layout, it has a good accessibility and internationalization story, all these things are benefits.
Manu Sporny: The main argument against it, and I am one of the people that was very opposed to it until recently, was that we don't have enough control over sandboxing, meaning that there are things you can do to escape the sandbox, and what that means is that you can then start tracking people and figuring out what credentials they're showing and figuring out where wallets exist in the world and all kinds of really terrible things from a privacy perspective. More recently, we've run a series of experiments and found out that that is incorrect. So, Dmitri, you were right, I was wrong. There are combinations of sandboxing mechanisms that you can use on an HTML iframe through the sandbox feature that are broadly deployed across every single modern browser.
Manu Sporny: And are available to us if we want to use it. So, basically, what we can do is we can have an HTML document with an active programming environment, which means that JavaScript is enabled. We can turn off all external network communication to that sandbox. So it can't reach out and ping back or report on the display. So it's just this fully contained rendering engine. And with just HTML and JavaScript, the person that is deploying that, that verifiable credential can use any templating mechanism they want. They can render to SVG if they want, they can render to PDF if they want, they can support audio, they can support animation.
Manu Sporny: They can support all these crazy things that HTML supports in a fully sandbox mode. The remaining concerns are resource usage and things like that. And you can constrain those things as well. This capability exists on Android, Windows, Linux, Brave, Chrome, Chromium, Safari, every modern platform that is probably going to try and display a visual verifiable credential.
Manu Sporny: So it's a revisit of this assertion that we can't sandbox. We can sandbox. And as a result of that, it may be that we can unify all of these things. So if we're able to do this, we can get rid of SVG render method, we can get rid of PDF render method, we can unify the open attestations render methods, and we can unify the Singapore based mechanism because that's HTML based. So, let me pause there. Dave, did I miss anything high level? And then I'd like to just get a reaction from the working group on, is this path worth pursuing through a PR, or do people have remaining concerns?
Dave Longley: Just to respond, I don't think you missed anything high level. There are some lower level details around sandboxing and other technologies that have to be used to accomplish this goal, but we can get into those details as needed later.
Dave Longley: Actually yes, and I can go ahead and put into chat some test code that we've been running. If this is for the highly technical people, the second link is the GitHub pages for the first link, which is a repository that has the source code in it. So anyone who wants to look at source code can look at that first link, and the second link shows you a simple technical demo with a button. If you press that button, the rendering is just in JSON. That rendering could have displayed anything at all, but it's a technical dev demo.
Dave Longley: So, it's just showing that the credential in JSON, and it's demonstrating a sandbox plus CSP protected display of a verifiable credential. If you open up the console in Chrome or whatever browser you have, there's also some stuff that's printing out that's demonstrating that network connections are blocked. And Manu is going to present that.
Dmitri Zagidulin: So, I think the question, and I suspect the rest of the folks on the call have, is so what should be our next steps on this? Okay, we have two sort of big ticket items. One is to propose a templated parameterized render method based on this, and then the other, I guess, there's a procedural question of, should we give guidance of when implementing this method, put it behind an iframe with the CSP directive? Where does the implementation guidance belong? Can we put it in the spec, or does it necessarily need to be in an implementation guide? So that's a question to the group.
Ivan Herman: So, I think that it depends on the sizes, of course, but at first hand, I would think that putting implementation guide into the spec is acceptable unless it becomes very complicated and convoluted. But if it's acceptably simple, let's put it this way, then I think part of the spec is perfectly fine.
Manu Sporny: Yeah, I think we do it in two passes. The first one is to just define this thing we're talking about today, and then the second pass is to see if it provides equivalent functionality to the other render methods in there. I think potentially we will end up there, meaning there's no reason to have different ways of doing HTML rendering because we know because this mechanism does all of them.
Manu Sporny: I'll also make a quick comment, Dmitri, on what you said about we would define a templated thing. We would not have to define any templated anything at this point because the iframe, the HTML rendering engine is running in a sandbox thing. You can run arbitrary JavaScript, which means that you can choose whichever templating language works for you. So we'd say, "We don't have to say it's a network subset of mustache." We don't have to say it's Handlebars, anything else like that. You can actually put the template engine in the actual source doc itself and use whatever templating mechanism you want.
Manu Sporny: Which means for the OCA thing, you can put an OCA engine into the HTML document. You could use JavaScript as your templating language. It allows you to use the tooling that you want to use. And as long as that tooling runs on top of HTML and JavaScript, which almost all tooling does today, we don't have to specify any of this in the spec, right? Meaning that's totally out of scope for the spec. It simplifies the spec by a huge amount and it prevents us from having to have month-long discussions around what subset of mustache are we going to use and so on and so forth.
Benjamin Young: Yeah, I think if you think of this as the render method is providing the runtime that receives some or all of a VC and then renders it via JavaScript into HTML stuff that is displayed, you have the right mental model. This is going to sound similar to the web publication stuff Dave and I were doing or many apps if you've come across any of the past Webby attempts to have a constrained JavaScript and HTML engine that receives some file and then does a thing. That's the foundational premise here. So you can in effect do anything you want, short of communicating with the network. So the JavaScript receives a credential and then does whatever it's going to do.
Dave Longley: So, I put this into chat. I might be getting into too many details here. Uh, but just a quick overview. I think we're going to have some basic interop things we'll need to put in the spec that just talk about how to use standard browser JavaScript to reduce the credential by the fields that are specified in the render method. So this is selectively disclosing the fields that will be displayed and then how to pass that credential and the template from the render method into the iframe and then getting a message back from the iframe that says it's ready for being inserted into the DOM or displayed. So I think there's a couple little places where we will talk about what someone who wanted to implement this, so anyone could plug in any HTML render method from an issuer would need to do.
Dmitri Zagidulin: So I really like this approach and I think it's going to address several of the use cases. My main concern about it is or I guess it's more of a question is, does it handle the print to PDF use case?
Dmitri Zagidulin: It sounds like it requires a browser rendering engine to run, the browser rendering engine and a JavaScript runtime to process it inside the iframe. It performs the template substitution. So my question is more about, let's say the use case that my team at DCC implements, which is a static HTML template, perform the application code performs string substitution, and then converts to PDF without firing up a separate browser renderer and JavaScript runtime.
Dave Longley: I don't know about that latter bit, but what I was on the queue to say was, using this mechanism, you can pass the VC in and a template into this iframe, and you can have the iframe perform whatever templating you want to, whatever substitution you want to. You can have a display PDF. You can also put print links from there.
Dave Longley: So you could download a PDF file or any other file format you would want from this. So those are the affordances. I don't know if that addresses your last comment, which was because you were saying without having another HTML environment, but this whole method requires there to be this HTML environment.
Dmitri Zagidulin: So I think it may be obvious, but just to state explicitly. So this method will be able to cover a lot of the use cases, but we will need a couple of other render methods for the remaining use cases that can't use an iframe and JavaScript runtime.
Manu Sporny: Possibly like that. That's what the summary card thing is about. I am wondering, and this is one of the questions that came up internally, I think the response is, if you are on an environment that wants to print or render this, tell us what environment doesn't have an HTML engine today where you want to do that, right?
Manu Sporny: And so I'm not talking about IoT devices. I'm saying you are on something and you want it to print to PDF, what are you using that doesn't have an HTML engine? Right? So if it's Android and iOS, you've got WebKit and iframe, and you can instantiate. So all mobile phones have that today. If you're on a desktop, you've got again multiple browser options there. If you're on a Raspberry Pi, it's got multiple rendering engines that you can provide there, multiple headless implementations, Chromium, you can pull it in and run it in headless mode. So, if you're even on a server, you've got these render environments.
Manu Sporny: So I think the question is, if we hit a use case like that, we need to hear from the person, what device are you using where you need to do this, and it doesn't have access to a rendering engine, I think that should be the first question we ask people, is, "Name the environment that you're really using in production that doesn't have access to a rendering environment or an HTML engine." That's it.
Dave Longley: I also wanted to remind the group that we have at least one other simple render case, which is rendered to NFC, that doesn't involve any visual or audio or anything. It's just transmission over NFC. So we do have some very simple cases, but I think if you bring in visual downloading files, anything of that sort, I think everything that Manu just said is a great way to frame the conversation to ask, "Where, if you need to do these things, where is it that you need to do them where you don't have an HTML engine to accomplish?"
Dmitri Zagidulin: Thanks, everyone. Do we have any other questions from folks? So this sounds like a very useful method, and I think we're all looking forward to seeing the pull request. Any other questions? All right.
Phil Archer: Dmitri, if I may just chuck in a thank you to Dave and Manu and Benjamin for working on this. This obviously sounds very exciting and very valuable work that's moving us forward. So, thank you for taking the time to do it.
Dmitri Zagidulin: Thank you much. I do have a question about rendering this as a list, but Manu, you're on the queue.
Manu Sporny: Speaking just reminded me that we didn't answer one of your questions, Phil, which was, what do you do with VCs that are linked from one to the other? I think right now you can take one of those VCs and put it into the rendering engine. It may be that you could fully resolve a network of VCs and send it into the rendering engine. I think that's work that still needs to be explored. But I'm pretty confident that for the supply chain use cases that GS1 is looking at and working on, I'm fairly certain either the single VC itself can definitely be rendered and...
Phil Archer: Actually, just a thought on that. If the rendered VC in the frame that is sandboxed contains a hyperlink, can I click it or is that blocked?
Manu Sporny: It's blocked.
Phil Archer: It's blocked, right? Okay.
Dmitri Zagidulin: Wait, wait, wait. Are you sure? Because I think the sandbox is to the JavaScript, not to the resulting HTML. Safety.
Manu Sporny: I think you can turn things on and off in the sandbox through the CSP directives, and I think there's a way to allow that if I remember correctly. And this is going to be a discussion on the details, right, which content security policies do we enforce by default? Do we allow people to, do you allow links, things like that?
Dave Longley: Yeah, there are details, but by default, navigation is disabled.
Phil Archer: Okay, thank you.
Dave Longley: So there are details we can work through as we look at it and figure out what's okay, what's not okay, and what security privacy considerations might apply.
Dmitri Zagidulin: Got it. Okay. So, yeah, there's going to be several use cases where, for example, you want to embed an image source into it, where you're going to links that will need to be openable, but it sounds like that's toggled on the CSP level.
Dmitri Zagidulin: And thank you, Benjamin, for the documentation link. All right, any other questions from the group? We're almost at the top of the hour, so this is a great place to end.
Ivan Herman: Confidence.
Dmitri Zagidulin: Right. Thanks, everyone. I'll see you next week for content, for not, got that, for...
Phil Archer: It's a full working group meeting next week.
Dmitri Zagidulin: It is a full working group. Okay. Got it.
Phil Archer: Yeah. Yep.
Dmitri Zagidulin: Right. Cheers.
Phil Archer: Thanks for. Thanks. Thanks, everyone.
HTML Render Method Proposal Continued
Manu Sporny: We would not have to define any templated anything at this point because the iframe, the HTML rendering engine is running in a sandbox thing. You can run arbitrary JavaScript, which means that you can choose whichever templating language works for you. So we'd say, "We don't have to say it's a network subset of mustache." We don't have to say it's Handlebars, anything else like that. You can actually put the template engine in the actual source doc itself and use whatever templating mechanism you want.
Manu Sporny: Which means for the OCA thing, you can put an OCA engine into the HTML document. You could use JavaScript as your templating language. It allows you to use the tooling that you want to use. And as long as that tooling runs on top of HTML and JavaScript, which almost all tooling does today, we don't have to specify any of this in the spec, right? Meaning that's totally out of scope for the spec. It simplifies the spec by a huge amount and it prevents us from having to have month-long discussions around what subset of mustache are we going to use and so on and so forth.
Manu Sporny: So if we're able to do this, we can get rid of SVG render method, we can get rid of PDF render method, we can unify the open attestations render methods, and we can unify the Singapore based mechanism because that's HTML based.
Manu Sporny: The main argument against it, and I am one of the people that was very opposed to it until recently, was that we don't have enough control over sandboxing, meaning that there are things you can do to escape the sandbox, and what that means is that you can then start tracking people and figuring out what credentials they're showing and figuring out where wallets exist in the world and all kinds of really terrible things from a privacy perspective. More recently, we've run a series of experiments and found out that that is incorrect. So, Dmitri, you were right, I was wrong. There are combinations of sandboxing mechanisms that you can use on an HTML iframe through the sandbox feature that are broadly deployed across every single modern browser.
Manu Sporny: And are available to us if we want to use it. So, basically, what we can do is we can have an HTML document with an active programming environment, which means that JavaScript is enabled. We can turn off all external network communication to that sandbox. So it can't reach out and ping back or report on the display. So it's just this fully contained rendering engine.
Manu Sporny: And with just HTML and JavaScript, the person that is deploying that, that verifiable credential can use any templating mechanism they want. They can render to SVG if they want, they can render to PDF if they want, they can support audio, they can support animation. They can support all these crazy things that HTML supports in a fully sandbox mode. The remaining concerns are resource usage and things like that. And you can constrain those things as well. This capability exists on Android, Windows, Linux, Brave, Chrome, Chromium, Safari, every modern platform that is probably going to try and display a visual verifiable credential.
Manu Sporny: So it's a revisit of this assertion that we can't sandbox. We can sandbox. And as a result of that, it may be that we can unify all of these things.
Process and Transcription
Brent Zundel: Any day that we proceed with meetings with this format, as folks may know, I am the chair of the process CG. And as such, I have had far more time to dedicate to pouring through the process than most people should ever have to spend time pouring through the process. And there is a very clear bit from the process about recording and auto-transcription of meetings, which is what we're doing with these. And so this is to announce that we intend at the start of this meeting to do an auto-transcription.
Brent Zundel: The purpose of this transcription is to serve as a record of the discussion primarily for the working group to have at its fingertips. How is the transcript being retained? I believe it's being retained as meeting minutes. Is that right?
Ivan Herman: They are archived with the rest of the working group minutes at GitHub.
Brent Zundel: All right. Is there anyone here who withholds consent for retaining this automated transcript?
Brent Zundel: Okay, I'm not hearing anyone withholding. Auto-transcription can proceed. And apologies for future meetings, which also should have this happen at the beginning of every single one of them. Yay. Yeah.
Dmitri Zagidulin: So add these meetings are recorded, etc.
Brent Zundel: I mean, and basically just say, an automatic transcription of this meeting will be held indefinitely at a W3C namespace. If there's anybody who objects to that, then we can't do the auto-transcription according to the current process that we're operating on. So I'm on it.
Manu Sporny: Yeah, I don't want to go into process things. I just have a note for maybe the process CG. I think it should be an option for the working group to continue and that party to not say anything or for the working group to say, "Sorry, this is the way we operate." My concern here is that you can have one person throw off the entirety of the meeting. I think that's for later. Today, we don't have that problem, but I'm concerned about what happens if you have a random individual show up and then say that stop the working group from being able to operate as it normally does. That's it.
Brent Zundel: I agree with that concern.
Brent Zundel: This little bit has been part of a much larger conversation that's been happening. This comes up in the AB meeting all the freaking time. There are people who feel deeply and very strongly about this, and I'm hesitant to believe that it could ever be changed too much. But I will certainly, I mean, as problems arise, please let us know. If your things completely got derailed, we have to fix this. Please let us know so that we have those data points.
Michael Jones: Brent, people feel strongly about what?
Brent Zundel: People feel very strongly about their words being auto-transcribed and...
Ivan Herman: Yes. I mean, to clarify one thing, but that's a question to Manu. The audio recording itself is not stored. Is that correct?
Manu Sporny: It's stored on the CCG servers, but we can change that. So, it's deleted.
Ivan Herman: Because if we do that, if we delete the audio once the minutes are published on wherever it is published, then the whole situation is not much different from any other meeting minutes that we have. People can ask to have some things deleted or changed if that creates a problem for them. That's also true for the minutes that we produce with the traditional means.
Brent Zundel: I suspect that the pressure to allow automatic transcription is going to increase because the tools are getting much better and scribing is miserable.
Brent Zundel: And it'll be interesting to see how the holdouts against that respond. So if problems arise, please let us know because there are people who are like, "No, this needs to change in the process." So at the moment, though, if we could spend 30 seconds at the beginning of each call and say, "There's going to be an automated transcription. The recording from this is going to be deleted, but there is not an automated transcription that will persist as the notes. Is there anybody who objects?" If you have that at the beginning of each call, then we're covered by the process. And as problems arise, let us know.
Dmitri Zagidulin: And just to clarify, the option of saying, "If you object, drop off," is not a good option, right?
Brent Zundel: It's, I mean, if someone is a paid member of the W3C who has joined the group, they have a right to attend the meetings.
Dmitri Zagidulin: Right. Got it.
Brent Zundel: And so, it doesn't really work to say, "Sorry, you can't come."
Dmitri Zagidulin: Yep. Understood. Just wanted to check.
Brent Zundel: Yeah. Yeah.
Dmitri Zagidulin: Yep. Thank you so much...
Brent Zundel: And now I'm going to be quiet because I'm not in charge of leading this meeting.
Dmitri Zagidulin: Brent. All, welcome everybody to what is hopefully going to be a regularly weekly spec improvement meeting.
Dmitri Zagidulin: This is the render method half of the call. This meeting is going to be transcribed and the transcription is going to be stored on W3C servers. So if you object, let us know. I'm just practicing. All right.
Dmitri Zagidulin: So I suspect a lot of us, after the sort of holiday break, need to refresh our memories on what all is going on with render method. So let us start with the pull requests and then we'll do issue processing. I'll share my screen. Go ahead, Manu.
Manu Sporny: Okay, just a real quick agenda request. We have done some work on HTML render method and we'd like to report out to the group on that because we think it might impact a number of the issues. So after PR processing, just an agenda plus please on HTML render method.
Dmitri Zagidulin: All right, so we'll take a look at the PRs there that aren't actionable today, and then we'll go to the HTML render method. Thanks.
Use Cases and Alternatives
Dave Longley: I also wanted to remind the group that we have at least one other simple render case, which is rendered to NFC, that doesn't involve any visual or audio or anything. It's just transmission over NFC. So we do have some very simple cases, but I think if you bring in visual downloading files, anything of that sort, I think everything that Manu just said is a great way to frame the conversation to ask, "Where, if you need to do these things, where is it that you need to do them where you don't have an HTML engine to accomplish?"
Dmitri Zagidulin: So I really like this approach and I think it's going to address several of the use cases. My main concern about it is or I guess it's more of a question is, does it handle the print to PDF use case?
Dmitri Zagidulin: It sounds like it requires a browser rendering engine to run, the browser rendering engine and a JavaScript runtime to process it inside the iframe. It performs the template substitution. So my question is more about, let's say the use case that my team at DCC implements, which is a static HTML template, perform the application code performs string substitution, and then converts to PDF without firing up a separate browser renderer and JavaScript runtime.
Dave Longley: I don't know about that latter bit, but what I was on the queue to say was, using this mechanism, you can pass the VC in and a template into this iframe, and you can have the iframe perform whatever templating you want to, whatever substitution you want to. You can have a display PDF. You can also put print links from there.
Dave Longley: So you could download a PDF file or any other file format you would want from this. So those are the affordances. I don't know if that addresses your last comment, which was because you were saying without having another HTML environment, but this whole method requires there to be this HTML environment.
Dmitri Zagidulin: So I think it may be obvious, but just to state explicitly. So this method will be able to cover a lot of the use cases, but we will need a couple of other render methods for the remaining use cases that can't use an iframe and JavaScript runtime.
Manu Sporny: Possibly like that. That's what the summary card thing is about. I am wondering, and this is one of the questions that came up internally, I think the response is, if you are on an environment that wants to print or render this, tell us what environment doesn't have an HTML engine today where you want to do that, right?
Manu Sporny: And so I'm not talking about IoT devices. I'm saying you are on something and you want it to print to PDF, what are you using that doesn't have an HTML engine? Right? So if it's Android and iOS, you've got WebKit and iframe, and you can instantiate. So all mobile phones have that today. If you're on a desktop, you've got again multiple browser options there. If you're on a Raspberry Pi, it's got multiple rendering engines that you can provide there, multiple headless implementations, Chromium, you can pull it in and run it in headless mode. So, if you're even on a server, you've got these render environments.
Manu Sporny: So I think the question is, if we hit a use case like that, we need to hear from the person, what device are you using where you need to do this, and it doesn't have access to a rendering engine, I think that should be the first question we ask people, is, "Name the environment that you're really using in production that doesn't have access to a rendering environment or an HTML engine." That's it.
Manu Sporny: We would not have to define any templated anything at this point because the iframe, the HTML rendering engine is running in a sandbox thing. You can run arbitrary JavaScript, which means that you can choose whichever templating language works for you. So we'd say, "We don't have to say it's a network subset of mustache." We don't have to say it's Handlebars, anything else like that. You can actually put the template engine in the actual source doc itself and use whatever templating mechanism you want.
Manu Sporny: Which means for the OCA thing, you can put an OCA engine into the HTML document. You could use JavaScript as your templating language. It allows you to use the tooling that you want to use. And as long as that tooling runs on top of HTML and JavaScript, which almost all tooling does today, we don't have to specify any of this in the spec, right? Meaning that's totally out of scope for the spec. It simplifies the spec by a huge amount and it prevents us from having to have month-long discussions around what subset of mustache are we going to use and so on and so forth.