Meeting minutes
Dmitri_Zagidulin: Welcome everyone.
Dmitri_Zagidulin: All right, 3 minutes past the hour. Let's get started. So, welcome everyone to the weekly task force meeting of the VC render method task force of verified credentials working group. The meetings are recorded. Uh we are as usual under the W3C code of conduct and IP restriction agreement. We have a lot to discuss much of it related to internationalization and localization. Uh so let's dive into it.
Administrative Questions
Dmitri_Zagidulin: Actually before we uh take on a bunch of uh localization discussion, I do want to briefly uh go into the issue that Patrick opened recently uh having to do with following links from the HTML suite template. Uh this is issue 99. Let me put it in chat. Uh, go ahead, Coyote.
Kayode_Ezike: Uh yeah, before we do, I just wanted to like go over like ask a few administrative questions. That's okay. um just like a few administrative questions that I had um before we dove in. Kayode Ezike:
Dmitri_Zagidulin: Uh could go over…
Dmitri_Zagidulin: which part? Yeah, go ahead.
Kayode_Ezike: So the first one is I just remembered before this call that um on the last BCWG call there was a gentleman who from UNP who was asking to basically find a better time. I don't know if you've been chatting with that individual offline and what that means for us uh moving forward.
Kayode_Ezike: That's the first question that I had.
Dmitri_Zagidulin: I have not connected uh with that person yet.
Dmitri_Zagidulin: Uh we do need to find a uh Australia friendly, so likely in the evening slot for whether to have uh a handful of special topic calls or do an AB sequence kind of thing, but probably the former
Kayode_Ezike: Sounds good.
Kayode_Ezike: Then the other question I had was uh I don't know if we wanted to do any prep for tack next week just so we have a sense of what we wanted to get out of that conference for a few minutes or it's my first te pack ever so I don't know what the protocol is but that would also help to understand okay how we should go about it.
Dmitri_Zagidulin: Yeah, great question.
Dmitri_Zagidulin: So we uh at very least we have a slot reserved in the overall VC data model working group programming. So I believe it's on Thursday. Uh it's a um morning eastern time zone slash late afternoon Dublin time.
Dmitri_Zagidulin: Uh so so we've got I believe like an hour and a half or so chunk to to discuss with the overall group. Best you best use of time for that would be to bring handful of um decisions and internationalization discussion and uh threat model for linking to external resources discussion.
Dmitri_Zagidulin: since all of them affect the verifiable credential working group in general as well as us. Uh but uh we have Ivan on the queue. Go ahead.
Ivan_Herman: Yeah. So with the experience with former TPEGs, uh one thing that Tek gives you is to be able limiting by the time etc. to go outside the group itself. uh there are lots of discussions happening with the Wednesday the whole day of Wednesday is is full of short sessions where you can hear and you can contact with people with all kinds of places within the organization and it's in a sense uh may be a better use of one's time to do this rather than do what we can do on this course continuously.
Ivan_Herman: Uh so in a sense yeah I mean that's that's a personal reaction for me but I think that having the these task force calls for example happen and…
Ivan_Herman: during the TAC would be a bit of a loss of opportunity but again this is not my staff contact this is my several TEX organ presence over the Yeah.
Dmitri_Zagidulin: I agree.
Dmitri_Zagidulin: I completely agree, Ivon. So just to clarify, are you suggesting that uh folks here on the call and members of the task force in general essentially go out and network, attend other sessions?
Ivan_Herman: I mean, which which may also mean that two of three of us get together in a corner or around the coffee table and do some work together on that. That's I'm not saying we don't do that and I'm sure that we will have discussions on god knows which details but to have an eye on what's going on around you and maybe give a priority to that. That's all.
Dmitri_Zagidulin: Uh, highly agreed. Anyone else comments on TAC and and this task force, right? So, K does does that answer your question? Uh, we have a uh VC working group slot to discuss vendor method stuff on Thursday. uh we have the Wednesday for the for the free form sessions that uh is a great opportunity to connect to other groups uh bring up some of the concerns which again are not just unique to us are definitely relate for example our two two or three main uh issues here uh the threat model trade-offs of embed
Dmitri_Zagidulin: heading versus linking and then when linking uh locking it down with a hash versus not right these considerations the the overall working group as well as a bunch of other task forces will need to solve as well. Uh internationalization localization everybody will need to solve it as well even though we have a uh particular focus and a particular responsibility to do that in the render method suite. Uh and similarly uh this uh issue 99 that we're going to talk about next uh is another example of I suppose it's um again particular emphasis on the render
Dmitri_Zagidulin: But other uh task forces and verifiable credential impleers in general uh will will have to deal with this overall.
Kayode_Ezike: Sounds good. Thanks.
Issue 99: HTML Suite Link Following
Dmitri_Zagidulin: right. Okay. Excellent. Thank you. Uh any other general uh announcements or questions before we dive into the specific issues and PRs? All right. Uh, so real quick, let's um let's go over uh issue 99 that Patrick opened recently.
Dmitri_Zagidulin: essentially saying, "Hey, HTML Suite is for is intended to be sandboxed, which means at very least sandboxed iframes uh may not open popups or change the top level document. They can navigate within the iframe." Uh but Patrick brings up, hey, what about the fact that in a lot of cases the variable credential is going to be referencing one or more related documents. Uh and in in general is going to have links for the user to follow.
Dmitri_Zagidulin: uh whether they're for example uh links to uh issuer detail um issuer um recognized entity. Yeah. Go ahead Patrick.
Patrick_St-Louis: Uh yeah sure or if you want to finish introduction that's fine. Um yeah I'm not I would say like in most cases uh so this issue uh you know for those who are on Slack you know I posted this a while back. Uh so it's a direct um reaction to the UNP. So the UNP has historically been following the VC render method. uh they add this uh I forget like this HTML render suite 2024 something like this like a very old uh render suite the VC render method uh and obviously since then uh this group has uh been working on things and they find this new render suite model uh and when this was pointed out to the UNP they reviewed the spec and they've decided that in the current situation the VC render model was not a good fit
Patrick_St-Louis: for the UNP. Uh the main thing that they gave was that the UNP is based around this idea that when you have a credential, it can link to other credential. So uh it's not really about other links in general. It's like this. At least at this level, it's very specific. when you have a link to something that is expected to return a credential related to the present credential. Um so I add a couple back and forth with them. Uh their current situation is that they will take the um older HTML render 2024 and just define it at the UNP level and keep using it.
Patrick_St-Louis: Uh so I tried to at least come up with a proof of concept to say that uh well there are ways uh to do it like this. Uh the main approach here was to remain like keep the security and privacy uh sandbox element and uh selectively allow specific feature to be enabled. So it's the concept that you start with all the walls closed and then you add a very controlled reflected features uh in there or at least demonstrate like how this could be possible. uh how this would be implemented. You know, it's I don't know. I I gave a proof of concept. There's a demo here. Uh whether that's something that's added there or not, whether this gets dropped down, whether this gets exposed as a flag or an option supported. So, this is very additive.
Patrick_St-Louis: Um the way it works is it keeps using the already existing message channel uh that is already a concept and adds a specific function like a normative function if someone choose to extend it with with it called render method follow. And then there's a small algorithm to go with this to try to handle this uh in as much as a secure way as possible. Um yeah, so that's kind of where that came from. Um you know, I think all things considered, uh UNP is pretty significant and it'd be a shame, I think, if they would move away for something that could be addressed. Uh my second preferred solution with them was to, you know, instead of taking over defining the type of their own thing, just to uh propose a small render suite, right?
Patrick_St-Louis: Like I think there's another issue about the render suite kind of directory. Uh you know they can take their own render suite doesn't have to be HTML it can be HTML adjacent but focus on their use case while still being mindful of the security implication. uh I think you know this being a trade and supply chain group uh you could have credential graph with potentially hundreds of credential uh so even though if you have a small trust registry you might end up with some issuers that are uh very far away in the chain um you know yeah sure maybe they'll do this super trust graph that you can trust all issuers but you know it might not be the case so I think security of render
Patrick_St-Louis: ing um you know a lot of the thing outlined in the threat model for the VC render method is really applicable and the supply chain state uh just for this idea that you have a chain of different credential um you know from various issuer uh so first thing I would encourage them to read the truth model and…
Patrick_St-Louis: then yes kind of see if there's a way that their use case could be satisfied So,…
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: So clarifying question, where exactly is their point of friction with sandbox HTML approach? Is it that they want link Is it that they want links inside the sandbox to be able to control the top level document? Is it that they want pop-ups? Or is there something else that that we're missing?
Patrick_St-Louis: um it's not 100% clear. There is uh you know it's it's all documented. Let me put the link here. uh you know they have a they explain it on their specification there's a render method section and they explain all this in a note from what I have seen uh so you have something like a product passport right some kind of product that has a credential and this credential might link to another credential which is some kind of audit on a facility you know transformation that the thing included and they want to have this application that renders the credential and is able to go from one credential to the next and kind of render these different credentials. So you can like kind of click from one to the other and move back and forth. Um it's kind of similar.
Patrick_St-Louis: So there was another issue open about I think the the CLR record where it's a little bit different because in that case you have like embedded credential that you want to render distinctly uh in here these credential are outside right on another domain maybe on the same domain. Uh but the idea is that these credential could be fetched securely by you know doing some prevalidation of the data model and uh then render them um in place of their current credential. So I don't think a popup is suitable. Um their current way I from what I've seen it follows the link right you just go to another web page.
Patrick_St-Louis: Um this is not the solution I've proposed. The solution I've proposed is it just renders it but you do not navigate to a different location. Um so you know I think for this would need some of their input like I'm not super active on the UNP. uh I've been following mostly uh you know on the verifiable credential side and how they they modeled things. Um we did an implementation in BC uh with you know the conformity credentials. Um but you know other than that I I don't attend the call or anything. I know Kyod you mentioned someone reached out so it's probably one you know because I kind of had a discussion last week with them.
Patrick_St-Louis: So it's probably something following this and it would be great to get some of their input to uh have you know a very more specific details here.
Patrick_St-Louis: Uh from my best understanding that the solution that I propose there does meet what they're looking for. Uh not 100% sure.
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: Come on. Go ahead.
Manu_Sporny: Yeah. And from what I saw in the the thing that you put together, Patrick, thank you very much for putting that together. It felt like a reasonable thing um to do. Uh meaning that you know we then it is explicitly under the control of um you know the application on whether or not it chooses to allow navigation to those other places. So um I mean plus one to that. I think we have a solution. We just need to figure out if um or I think we have a reasonable solution that you've proposed, Patrick. Uh so we just need to make sure that it works for them or…
Dmitri_Zagidulin: Go ahead, Patrick.
Manu_Sporny: not. Um,
Patrick_St-Louis: Yeah. And like we've had this discussion, but here, you know, it's like they have their own kind of link URL thing, but I could see this solution be very good for related resource, right? If you have a a related resource item, which is a credential, I think it would also fit this model. So the current implementation yeah it's proof of concept really based around the link URL and it's meant to be uh well I just wanted to discuss it first right to see if it made sense um you know I think next step would be to chat with the UNP if it's something that suits their need uh and then you know I'd be happy to refine it and spend a bit more time to at least make a little something uh that could go in the specification.
Patrick_St-Louis: I guess one of my question I would have is if the UNP does not feel it suits their use case is this a use case that the group sees as valuable um you know that's something interesting to think about and then the second question is time frame wise is this something we see uh as a two like next version or…
Patrick_St-Louis: is this something we can implement here um how it would be implemented and etc.
Dmitri_Zagidulin: So I see Dave on the queue…
Dmitri_Zagidulin: but I want to jump Q to say I feel like there might be misunderstanding on their part uh with the capabilities of the HTML engine uh the HTML render method. Look looking at the navigate navigating to supporting evidence section. Uh, all four of these items are supported out of the by just the sandbox HTML for example renderer must isolate the template and must not expose it uh right so this this is exactly describing an iframe and links clicked on an iframe just follow naturally in the browser right so I I'm wondering if there's a m misunderstanding that we could clear up with them uh Dave and then Benjamins
Dave Longley: So I was just on the queue to say uh you it might be of use to also pass uh a digest if there's anything associated with the link uh in the render method follow spot.
Dave Longley: That's it.
Dmitri_Zagidulin: Benjamin, but there is a hold on…
Benjamin_Young: Yeah, just a point of clarity,…
Benjamin_Young: Demetri, links in these particular sand overly sandboxed iframes do not just browse. They can't browse in their own I frame. They can't break out to the parent, which of course one would not want. Um, they don't work. They're functionally broken.
Dmitri_Zagidulin: but there is um there's a directive that you can pass to the sandbox to the iframe.
Dmitri_Zagidulin: Uh there's an argument that you you can pass in to allow that is there not
Benjamin_Young: not not per the current spec.
Benjamin_Young: So our the our spec the HTML render method has a a must list of allow dashes and the the current set basically by design means it is uh it runs JavaScript and displays a thing. um it doesn't give you hypermedia. It doesn't give you a lot of stuff and we're still finding the the edges of where that's at. So, a lot of what Patrick is trying to address here is, you know, we've we built the box and now there's places and moments where we need to get out of the box and then how do we do that without having to call the browsers to create a new like allow this kind of link or whatever.
Benjamin_Young: So just just to be clear,…
Dmitri_Zagidulin: I see.
Benjamin_Young: this is not the old I frame. This is a very different animal.
Dmitri_Zagidulin: Got it. Thank you,…
Dmitri_Zagidulin: uh, Dave and then Patrick.
Dave Longley: Yeah, I'll let Patrick speak to that more,…
Dave Longley: but I was just going to comment that uh if you don't have a good security model there, uh then any rendering could redirect in any number of ways and exfiltrate information. And so it's it it's important to have that and the host uh if if the host were going to change those restrictions in some way the host should have some kind of understanding or uh be able to use some heristic to know that that is not going to happen which you definitely can't do in the general case. Goodness.
Patrick_St-Louis: Yeah. So like the first thing I I had to look at was these flags, right? Like these flags that you could give to the sandbox like lls and things. Uh but as pointed out like this then you know would need change in the spec and would like affect the HTML render suite as a whole, right? And it would uh you know it's very specific on what you need to allow. Uh so the second option here is just building upon this like I mentioned this like message channel like this kind of uh permissive instruction very specific task function that you can provide to the host and kind of expand on this uh which I felt was the preferred source the preferred solution and to add to some of what Dave said um you know browsers are pushing
Patrick_St-Louis: ing more and more features related to DC API and you know different credential and like we don't know what this what attack vector this could allow eventually right as feature as browser supports more features uh it adds more um exposure layer for potential malicious actors so you know I think there is value in in locking it down very precisely and…
Patrick_St-Louis: then just having very specific reflected solution to do like small features like this.
Dmitri_Zagidulin: Thanks, Benjamin.
Benjamin_Young: Yeah, if you can go back to the UNP requirements again. Um, the second bullet point is is a richer uh expression of what they actually want…
Dmitri_Zagidulin: Interesting because
Benjamin_Young: because just just providing a link and letting somebody click it is voiding the warranty on just about everything that happened before that. So, I I think you know the the general shape of what Patrick's presented is fine, but what they need and what we will need if we're not just punching a hyperlink sized hole in the box we just made um is something closer to this where we're essentially they're asking that whatever their UNP scanner renderer user agent thing is and whatever this credential link
Benjamin_Young: is which is clearly not just in the URL that there is follow on I know it's a should in here but like should result verify render the linked credential they have a like very narrow use case of this is another credential right and that's what you were discussing in the context of a a transparency graph or or whatever it's it's not merely a render method being like here's a link to this credential rendering at adobe.com so it can render the PDF I just gave you like voiding the entire warranty on everything we tried to build. So, we need to be really careful with punching holes in the box um and knowing what other requirements we put on that. And if it's just a URL,
Benjamin_Young: That URL, as Dave was saying, can totally excfiltrate all kinds of data when the user clicks it. So, it's, you know, just just like if you're um wanting to render a PDF, the way you have to do it with HTML render method is pass the PDF binary back to the browser outside of the sandbox and then trust that there's nothing in that PDF that can't do other stuff when rendered. And you just really don't have that guarantee. That's it.
Dmitri_Zagidulin: Right. Okay.
Dmitri_Zagidulin: So, I do I do want to leave uh enough time for uh the internationalization discussion, but this is this is interesting and important. So, uh real quick, Patrick
Patrick_St-Louis: uh well I was just going to add like you know clearly here they're putting some verification thing on the renderer right uh…
Patrick_St-Louis: because I I know like another issue I open is like what happen if you render credential that are not verified and like this just makes me think of that like it's starting to muddle the water a bit about what a renderer should do. Uh so this makes me think like shouldn't this deserve actually a new render suite that takes into account these things or you know do we kind of move out this verify and say like this part we're not going to handle how you do it you know we're just going to handle provide instruction on how to handle links and the media type that's returned and this kind of thing process the render method…
Patrick_St-Louis: but you know these kind of extra steps are sitting King somewhere interestingly in the middle
Dmitri_Zagidulin: The thing that gives me pause uh with with this particular that second bullet there is there's there isn't really a good way aside from fetching and…
Dmitri_Zagidulin: content sniffing or a renderer to know whether something is a credential link or a regular more different link. uh for the example of the latter uh we have for example uh OBV3 description field which allows uh sanitized markdown which specifically allows markdown links and this is for uh again external references.
Dmitri_Zagidulin: So how the wallet or any other renderer is supposed to know that where an outgoing thing is a BC or not is uh significant question that I have Dave and then Ivon
Dave Longley: Yeah, that since linking to other credentials from credentials is a common use case, uh we might want to have uh two features here or an option to tag that this the thing you're fetching is a credential. And so you could you could um provide something to follow links and you could could provide something to uh receive that the user asked for some other cred some other action on another credential. And both of those could be optional features that it sounds like would be useful in the CL CLR case and here in this case and… there are other cases where people talked about this sort of linkage. And you could reuse all of the same machinery if you just had that piece. Dave Longley:
Dmitri_Zagidulin: Just to make sure that I I heard you correctly.
Dmitri_Zagidulin: So you're saying we may need uh to have a general purpose linked VC mechanism notation.
Dave Longley: No. So, this proposal from Patrick is uh here's a way to uh here's an API you can call from within the template when you want someone to follow a link. Maybe we want that, but we we might also want here's a way here's a function to call when a credential is selected by the user. a linked credential selected by the user within the template and you can then uh you know provide the link to the credential a digest for it if that makes sense. You probably don't need it in the credential case. Um and that way digital wallets can all implement uh…
Dave Longley: if they would like the ability to follow uh credentials around and and continue rendering those Sure.
Dmitri_Zagidulin: Do you mind leaving uh a comment explaining this on uh on issue 99?
Dmitri_Zagidulin: I'm not sure I can c I can do it justice uh in the capture. Ivonne
Ivan_Herman: Yeah. So a bit more general comment on on the discussion.
Ivan_Herman: Uh I must admit that I am not bothered at all if the UN guys say we will have to define our own render method because the standard one are not appropriate for our use case. I think that's a feature that's a feature that we offer something that can be extendable. So I am not sure we have to go out of our way to sure somehow the extra features into what we have if we think that what we have covers a large enough uh application area. On the other hand, we have to make it very clear in our spec and in our infrastructure that people can define their own application dependent render render methods. It is not a closed uh entity.
Ivan_Herman: So it's just a general thing if we can solve the US the UN specific case easily that's wonderful that's fine…
Ivan_Herman: but there will be other complex use cases and the UN is in general complex one where we will not be able to do that in a standard and that's all Right.
Dmitri_Zagidulin: I'm up to our mind about this.
Dmitri_Zagidulin: I agree with you that extensibility is a feature for us, right? that that yes, we we can we can point out if our the three render suites that we ship are insufficient, you can extend. To me, it's also a signal though this the the need to support uh linked credentials and linked information is going to be super common. It's not just UNP. So, so to me, the fact that they're not able to do it with the spec as it stands
Dmitri_Zagidulin: currently is is a big signal that we need to do some work on uh on this. Okay. So, specifically question to the group, what are our next steps?
Patrick_St-Louis: I would say the UNP person uh you know uh reach out…
Dmitri_Zagidulin: Part one. Go ahead.
Patrick_St-Louis: but maybe yeah maybe we need to decide what's the next step for us um you know as the working group um in the two scenarios like one scenario they say yes this is a good approach we would like it and second scenario is uh no we will just define our own right so these are the two scenarios I can see and what would be the next step one or the other if it doesn't suit their use case is it something we want to pursue and put effort in redefining which I'm happy to do uh and…
Patrick_St-Louis: if it does suit their use case then you know it's probably the same question but you know with a bit more encouragement and direct purpose I can uh well I can chat with Kyote.
Dmitri_Zagidulin: Patrick, could we deputize you to make that uh initial connection to let's say say uh send an email?
Dmitri_Zagidulin: Uh yeah.
Patrick_St-Louis: Kyod seem to say like someone reached out so maybe we can follow up on that and…
Dmitri_Zagidulin: Oh, also yes. Fantastic.
Patrick_St-Louis: yeah I I think that's the the the the current thrill. uh you know uh we can decide if we want to move the meeting have a new meeting at a new hour or you know I'd be happy to just set up a small call with them or something. Yeah. So maybe K like and that chat.
Dmitri_Zagidulin: Benjamin, go ahead.
Benjamin_Young: Yeah, I think regardless of I I think all that needs to happen.
Benjamin_Young: We need to get Steve and whoever else from ENTP involved. Um because so that's one thing. The other thing is I we need to be clear on what this proposal does and does not do and and what concerns it would introduce for even just threat model updates. Um because it's it's totally possible to pass a link back from a render method that contains all the PII that the render method had access to into a URL.
Benjamin_Young: and in a in a way that the uh the wallet's not going to know that. And then if the wallet's like, "Yeah, click this thing. It's fine." Um it's it's like the door for data exfiltration. So I I think we need to be a lot more careful here than just give me an href. Um, I don't I don't know what the alternate solution is, but I I think we need to better understand their use case and circle back on on fixing their specific needs,…
Benjamin_Young: which may or not may not even be render method related or could be seen as a a different render suite like Patrick keeps saying. Um, but I I really don't think punching a hole in the render method box is going to get us…
Dmitri_Zagidulin: Agreed. Agreed.
Dmitri_Zagidulin: All right. Benjamin Young:
Benjamin_Young: what we want. And if and if we do go this route, we need to threat model the tar out of this. That's it.
Dmitri_Zagidulin: Right. Right. Thank you. Uh so I do want to move on uh Coyote real quick and then
Kayode_Ezike: Oh no, I was just really small. I was just going to say like just for context from earlier that outreach was not to me directly. That was actually on the VCWG call. Um but I'm happy to be involved with that. I do know that they've been more active even in VCOM. They raised an issue recently uh a few days ago. So if you need me to be a part of that, I'm happy to. Just wanted to make sure that I don't have any extra information. Yeah.
Dmitri_Zagidulin: I see. I see. I see. I see. Got it. Got it. Okay. Got it. Uh Patrick, do you mind…
Dave Longley: Yeah. Yeah.
Dmitri_Zagidulin: if I assign this to you?
Patrick_St-Louis: Uh sir yeah sir.
Dmitri_Zagidulin: Okay. Uh go ahead, Dave.
Dave Longley: I just want to quickly re reiterate um as Dimmitri pointed out, it looks like this uh that UNP wants to have pretty much all of the features from the HTML sandbox plus another feature. So, I do think it would be a shame…
Dave Longley: if they had to reinvent everything just to get an add one more feature out of it. So we should keep that in
Dmitri_Zagidulin: Yeah, plus one.
Dmitri_Zagidulin: Agreed. Okay. Uh All right. So so many of our issues we either end with or I have a comment that this is a wider VCDM thing, right? Data expiltration concerns for linked uh credentials uh needs to be addressed. Hopefully we can inherit some of that uh from the from the threat model, but I suspect we'll we'll need to do uh additional work specifically.
Internationalization and Localization PRs
Dmitri_Zagidulin: Okay, let's uh we have couple of um we have three pull requests 100, 101, and 102 that address we uh we had a number of issues open by Addison Phillips who's the chair of the internationalization working group. Uh so this this is wonderful. This is exactly the kind of feedback uh that we wanted with horizontal review. Uh the overall the the the overall takeaway here is yeah okay we need to Continue.
Dmitri_Zagidulin: We need to finish up the initialization work on all three of our render methods. Uh, fortunately, a couple of the issues um, the ones marked here with PR exists are fairly easily uh, addressed. So, for example, issue 96 says valid from, invalid until, might be underspecified. our current current spec just says ISO 8601 but as we know from the DC data model uh it needs to be more constrained than that and Ivon pointed out well this there's no reason for us to uh to redefine we should just point and in that to that effect uh PRs 100 101 and 102 uh do exactly that they specifically just site the uh VC data model definition of the validity
Dmitri_Zagidulin: periods uh instead of redefining them. So uh please review and add your plus ones, minus ones. Dave, go ahead and…
Dave Longley: So, um, before someone else raises it, there's still some, uh, I would consider it some blight in this, in this PR and in our current, wherever this is currently used, we have this or adjacent pointer thing that we need to get cleaned up. I don't think we're going to get it cleaned up in this PR.
Dave Longley: So, I it would be nice for people to hold their nose while we do that, but uh, that really needs to be separated out so that um, like clearly we're we're still doing some kind of cleanup on that. Uh, I've I would expect that this is covered under us redoing that entire data modeling for the whole summary thing.
Dmitri_Zagidulin: Do you think we need a separate issue to clean up or…
Dmitri_Zagidulin: a JSON pointer?
Dmitri_Zagidulin: Okay, we may not in reworking that we may not remember to reach into the valid from and…
Dave Longley: I mean, we're currently reworking that whole thing. I don't think we need yet another issue for that.
Dmitri_Zagidulin: valid until uh JSON schema and remove the or JSON pointer part. I'm just saying uh regardless,…
Dave Longley: Okay. Yeah.
Dmitri_Zagidulin: right? Like that this may be easily lost in the reworking is my point. Uh would you would you like to see would you like to see this removed for example since this is just a description in the JSON schema?
Dave Longley: Yes. So if you want to just delete the last part of that, that that would be fine.
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: Ivon, you you're saying
Ivan_Herman: Yeah. No,… some something different. Um just a warning that we might have to look at the VCDM specification itself for the exact place for valid until buried uh from the problem is and it's even an issue that I haven't Three. as yet I wait for other PRs to be merged before that. But at this moment the definition is such that it it it makes believe that those those properties are only for uh credentials and for nothing else. Ivan Herman:
Ivan_Herman: We have worked Dave and I to change the vocabulary and the the context file to to solve that that PR is still pending to be merged and then we have to look at the document itself. The only thing I'm saying is that the pointers that you have there might change at some point and we have to remember that we may have had to come back and…
Ivan_Herman: change the pointers but yeah.
Dmitri_Zagidulin: Understood. Understood.
Dmitri_Zagidulin: So the the upstream VC data model uh pointers will will get clarified but that doesn't change the fact that we should reference them as opposed to redefined.
Ivan_Herman: So this this has to be merged as it is in this respect.
Dmitri_Zagidulin: Right. Right.
Ivan_Herman: But just warn for ourselves that yeah
Dmitri_Zagidulin: Uh agreed. Uh, anyone else on this on this subject? Uh, go ahead, Patrick.
OCA Bundle Comparison
Patrick_St-Louis: Um yeah so since this is more on the summary uh method uh so one of the thing I'm doing right now um so I closed the OCA bundle uh issue um so we have been you know using OCA bundle and I've been trying to get like an OCA bundle based uh render suite here uh so We're currently uh looking if the summary uh render suite is suitable for the use case where we used OTAA bundle which seems to be the case. Um I'll do like a full comparison to say the specific overlay information that are or are not replicated here.
Patrick_St-Louis: Um, but yeah, I just I just thought I'd mention this uh because it seems sort of related that you're defining things uh in the summary that are kind of duplicating uh VCDM concepts uh and OCA certainly did something similar,…
Patrick_St-Louis: right? like a note issuer name or you know some of these things in this case seems to be valid from valid until um so yeah I just wanted to say this um interested to see where this lands
Dmitri_Zagidulin: Okay, sounds good.
Dmitri_Zagidulin: So, we look forward to uh your thorough comparison to the OCA bundle. Uh-huh. All right. So everybody uh review PR 100 add your comments so we can address it and get it merged. Similarly uh PR 101 also stems from uh an Addison opened issue uh in this case issue 93 uh saying the names and descriptions of the render method suites should be localizable. So this BR
Dmitri_Zagidulin: Just again uh same pattern as the valid from invalid until instead of uh redefining we're we're pointing to the VC data model we're saying uh if there is a name or a description then the value must be either strings or language value objects as defined in the VC data model. So uh that's PR 101 similar thing. Uh please uh give your reviews to it. And lastly, PR102 from this same family. Uh specific.
Dmitri_Zagidulin: So it just so happens that at the moment we have um name and description defined in the top level sweet render method. So these are the common fields and then separately specifically in the summary render method field uh we have name and description uh which are required in this case whereas there's option they're optional in the in the top level. So PR 102 gives the same treatment to the separate definition in the summary render method suite. Uh again changing them to strings or language value objects and referencing the VC data model.
Dmitri_Zagidulin: Uh the question here incidentally is uh to just double check do we feel that the summary object needs it needs a re redefinition of name and description or can we use uh the definitions from the top level render method property. That's question one. Uh do we agree that in a summary these these two are required? And my my uh my leaning is yes because that's exactly what this is for. This is the the card so to speak. Man, go ahead.
Manu_Sporny: I mean they're required but they're um they need to probably be localizable uh values uh like we define elsewhere. Um otherwise you know they're not going to meet internationalization's needs. Mhm.
Dmitri_Zagidulin: That's that's fine. And that's what PR 102 does. Uh I just wanted to double check on the required part. Ivon
Ivan_Herman: The problem is that the name and…
Ivan_Herman: description for the summary object is not the name and description that we have in VCDM. In VCDM, we define well, we reuse a term that we inherit from schema.org or in an RDF environment. The summary object is a pure JSON object which has nothing to do with schema.org or any values that we have defined in the BCBM. There is a there is a very direct difference here. So I am not sure how to handle that without over complicating for people.
Ivan_Herman: Um but the point is the construction for internationalization that we have in VCDM…
Ivan_Herman: which use the at language and at direction is not something that is defined for the summary object because that's not JSON LD.
Dmitri_Zagidulin: right? Uh so I'm I'm glad I'm glad you bring that up and…
Summary Method Localization Approach
Dmitri_Zagidulin: that's that's actually uh one of our next topics uh specifically that the fact that currently summary is JSON uh which means as Addison points out uh in in issue 94 uh as he points out being JSON we don't have a localization story so it's going to bring up to the group of uh do we need to switch it to JSON LD mono you're on the queue
Manu_Sporny: Yeah, I was going to point that out. Um, if if if we keep it separate, um, then I think we hold our nose of and just reuse name and description. Um, if we keep it separate, um, I I am semi- opposed to having JasonLD infect this thing as well.
Manu_Sporny: Um, but I think we can have a discussion around that.
Dmitri_Zagidulin: M you know what's the question that's that's going to come…
Dmitri_Zagidulin: if we don't change it to JSON LD how are we going to handle internationalization Wait.
Manu_Sporny: We're just going to put it's it's easy. We just put u uh language and direction and whatever just like a JSON LD but we strip the at values off there and just that's it. It's it's straightforward. I think you know people are making it seem like a bigger deal than it is but this is a domain specific language that we're defining. Um and we can do whatever we want there.
Dmitri_Zagidulin: So that's totally fine for name and description.
Dmitri_Zagidulin: The problem is uh the rest of the summary fields need to be localizable as well.
Manu_Sporny: Yeah. Yeah,…
Dmitri_Zagidulin: All the field labels.
Manu_Sporny: we do the same thing. Yep. Yeah, we do the same thing there as well.
Dmitri_Zagidulin: O Ivon,…
Manu_Sporny: You know, this is if if we are going to do a DSL here, which is the initial proposal, then that is what we're going to do. If we're going to go to JasonLD, then we're going to hold back have a whole bunch of people complaining about how JasonLD has no place. Uh, uh in this thing, right? So, we're either way we're going to get cranky people. Um,
Dmitri_Zagidulin: you're on the understood mono. Ivon, you're next on the queue.
Ivan_Herman: Uh you might be surprised mommy that…
Ivan_Herman: but I fully agree with you doing JSON LD for this is an overkill sledgehammer or whatever the metaphor you want to use. So we we should use that. Uh you are probably right that the clean cleanest in inverted comma the cleanest way to do that is to reuse the constructions but we should somehow make it clear in the text that we do that or or you know we should not we should not just put it there without any reference to the problem that we are raising. At the minimum, we should put a note somewhere uh which explains exactly what we do that we reuse the construction of JSONLD…
Ivan_Herman: because it's already there but this is not JSON LD be careful or something like
Dmitri_Zagidulin: Uh, all right.
Dmitri_Zagidulin: Benjamin, Patrick, and then Mono.
Benjamin_Young: Yeah, there's a whole lot of work going into not being Jason LB for reasons that aren't really clear other than somebody somewhere might complain who isn't on this call. Um, and I'm I'm curious what technical pain is actually exhibited by like we make a thing that is JSON LD like or… Benjamin Young:
Ivan_Herman: Is there any
Benjamin_Young: is is JSONLDD and it doesn't have a JSON LD context in it and it Yeah, I just I don't I don't Anyway, there's there's a whole lot of weird things being said that aren't technical. So it'd be good to come back to like these are the technical constraints um in the context of we've made verifiable credentials bridge the gap between JSONLDD and not JSONLDLD and it has its own media type and this thing is careening towards getting its own media type and looking a heck of a lot like JSLD without an at context value. So why not just say it is a JSON LD that doesn't have an at context value and then it's extensible because if you don't do that then it's not.
Benjamin_Young: So, I don't really gain…
Benjamin_Young: what I don't understand what the play is other than somebody somewhere is going to see Jason LD and be like, "Oh, gross.
Dmitri_Zagidulin: Uh, Patrick and…
Dmitri_Zagidulin: then Mono.
Patrick_St-Louis: Um yeah very simple. So like um regarding the doca summary comparison like internationalization is like a big feature that is uh critical for credential like all credential in BC needs to be available to rerender to diverse communities uh for inclusion. Um whatever the solution is, I think two things need in the spec like there needs to be clear instructions on how to do it and some very clear examples of how it's to be used. Um you know I I think these would be very important instead of just a small note that kind of says very broadly…
Dmitri_Zagidulin: Mana on. Patrick St-Louis:
Patrick_St-Louis: how to do it. I think there there are some text and examples that would need to be formally included.
Manu_Sporny: Yeah. So, uh concrete technical things. So, so I so Benjamin I am on this call and I am complaining. Uh I think using JSON LD for this is inappropriate uh for these technical reasons. Uh uh we don't need this thing to be extensible. This is not an open world uh data model thing that we're uh talking about. In fact, we don't want this thing to be extensible because we want a processor to take it in and render it without having to worry about all the extra JSONLDLD stuff uh coming in there. So, extensibility is explicitly something we do not want and JSONLDLD would uh uh trigger that uh in a bad way. That's technical reason number one. Technical reason number two is we need array ordering and array ordering really sucks in RDF and JSONLDLD.
Manu_Sporny: Uh so we need array ordering because we need to specify what order in which uh we want these uh fields rendered. Uh yes we can do it through other mechanisms but JSON array ordering is the simplest uh way to do that. Um that's technical reason number two. Technical reason number three uh is is we don't want it to be extensible like it doesn't need it doesn't need extensibility. JSONLDLD uh is overkill which means if we make it a JSONLDD then we are insisting that you have to do JSONLDLD processing on it and for that you need a JSONLDD processor uh way like again overkill we do not need uh that uh technical reason number four this is borderline technical we want other communities to reuse this thing so for example if we created this and in SDJVC ended up reusing it I would see that as a win if
Manu_Sporny: we make it JSONLDLD. They absolutely will not do that because they'll complain that it's JSONLDLD, right? Uh so we want the MDOT community to use it. We want the SD Jot uh VC community to use it. We want the DID or sorry, the the theOM, you know, community use it. We all want all these other communities to use it. And in order to do that, if we use JSONLDLD, they're going to reject it outright uh for, you know, what some of us think are bad reasons. But it doesn't matter. they're going to reject it, right? Versus if we use JSON, there's a chance that they can just reuse at least that component. So I think there are you know solid technical reasons for not using JSONLDLD. Uh and if we cannot address every single one of those technical reasons uh I don't think we should use JSONLDD for that. Um so what's the backup?
Objections to Internationalization Approach
Manu_Sporny: uh we just use the JSON LD style constructions uh because um those will look familiar enough to internationalization to help them understand that we've actually addressed the issue uh without uh pulling in the requirement for a JSON LD processor.
Dmitri_Zagidulin: Thank you, Ivan.
Manu_Sporny: That's it.
Ivan_Herman: Yeah, I answer to Patrick.
Ivan_Herman: Um just to make clear what we would do is referring back to the VCDM which has examples and just all kinds of uh specifications or or more detailed descriptions about how internationalization is done. We would refer back by saying we use the same constructions here. Um and and in a note we could say this doesn't mean that we use JSON or something like that. This is an editorial question.
Ivan_Herman: But but uh what I want to avoid is repeat specifications and repeat examples when we already have it somewhere else.
Dmitri_Zagidulin: pass on to that by the way…
Dmitri_Zagidulin: which is incidentally what these three PRs do. Uh kick it up kick the bucket uh up to the VC core Patrick
Patrick_St-Louis: Uh yeah so my my only concern with this is there's two layers of internationalization needed. There's one which is the credential data itself right. So I want to internationalize a value that's I've asserted as a an issuer. And the second one which is the one that we're looking at is uh we want to internationalize for example if I want to provide a label for a field or a description for a field which is uh specifically appearing in a specific render suite. Right? So uh if I have like a label that says first name and I want to give different labels for different version uh provide these there. So this is different than you know rendering the values of the credential in different language…
Patrick_St-Louis: but it's more about the what the render method adds.
Dmitri_Zagidulin: Wait, ju just just to to be clear.
Dmitri_Zagidulin: So I understand what you're saying that we want to be able to internationalize field labels as well. We get that for free using the summary method.
Patrick_St-Louis: Yes.
Dmitri_Zagidulin: Summary method gives us turns the field labels into values.
Dmitri_Zagidulin: So, but I I hear you that uh it's an important consideration. Uh Ivonia
Ivan_Herman: So the mechanism that we reuse is not bound to name and…
Ivan_Herman: description. It's a generic thing when we want to use internationalization internationalized or internationalizable uh text in some places. So it's only up to us to say these and these keys are internationalizable and we use this mechanism.
Ivan_Herman: So I I don't see there is a difference here.
Dmitri_Zagidulin: understood. Uh well,…
Dmitri_Zagidulin: let's go one step further. Does anybody have any strong objection to this approach? It sounds like we've got at least three plus ones uh to just using the internationalization part of JLD without using the rest. Would anybody strongly object and we are past time? We just wanted to twice. Okay. I'm not hearing any objections right now.
Dmitri_Zagidulin: If you do have them, please put them in the issue. Uh otherwise, that seems like a reasonable way out of this. Thank you all. See you uh next week uh during TAC. Uh I'll be remote myself,…
Ivan_Herman: Okay, bye-bye.
Dmitri_Zagidulin: but hopefully see you on uh on the calls. Thanks all. Meeting ended after 01:09:55 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.