Meeting minutes
VCWG Render Method Meeting
Manu_Sporny: All right, let's go ahead and get started. welcome everyone to the render method task force. we have an agenda for today which is largely to spend time on threat modeling. We have not spent any time on threat modeling. and so we are going to try and crowdsource a number of the threats that we're concerned about with the render method.
Manu_Sporny: We will also do our standard kind of looking at pull requests. We have four of those that are more or less ready to go. and we will look into merging those in. I think there are some merch conflicts there but we need to get those into at a high level that's the agenda for today. Any other updates or agend additions to the agenda? Anything else we want to discuss? Go ahead, Benjamin.
Benjamin_Young: Yeah, I posted something just this morning about PDF related expectations. it can be at the bottom of the agenda if it's any issues,…
Benjamin_Young: I think.
Manu_Sporny: Got it.
Manu_Sporny: Okay. I mean, we should How long do you need on that? Okay.
Benjamin_Young: It depends on how people feel about it. it's mostly stuff I've run into when trying to do sandbox PDF stuff. And it became clear that the current PDF mustache also doesn't really have explained expectations about who's going to do what. is the wallet renderer going to show the PDF? Is it going to make it available for download? Is this expected to be used by some other thing that's going to print PDFs whatever?
Benjamin_Young: So the sandbox I frame has some limitations I can talk folks through at least in my current testing. and that doesn't need to drive what we would like or expect already that wallet renderer things would be doing. but I kind of need to know which one to try to skate toward or…
Benjamin_Young: or inform either way. Yeah.
Manu_Sporny: got it.
Manu_Sporny: Okay, let's do a poll request then we'll tackle that issue, Benjamin, and then we'll spend the rest of the time on threat model. Does that sound okay to you? Seeing a thumbs up. All right, any other updates or changes to the agenda?
Manu_Sporny: All right, if not, let's go ahead and jump into it. the first topic is poll requests. We have four poll requests out there. I think we need to do something about these poll requests. We have poll requests from October. I'm going to suggest I'm a bit concerned that the people that raised this are not here, but we need to, figure out what we're doing here and move on. so the f first poll request subtopic is pull request 30. this is Patrick suggested the overlay render method as one of the render methods that we use.
Manu_Sporny: I am going to suggest that this pull request has been overtaken by events meaning that any kind of overlay render method can be implemented via the HTML render method because the HTML render method can contain all sorts of logic. You can put the entire data model into it and to render something as output you can run arbitrary logic to do that. So if folks want to do the OCA render method mechanism, it can just be put into HTML render method late. so that is what I'm suggesting is the outcome of this poll request. I'm suggesting that we close it on the call today.
Pull Request Discussion
Pull Requests
Manu_Sporny: And again, remember if there's violent disagreement about it being closed, we can always just reopen it because GitHub will just keep it around. would there be any objections to taking that plan of action on the call today? not hearing any objections. I'm going to suggest that the task force discussed this.
Manu_Sporny: Go ahead, speak of the devil.
Add OverlayRenderMethod with oca-bundle-v2 render suite by PatStLouis · Pull Request #30 · w3c/vc-render-method · GitHub
Benjamin_Young: Yeah, it'd be great to get Patrick on here.
Benjamin_Young: And there he is.
Manu_Sporny: There he is. Patrick, we are looking at closing the overlay render method. just to give you some context primarily because we're asserting that the HTML render method is capable of running all logic that OCA would need to do the rendering. but would love your thoughts on this. We're trying to close out pull requests that have been open for a very long time now. so over to you Patrick to provide your thoughts…
Manu_Sporny: if you have them.
Patrick_St-Louis: Yeah, sure.
Patrick_St-Louis: Happy to provide my thoughts. definitely. So, what's currently in the spec, they're all template based. So, they're a way to provide a template that people can feed the verifiable credential and display some values. the approach of OCA is really to provide semantic information. So you don't provide a template but you provide rendering hints and instruction through an external bundle and it comes with all the overlay capture architecture features and overlays you can put.
Patrick_St-Louis: So I personally will keep saying that I think it provides a significant different approach than just providing a template and could possibly offer extra capability. But I've not heard the conversation that just had about this being possible with HTML.
Manu_Sporny: So, let me kind of highlight what's possible with the HTML nder So the HTML render method can run arbitrary code over the entire verifiable credential and then render it to HTML which then be exported in the future we're going to add this feature can be exported to an image or a PDF or an SVG. So the entirety of the logic, how OCA can work and be expressed in the HTML. So I think your mental model about what we're doing is template based is out of date, right? Meaning meaning that we have new mechanisms like the HTML render method that can run arbitrary code.
Manu_Sporny: it can take, the verifiable credential as input and then it can do whatever transformations and whatever it wants to render it then to an image format. And the suggestion is we can do that with the HTML render method and OCA can be a subset of that. back over to you Patrick.
Patrick_St-Louis: So I'd be curious just a simple example here. I have a credential and I want to be able to render a HTML page that shows the credential across three different language including labels, descriptions and so on. How would you achieve this with a HTML template without hard- coding all the descriptions and different language in the template itself? duplicating the template or times. For example, if you want to support for language back to you
HTML Render Method Capabilities
<Dave Longley> https://
<Dave Longley> ^this demo site runs a mustache renderer (which could have been any arbitrary code)
Manu_Sporny: how do you do it today there is there I'm concerned that using the word template is we're interpreting it in different ways Patrick I'm concerned you think template is static and unchangeable. I'm saying the template includes a whole bunch of dynamic logic that can do the translations, not hard- coding everything. Meaning it can take all of the translated values out of the verifiable credential that comes in and then let's say it's in French and German and English. it can then render the appropriate thing based on the language that's set.
Manu_Sporny: So that's how it would be done is whatever logic you have would be in the HTML template to do all of the internationalization conversion within the template if that makes sense. Go ahead, Patrick.
Patrick_St-Louis: Maybe that makes sense. I'm not sure I understand currently how this could be achieved. because if we think about translation and description and so on these values need to live somewhere. They cannot be generated on the spot unless we're talking about, embedding some AI functionality in the HTML template, which sounds a bit advanced at this point. Looking at the spec, currently it does very much seem to me like HTML template is just providing HTML CUD with mustache type variables in it. That's understand it by reading at the spec. But this being said, I haven't been really attending these meetings a lot. which seems to me like a good but simple use case.
Manu_Sporny: Yeah, your mental model of the spec is wrong. Sorry to be blunt, but we have talked about over the past couple of weeks how the HTML thing works. It is not ic. There's dynamic code that's executed within the template. I think you should probably spend a bit of time reading it is in the spec now, I don't know if you've read an old version of the spec. I guess Patrick is saying. what you just said is definitely the way it used to work. That is no longer the way it works.
Manu_Sporny: So for example, what kind of translations are you looking to do Patrick? is that our expectation is that with the verifiable credential data model the fields if you have a multi- language credential you would have multiple fields in there meaning the data would be in different languages in the VC itself. And when that VC comes into the HTML, rendering engine, you would have code in there that would display that thing. And let's talk about key value pairs the first name and then the person's name the first name internationalization stuff that code would go in the HTML rendering engine to
Manu_Sporny: displayed in French, Spanish, German, and then the values themselves would come by selecting the appropriate language from the credential. So hopefully that made sense. I'm kind of rushing through the explanation of how it would work, but that is the way the new HTML rendering engine stuff works.
Manu_Sporny: Go ahead, Benjamin.
Benjamin_Young: Sorry, had my mute button backwards.
Benjamin_Young: Yeah, I've got a demo I'm happy to show if it would be helpful, but I think something that might confuse people is when we say HTML, it's really the name for the entire trinity. TML, JavaScript, and CSS. And mostly JavaScript's going to do all the hard lifting because it's going to carry mustache or liquid or edit your JSON or create new stuff or juggle the overlays that you give it or whatever.
Benjamin_Young: I think a piece to explore with OCA if we were to bring it in this way is where if you didn't want to repeat those overlays inside the JavaScript bundle essentially then where would you put them in the JSON of the credential because the JavaScript cannot get anything off the web can't do remote resource stuff so you could potentially reference your OCA bundles or inline them maybe in related resource. and then once they're there, you can selectively disclose them into the JavaScript that's going to do the rendering and then that JavaScript's going to do whatever that JavaScript's going to do on behalf of those OCA bundles.
Benjamin_Young: But you really have to think of the stuff that happens in the sandbox iframe as the entirety of the rendering thing. so it's doing way more than any of the past ones have been conceived to do. And they really are mini apps. If you're at all familiar with that phrase, it's mostly coming out of China, which is just HTML XML plus JavaScript running in a super constrained, often non-browser container. And again, Patrick, let me know if you want to. And everybody, it's not a pretty demo, but it is easy to see it.
Manu_Sporny: Thanks, Patrick, you're on the queue.
<Dave Longley> +1 to a demo
Patrick_St-Louis: Yes,…
Patrick_St-Louis: I'd be definitely interesting in seeing a demo. I just want to give a simple example. there's a client they require you to support five different language in an application you receive a cred you want to issue a specific type of credential and you don't want to duplicate the credential five times to support different language when you render it and when you pass it to this mini app a bundle is a great way to fetch and generate this context
Patrick_St-Louis: text without making the credential itself significantly larger. which that's why a demo would be really beneficial for me. but it sounds to me like we are now talking about inventing a new way to do this with this new HTML render method when I would like to be able to just use a specification…
Patrick_St-Louis: which is already in so yeah, that's kind of my stance
Benjamin_Young: Yeah. inventing a new thing and…
Benjamin_Young: more that we're punting to the browser and allowing anybody to deliver their own renderer just as they would render any web page or iframe or ad widget or whatever. it's way more analogous to advertising iframes into anything else.
Benjamin_Young: And I can give that demo, but Mono, I see you on the queue.
Manu_Sporny: Yeah, mostly because we're eating up a ton of call time on this thing.
Benjamin_Young: Yeah. But…
Manu_Sporny: So, I'm gonna yeah,…
Benjamin_Young: if we're saying this is going to displace everything, I think it's important that everyone understand it.
Manu_Sporny: yes, I think we need to come back around to this, I think Patrick, you need to read the spec as it exists now and see if there's any way that you can see that it addresses your use case. I think it does. Once you're up to speed, Patrick, on what the current spec does, and once you've potentially seen the demo that Benjamin is going to show, we've shown it on previous calls. I don't want to rehash things we've already discussed on the call again, so Patrick, I think the onus is up to you to bring yourself up to speed on the spec. Take a look at the demo that Benjamin has. Maybe do that offline and then we can come back to this later on. we need to figure out what we're doing here.
Manu_Sporny: It's been sitting out here for too long. Avon, go ahead.
Ivan_Herman: Yeah, the whole discussion for me means that maybe we have already discussed that by the way that we…
Ivan_Herman: if we go down this HTML line then we would have to have a kind of a collection of I say well doumented well specified
Ivan_Herman: ified example codes, patterns that people can pick up and use and not reinvent the wheel all the time because it's not necessarily obvious although I understand that for example what Patrick wanted to say to do you can run a JavaScript which reach out to translator services and would translate those things into French any other language. but this is not absolutely obvious and having an example library is probably very important.
Manu_Sporny: Thanks Patrick, go ahead. And then I'm going to move us on to the next poll request.
Patrick_St-Louis: So the new HTML render suite has new feature. How does that come into play with the embedded renderer which is an HTML rendered in an iframe? what makes it that the embedded renderer is different than this new HTML and why does this new HTML render suite cannot do what the embedded renderer does? So, we're not talking.
Benjamin_Young: I think they're the same.
Manu_Sporny: I Hey,…
Benjamin_Young: I think you're using two words for the same thing. We just started calling it a sandbox iframe.
Patrick_St-Louis: So, I was talking about the Yeah.
Manu_Sporny: hey, Patrick. We have more agenda items. we can't spend the call bringing you up to speed. please do it offline. Benjamin I'm sure can do it offline and then we can dedicate an entire call if we want to go through this again. But we are repeating conversations we've had over the past couple of months. it not a good use of call time. thank you for we want to answer your questions just to be clear. It's just I don't want to spend the entire call doing that this time because we're just going to end up repeating ourselves. appreciate you understanding. moving on to the next item. This is a poll request that you raised to add cardlike displays in wallet displayers.
Manu_Sporny: We've gotten high level interest in this people are generally interested in doing something here. I don't know Nate if you feel like this is ready to merge or it needs more work and if it needs more work the question is when are we going to do the work on that? Go ahead, Nate.
Nate_Otto: I dropped in on I found the link and this is my first time on this call for a while since it's been moved under VC working group. great. I'm glad to hear that there is interest in this cardlike display method and I think it does need a little bit more work especially if there have been significant recent changes in the other renderer methods that this would sit alongside just to make sure that it is sort of wellcraftrafted text and probably just needs a rebase. As far as when that could happen, I'm probably pretty busy the next few weeks. I'm perfectly happy to collaborate with someone else to speed this along. and otherwise I could take a look in mid July guaranteed but I could definitely collaborate with someone to speed that up a
Render method to enable card-like displays in wallets and displayers by ottonomy · Pull Request #39 · w3c/vc-render-method · GitHub
Manu_Sporny: All right. sounds good. Nate, again, we're trying to not let PRs just sit out there for extended periods of time. would it be better to move this back to an issue and work through? I mean, it's how complete do you feel is this we're just going to revise the PR until we can review it or what do you think the path forward here is?
Nate_Otto: I imagine this is a 90% complete. I bet that I think there was some useful small comments and I don't recall every little bit of the history of whether I went back and made more commits. I don' think you could close the PR or something. Don't delete the brand.
Nate_Otto: I mean, it's on my remote, so you can't delete the branch. that's more
Manu_Sporny: Okay, thanks on the queue.
Benjamin_Young: Yeah. I would suggest that this is far enough along that we merge it and…
Benjamin_Young: and then file issues against it. Even if the JSON format or whatever is going to change, if it's 90% complete, otherwise it's just going to idle so long. it's going to be a pain to merge later. And I think we got to the place where it was like this is probably unique opposite the HTML sandbox thing at minimum for efficiency of display. So that's it.
Manu_Sporny: Thanks I'm concerned about merging it in its current form primarily because I don't know if J so I think it's just a terminology, JSON card us data display versus something else. I think we need to be pretty clear about what are we doing here? meaning how do we communicate this to the outside world? One of the things I'm concerned about Benjamin is we merge it and the term Jason card sticks and I don't know if that's the best way of explaining what's going on here. It's really a data view. what you're doing is you're generating a data or it seems like what you're generating is a data view on the thing.
Manu_Sporny: and there's some open questions like why not YAL that sort of stuff not that I think we should do that but those are the other 10% of things it feels like we need to do here go ahead Nate
Nate_Otto: I mean, if there is interest in trying to get this merged and you think that we could resolve open questions around language, I could try and accelerate a little bit of efforts to be able to sort of clean up the last couple things and get it to what I feel confident in merging pretty quickly. I don't care so much about the JSON in there, but I do like the word card is included in here because the idea here was essentially to look at the sort of standard credit card shaped space that something could be displayed in and look at about the amount of fields that could go there.
Nate_Otto: and we're seeing lots of wallets that are choosing to display various credentials even down to the level of concert tickets in a cardlike format. So if we call it a data card whatever, I don't care. And then as far as the use of JSON, I think if folks want to make an argument for a preferred language or syntax other than JSON is the lingua frana most common thing. And I think it would probably be hard to say that there would be something that would be more ubiquitous and easier to use.
Manu_Sporny: Yeah, plus one to that. I was just suggesting we hadn't necessarily talked about that. So, it sounds like maybe if we can try to get quick iterations on this just to make sure we've got the concepts that's nailed in nailed down I'm seeing Dave saying some things that are slightly different from what you said Nate which are slightly different from what I have in my head which is Benjamin why I'm a little concerned about merging it right now but if we can iterate on this quickly I think we can get to something quickly noting that we're all very busy so how about we keep the PR open and we see if it gets any movement over the next couple of weeks hopefully
Manu_Sporny: And then we'll revisit on the next call. Does that sound okay to folks or any objections to taking that path? seeing a thumbs up. all right, one is removing this next one is removing the PDF and SVG mustache render suites. No reviews on this. I think I would like to merge this…
<Dave Longley> +1 it's some kind of data view / field view ... something along those lines
Manu_Sporny: because I don't think any of us, believe this these two things are going to continue. go ahead, Benjamin.
<Dave Longley> worried about locking too much to a "card" concept as UIs can change a lot in a short period of time
Benjamin_Young: Yeah, I linked to the issue I created this morning and…
Removing PDF and SVG Render Suites
Benjamin_Young: mentioned some other things about the example that I was going to demo earlier that shows mustache in use in the HTML render suite which could be used for SVG. It's just not currently. so other than the PDF one, which I don't think it was clear in the mustach- one what was supposed to happen with that either. so I don't know that we have to block this issue on that point.
<Dave Longley> i'm ambivalent about "card"... pros and cons.
Benjamin_Young: But it is related in that I think we still need some clearer expectations about what happens and can happen in those eye frames.
<Phillip Long> I rather like the "card" terminology
Remove pdf-mustache render suite and svg-mustache render suite. by msporny · Pull Request #49 · w3c/vc-render-method · GitHub
Manu_Sporny: Okay, Benjamin, was that a we can't merge it yet until we discuss the other issue. too. Okay.
Benjamin_Young: I'm fine to take it out as I don't think we're losing anything per se. you had wanted to keep it in originally because it had the word PDF in it because SVG mustache and PDF mustache do exactly the same thing other than the media type. I'm fine to take them out.
Manu_Sporny: I think Dimmitri, it was you that wanted to keep the PDF mustache rendering template in if I recall correctly. Manu Sporny:
Dmitri_Zagidulin: No, no.
Dmitri_Zagidulin: Other way,…
Manu_Sporny: Okay.
<Dmitri_Zagidulin> (apologies, big calendar fail)
Dmitri_Zagidulin: other way around. I'd love to keep the SVG for the moment until I can figure out how to do the equivalent with the, I frame sandbox, plus one to removing PDF mustache.
Manu_Sporny: Got So, if we discuss your issue, Benjamin, do you think we could get closure on the PDF part of that?
Benjamin_Young: Yeah, I think so.
Benjamin_Young: Again, I don't remember any Sure. Manu Sporny:
Manu_Sporny: Sorry, the SVG part of it. Thank okay.
Benjamin_Young: Yeah, I think either way, it's going to help folks to know what the HTML render suite can and can't do currently. but I think we also need to be aligned on expectations of what we're expecting the render method to be capable of Manu Sporny:
Manu_Sporny: So Dimmitri, if we were able to demonstrate that the HTML render suite can do what the SVG one does today,…
Manu_Sporny: equivalent can pop out a SVG, then you would be okay with removing both of them. All right.
Dmitri_Zagidulin: Yeah. Yes.
Dmitri_Zagidulin: Yes. But…
Manu_Sporny: All right.
Dmitri_Zagidulin: but in the interest of progress,…
Manu_Sporny: So yeah.
Dmitri_Zagidulin: we can just split it into two, right? Remove the PDF mouth stash now and remove the SVG shortly.
Manu_Sporny: Yeah. The only thing I'm concerned about is I've been meaning to get around to this for three weeks and…
Manu_Sporny: haven't split the PRs out yet. So, it might be faster for us all to agree to remove both and just merge this.
Dmitri_Zagidulin: I got all right.
Dmitri_Zagidulin: Yep. is enough.
Manu_Sporny: It's purely just unless somebody else wants to raise the PR. I'd be super happy if that happened as note So Benjamin, there's one other and I'm rushing because I wanted to try to get to the threat model discussion today, but …
Manu_Sporny: we get to when we get to it. Benjamin, the last PR is this one that you've opened. output preference term section. I think we've got a bunch of thumbs up.
Benjamin_Young: Yeah, it's approved and…
Benjamin_Young: I process the comments into an additional commit.
Manu_Sporny: So this is good to merge.
Benjamin_Young: It is as far as I know.
Manu_Sporny: Okay.
Benjamin_Young: You had some feedback and tall Ted did as ever and those are all in now. Ivon did have a call out about the canonical reference to a CG spec. I think the way it's referenced now is fine and when we check again later when we move to the next phase we can update that…
Benjamin_Young: if it's required.
Add outputPreference terms section. by BigBlueHat · Pull Request #51 · w3c/vc-render-method · GitHub
Manu_Sporny: Okay, great.
<Benjamin_Young> Mustache in HTML Render Method for folks to check out: vc-examples/credentials/html-render-method-mustache at main · credential-handler/vc-examples · GitHub
Manu_Sporny: right, that looks good. Then let's go ahead and merge unless anybody has any objections. Looks like I approved as and this is normative, right? No objections.
Benjamin_Young: Yeah,…
Benjamin_Young: it adds a new should section. No, I don't think so.
Manu_Sporny: And rebase and merge. Thank you very much for that one, Benjamin. And did this address an issue that you can think of that you can All right.
Benjamin_Young: This was born out of the HTML render method coming into being without some of the things that SVG, Mustache, and other things had.
Manu_Sporny: right.
Manu_Sporny: Then let's go ahead and jump to the other issue that you raised which is discussing PDF rendering expectations. That's issue 53. over to you Benjamin.
PDF Rendering Expectations
Benjamin_Young: Yeah, I can summarize what's there.
Benjamin_Young: Essentially, we as a group haven't really pinned down what we expect to have happen in the renderers, generally speaking, or the capabilities of the thing doing the rendering. whether that's the wallet or some viewer or something. meaning we talk about PDFs, but you can obviously do a whole range of stuff with those. You can display them. You can download them. You can print them. your browser can do all of those. HTML and JavaScript can inform which one of those happens even if it's client side generated.
Benjamin_Young: So when trying to build this out in the sandbox iframe, most of the tools that are currently actively developed anyway for client side HTML to PDF rendering, which I realize is not the only option here, but it is the sort of obvious path that you've created this HTML template and now you want to make it available either for download or viewing as a less mutable PDF. none of those work in a sandbox iframe because they all lean on the ability to clone HTML or push it into a canvas or some mix of those things. those libraries might be doing it wrong. There's some chance because most people do not write software for sandboxes.
Ivan_Herman: Look at that.
Discuss PDF rendering expectations. · Issue #53 · w3c/vc-render-method · GitHub
Benjamin_Young: There might be some chance that those are library limitations.
Benjamin_Young: but it does point to a number of things that are not possible in the sandbox. So then I pivoted a little and explored a library called PDF make which is really just a JSON format for laying out a PDF and that also tripped over or fell over because I can make the PDF but I was no longer able to display it. I had the data for it. they could give me a data URL or a blob which I could put into an anchor tag with the download attribute and you could click it and download your thing and it would view in whatever the native viewer on your computer or phone might be.
Benjamin_Young: But the wallet renderer would not be able to display that. because you're not able to use embed or…
Ivan_Herman: Oops. Okay.
Benjamin_Young: object tags, those old guys. and you're also not able to just have a sub iframe inside the sandboxed iframe that has application PDF as its media type and the browser know what to do with that complains about origin problems and all kinds of stuff.
Benjamin_Young: mostly that centers around the use of SRC doc or source dock on the parent iframe in this case which then left it at the only option then to display it by the renderer is to somehow send that data out of the sandbox up to the thing doing the rendering and then let it sort of shell out to the browser or make a new iframe with just PDF in it or whatever. So in that sense display seems off the table within the sandbox unless we're okay with messaging the PDF data up a layer which is to the layer which already has the VC in total but PDFs themselves can also contain JavaScript and all kinds of other scary things.
Benjamin_Young: So it's worth considering that space. But what can happen now at least with the PDF make approach is that we can make download buttons if that's even wanted. So some of this is what affordances were people expecting a renderer to be able to provide in and around PDFs and then measuring that against what's actually possible and what holes we might have to punch in the sandbox to do any of them. That's it.
Manu_Sporny: Thank you, Benjamin.
Dmitri_Zagidulin: Benjamin, thank you so much for doing this work. this is amazing. This is exactly what's needed for us to sort this speaking for myself and my team and my use cases, the main affordance I would like to see is not display but the download. and yes I realize that posting back the sort of resulting PDF for the outer client to make a PDF out of it quoteunquote votes the warranty as you put it.
Dmitri_Zagidulin: But I think that's within our threat model because the main trust sort of pillar there is still trust in any case I would be content with just the download. I don't know if other people have display expectations, but I do think we can just posting back the message and rendering the PDF outside of the iframe would still allow us to have to display in the next step. Just passing it to a regular displayer. But over to you
Manu_Sporny: Thanks I guess my so let's get down to kind of like what are the I'm hearing the concrete options are within the iframe we provide a download button and then you can download as PDF or download as SVG as The other option is that we allow a post message or I forget what it's called back to the parent iframe that is effectively the raw content the raw content of the SVG as generated through whatever program is running inside the downsides there being that may be a dangerous object. and it may be that the thing using the render method really needs to be careful about what it does with that data.
Manu_Sporny: So, for example, in our threat model, as Demetri mentioned, we might say hey, it's really dangerous to just include this in a parent iframe that has network access…
Manu_Sporny: because it may do start doing some crazy stuff, are those the two general options that we have on the table? over to you, Benjamin.
<Ivan_Herman> +1 to Dmitri (not display but to download)
Benjamin_Young: Yeah, I think more or…
Benjamin_Young: less. But I think one note before we dig in a little is we need to keep SVG out of this conversation. It's not related in it's its own thing and renders fine in a sandbox iframe. PDF is the only thing in question here. and you could make any other file format downloadable just by setting it as the href of an anchor tag with the downloading is again not the problem.
Benjamin_Young: If we say that we're going to use post message and send back the raw data of the PDF then which is fine and we can explain that in a threat model. I think we will also want to constrain that post message to not be able to do anything else but PDFs because that threat vector is pretty identical to just rendering the HTML directly in a non-sandbox iframe. So, maybe the PDF display thing in your browser is a safer box than a wide open iframe.
Benjamin_Young: I don't know. Somebody would have to have to compare but it is a thing that if we're allowing more as originally conceived and I think written in the spec so far, at least the example the post message function is only used with to send back the word ready and that's it. and we're having to state that and constrain that so that you're not sending back more stuff that the renderer might do the wrong thing upon receiving it. So this changes that punches a good 8 and 1 half by 11 hole in the post message channel. and when we do that we need to think hard about why we're bothering with this sandbox.
Benjamin_Young: which might be we're only using post message for application PDF in this very constrained way and here's how we're going to further constrain the post message to not let other stuff through that hole …
<Dmitri_Zagidulin> displaying the Download button within the iframe is a big ask, since there's no way the iframe (or the issuer) knows what the UI/CSS expectations of the outer client is
Ivan_Herman: It's good.
<Phillip Long> sending it back to the parent iFrame sounds bad to me.
Benjamin_Young: but it is an implementation thing we need to think through more than saying yeah this is a danger because it's the danger we just said we were avoiding by using sandboxes that's
<Dmitri_Zagidulin> not parent iframe, parent client. (like, the wallet)
Manu_Sporny: Plus one of that. So Benjamin, could we maybe the next steps here are for you to concretely propose those two approaches so that we can have detailed discussion on the next call. Would that work show us what the interface might look like? that gets the stuff out of there and then show us what would have to be done for the download links and then it feels like SVG is somewhat I'd like us to talk about the SVG thing as well…
<Phillip Long> Thanks for the correction @Dmitri
Manu_Sporny: because it's important to Demetri and…
Benjamin_Young: I can yeah it's not related at all.
Manu_Sporny: I'm trying to figure out how Hey,
Benjamin_Young: I can work up examples, but SVGs live happy as clams and sandbox iframes and are safer to use in there because they could also have JavaScript in them just like any markup in a browser can, but it would be in the same constraints inside the sandbox. So unless there's some printing of them that you're wanting that maybe an iframe can't do, which I don't know if it can or not.
Benjamin_Young: I have not yet explored printing which is part of why I wanted to have this discussion but I did again I can work up an example but the experience so far is that SVGs are much simpler to work with and…
Benjamin_Young: and they don't require external viewers is the biggest difference I think that's
Manu_Sporny: Got it.
Manu_Sporny: I can think of a use case, but we can take that offline. Go ahead, Dmitri. You might be muted, Dimmitri.
Dmitri_Zagidulin: And just to be super clear, the download inside the iframe is a non-starter. because there's no way for the issuer inside their suggested display thing to know the the buttons of the client, what the outer environment looks like.
Benjamin_Young: the frame provides the button. that's the difference.
Benjamin_Young: So the thing you're rendering is a button that says download your PDF or whatever. How…
Dmitri_Zagidulin: That's my point though.
Dmitri_Zagidulin: The iframe doesn't have enough information. The outer client does.
Benjamin_Young: how would it not have enough information? So if I can render HTML, I can render an anchor tag that looks like a button that says download on it. and you click it and you get a download and the surrounding web page doesn't know anything that is well depends on…
Dmitri_Zagidulin: Yes, but it'll be unstyled.
Dmitri_Zagidulin: the issuer when issuing doesn't understand what styling requirements the outer environment will have. That's the main problem. That's why it's a nonsparter.
Benjamin_Young: who you talk to that's a thousand% true of this approach with render method unless we want to spec some ability for the wallet to inform UX inside the render method. But then I think that's exactly not why we're doing this for issuers to have full control over a little box in…
<Dave Longley> if you want consistent theming, use a "data view" (aka json-card) render method
Benjamin_Young: which they can do stuff.
<Dmitri_Zagidulin> doesn't help, yeah
Dmitri_Zagidulin: Exactly.
Dmitri_Zagidulin: Of the display.
Benjamin_Young: So if no…
Render Method Threat Model Brainstorming
<Manu_Sporny> Render Method Threat Model Brainstorming - Google Docs
Dmitri_Zagidulin: But Not the EUI around
Benjamin_Young: because we're correct yeah it'll be within that box. But that again, these things are, I would say, 100% analogous to ads on the internet. Those ads can do whatever they want. They can look like the surrounding web page if they know where they're going to show up. They can look like They can look like a download button. They can whatever. basically once you're inside that iframe, it's whatever that iframe wants to do and it is not fully informed about where it is.
Benjamin_Young: most times. so unless we're somehow affording the web page that embeds the iframe essentially to tell the iframe, hey, here's some things you should do if you're going to render a button. it's totally possible with this approach that people could make all kinds of whatevers, buttons and login forms and make it look like anything. the safety net here or rather the counterwe is that the thing the sandboxed iframe can only do so much. So you can make buttons and links that go places and they can only do things within their little box. So those will fail or they'll trigger a download. and I don't know how much that helps your concerns, Dimmitri, or not. That's it.
Manu_Sporny: All right, great. Thanks, Benjamin. We have five minutes left. I have completely failed to get us to our main agenda item today, which was to go over the rendered threat model and get some ideas down. I don't know if folks feel like they could write down a whole bunch of threats in five minutes to just get us started or if folks want to continue discussing the PDF rendering issue. Any strong feelings one way or the other? I'd like us to try and get as many threats down as we can, but go ahead, Patrick.
Patrick_St-Louis: Yeah, I'd like to if we could finish on opening the discussion on the threat model.
Patrick_St-Louis: I think that would be good to kind of preface the next meeting.
Manu_Sporny: Okay, we will do that then.
Manu_Sporny: Patrick, any objections to doing that from anyone? All right, here is the document. The way we do this is you go to this section threat brainstorming and just start typing out ideas. How can you attack render method? it's and you just add numbers to whichever section if you don't know if it's a dependency thread or uncatategorize just go ahead and and just start, adding items and adding threats. And we'll go quiet while folks get their ideas
Manu_Sporny: All right, looks like contributions have slowed down a bit, but that was fantastic. I think this is a very effective way of getting threats into a document. We got I mean 19 of them in four minutes. That's pretty awesome. thank you everyone. Really appreciate that last 11th hour push into threat model. we will come back around to it next week and recategorize things. also thank you to everyone for engaging in all the items today as well.
Manu_Sporny: Patrick, we'll cover the OCA thing next week as well. so please reach out to Benjamin and demos and sync up so that we are all on the same page with respect to what the current spec is supposed to be able to do and then we can have a updated discussion next week. Benjamin will also try to concrete approaches whatever you put into the issue there. and then we'll also cover threat model next week. All right, that's it for the call this week. Thank you everyone very much for your time and sharing it with us today. have a wonderful rest of your week and we will chat again next week. Take care. Bye. Meeting ended after 00:56:59 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.
<Phillip Long> sounds like there are lot of threat avenues here!