VCWG Render Method

Dmitri_Zagidulin: Hello everyone, welcome. As usual, we're going to give it about another minute for folks to assemble and we'll get started.

Dmitri_Zagidulin: All right. Uh, welcome everyone. It's 3 past the hour. Uh, this is the render method task force of the verifiable credential working group. Uh, we are under W3C code of conduct and uh, IP restriction agreement.

Dmitri_Zagidulin: Uh with the usual implications, this meeting is recorded. Let's dive in. Uh well, before we dive in, I suppose uh are there any uh announcements uh relevant to the group?

European Commission Interest In VC Work

Brent_Zundel: I wanted to share with this group in particular. Um I I don't know how many folks are aware the uh W3C uh staff members have been meeting with European Commission standards folks monthly uh to track the work uh this work in particular but the work of the working group in general.

Brent_Zundel: Um they they ask on a monthly basis how things are going and talk about interest in these topics and I thought folks would like to hear that. So I'm sharing I mean they specifically asked you know…

Dmitri_Zagidulin: that is really interesting and…

Dmitri_Zagidulin: relevant. Thank you. Good to know uh people have eyes on this.

Brent_Zundel: what is the anticipated publishing date of the render method uh recommendations. So I told them we're on track but I didn't tell them much beyond that.

Dmitri_Zagidulin: Excellent. Excellent. That's the spirit. Well, it's slowly annealing to uh to use uh um crystallization and and metallergy uh analogy. It's it's uh slowly jelling. Uh Mona, you're on the queue.

Manu_Sporny: Yeah. I mean, plus one to that. Um, and I guess on that, um, the the bit that isn't quite done is, you know,…

Shipping Render Method Implementations

Manu_Sporny: the the summary, whatever we're calling that thing, right? Um, and I wondered if we were going to spend some time on it today. Just as a as a heads up, we are starting to ship some of this into production.

Dmitri_Zagidulin: Oh, fantastic.

Manu_Sporny: I I know. Well, not not super fantastic, right? because it's always really bad to ship stuff into production um that uh uh is not in CR. Um uh just wanted to give the a heads up. We we're doing it in a way that of course we will like update our implementations and and whatever um as as things progress in this group,…

Manu_Sporny: but we've been kind of holding off for as as long as we can and uh it's starting to escape into the wild um at this point.

Dmitri_Zagidulin: Can you tell us can you tell us more?

Dmitri_Zagidulin: Are you focusing specifically on the uh HTML app? Uh Manu Sporny:

Manu_Sporny: HTML largely. Yes. So largely HTML because we feel like it's in, you know, good enough shape where we can probably uh change. We haven't done the summary thing uh I mean yet because you know who who knows what it's going to turn into. Um but but specifically the HTML one is the one that we're we're starting to uh ship um into production. When I say we, I mean we are working with other organizations that are just don't care. they're not going to wait and they're just going to ship it, right? And so, uh, we don't think, um, uh, we've implemented it in a in a way that is incompatible, uh, with the current, uh, specification. Um, we do expect to have to update it.

Manu_Sporny: Um, I'm just kind of hopefully giving the group enough of a heads up so that we're not surprised when all of a sudden this that's get gets into the wild and we have people going like, "No, we're not going to change it." Right? So, um,…

Dmitri_Zagidulin: Excellent. which means we're going to need uh to make some hard decisions and…

Manu_Sporny: I I certainly feel a sense of like urgency to finalize and and get into CR and am hoping we can do that over the next um, you know, couple of weeks. Um.

Dmitri_Zagidulin: finalize some names. Uh since you and your team are sort of at the forefront of implementing the HTML suite specifically, please uh have have your folks take a look at the the current spec and see how it differs from what you're deploying, right? Like you you're at the forefront. Uh you're probably going to be the the first to run into uh whatever the blockers are with the HTML suite.

Dmitri_Zagidulin: I I suspect others are reaching for the summary and the static first. I know I am. Uh go ahead.

Manu_Sporny: Yeah. And I think that's a question to Benjamin. Uh Benjamin, do you know what we've implemented to date? I think we get we get one more iteration um before this stuff, you know, escapes. I think uh we've we've implemented an older version of the HTML one. I think we can potentially, in a backwards compatible way, you know, go to the new one. Um, and then that's that's kind of going to be it, right? Like if this stretches into next year, I don't think we're going to be able to hold it back um that much longer.

Manu_Sporny: Uh go ahead Benjamin.

Benjamin_Young: Yeah, I don't think the HTML ones are that different between what's been implemented and…

Benjamin_Young: what's in the spec. It hasn't it hasn't changed on either side a whole lot. There might be a couple things to check on. Um the summary card whatever has been too in flux to implement.

Benjamin_Young: So, we don't have anything there done or even in flight, I don't think. I can double check, but um yeah. Yeah, there's no deviation that I'm aware of.

Dmitri_Zagidulin: that that's fine as as long as the HTML one specifically.

Dmitri_Zagidulin: Okay. Fantastic. like you both said uh the summary suite is the one uh that's specifically uh in flux that has annealed the least the static and HTML are fairly stable like we may f we may change a field here and there but they're pretty much doing what uh what we expect right there's only so many ways you can deliver a static payload uh and speaking of which uh the template field has been renamed to payload uh throughout the spec

