Meeting minutes
Automatic Transcription Discussion
Michael Jones: Hey, Demetri.
Dmitri Zagidulin: Hello. …
Michael Jones: Hey, on a topic that's not this working group, I sent you email a few hours ago. Perfect.
Dmitri Zagidulin: Okay. Yeah. Yeah. Yeah. I was just coordinating with Lucy about this. Yeah.
Michael Jones: I'd love to have the conversation. Hi, Brent. Elaine, I'm going to heat my coffee.
Brent Zundel: Hey Mike. Hey everybody.
Michael Jones: I'll be back in two minutes.
Brent Zundel: So before we get started, the word has gotten out that the VC working group is experimenting with automatic transcription and folks are very interested in hearing how it's going. Just wanted to share that. So it will definitely be a topic of the upcoming advisory board face-to-face meetings.
Ted Thibodeau Jr: I for one welcome our robot overlords.
Brent Zundel: So if any of you have anything that you want me to make sure I bring up, feel free to reach out.
Dmitri Zagidulin: No, I mean you already know all of the main issues.
Brent Zundel: Yeah. Yeah.
Dmitri Zagidulin: Concerns about proprietary versus open source, concerns about can you pause and say this is off the record, and the amazing benefits of not having to ask for scribes.
Brent Zundel: I mean, I think the two big ones at this point we're still figuring out the best way to pause and automatically move, automatically moving of the conversation into the GitHub issues, I think, are the two main things. If I'm missing one, let me know. And with that, I'm going to be quiet. Have a great meeting.
Dmitri Zagidulin: So, just to double-check. So, this is the render slash confidence method alternating one, right? It…
Brent Zundel: That's my understanding. Yes.
Dmitri Zagidulin: Because I know some of the meetings the group. Great. In that case, it's the turn of the render method half of the call. Usual boilerplate: this is a meeting of the Verify Credentials Working Group. Usual IP protections apply. You need to be a member to contribute. If you're not, let us know. We're under the W3C Code of Conduct, and this meeting is recorded. So, with that, let's get to some issue and PR processing. So, let me share my screen and pull that up. Give me a second. As I'm pulling it up, does anybody have any questions or concerns? All right, get that sound?
HTML Render Method Discussion
Dmitri Zagidulin: All right. So, as traditional, let us do pull requests first in reverse order. All right. So we have a couple of the older ones, like the Open Station embedded render and OCA bundle, which we both asked to hold off on as we're sort of discussing the unified render method parameterized approach.
Dmitri Zagidulin: So here we've got Big Blue Hats with just a few sort of grammatical changes from Tall and couple of change requests. Let's see. Yeah. Do you want to comment on this one?
Dave Longley: So, I'm thinking this one might also be impacted by what we discovered through the HTML template rendering method. I think we might, I'm not sure…
Dmitri Zagidulin: Mh. All right.
Dave Longley: where the group. Okay, there's thumbs up from Benjamin as well. So, we might want to hold off on going through that one. We might find that things have been unified through the other approach.
Dmitri Zagidulin: So, let's take a look at Benjamin's latest PR on the HTML rendering method. So, we've got an approval from Dave, which is great. So, this is PR42. I'm going to throw it in chat here for folks to pull up. Are the underscore includes? Is that stuff actually included in GitHub or should that be an ignore? Technical question.
Dave Longley: There's a QR.
Dmitri Zagidulin: Go ahead.
Dmitri Zagidulin: For some reason, I'm not seeing the raised hands on the. Okay,…
Dave Longley: So Ivon was on the queue first and then Benjamin went on. And I think he was going to answer your question.
Dmitri Zagidulin: Ivon, go ahead.
Ivan Herman: If Benjamin…
Ivan Herman: If Benjamin can answer your question, that's fine. Mine is a much more general thing. Okay.
Benjamin Young: I was actually going to ask for clarification about which thing to be ignored.
Dmitri Zagidulin: The underscore includes files here.
Benjamin Young: No, you need those…
Dmitri Zagidulin: Okay, you need those. All right, great.
Benjamin Young: Because those are included in here. If you search for, I think it's data-include, it's a respec feature so you don't have to have all your stuff in one HTML file because that gets maddening, especially with big JSON documents, so I used includes for that. So that's what that includes folder is. Yeah.
Dmitri Zagidulin: Got it. Makes sense. All right. So, I think folks might be familiar with the general idea behind this method. It is a general purpose. We're going to pull in a template, do the substitutions. Go ahead.
Ivan Herman: No, no.
Dmitri Zagidulin: Who's next on?
Ivan Herman: Go on. Finish.
Dmitri Zagidulin: We're going to do general purpose substitutions on the method with the following parameters. We're going to substitute the following fields specified by the property using JSON path. We have here the specification of an external or an embedded template file, as well as media type. It has digest hash, as well as some output parameters. We've got some excellent sort of security consideration language that it needs to be in a JavaScript sandbox. Some recommendations about the host page, which is the sort of the output window, which also applies to mobile apps.
Dmitri Zagidulin: Do folks have any other questions about this? Because from my end, this looks great. I guess my only other question is, what does the HTML template for this example look like? Would it make sense to provide that so that folks can glance at it and say, "Yeah, okay, we're not using handlebar substitution here." Or would the example template be too complicated to use as an example? And if that's the case, that may be a problem with developers understanding it in the first place. So, yeah, question to the group.
Dmitri Zagidulin: Would it make sense to also provide what the actual HTML template looks like to power this example?
Dmitri Zagidulin: So I think Ivon, you're next.
Dave Longley: If you can't see the queue. Yeah, we've got three people on there. Ammon's first.
Ivan Herman: So I have gone through this spec yesterday, knowing that I don't have too much experience with the deep guts of the JavaScript programming on HTML with all the security things. But my overall impression, question from a specification point of view, was that in a W3C specification, as example is non-normative, here the whole document is such that the normative things are sort of in an example, and that won't work. So that requires a kind of an editing where examples stay example, and what they are supposed to do should somehow be formally specified, which is missing. And I would like to have some sort of a diagram or equivalent, and not necessarily a diagram which shows what exactly happens in terms of actions and messages between the client in the sense where the final representation of the credential will occur for the user, the host which hosts and stores the credentials, where does the template pattern really happening, how, etc. All this is sort of between the lines, among the many lines, so to say.
Ivan Herman: And again, going back to examples, and this is what happens, and this reminds me of a style of a lot of software you see on GitHub or elsewhere where they put in a very complicated software, and as documentation, they put two examples on the homepage, say, "This is what I do this way and that way," and for the rest, figure it out. That won't work for a W3C specification. So, I am not criticizing the underlying idea, on the contrary, but I think this needs a major work in terms of editing to be put into the document and…
Ivan Herman: I don't want to offend anyone who put money, also money… but also work in this.
Dmitri Zagidulin: Agreed, Ivon.
Dmitri Zagidulin: I completely agree with everything that you said. However, this is a fantastic sort of first step, and then we need everything that you just mentioned. Go ahead, Benjamin, you're up next.
Benjamin Young: Yeah. …
Benjamin Young: No offense taken, and I'm afraid all of what you said is painfully known because the reason it is just a giant example and then explanations of that is because it's really not clear to me, and I was hoping to get help from the group, what we are able to specify and for whom. Because if we take this approach, which we're dictating certain post messages going back and forth, we're dictating certain variables being set on a web app, because essentially we're prescribing rather a way to build an embedded web app in an iframe.
Dmitri Zagidulin: Sure.
Benjamin Young: So short of ending up recreating many apps, if you're all familiar with that spec, or in some other way drifting into what WG territory and offending the TAG and whatever else, that's where guidance would be useful on how to specify this. Demetri, I think we might be better served looking at the actual spec preview rather than the diff, because we're at least not getting color coding. At minimum, though, if you want to stay or come back or whatever, try the preview, go there first. But the combined one is probably the best one to walk through. You can click on HTML render spec in the sidebar and then scroll down quite a ways. That's the combined one, I think. Yeah. So this is the simplest thing. And then there's a TBD on the render method ready bit that's explained in the next section. So ultimately, what this thing is, is the renderer. It is setting through this prescription a script tag with the name of credential that holds the actual credential. It is then delivering a script to take that credential and then render. And then once done, it tells the parent wallet that it's done with its rendering. And the rendering, as you can see here, the query selectors and things, it's just injecting the name of the credential and then setting "issued by," which is towards the bottom of the, those two lines. So that's the actual quote unquote template if this were Mustache or something. Those are the two HTML tags that are going to show up for the user. The script section above that is the thing doing the injecting of the data from the credential. And all of that is taking place inside of an iframe that is explained how all that gets there in the ephemera above that. But as stated, this is really just how to write a web wallet that can do this, and it's not clear to me yet. Again, I was hoping for input, especially with known sharks in the water, of how best to come at specifying something like this, and I'm happy to do the typing if I can get some guidance on that. That's it.
Dmitri Zagidulin: And real quick, so I see we've got two people in the queue, but clarification question. So if I'm understanding your example correctly, the thing located here in "credential.html" is this is… what we're looking at? This is the thing and this script gets injected?
Benjamin Young: Almost.
Benjamin Young: Yeah, it's almost correct. Yes, the last thing you said fills it out. So, yeah,…
Dmitri Zagidulin: Okay, got it.
Benjamin Young: You would get just the script and the HTML.
Dmitri Zagidulin: Mhm. Got it.
Benjamin Young: Yeah, basically that last div section would be the template. That's the L. Then it gets added to this shim code as it's described in the current write-up. And the reason for that is because this meta tag at the top needs to be set to further restrict things.
Benjamin Young: So we can't get this implier gym thing back in part because it contains the credential and in part…
Dmitri Zagidulin: Right. Okay,…
Dmitri Zagidulin: Got it.
Benjamin Young: because it has to set that meta tag to be safe. And I could write those up as algorithmic steps or something, but that's still not necessarily the right way to go. I don't know. We've got a queue. So,
Dmitri Zagidulin: Dave and then Ivon.
Dave Longley: Yeah, couple things. First, since you were just talking about how does this work, the template is going to provide the body of the HTML document. So, as Benjamin was saying, this between the starting div tag and the ending div tag that's furthest to the left there, is what an author would provide as a template. And then I wanted to plus everything on set. At least, I believe these are Benjamin's goals with this PR, were to get something in place for this new concept that has been discussed for HTML rendering, that we think is probably going to cover and…
Kevin Dean: Perfect.
Dave Longley: we hope the group agrees and it seems to be like the way so far is probably going to cover many of the other types of rendering things we were trying to do.
Dave Longley: And so the goal for this PR was to get something into the spec as a starting point for showing how this works and then we figure out exactly how we want to specify and how prescriptive we want to be about how to make it work.
Kevin Dean: Perfect.
Dave Longley: And effectively, what we need to talk about in the spec is we've got the host party that's going to be hosting or displaying some rendering code. We've got whoever is providing that rendering code. Those might be the same party. They're certainly going to be coordinating. Then you've got template authors. And then the parts for involve if you're going to be a template author, what do you have to do to communicate back with the piece of software that's rendering your template? What do you have to expose in your render method as an author of the credential? And then what does the party that's going to accept your template and decide to render it, what do they need to do? What do they need to send you? What environment do they have to set up? And so there's some places we have to figure out exactly how we want to specify that and how prescriptive we want to get. But I think we want to have a baseline PR that gets this into the spec so we can start iterating on that and drive the focus and attention onto this rendering method to solve the HTML cases generally. So we're all working in the same direction. So I think that was the goal.
Dmitri Zagidulin: Okay.
Dmitri Zagidulin: So, we've got Ivon up next, but I want to pause and make sure after Ivon, I want to pause and make sure that everybody really, really understands our approach here, why did we come to this solution and so on. I think I understand it, but I'm one of the implementers and… and so I've been following this thing from the start. I want to make sure that everybody's on the same page. But go ahead, Ivon.
Ivan Herman: So I try to think out loud here to see… if I understand the credential itself through the render method tag will refer to that template is therefore authored by whoever wants to present that. So far, I think that's correct. And then you have a third party, which is the one which takes the template and displays it in some way. And that third party also had the freedom to choose how that template is really displayed. So, in a way, the rendering itself is spread into two different actors. One is the template itself, and the other one is the script that you show here, which is part of the page that is on the client side. And I can use all kinds of
Dmitri Zagidulin: So, not quite. This is the entire template with the provision that the VC gets injected into it. So, there's two parties in the sense that there's the template author and host. Let's combine them into one and…
Kevin Dean: Thank you.
Dmitri Zagidulin: then the second one is the display software. But the display software doesn't have choices.
Dave Longley: Yeah, by the…
Dmitri Zagidulin: It just follows the algorithm. Loads the template, injects the meta tag and the script with the PC. But Dave's on the, I think you were on the queue.
Ivan Herman: Just let me finish what I wanted to say there. But for example, on a very practical sense, who will define the type of CSS statement that will control the display of the credential at the very end?
Dmitri Zagidulin: Great question.
Ivan Herman: This is something it is not in the template. It is somewhere else in the HTML file which is on the client side. So, there is a separation here between various actors…
Dave Longley: So, I can answer that question.
Ivan Herman: who at the end, combined the action of all the actors, will display something for me as a user.
Dave Longley: All of the styles and everything else that are desired are embedded within the template that goes into the body of the HTML. So the expectation is that the party providing the HTML has built and combined all the styles, all the JavaScript, everything else they want to appear, and that will just be fully injected into the document. So the host party that will set up an iframe to allow the template to be injected is going to follow an algorithm as Dmitri said, that we expect to put into the spec with some level of prescription. I would expect that we can make every single implementer more or less do the same thing. There's no reason to have any optionality there. Then the template that is received is injected wholly as the body of the HTML. And all that's important is that there are some messages that go back and forth between the host and the template author to indicate when the template is ready for rendering. So you don't have displays of unstyled content and so on. So, there's a host, they provide an iframe that's going to have effectively a slot or a hole in it…
Kevin Dean: We're going to…
Dave Longley: where the template goes for the body of the HTML document. And then that body gets injected into the frame. It runs whatever JavaScript it wants to, which includes running any template libraries it might want, Mustache, whatever it desires. None of that has to be in our specification, which is one of the strengths of this proposal. And after it's ready, it makes a call that we will define in our specification to send a message back to the host to display. Hopefully that made sense. The answer to your question on about style and so on is the template author provides all of that.
Ivan Herman: May I intervene, Benjamin? Sorry,…
Benjamin Young: Yeah, go for it.
Ivan Herman: just but how do we expect to control that? I mean, what you cannot control the HTML which is on the client side in the sense of putting in to stay with this example its own CSS? This…
Dmitri Zagidulin: You can, though. You can have inline CSS…
Dave Longley: So, yeah,…
Dmitri Zagidulin: but go ahead, Dave.
Dave Longley: So, we have to dig in further into your question, but my intuition is, and experimentally this is true, you have control over that as the template author. There are some things that we have in that example on the page right there. As the template author, you might want to express the expected output preferences for the size of the template, of the iframe that's going to be rendered, for example, width and height. And there might be other style parameters that are important to announce to the host system. I don't expect that to be a large list, but we're trying to reuse CSS terminology there to get as much reuse as possible.
Dave Longley: But the rest of the style for how everything else looks and so on, just, you can think of this as putting an iframe in any other web page where the source document, whoever is providing the source document, gets to control entirely how that looks, and that's already how things work on the web today. And this should not be different from that.
Dmitri Zagidulin: Ivon,…
Dmitri Zagidulin: hopefully that makes sense. If not, hop back on the queue. Benjamin, you're up next.
Benjamin Young: Yeah, I think it's probably well clarified, but I'm happy to extract. I think one thing that's missing in the current write-up is there's nowhere where you see just the template code by itself. The host shim code is there, and then the combined thing is there. But I can extract just the template, the two divs…
Dmitri Zagidulin: Yeah, perfect.
Benjamin Young: And then I can put inside of that some CSS and a style tag to show where that would come from. But I would be curious…
Dmitri Zagidulin: That would be wonderful.
Benjamin Young: if that's all now understood as how it would work or not.
Kevin Dean: Oops.
Ivan Herman: I am a very visual person, Benjamin.
Ivan Herman: So a kind of a diagram which shows where things happen, who decides and who controls what and where, at least for me, would be very helpful. Okay.
Benjamin Young: Yeah, I had one half-made in Mermaid, and it kind of broke the spec output. So I didn't end up committing it, but I do have one in process. I'll have to probably do it in SVG and add it. But yeah, I had to draw one before even writing the HTML. So I will happily do that.
Dave Longley: Yeah, I think all that's great. We definitely want all that. I guess my question to you, Ivonne, is how much of that needs to be in the initial PR to get things rolling as opposed to these are continuous PRs that start making this better and better?
Dmitri Zagidulin: Thanks, Dave.
Dmitri Zagidulin: Yeah, that's a great question. To the group, for myself as one of the editors, I think this is a great start and we can build on it with the isolated template, adding CSS to it, adding diagrams, and…
Dmitri Zagidulin: adding a lot of algorithmic explanatory code. But I just want to make sure that nobody objects to that approach. Ivon.
Ivan Herman: Yeah, my problem is coming back to the previous to my original comment.
Ivan Herman: I mean, as it stands today, as what I see on the screen, I don't think it's really appropriate in the sense that everything which is specified is in. So there must be some specification text outside the example which is really the normative part. The diagram obviously can come later, that's absolutely clear. But the specification of what happens and where, even if it's not complete, even if it's not final, it should be clear that this is where it will happen eventually when we fully specify the thing. Today, you look at the examples…
Dmitri Zagidulin: Thanks, Patrick.
Ivan Herman: that's the only thing that you really understand.
Ivan Herman: So I think at this stage.
Patrick St-Louis: Yeah, I just have a question regarding the credential injection that we see here. So in the render method, you have a render property that highlights which field should be rendered. Would it make sense that these are filtered before you inject the credential? Because in this case, we see the "not rendered" and if I understand correctly, this will now be in the browser, it won't be rendered, but it's very much going to be on in the browser. And would it just make sense to limit what is shared with the browser to the render property, just sensitive, just for sensitivity, in case there's other…
Dmitri Zagidulin: Great question.
Patrick St-Louis: more sensitive information in there?
Dave Longley: So, yeah, the way that this is done today in the example that we linked to in the PR is, those fields are used to essentially do selective disclosure on the VC to produce a derived object, which is then passed into the render. So, I believe that matches what you're describing, Patrick, and we just need to make sure that the spec code says that, and I think the group will agree that's the best way to do it, but we want to get agreement on that as…
Patrick St-Louis: …
Patrick St-Louis: you're saying that this example here doesn't necessarily respect what we would expect? Instead, we would only have the issuer, credential subject, with the name property. We wouldn't inject the "not rendered" types context. Basically, anything that's not in the render property JSON pointers would not be injected. Is that correct?
Dave Longley: I believe that's… So I do think this example is not matching. It depends on what piece of software is going to perform. I'm pretty sure that this is not correct from or…
Kevin Dean: Excuse me. Oops.
Dave Longley: doesn't match how the existing test works. So, I think I agree with that, and maybe this example is written to try and show everything, but it doesn't actually match what would happen.
Patrick St-Louis: Okay, that's good…
Patrick St-Louis: because in a case where this is rendered in a wallet, it's the user's credential. It's not that the user owns his data. But I could very much see the render method being used in cases where someone shows a credential that doesn't belong to the person seeing it.
Patrick St-Louis: So, in those cases, yeah, it would be preferable.
Dmitri Zagidulin: Wait, Patrick,…
Dmitri Zagidulin: just to clarify, the same party is controlling the outer wrapper which has access to the full credential and the iframe and…
Patrick St-Louis: But let's say I'm a user on a website.
Dmitri Zagidulin: That's okay.
Patrick St-Louis: The website wants to show me, render me, a credential that doesn't belong to me, and then I should not have access to any properties of that credential that wasn't intended to be rendered or publicly disclosed.
Dmitri Zagidulin: I see. Benjamin, go ahead.
Benjamin Young: Yeah, I'm gonna let Dave speak to that and I'll queue up.
Dave Longley: Yeah, I think what's key is that the Verifiable Credential should be fully filtered and selectively disclosed prior to going into any place that the template provider might be able to do something with it. That's the template provider announces the fields they're expected to get. You should perform the selective disclosure on the VC and then only provide that to that late. And I think that's the goal. I think the example today probably doesn't reflect what is actually happening in the test implementation and…
Dmitri Zagidulin: Got it, Benjamin.
Dave Longley: what we would actually want in the spec when we're…
Benjamin Young: So, it's definitely a bug, as you can see there by the line highlighted, that "not rendered" is there. I think we need to be careful not to keep calling this selective disclosure because we are probably not going to generate an actually selectively disclosed credential to add to the data. And in fact, whatever goes into this script tag data block, if it's not a full VC and it is just the data extracted using those JSON paths, then we need to discuss what that object looks like. Is it just an object where the render property paths are the keys and then they have a value? In which case, you reference it by the full path, which would be the simplest thing. Or is it going to attempt to rehydrate some object from the JSON path that it did extract, which I think is going to be a pain in the butt to write? But go ahead.
Dave Longley: Yeah, I don't think we need to make this more complicated. If we want to avoid the selective disclosure terminology, that's fine, because we're not generating a derived credential. So we just need terminology for it. Maybe a filtered VC or something. But using the JSON pointers, you just select that information and then that should be passed on as data. I don't think we want to make a new format.
Dmitri Zagidulin: You on
Dave Longley: And I don't think we want to make it any more complicated than…
Ivan Herman: To continue on what Dave said. After all, it's up to the holder to create a presentation, whether it's a verifiable credential presentation or a single credential, where the selected disclosure is already happening on the holder's side. So whatever gets to the presentation is a credential that can be displayed.
Ivan Herman: So I'm not even sure that we have to get into all this complication because this is not part of the rendering part.
Kevin Dean: Thank you.
Patrick St-Louis: …
Dmitri Zagidulin: Benjamin. Yeah.
Patrick St-Louis: Not all credentials will support selective disclosure. So that would be one reason in cases why we might still want to have this filtering.
Benjamin Young: So, I think there's some tension introduced by what Patrick was saying about an untrusted renderer. I don't think we have one of those…
Kevin Dean: I need this.
Benjamin Young: because if you've got a renderer, and again, this is also some tension with having a render property at all, unless you're somehow trying to not like you're saving bytes on the wire or something by not injecting a learner record into an HTML source doc that goes on an iframe. Maybe that's a reason. But otherwise, the thing that is the host page, the wallet, the renderer, whatever, that creates the shim code that makes an iframe that's cordoned off so it can only do what's in the render method template, that thing's also already stupidly trusted because it has the credential and it's retrieving all the other bits.
Benjamin Young: So if you're somehow imagining a renderer that you're only giving some of the data to, then you've got a different thing entirely, in which case you should derive a different credential with a different template and selectively disclosed or otherwise, and render. Then for me, it circles back to what do we want to put in that data block? Is it just part of the credential or is it the whole credential? If it's just part of the credential, what is this JSON that's going to show up there? And how is it formatted? Because I, for one, don't want to take these two render property paths and extract the data and then also try and reconstruct a tree shape from any number of unknown paths. But go ahead.
Dave Longley: So, in the previous iteration of the VCWG, we defined methods for that are used during selective disclosure that could be reused here, even though we're not generating a derived credential. But there are helper methods that'll take a list of JSON pointers and produce the credential that is in part selectively disclosed. You don't have to do any cryptography or anything like that. It's just JSON pointer selection to produce the output, and you still output a valid Verifiable Credential with reduced fields. So I think we might even be able to get some benefit from just referencing, using those helper functions as in this work. So if you want to render a VC, you have an input VC, you have the render property inside of the render method. You run, and that's those two parameters are all it takes with these helper functions that we've already standardized. So you pass in the list of pointers, it will produce a new VC object that is a I keep saying selectively disclosed because that's how it was defined in the previous iteration, it will produce that data object.
Dmitri Zagidulin: We can take free. So I jumped on the queue, so I have a question for Benjamin and…
Dave Longley: So you have all of that, and…
Kevin Dean: Yes.
Dave Longley: then instead of doing any cryptography on that, you just pass that into this iframe for it to be given to the template to work with. So I think we have those primitives to make all of that work.
Dmitri Zagidulin: Dave, which is it sounds…
Dmitri Zagidulin: we might not even need to inject the full verifiable credential because really the only thing that the template cares about are these fields. So ostensibly, you could pass in the dictionary of just key values, keys being the property fields and…
Kevin Dean: Question.
Dmitri Zagidulin: and being the values. None of this other stuff is needed. Go ahead, Patrick, and then…
Patrick St-Louis: Yeah, I know what you just said makes a lot of sense. My other point was like, why not make the render property instead of being an array, it's an object? And then you put the variable name that's to be referenced in the template and…
Patrick St-Louis: the value is the path where to find the value for this. And then you can just pass that object itself to the template with you just replace a path with the fetch value from the credential. So, for example, here the first element would be "issuer name," semicolon, and then the value would be `/name`. Second one, like "subject name," and…
Kevin Dean: I hope you don't…
Patrick St-Louis: in the HTML template then you have "issuer name," "subject name," and you pass that exact object. Does that make close?
Dmitri Zagidulin: Benjamin, go ahead.
Benjamin Young: Yeah, I was typing in the chat. Is this what you're saying, Patrick? Because that's what was in my head as well.
Patrick St-Louis: No, not so, let's say you have…
Patrick St-Louis: Just going to type it real quick.
Benjamin Young: Did you have some interstitial variable that was being populated?
Dmitri Zagidulin: Patrick, I think I understand what you're getting at, and the problem is…
Dmitri Zagidulin: what you're picturing assumes a particular templating mechanism, which this overall method does not assume.
Dmitri Zagidulin: Yeah. Yeah.
Benjamin Young: Yeah, I wouldn't…
Benjamin Young: that's creating an interstitial variable thing that I don't think we need. Because what I think, if we detach our brains from the word "template" and just think about JavaScript, all I need JavaScript to have is the data, and then I'm going to do whatever I'm going to do with that data. And when I get that data, I need to know enough about what it is. So, what the object I defined…
Benjamin Young: is just saying I wanted these pieces out of that previous thing, which is a VC in this case, and I want to know what their value are values are. And then the JavaScript would be written for essentially just those render pointers hydrated with values. And if you scroll down, Demetri, to where the code is, right? Yeah, where the code is. That big, yeah, these document query selectors, they're finding the place in the HTML to inject the text. And then rather than where you see "name," you would see "data," "credential," "subject," bracket, and that's going to get the value out of this data object. That's about the dumbest, simplest use any JSON path thing off the shelf. Don't write anything, because you're just going to feed it the object, an array of JSON paths, and it should give you an object, keyed off those JSON paths, with their return values. And…
Dmitri Zagidulin: Yeah, agree.
Benjamin Young: then you do whatever you're going to do with them on the render set.
Dmitri Zagidulin: Yeah, agree.
Dave Longley: Just a quick clarification.
Dave Longley: Throughout all this, we're actually talking about JSON pointer, which is a different specification. It's an RFC at IETF. From JSON path is significantly more complex than JSON pointer, and…
Dmitri Zagidulin: Okay.
Dave Longley: we are trying to work with the simpler spec. So I just want that to be clear. It's JSON pointer is the Yes.
Benjamin Young: Yeah, thanks. So JSON pointer, sorry. What's screwed up with that is JSON path doesn't look like paths, and…
Dave Longley: JSON pointer.
Benjamin Young: JSON pointer does. So naming is hard, I guess, for something.
Dmitri Zagidulin: All right.
Dmitri Zagidulin: Any other questions? Does everybody else listening to this understand the broad context and what we're talking about and why we're using, instead of a template, essentially sandbox rendering code? Go ahead, Dave.
Dave Longley: Others can jump on the queue if they want to respond to that. I just wanted to say my next question would be, what specifically do we need to do to get this PR into the spec so we can move on to doing more PRs to make all of this better and address a lot of Ivon's concerns and so on?
Dmitri Zagidulin: If Ivan,…
Dmitri Zagidulin: feel free to jump in and clarify, but if I understood Ivon correctly, he was saying he would want to see the addition of spec language and…
Dmitri Zagidulin: algorithm before merging this PR, and then diagrams can come later.
Dave Longley: So, is that specifically decoupling the example code so we have a clear normative section that's not just in examples? Is that the main thing? Go ahead.
Ivan Herman: That was my point. Yes, I think at this stage.
Dmitri Zagidulin: Benjamin, go ahead.
Benjamin Young: So, what would be spelled out there is a flowchart, I guess, and then also algorithmic language about what's supposed to happen by each of the actors.
Ivan Herman: Yeah. Yeah,…
Dmitri Zagidulin: with the preference, with the priority given to the algorithmic language. Flowchart can be secondary.
Benjamin Young: Yep. It'd be non-normative emitting that, right? From everybody.
Dmitri Zagidulin: Yeah. Excellent.
Ivan Herman: I mean, that being said, if I was the editor, a flowchart would help me to do the spec language.
Benjamin Young: I'm going to start with a flowchart.
Ivan Herman: So if you have it, then please don't restrain yourself from the. Yeah.
Benjamin Young: It's partly done and I need it to write that algorithmic language anyway.
Ivan Herman: So we are thinking the same way, Benjamin.
Benjamin Young: Make sure I don't miss anything.
Ivan Herman: Then just put the MC into the document as well.
Benjamin Young: Yeah. Yeah, I will. And I said, it was nearly done in Mermaid and then it broke respect.
Dmitri Zagidulin: Patrick, go ahead.
Benjamin Young: So I got to switch to SVG. It was just too awesome. Yeah.
Ivan Herman: Generate an SVG and then you are done.
Kevin Dean: Jesus.
Patrick St-Louis: Yeah, so I just wanted to mention, so I've been having a difficult time attending this specific meeting, I think just the time made it difficult for me to attend in the past. However, I was very interested in the render method work item, and I was especially interested in contributing a topic that I've seen was discussed previously, but I wasn't part of the discussion with the OCA render method that myself and Michael were working on. And I was just wondering if we could loop back in and…
Dmitri Zagidulin: Good question, Benjamin.
Patrick St-Louis: I'd like to be part of the discussion since I'm the one who proposed it. It would make sense, probably some clarifications I could make, and just what's the sort of the state of that proposal and how it fits in with all the latest work that's been done in the group. Yeah.
Benjamin Young: Yeah, I'd love to return to that because it did get merged and then there was no discussion. Possibly because it went in that order that it was merged rather than discussed and then merged, I think. But one of the things I wonder, Patrick, is, in light of this sort of HTML injection JavaScript model approach, does the OCA bundle thing, does it or could it, and I think Longway's already probably mentioned that on the proposal number 15 or whatever. Could that live as just a JavaScript engine in the same way that the existing things, the two Mustache ones, or the other proposals for Handlebars, or any template engine would ostensibly just become these HTML templates that people provided, and they could use whatever other bits, Mustache templates, or Liquid templates for OCA bundles, or whatever? I don't know if you thought that far, or if this proposal was too vague to see that as an option, but maybe it is…
Patrick St-Louis: Yeah, at first glance, so the OCA render method is not really, it doesn't provide a template. It provides, so the way it works is, you select the same way you have the render property here, you highlight…
Benjamin Young: Maybe we talk about it next time.
Kevin Dean: This one.
Patrick St-Louis: which JSON of your credential are to be included in this OCA bundle. And then for you can provide different overlays, which each overlay can add a specific layer of metadata for these properties. And could include different translations for different languages. It could include all sorts of things. But it doesn't provide a template per se, right? It only provides descriptions, other information to be used by another software to do all sorts of operations that could be useful. We have used it for things like mapping data between the credential and the root system. From, so it's really not a render method as in you will visualize something. You could very well use this to render visual cards for your credential. You can use OCA to highlight primary, provide some branding information with colors, but you are rendering the credential in a format that can be useful to you. You could display it in a table, for example, or different things. I know talking at IW, I forgot her name, but she was using credentials and OCA for scientific research where different students could u provide their result using a consistent OCA bundle, so it could be easily processed by different software.
Kevin Dean: That is bad.
Kevin Dean: What is it? Where's the…
Patrick St-Louis: So, yeah, I don't see the reason why. I'm not sure it would fit in the render method. It doesn't really provide a template. So, it's slightly not super, yeah. And the other thing, so, there was discussion around the version aspect. So the overlay capture architecture is a specification, it's external, right? It has some way to protect its content with hash, with digests. This could also be taken into consideration on…
Patrick St-Louis: the credential side with providing a digest multibase or, yeah, so you wouldn't want to re-explain the whole specification. My main goal here was to provide a way to relate the credential to the OCA bundle. And the main thing is to interpret the attributes as JSON pointers here. That's the main part. Because the attributes in the OCA specification is just you can put the string, it could be anything. But here, since the source is a verifiable credential, it's important to understand that the attributes you want to actually use the JSON pointers as the key here. Yeah, I'll stop here, running out of time.
Dave Longley: So, this sounds like it isn't so much you're rendering to some and providing some visual elements, but you're translating the incoming data into a format for display in a table or in a card structure. And I want to point out that we might find commonality. There's another PR for a JSON card renderer, and we might find commonality there where we could combine those things. We're not rendering specifically to a visual interface or whatever like the HTML one is, but we're taking an input and turning it into a different kind of structured data that maps to tables, cards, other things like that. And then how you display those is entirely up to the host system based on whatever unified user interface they want to have. And I think those are the two main types of render methods that make a whole lot of sense that people have been talking about. And I think that we might be able to get things to fall into one of these other category B.
Patrick St-Louis: Yes. Yeah,…
Patrick St-Louis: With this other method that you're referring to, I'd be very open to finding a way to make it support OCA as well as other things that would fit. I just didn't feel that the template itself was a little bit misleading. So, if we can find another family of render method that this could fall into, I would feel a lot better. For this, I think it would be great, because right now, as far as visual rendering, it's used for credential cards and…
Ivan Herman: All right.
Patrick St-Louis: wallets, right? You can provide a background image, you can provide a hex for colors, you can flag primary, secondary attributes that you might want to display in a minimal version of the card of the credential. So, that's good to know. I will have a look at this other render method and to be more prepared for discussion.
Dmitri Zagidulin: So, to add to what Dave said, looking at the OCA bundle method, I'm seeing several areas that are in common with both the template render method and this other family approach that they've mentioned. That the JSON card type also also does. So, things in common, right? We've got the language…
Dmitri Zagidulin: which I think most of the methods in common. We have the digest mechanism, which we can pull out into the outer templated definition. Although I do have a question about what the logic with these inner digests is, but that's minor of this object.
Patrick St-Louis: Is there a digest on the overlay object itself?
Patrick St-Louis: So you calculate and then you add the digest property with the digest. But the digest we see here is the digest of this object you highlighted and the capture base.
Dmitri Zagidulin: Got it.
Patrick St-Louis: So the capture base, which is the first thing in the bundle, right above the overlays, that's your capture base. So this has a digest in itself, and the overlays, when it says capture base, it gives the digest of the capture base to which it refers, which is, I guess, used as some sort of ID.
Dmitri Zagidulin: I see.
Patrick St-Louis: Yeah. So just quickly.
Dmitri Zagidulin: Yeah, I see. That makes sense. Plus one to what Dave said.
Dmitri Zagidulin: It sounds like at least two generic render families are emerging: the approach in Benjamin's PR, which is instead of a template, load a sandbox renderer, and then this other approach, which is essentially a way to extract just the fields and values, but not provide the rendering code, and…
Patrick St-Louis: Yes.
Dmitri Zagidulin: assume that the host environment will know what to do with it. All right. We are at the top of the hour. Any other quick questions before we adjourn? Thank you, everyone. By the way, this is really good work and really good progress.
Ivan Herman: Okay.
Dmitri Zagidulin: Any other questions?
Dmitri Zagidulin: Okay, I'll see you hopefully in two weeks. Cheers, all.