Dmitri_Zagidulin: Uh similarly with HTML there's only so many ways you can say go fetch that app over there and put it in a uh in an iframe. So that those two I'm comfortable with. So please uh add feedback early and often uh which means we should turn our attention to uh the summary of course to finalize those fields. Again, I'm I'm fairly confident we can agree to some subset uh of fields that everybody can can live with. And then for the rest, that's what we have the non-normative appendices for. Uh so, for example, I'll be adding a non-normative appendix for the our old friend, the mustache template. uh because I do still feel

Dmitri_Zagidulin: that uh the HTML uh the HTML suite is not um is not really well suited for rendering to PDF and that's okay. It's it's for a different thing. Um okay, so uh let's let's look at the the open poll requests. Uh the first one is uh just a sort of housekeeping uh GR91 here. Let's let's do the proper topic thing.

Language Selection For Render Methods

Dmitri_Zagidulin: Uh this one just addresses a uh editorial issue 90 that Ivonne brought up uh and changes the AHF uh links to the uh respspec biblio format. So not nothing exciting but uh what is exciting is adding your plus ones to it so that we can merge it quickly. uh the more interesting PR for discussion is uh I want before we uh dive into a summary in more depth I I want to come back to the previous call discussion about internationalization when we last left off we have this um uh PR draft 89 on language selection. Uh so one

Dmitri_Zagidulin: During the previous call, we went over the internationalization toolkit that we have available that we inherit from JSON D1.1 and uh VC data model. We talked about the language tag, the the direction tag, the um language map from um internationalization section of the VC data model. And we said, okay, so there's three rough categories of internationalization. There is the value level translation. We get that for free for uh with with JSON LD.

Dmitri_Zagidulin: Although there to you need to decide whether you're using the language map uh idiom or not but that's that's cool like we we get that for free. Uh then so that's the first category. Uh the second category or level of internationalization is field label translation. That's the mechanism that several of the competing render method um specifications use.

Dmitri_Zagidulin: they have the uh they have the verifiable credential of some sort and then they have a set of metadata labels and then translations for those labels for the field labels. So here our summary field or sorry our summary suite plays that role. The summary suite combined with the value level translation we easily have the field label translation as well. And then this PR introduces a third level of localization which is not just the values, not just the labels, but the ability to select the layout, the overall render method suite based on the language. So what does that look like? So this PR introduces uh the in language tag uh which it borrows from in language property which it borrows from schema.org.

Dmitri_Zagidulin: That's what uh Google and company uh uses for for their JSON LD in in the pages. So what does that look like? Let's take a look. Um so the example here uses the static render method suite. The overall overall idea here is we need not just uh field or field label level translation. We need to be able to ship different payloads or different uh templates if you will uh or different HTML applications based on the language. So one of the uh for example or the tech demon uh diplomas they have a diploma layout uh with with different um logos and colors and things like that in Spanish and then a different one in in English.

Dmitri_Zagidulin: So the idea being is for the if you need to have a uh multi- language credential first thing you reach for is the offtheshelf VC data model value level translation but in addition to be able to select different layouts to be able to refer to to select different render methods the consuming client can

Dmitri_Zagidulin: dispatch off of the in language tag. And um if you remember the language tag uh if if we look at the W3C internationalization Skype best practices uh is able to filter on language families uh and and um ranges of localization. Right? So it's not just a a single language. There's there's some flexibility here using the um RFC 4647 mechanism. Uh go. So, last did last call. We went over the three levels of

Dmitri_Zagidulin: of localization. Uh we talked about the need for selecting based selecting the render method specifically based on language. Uh and then had just a brief discussion on uh this particular approach. Dave Longley brought up the concern that uh like with the other render methods, the threat model consideration of embedding versus linking uh leads to potential concerns about uh tracking and so on. Right?

Dmitri_Zagidulin: I think the example that Dave brought up was uh if we instead of embedding if we link to a uh an English language payload and a uh a Basque uh language then the host of the of of the static payload can track the relative popularity of of the particular language. So uh does that well let me let me pause here uh questions comments about this mechanism about uh Dave's comment on the uh tracking concern and so

Dmitri_Zagidulin: Dad.

Ted_Thibodeau_Jr: uh as I put into the thread there, um while there is a privacy and possibly other uh kinds of risk in here, um if you request only a specific language, there are 7,000 languages in the world today and getting all of them all the time is not going to be scalable at any sense. So there has to be a balance there as with all of these concerns, a balance between how do we maximize protection from these risks and…

Ted_Thibodeau_Jr: how do we maximize functionality. That's a

Dmitri_Zagidulin: Thanks. Wholly agreed.

Privacy Concerns With Linked Payloads

Dmitri_Zagidulin: Uh Dave, any any more comments? Go ahead.

Dave Longley: Yeah, I just uh I worry that this solution isn't scalable. uh maybe we maybe we accept that but I don't know how large each one of these images is and it seems to me like uh there could be cases where even having one is a pretty significant size burden for a particular BC and then you're looking at well for some use cases maybe we could fit three of these images in here. It just doesn't seem it it seems like we need a different solution to this problem if we really wanted to solve the general case. Uh I think this is going to be like we can make examples that uh have small images with English and… Spanish in them. That's but that doesn't seem well suited uh to be a general solution to the Dave Longley:

Dmitri_Zagidulin: Absolutely. So size of the embedded payload is a huge concern.

Dmitri_Zagidulin: uh like we straight up encountered this in uh for example the mobile app that um dcc back in the day shipped as in it it breaks the JSON renderer sorry JSONLOD parser when and like crashes the app when uh the payload is too large right like mobile device has only so much memory

Dmitri_Zagidulin: memory so needs to be so absolutely the concern is very valid. The thing I want to be very crystal clear about is this is not a concern specifically to the lang to the in language tag or internationalization translation. This is this is a larger concern for the entire render method and we have we either currently address it in the threat model document or if we need to have more language there we'll add more language right uh payloads are too large you're not going to so you can barely going to fit one let alone whatever 27 uh languages for the uh European Union.

Dmitri_Zagidulin: So one way or another, regardless of translation, implementers are going to need to find to to be able to ship uh either small embedded or let's be realistic linked and hashlin uh external payloads, which means caching, which means CDN's, which means all of the other bulk privacy uh protection mechanisms that we have. So the scalability is a very valid concern but not specific to the render method or translation. Go ahead Dave.

Dave Longley: Yeah, I agree. It's not specific uh to uh to language. Uh it just language helps highlight particular privacy privacy concerns. I think uh generally speaking that the spec should uh lean heavily on externalizing all of these resources and then we should focus on how if if they are all externalized how do we ensure that we meet uh privacy considerations.

Dmitri_Zagidulin: I agree.

Dave Longley: I think the embedding is an exception rather than around. I think I think the normal way of doing this is going to be externalizing and there there's more than one way to externalize. uh you can externalize with a link and a and a hash as you said, but we could also externalize with other VCs and that might open up other opportunities so that Uh, You can we can discuss what you can do. You can make some kind of request that's like uh give give me these three VC wages to give yourself some sense of group privacy.

Dave Longley: Uh I don't I don't know if that that's just off the top of my head, but um I if the VC if the external document is a VC, it also gives you the capability for that to be updated because it's carrying a signature and it doesn't have to be bound to the uh to the credential as tightly. So it also allows for fixes to a variety of things. So we I I I I think we need to shift the way that the spec talks about this,…

Dmitri_Zagidulin: Thanks Dave. Okay.

Dave Longley: prioritize externalizing and then we need to make sure that we address the privacy concerns.

Kayode_Ezike: Yeah. Um I'm a bit nervous to say what I'm about to say, but I'm going to just put it out there and see what folks think. Uh so a thought that just came to mind as I was thinking about this is, you know, we talk a lot about content negotiation. I think that's also I guess the the way that the default uh DC VC sort of protocol way of doing it would be. But the thought that came to mind is that you know we have in VCOM this notion of accepted cryptoes, accepted methods, accepted issuers. I wonder if there's room for accepted language and we can play with that a little bit um as a way to do this negotiation such that you don't have to embed all this data up front. You can determine throughout the course of the delivery protocol which one gets selected. Uh and in that case we wouldn't have to solve for it in this spec.

Kayode_Ezike: to just be like maybe some protocols would allow for you to do this and um yeah and that's kind of you can sort of benefit off of that. Uh just throwing it out there. There's probably some challenges to a solution like that…

Kayode_Ezike: but I just wanted to like call out that there could be ways to solve for it in at the protocol layer. That's all.

Dmitri_Zagidulin: Exhale. Man,…

Dmitri_Zagidulin: go ahead.

Manu_Sporny: Yeah, that um a part of that resonated with me. Uh Coyote, you know, like HTTP kind I don't want to say kind of cheats here. Like there's a bit of a punt that happens in HTTP where they're like, well, just accept language and you'll get the resource in the language if it exists and otherwise the server is just going to give you whatever it thinks it should give you. Um and you know in many cases uh that is not actually how so so that that spec gets away with it by saying like oh except language is the way that you do this and you just put in the language and if the server wants to give it to you they they give it to you. What what has actually happened over the last you know 20 30 years is that servers don't actually implement it unless they have a very strong multilingual um uh you know thing and even then they have a language selector on the website itself because sometimes people.

Manu_Sporny: 's browsers are misconfigured uh you know for the default language um or it's a public terminal or whatnot. So we could cheat and basically say you know what externalize everything and use accept language and that is our language solution. Um, and in reality it will probably not work, right? You will just get one language supported. Um, uh, that's the downside there. And, and I would rather not have us cheat on, uh, you know, this this, uh, solution. Um, in language, this this thing, Dimmitri, that you have on the screen, it feels useful, right?

Manu_Sporny: Uh, so my concern Dave is that we're overoptimizing for the privacy use case. I don't know how much we're really leaking by, you know, expressing by by by, you know, putting the language um uh in here. There is a privacy uh leak. I don't know if it's so bad that we shouldn't have the feature in there. Um or…

Dmitri_Zagidulin: also that's the same leak with X batter same exact same

Manu_Sporny: if people are really concerned about the privacy leak, we are like, well, if you don't like this privacy leak, then use the accept uh header and maybe the right thing will happen. Even though we know probably that's not true. Um it happens, does it happen at a different layer? It feels like in some cases it can happen at a different layer. uh to me. Um I do agree in some cases it's the same leak, but I don't know if that's true for all cases. Um the other the other thing that I'm more concerned about is like this is a sledgehammer in language is a sledgehammer, right? It's just like if we're going to use it here and it applies to images, we're going to use it for HTML, which has its own way of doing, you know, language. Um uh and you can have a single HTML document that's multilingual. Um uh and it just works without this tag.

Manu_Sporny: Um, and what I'm most concerned about is the field stuff in the summary. Like I feel like if we don't solve the problem there, this is just like window dressing. So I'm I'm wondering if we need in language and we need the per field stuff and if we focus on those things um maybe we get somewhere. I I think I'm specifically saying uh uh language negotiation uh via accept lang is is the wrong way to do this. We can still say you can do it but like we know that the the the outcomes of that is bad and so designing around that. I'm wondering if everybody else agrees with that or…

Dmitri_Zagidulin: Thanks.

Manu_Sporny: or not. I'm trying to take options off the table so we can narrow down on on what solution we actually want. Good idea.

Dave Longley: Uh, no. don't necessarily agree that the what happened on the web um would necessarily happen with VCs. Uh it's I I think there's a uh different interface when you're on the web that is more well suited to present different language choices and it's right there in in usually on your web page in a place for a user to interact with and you don't that feels like there's a different there's a layer there's a layering change and when we're talking about VCs I would expect

Dave Longley: that the way that you would interact would still be the same. For example, in your digital wallet or in your system, you would be choosing your language on screen. But how do you go fetch that information in that other language? You then make the call with the accept header. And if you're taking that approach, we could also instruct uh renderers that are doing this to take do some kind of additional thing to increase privacy. Uh we can talk about proxies that they could set up. We could talk about having accept language include some random selection of languages that where only one of them is the one that that is of interest um and and things like that to try and help address the externalized privacy problem that we hit.

Dave Longley: I don't think that we should assume that what happen on the web uh widely uh would be the same thing that happens here or that we're even necessarily using the primitives in the same way.

Dmitri_Zagidulin: Thanks Dave.

Accept Language As Mechanism

Dmitri_Zagidulin: I wanted to hop on the queue to agree with pretty much uh what everybody said that yes we have the HD HTTP mechanism of accept language. uh it absolutely has not been widely deployed like Manu said. Uh I agree with Dave that that doesn't mean it won't work this time.

Dmitri_Zagidulin: So my proposal is okay we we add a small section to the considerations that say okay the the two two ways of selecting are embedding the credential linking to the credential and if you're linking to the credential oh sorry if you're linking to the payload then you have this additional mechanism of accept language on the HTTP level uh so we we we can mention the mechanism that it's there and and let the quote unquote market decide. The so far what I'm hearing is uh no real objection to the in language mechanism itself like uh I agree Manu that we need uh the field level and and field label level uh selection in the summary card. So we'll we'll get into that uh shortly.

Dmitri_Zagidulin: But for the for the static and in some ways uh for the summary as Well, I'm I'm hearing no no objection to the in language field itself barring proper threat mitigation.

Dmitri_Zagidulin: Dave, go ahead.

Dave Longley: I still don't know…

Dave Longley: if it's the right way to do it. It doesn't feel like uh it scales. So if if we think of how we would externalize this, we have the two options. Um and I'm not saying we should keep both options, but we've talked about two options, which is a link and a hash or a VC. And if we're talking about it being a VC, then the what's going to happen is you're going to make an HTTP request with some number of languages that includes at least the one you want and other ones you'd be willing to accept and some other random selection, for example. None of that.

Dave Longley: um you're going to get a VC back and then the question is when you get the VC back uh does it carry information about what language it's in or do the HTTP headers respond with and say what language that VC is in or is it both and so this is really about uh self-escribing rather than selection so I and and so we need to figure out where that description happens for uh that says what some what language something is in and I would prefer that to be what this is for rather than using it to make selections and we might already have a mechanism for doing that so that it's not necessary. So if we're going to issue a VC that is a render method VC and…

Dave Longley: a render method VC is going to come with JSONLDD we already have that language. So maybe we're we're inventing something we don't need. And and so I I'm not convinced that we necessarily need this property…

Dmitri_Zagidulin: So what you're proposing is outsourcing language selection completely to the HTTP accept language mechanism.

Dave Longley: if that's the way we're going to tell people to do this.

Dmitri_Zagidulin: Uh to me that puts an undue burden on implementers. If you accept the fact that we do need to select layout specifically based on language saying that accept language is the only mechanism to do that. I I'm not sure I I can agree with that. Mono, you're on the queue.

Manu_Sporny: Yeah, I feel my my concern here is that we're taking I think I'm a pretty strong minus one to using a VC for this, Dave. Um because of the perceived complexity uh there and and the actual complexity there. Like yes, it's true. You're in a VC ecosystem. You should be able to consume any other VC and and operate on it. Um, but that feels like overkill when what we're trying to do is just do some language selection. Um I think I would be strongly opposed to making this into a VC. Um maybe we play around with it and then in version 2.1 or or you know 1.1 or 2.0 we we add that option but at this point it feels it feels like it you know doing that just to get the language stuff is not u useful.

Manu_Sporny: I I think the other way to do this is to just don't put a digest multibase on it. Like do you know for for use cases where someone's like I absolutely 100% need this to to match up with you know I need this protected and it cannot shift. Then you know pick one or one or more default languages and and you're good to go. Like use use an HTML you know render suite and provide multiple language selection in there.

Manu_Sporny: and we tell people to to convey the you know preferred language into the HTML render suite. Um and that's the way that you do that. Um I I feel like there are many other better less complicated uh to explain ways to do this than using a VC. So I think I'm a strong minus one to the VCbased approach. Um and I'm a pretty strong minus one for accept language being the only mechanism.

Manu_Sporny: um uh for doing this selection I think we've got to put it in the data um in some ca in some way right um I think conceptually explaining to someone that like oh it's a render method VC and like we've got to go and define that now in the spec that's a non-trivial amount of you know extra work and discussion that we're going to have to do all in the name of like trying to get the language stuff right right um anyway that the just have some strong reactions to, you know, that that approach. But but I do I I want us to like Dave, like it is hard for me to understand what concrete thing you're proposing. I think you're giving a bunch of plus and like benefits and drawbacks to each one of these things and it's not clear what you're saying. If you're saying like no, we have to, you know, we really should do this as a as a VC, uh, you know, that's that's one thing that we could evaluate.

Manu_Sporny: But right now I it's not clear to me other than like this thing might not scale. Um and to me I'm kind of like yeah well it's a single property and you know it feels fairly straightforward to use in a in a general sense even though it's a sledgehammer and is it going to cause the market to fail? Like no I don't think so. Um and it and if you know it turns out that this VCbased mechanism is a better thing to do like we can do that in the future. Uh but for right now, we're just trying to get, you know, this this thing off the ground versus um anyway, just some thoughts on

Dmitri_Zagidulin: Thanks, Mano. Dave, before we jump to you in the queue, I just want to echo the sort of editorial aspect of this, which is uh the VC approach is a completely new mechanism, which we don't have in the spec yet. So, if you'd if you'd like to see it, then uh make a PR. Let's put it in the agenda. Let's talk. But this close to the CR, we don't even have a sketch of what the VC mechanism looks like. Go ahead.

Dmitri_Zagidulin: Over to you.

Dave Longley: I think we have an issue for it already.

Dave Longley: But um in any case uh something that uh I clearly forgot here is that these are static images. There's no template involved. These are uh the particular example that's on the screen is highly specific to the credential there. It's already processed. There would be nothing to fetch externally in any way that I think could be considered privacy preserving. It would have to be a phone home. So there there is no way to do this use case on the screen um other than having this stuff be directly embedded in the credential. Well, that that's wrong.

Dave Longley: there's there's no with if you make a choice to do this in a static way, there's no way to do it other than embedding it directly in the credential. Um, and we have already seen that that creates lots of problems with that approach if the images reach any significant size. So, I don't know what use case we're solving here. Uh, you you're not going to get a high quality image out of this um that could possibly scale. It might just be a bad uh use case. I'm I'm not it um we can put this in the spec, but I think it might just lead to people creating bad uh experiences and things that create other problems. I don't think we we probably shouldn't even do do this at all. Um I think it's neat to say here's a thing I gave you. It's already pre-processed. It's in your credential. Go ahead and use it.

Dave Longley: Uh but I don't think it will easily it I think we would have to do some kind of negotiation like uh Coyote was saying to for this to be some sensible thing. This is like an image for you for yourself to display uh and that's it and it's going to be in your one language. It's not really um it's not localizable.

Dave Longley: It's specific to the VC is really what this seems like to

Dmitri_Zagidulin: Dave, just to uh clarify,…

Dmitri_Zagidulin: it sounds like your concern is with the static method in general, not not with the language. Like you're saying…

Dmitri_Zagidulin: how high resolution is going to be the image. That's not the point.

Dave Longley: No, just to be clear,…

Dave Longley: it's the mix of the two. It's mixing static with language,… I think, is a problem. If you put those two together, I don't think it works very Dave Longley:

Dmitri_Zagidulin: Mana, go ahead.

Digital Wallet Language Support

Manu_Sporny: uh trying to come at this from a different direction. Um, How do we expect digital wallets to implement multi- language? Uh, I'm guessing just like browsers, digital wallets are going to have a default language for the user. So, the user is going to go be able to go into a settings screen and select their default language and then the digital wallet will change its UI to be in that default language. And my presumption is that default language is then used when any HTTP fetch is done for any resource in a VC. Is that a safe base assumption to make?

Dmitri_Zagidulin: dead.

Dave Longley: Yeah, I think that's a safe assumption to make. Uh noting that this would really have nothing to do with that would be it. It it it doesn't really work with the static method. I mean, you you pick some language and it's and all your VCs aren't in that language. they just don't display like there's no localization aspect. Um you're going to get a one static payload that's attached to your VC or someone might offer you a handful of three uh…

Dmitri_Zagidulin: Man, go ahead.

Dave Longley: if that's not already too large for a given VC. Um, so that that's where my comments are coming

Manu_Sporny: Okay. But but yeah, but going back, we've we've got to write something in the spec. And I'm asserting that we write that that is that is the way internationalization for render methods is expected to work. Your user agent/digital wallet is going to have a language that's set. And when you make requests, and this is probably goes beyond render method, it's any external resource. When you make an a request for an external resource, the through the wallet, the wallet is requesting this stuff. Your default language or language preferences go along with every single one of those requests. Um and the expectation is that the server will give you back uh the appropriate language associated object.

Dmitri_Zagidulin: Benjamin, go ahead.

Benjamin_Young: Yeah, I think…

Benjamin_Young: if we think that wallets are going to do this just in time, that's maybe upside down. That probably what will need to be happening architecturally with these is that the wallets are going to take render methods as they find them and cache the R out of them. um and bringing them all locally and then and then pulling them off of that. Certainly for op obuscating for privacy reasons that that a privacy preserving wallet is going to go fetch all of it. And if it if the wallet itself only supports German and English, then maybe it's only going to ask issuers or whoever's hosting this stuff for German and English. But then it's not it should not I don't think be going out every

Benjamin_Young: time, you know, any of us look at our pull up our wallet and switch to German, it's going to go like, "Hey, let's go get a German render method for this because I didn't think about that earlier." Um, so it mitigates all kinds of privacy risks if we either expect or demand or whatever that wallets do a better job of of loading this stuff if it's remote. Um, which then, you know, moves the need from, yeah, you could get this with content negotiation and maybe you did, but then the wallet locally is going to need to track that language and and do whatever it's doing in its own storage to pick the right render method based on both the user's preference, the state machine of language choice and its UI and whatever the credential set it has on hand.

Benjamin_Young: Um, so I think it it moves the moves the conversation a little bit from just in time retrieval.

Benjamin_Young: Maybe that's it.

Dmitri_Zagidulin: Uh agreed.

Dmitri_Zagidulin: I wanted to hop on the queue to to remind folks what's our goal here with this with this uh random method task force. Our goal is to get to CR is to give implementers tools for core use cases and see which ones they implement and drop the ones they don't. selecting the layout on language is a core use case that that we already have. So unless unless we have a strong like formal objection level against this, we need this field. Go ahead Dave.

Dave Longley: We have a solution for language and localization for images and any other display and that's the HTML render method. Um I don't know that it makes much sense to try and make a less powerful somewhat uh I hesitate to use the word broken but I'm trying to save time. That's just what comes to mind. Somewhat broken version of that with these uh static things that are specific to the VCs. It's like you've made a selection at issuance time and that's what you've got. The end here it is um and it's embedded and it's probably in a lot of cases uh very large. It's there are a lot of significant drawbacks for that and…

Dave Longley: if we're trying to do language and localization everything we have a much better solution uh which is the HTML render method.

Dmitri_Zagidulin: Dave, the HTML renderment method is not a universal solution.

Dmitri_Zagidulin: Don't forget that the image here is just an example. What it's also for is NFC payloads,…

Dmitri_Zagidulin: is pre-rendered PDFs and wave files and anything else. uh use cases.

Dave Longley: Yeah, sorry I did forget to respond to that.

Dave Longley: Um, not all of those are language fields. So if language comes into it, we should consider that to be a significant modifier.

Dmitri_Zagidulin: Mana, you're next on the queue.

Manu_Sporny: Uh yeah, to build off of what Dave's saying with the HTML thing, you know, I'm What could we do that doesn't ship something broken? So Demetri for example in language uh can you have an array like that would you can have an array. Manu Sporny:

Dmitri_Zagidulin: Yes. Yes.

Manu_Sporny: Okay. So, how do you specify uh because that's not in here, right? Um, and what happens when the array has in and then- uk? Like what are you what are you supposed to do? Right? Meaning like this is for a static payload. And so in a static payload, you can't have multiple languages. But what happens if the image actually does have multiple languages in it? Do you see what I'm saying? Like I think that's…

Dmitri_Zagidulin: Wait, hold on.

Manu_Sporny: what Dave's getting getting towards here is that the design space for this is is pretty massive and if we just if we just assert right we do have a technology that is tried and tested and works and that is HTML for everything else we're going to be reinventing the wheel in some in some variation and I don't think we have the expertise in this group to do that right so so for example what we could say is we can make some assertions here the user agent/digital wallet is expected to have some kind of language that is configurable by the individual. Right? That is just a base level. Your agent needs to be able to do that in order to do accept language.

Manu_Sporny: Um if you have that that information needs to be passed through to the HTML render method has to like you you you pass that information through and then it is up to the HTML render method having had the active language passed into it to make a decision on whether or not you're going to render in English or um you know uh French or um uh you know katakana what whatever right so I I think that is a that is a clean solution that solves 80% of the use cases. It doesn't address some of your use cases, Dimmitri, but I'm really concerned that we are trying to redesign internationalization based on a set of use cases that I, you know, I find questionable.

Manu_Sporny: So, so for example, what you know Benjamin put in put in chat, I expect that that is a legitimate way to solve 80% of the use cases where you display just different static images based on the incoming language HTML render method and that is our 10 and when when that fails and we get enough implementation you know field feedback with internationalization involved at that point we can try to fix this static you know um case. Um, so I'm wondering if like you know it's it really is UA sets the language, language gets passed in the HTML render method and that is how we solve 80% of these internationalization uh you know concerns. Um, I don't I'm not saying we have a solution for

Manu_Sporny: the fields,…

Manu_Sporny: you know, that domain specific language thing. Uh, but I'm saying we probably shouldn't do what's on the screen right now. Um, because I don't think I I just don't think that we have the knowledge in the group to to design for this.

Dmitri_Zagidulin: But I want to let's let's be really clear.

Manu_Sporny: That's it.

Dmitri_Zagidulin: Uh first of all that only applies to implementers who are going to implement the HTML render suite which is not going to be all the implementers. Secondly, uh so I just want to be great.

Manu_Sporny: Yeah, it's it's going to be 80% of them is my point.

Dmitri_Zagidulin: What about the 20%? Are we are we going to ship? Okay.

Manu_Sporny: Too bad 10. Yeah, sorry. You It doesn't work for you and 10 because because we there's too high of a chance that we get this wrong…

Dmitri_Zagidulin: So just to be want to be very clear are are either of you formally objecting to the inclusion or…

Manu_Sporny: if we try to try to solve that 20%. strongly objecting.

Dmitri_Zagidulin: not formally but like strongly objecting to the inclusion of the in language.

Manu_Sporny: Yes, Deitri because we need to we need to make progress and I feel like we could debate this endlessly like…

Dmitri_Zagidulin: Okay. Uh,…

Benjamin_Young: Can I Can I weigh?

Dmitri_Zagidulin: please. Uh,…

Manu_Sporny: if we can just like we can come back to it in CR and…

Benjamin_Young: Can I weigh in here?

Manu_Sporny: like try to fix it, right? But like it feels like this is very much an edge case. Um, I know I know you're asserting Dimmitri that it's not, but like we do not see at least our use cases. I don't think we're using static for anything except maybe NFC tab.

Manu_Sporny: That's it.

Dmitri_Zagidulin: go ahead, Benjamin.

Benjamin_Young: Yeah, Manu,…

Benjamin_Young: I think the case you're making assumes that the wallet is going to implement HTML render method.

Dmitri_Zagidulin: No, I don't plan to implement it for any of my wallets.

Benjamin_Young: And Demetri, I wanted to check in to see if that was in the cards for you. Is that right? In which case, Monte, there has to be another layer at which some of this is expressed somewhere. Um and we don't currently like half of us on this call are from the same company. So we don't currently have good visibility into um who is and who isn't doing HTML render method. I agree that functionalitywise HTML is the the super internationalization machinery that it always has been. Um, but it may not be available in the wallet that is on hand and which goes the VT probably needs some way to say this thing over there is in that language which schema.org in language is used lots of places usually next to the URL uh not necessarily the payload.

Benjamin_Young: I don't particularly think it's perfect, but um anyway,…

Dmitri_Zagidulin: Go ahead, man.

Benjamin_Young: I just I don't want to keep assuming that HTML render methods all stuff for people that aren't going to implement HTML render method. That's it.

Manu_Sporny: I think people that don't implement a HTML render method are going to fall behind in the market pretty rapidly. Um, and you know, again, we're you I'm gazing into a crystal ball right now, but like it it has so much use in the use cases that we're looking at and the output looks really good um that I think wallets that decide not to implement it are not going to be able to keep pace. Um, that said, Dimmitri, we may come back to in language in the field stuff like it feels like that might work. I'm I am not as convinced, you know, by Dave what you're saying with respect to like this is going to be broken. Um it's one field, you know, if it's broken, you know, I don't I don't I don't know if it's going to be as catastrophic. Um uh you know, if we put in language in here, I'm just trying to get the group to move, you know, in a in a way through this so that we don't debate this endlessly, you know, for weeks.

Manu_Sporny: So the the approach that I can see is UA sets the language language flows to HTML uh render method that solves 80% of the use cases. Uh let's make that as as a first pass of like how we're going to you know support language. We're going to use accept language uh to to fetch uh you know resources. Um, and then we really do need to talk about the fieldsbased thing. Um, the the the fields thing…

Manu_Sporny: because that's where this is going to appear again in Dimmitri.

Dmitri_Zagidulin: Great. Okay.

Manu_Sporny: The result of that conversation might result in yeah, we need a top level in language there. Um, otherwise we can't we can't address it, right? Um, and if that's the case, then we just put in language back here. Um,

Dmitri_Zagidulin: So then my my request to to Manu and Dave, please uh leave a comment on this PR with with your objection. I want to be able to point that like look we have this simple field to select language digital bazar objected uh in favor of the HTML language…

Dmitri_Zagidulin: which has and then point to how many implementations uh uh it has and so on like I I would like a paper jail for this. Go ahead Benjamin.

Benjamin_Young: Yeah, I think uh just practical feedback on this PR Demetri in in language has to be speced pretty carefully next to…

Benjamin_Young: what it's saying is in that language which you know the the context of what you're saying is the payload is in that language. Um, but one of the flaws of a property that holds a language about another property is that it's you have to tie that together some other place. Um, so it it might be better to specify it in something like related resource for your static use case and say that you know because the whole object inside of a related resource is talking about the remote related resource. So sticking in language in there makes it pretty clearly that you're annotating a remote endpoint. Whereas here it it gets tangled up in like are you talking about the name? Are you talking about the payload? Like what is the thing? Turn.

Benjamin_Young: there there's some practical steps that if you want to make the case for this hanging around um you know I consider it within something like the related resource object that we have on BCDM or um web annotation had a similar remote resource sort of concept where you could like be very discreet about this thing over here is what I'm now uh talking about and all the properties in this this object are about that thing over there um just to make it clearer in when you spec it out. That's it.

Dave Longley: Also want to point out that images can carry metadata for the languages that are in those images. And so that's an alternative. Uh if you want to put uh language information about your image, you can do that there. And that's probably a little more rich. Allows you to potentially talk about uh you have the image in all the cases here. It's in the payload. Uh and so you can you can read that.

Dmitri_Zagidulin: got a Uh when it's remotely linked,…

Dmitri_Zagidulin: you don't have it.

Dave Longley: You can't you can't remotely link. It's of a phone home. You can't do it. So that's what I was saying earlier. Dave Longley:

Dmitri_Zagidulin: Okay. But that's not all images.

Dave Longley: I I missed that that um this use case does not allow externalization of the payload which is I think a scalability problem. It doesn't easily allow uh many different languages to be present because of the size problem. Uh the language information can be present in in the image. It's there's a way to do that already. Um, and…

Dmitri_Zagidulin: First of all,

Dave Longley: that that's probably true, but there not all static payloads carry language, which is also why I am still supportive of the static uh render method. Um, so I don't think there's a localization capability here. It's an announcement that I I happen to have this uh static thing that happens to be in this uh language.

Dave Longley: And then it could and then there's a lot more work to do I think to pass the internationalization working group based on the things Benjamin just said around what that language is actually about whether or not there could be multiple languages and so

Dmitri_Zagidulin: Dave, I feel like uh your comment is is moving us backwards in the sense that you're you're now saying there's no way to do external fetching of payload without phoning home at all for render method.

Dave Longley: You you cannot I so to be clear…

Dmitri_Zagidulin: But realistically that's going to be a core way people are using render method regardless of languages. People are going to be fing

Dave Longley: what you can fetch what you can fetch are group are are resources that are not specific to an individual or that are specific to a a significantly sized group. So that includes templates that and that that includes uh any resource that uh isn't even a template but isn't specific to a particular individual. That's how you avoid the phone home problem. But you can't go fetching some in some resource that is specific to a particular individual. That's what makes it a phone Uh that was confusing to me.

Dmitri_Zagidulin: And so you're drawing the line at fetching a template in a language. as being specific to an individual.

Dave Longley: Uh no fetching a a template that is specific to a language…

Dmitri_Zagidulin: You and…

Dave Longley: if it's also specific to an individ the line is is the fetch for something that's specific to an individual or not.

Dmitri_Zagidulin: No, in this case it wouldn't

Manu_Sporny: that Dave, I'm I'm similarly confused as Dimmitri is on what you've been saying there. It it sounded to me like you were saying uh this entire call that fetching a template with a language was phone home and was a line we didn't want to cross.

Manu_Sporny: That's what I was getting from you this entire hour.

Dave Longley: No, I've I've made I've made two statements.

Dave Longley: One of them is if you're fetching a template in a specific language, there is a privacy consideration there. It's not necessarily a phone home, but if you're fetching something in Navajo, maybe your population only has one person in that speaks Navajo, and that's a problem. But if you're fetching a template, let's let's remove language from it entirely. You're fetching a template that's the same for 100,000 of your users, there's not a problem. It's not a phone home consideration.

Dave Longley: So it it matters how how narrow the scope is for the who the resource is applicable to. If it's open if it's applicable to a wide group, it's totally fine. And if it's not, then it as that group size gets smaller and…

Dave Longley: especially if it hits size one, you have a serious privacy problem. When it hits size one, it's phone home for sure. And that's…

Dmitri_Zagidulin: So, can I ask…

Dave Longley: what we have to avoid.

Dmitri_Zagidulin: what does that have to do with language?

Dmitri_Zagidulin: It sounds like your objection is to the static render speed in general.

Dave Longley: My my my objection is to a static plus language thing that could be exter my objection is to a static VC that could be externalized.

Dave Longley: That's my objection because if the static…

Dave Longley: if the static VC is for that particular individual my read of what's on the on the screen right now is here's a custom static image that is specific to you Dimmitri for your credential. So if you were to externalize that, anyone fetching it would know that's Demetrius. That's the problem.

Dmitri_Zagidulin: So again again so your objection is not for the language it's specifically to the static render method…

Dave Longley: I have I have multiple objections.

Dmitri_Zagidulin: if this was NFC

Dmitri_Zagidulin: See? Okay,…

Dave Longley: I have multiple objections. The one we're talking about right now is externalizing static resources because that's the context and of the questions I was being asked. But I would also I also think there's a problem with uh static language in VCs because I don't think that solves the localization problem. I think you're picking something at issuance time. You're locked to that. And because these are static, you can't externalize them. And so now you got a size problem with your VC. So all of those factors contribute to the various problems I have with what's on screen.

Dmitri_Zagidulin: please open an issue uh objecting to the static render suite uh in in

Dave Longley: I don't object.

Dave Longley: object to the static render speed.

Dmitri_Zagidulin: in the con.

Dmitri_Zagidulin: Uh, all right. We we are at time. Uh, I it sounds like you do because you you were saying it's specific to an individual, which is what static pre-rendered is. It's specific to an individual for all cases,…

Dave Longley: You can embed…

Dmitri_Zagidulin: regardless of language.

Dave Longley: if you embed a static one. It's fine.

Dmitri_Zagidulin: Like we said, embedding is not is going to be prohibitive in most cases. It's going to be too large.

Dave Longley: It will be too large in the language case.

Dave Longley: I don't think that's true for NFC. NFC is already a small payload. It has to be small. It's NFC.

Dmitri_Zagidulin: All right.

Dmitri_Zagidulin: Uh then let us continue this discussion in and especially if we want to make CR progress please I want like I I would like more activity on on these PRs otherwise we're not going to be able to ship. All right. Thanks. Cheers all. Meeting ended after 01:04:07 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.