VCWG VCALM

Kayode_Ezike's_Presentation: Y I'm good to

Patrick_St-Louis: Were you good to host today? Okay, perfect. Just making sure.

Kayode_Ezike's_Presentation: Hey everyone, just going to wait one more minute before we get started today.

Kayode_Ezike's_Presentation: All right, we are 3 minutes past the hour. Why don't we get started here today? Hello everyone and welcome. My name is Kaio Zik. This is September 22nd, 2026. This is our weekly call verify API for life cycle management task force. we'll be leading you with us through the call today.

Kayode_Ezike's_Presentation: We have a few things to discuss, but before we do so, to remind everybody that these calls are recorded and transcribed and that contributions are limited to folks that are part of the W3C Fair Working Group. And now I just wanted to take a moment to see if we have any community announcements, any updates relevant that people want to share for the VCOM. task force or reintroductions. Go ahead, Manu.

Manu_Sporny: I don't know if it's an announcement, but we probably need to talk about threat model again today. again, just because Joe and Eric are here and we have new information and…

Manu_Sporny: trying to figure out how to do these things, Right.

Kayode_Ezike's_Presentation: Yep, that's the first item highlighted here.

Kayode_Ezike's_Presentation: And you probably have the best language actually explaining that new process and know that you're kind of helping the shepherd the different task force leaders on that. So, yeah, I'll probably call on you to give a brief update there. And outside of that, the only other thing outside of the typical PR issue review that I wanted to give an update on is we do have results from the internationalization group for horizontal review. And so we can discuss that. I already put up two PRs for two of those.

Threat Model Deployment Process

Kayode_Ezike's_Presentation: The third one that is pretty much like what we got from the other specs which related to basically language V of the stuff that we'll be discussing. Anything else from the field before we dive in right so then why don't we get started with the new deployment process. So on the call last week for the ver working group we finally got a resolution or rather we've finally acted on a previous resolution to move forward with the new deployment process for the threat model. So every spec that's under the purview of the active charter is going to have a very particular way to deploy this as notes.

Kayode_Ezike's_Presentation: basically long live notes that can adjust and basically have a particular short name and all that good stuff. wonder if you wanted to shed a bit more light on this process as I know that you've started to work on that.

Manu_Sporny: yes happy to and pre-appies if I sound cranky when I describe this process because I think we have ended up almost exactly where we did not want to end up before. so as a verifiable credential working group basically what wasn't working was multi-chapter publication of a spec and so it was suggested that if we want

Manu_Sporny: a stable spec in space. maybe we can do a blanket approval for the way that we publish threat models. And we got that done and that was Like that that was excellent. and then I went to look at the process and found out that you don't have to do an FPWD at all for a note track. You just publish draft notes or notes and that's it. you don't have to get, approval or anything like that. so that was good. except the RS space publication tooling requires you to basically do an FPWD anyway, which means that you have to publish a stat the editor has to create a static snapshot. They have to do, all the syntax and link checking, which is fine.

Manu_Sporny: And then you have to request that the W3C team publish the static snapshot. and that basically kicks off all the W3C tooling that enables Akidna to work. the problem there is that we will have to do that for every single threat model that we have. So we will have to do that 10 different times. 10 static snapshots 10 u requests to publish the thing we have to set up a kidna and we're basically in the process that we were hoping to not get in which is the next time next working group that comes around we will have to effectively publish 20 FPWD

Manu_Sporny: s for every single point release, that we want to make. it is a very manual human-driven process. and it was what we were trying to avoid and we're very much in that process right now. rather than undo, the things that we have said, I think we're just kind of stuck doing that. and I question the sustainability of, publishing things in this way at W3C. but that's beside the point. where we are right now is that every editor of a specification that's also associated with a threat model is going to have to go through this process.

Manu_Sporny: The thing that makes it difficult I think more difficult is Ivon wants us to batch all these together and publish on the same date which means that all the editors have to synchronize their work schedules to make sure that we pick a target date which means that It's just not We're going to have to pick a date that's a month out and tell all the editors to do that and that's going to delay the threat models being published, for a month.

Manu_Sporny: So that's fine.

Joe Andrieu: So we're sorry to interrupt Manny…

Joe Andrieu: but the confidence method will not be available in that time frame. So

Manu_Sporny: Yeah, that's fine. I don't think there's an expectation there, Joe. I think it's just the Avon's like, " it would be much easier for the web masters to do this in one go."

Manu_Sporny: And I'm kind of like, okay, that means we have to sync six different editors together to all publish on the same date. And why? so we're in that pro So I think we're going to try to get the verifiable credential data model threat model published and set up in Akidna so we know that we've done the process correctly. that should be published this Thursday. And then once Avon and I are sure about, the publication process and the Akidna being set up and the TR space links working and the history working and all that kind of stuff, at that point we'll send an email out to all the editors, give them a date to shoot for, and then as many of those as we can batch together in that date, we publish.

Manu_Sporny: And for the editors that don't make that date, there'll be a second batch and then maybe a third batch to do the publication of the other documents. so I think that's where we are right now with the threat model deployment process. The good news is that once we do the first publication static, it's everything else after that's including I think the transition to a draft to a full-blown note. but it may be that there's more process that's there. So I think that's where we are as of today.

Privacy Review of Recognized Entities

Manu_Sporny: There's some other things that have come in from the privacy review of recognized entities that are a bit problematic and…

Manu_Sporny: troubling that we should probably also discuss because they're going to involve VCOM as well. So, let me stop there.

Kayode_Ezike's_Presentation: All right.

Kayode_Ezike's_Presentation: Thank you for that thorough update, lots to chew on there. Any questions, comments in the group? I guess as far as next steps goes, I guess it's just we'll see what the VC data model looks like and then we'll model it off of that and target whatever consensus date that we agree on for that first batch. Go ahead, Eric. You're on mute.

Eric_Schuh: Sorry, had the old double mute. Mon, I guess I'm just wondering is there any general timeline for that kind of first batch post the VC data model? just so I might have an idea of how long I have. I do want to get another revision of the threat model done mostly just to clean up and…

Kayode_Ezike's_Presentation: Yeah, I had my

Eric_Schuh: fill in some of the gaps currently. but are we looking a couple months? Would just be nice to know.

Manu_Sporny: The VC data model threat model should be published as a first public draft note if there is such a thing this Thursday. So in two days Ivon and I will set up the kid auto publishing over the weekend and confirm that it works and I don't expect us to have any issue doing that and then if that works that means the editor should probably target a publication date of where are we? We're on the 22nd.

Eric_Schuh: Okay, sounds good.

Manu_Sporny: a publication date of October 8th or the 15th and it doesn't have to be done Eric the first draft note it can be just like a hot steaming mess you just have to make sure that all the links work in the hot steaming mess and all that other kind of stuff it doesn't matter what the state of the document is you can just publish it and…

Kayode_Ezike's_Presentation: Yeah.

Manu_Sporny: then akidna will auto publish or any updates that you have to it after we set up the kid auto publishing for it. So all that to say, I wouldn't get you getting a revision on publishing this as a tor

Kayode_Ezike's_Presentation: And I was intending to do that work, Eric, but if you feel like you can take care of it, then that's also fine, too. We can chat offline, though, to coordinate.

Eric_Schuh: Yeah,…

Eric_Schuh: I guess just ping me if you start and I'll ping you if I start and that way we don't

Kayode_Ezike's_Presentation: Great. Thank you. Any other final comments, questions on dirt model before we move on?

Joe Andrieu: Yeah,…

Joe Andrieu: I just had a comment. I know Simone's reaching out to Nick over in Ping and trying to understand sort of what's driving their response. so he's trying to figure out how to make this easier and it is a mess and we just need to work through it.

Kayode_Ezike's_Presentation: appreciate that, Go ahead, money.

Manu_Sporny: Okay, Thank you for that confirmation, Joe, because I was surprised by Nick's response. I was like, "Oh, no. What are we supposed to do now?" I think there were a couple of things if you end up talking with Simone, Joe, Nick, there were a couple of things I noticed about Nick's statements. The first one is he didn't understand that the R1 R2 things were responses because he was like you're just talking about threats you're not even talking about how you respond to them and it's like no we are clearly documenting how you respond to them. so that's point one. I don't think he quite understood that.

Manu_Sporny: Point two is I think Simone in his review of the recognized entities thing was like you need to tie everything in this document back to the main spec. which it is a reasonableish request. the amount of work that it need there. There's some places where you like the response doesn it's like you accept the risk right and in those cases you can't link back to the original spec in some cases I forget which one I think it was for recognized entities Simone is asking for a pretty significant rework of the DFD right and so kind of I thought the DFD was supposed to focus on the things the group felt were important and I

Manu_Sporny: I think you should add these other things to the DFD which would make the DFD way more complex to look at. Doesn't really add much as far as I'm concerned. and then he had certain processes where he was like, "This process is actually four different processes. I want you to break those processes up. Also, you label something in the DFD where you don't talk about it in any of the threats. if you're going to put something in the DFD, you need to mention it in the threats.

Manu_Sporny: And so there are a variety of things there that I think again given infinite time are things that one could work on. But again it would take an enormous amount of time away from actually creating the technology in the first place and it is questionable on whether or not defining all those things and cross-linking to everything actually has a net benefit. In some cases, I think it would make the threat model harder to understand than easier. so those are just general thoughts like there are things that I think Simone wants to see that would be a significant amount of extra effort across multiple threat models.

Manu_Sporny: Nick seems like he's hearing about this for the first time. So that's not good. so getting him on the same page of understanding how we're trying to improve things is the second thing. So Simone's expectations and Nick's expectations are problematic. And the final thing is it is I am thoroughly confused as to what the security and privacy considerations in the main spec and the overlap with the threat model is supposed to be at this time. As you mentioned Joe, I think it's a mess. and I am loathed to spend a bunch of time reorganizing those sections only to hit this, again.

Manu_Sporny: And so I think there's a certain amount of this…

Manu_Sporny: which is kind of above our pay grade not something that we can work on until we've got very concrete guidance from both Singh and Ping. that's it.

Kayode_Ezike's_Presentation: Thanks for contact.

Kayode_Ezike's_Presentation: Go ahead. Joe

Joe Andrieu: Yeah,…

Joe Andrieu: let me go in reverse order and try and address some of this. the first one I guess deserves an apology from me. the intention that Simony and I leaned into around threat modeling being a suitable way to do privacy. apparently Nick is not as on board with that as we had expected. so sorry that we presented that we thought that this would be a way to make both of those sections simpler.

Joe Andrieu: The easiest way to address Nick is to not threat model any of the privacy and just have pros. I think that's a step backwards and I know that Nick has in other context supported threat modeling as a way to think about privacy. So that's why Simone and I were both surprised by that dynamic. But it was an attempt to get ahead of sort of how do we deal with all of this, but Nick is not yet on board with that. So that is a bit frustrating. with regard to the extra effort, I don't find that it's as much of an extra effort as your narrative suggests, manu I think we have been ignoring our responsibilities to make secure software. and so I think there is more work to have a specification that is secure and so I appreciate that it is not work that people are accustomed to.

Joe Andrieu: But I do buy into Simone's vision that a coherent constellation of threat models for web specifications will in fact make the web more secure. So there is more work but I think it's commiserate with the value of having a more secure web. That said, one of the challenges that's happening, it's just a dialectic challenge with the back and forth with Simone on the recognized entity response is there's a difference between, feedback on your qua threat model, and feedback from Singh, for security problems. And so, we had some of this dance also in hosting the web MCP folks in the threat modeling community group and it led to Simone creating their threat model for them.

Joe Andrieu: Because there's a conversation in the threat modeling community group that's hey bring your threat models we will help you make them better it's like an office hours you can get on the agenda bring in your spec we will look at your spec and look at your threat model and we will help you work through it so that you have a better threat model that is my primary engagement with that work is how do we make a good threat model and how do we do it within the context of a specification like these are the hard questions that unfortunately were the VCWG and the did working group and the WebMCP and a few other folks are the guinea pigs to work through this. DC API is also going through this stance. but the security review is not the threat modeling review and I think part of what Simony is asking for in terms of the diagram are the same kinds of things that I've had requests for from the WebMCP folks.

Joe Andrieu: As an example their diagram doesn't have how the user interfaces to deal with escalation of authority. And so I'm like your diagram doesn't have this component in it. So I don't even have a way to highlight the security problem. and they were like that's not us whatever. We had back and forth about it. And I'm like when it comes back around to Sing to get a security review we're going to have the same questions and there's going to be how do you deal with the security of this thing? And then it's Singh making a security considerations feedback and it's not the community group saying hey it'd be a better threat model if you did XYZ but rather the security analysis depends on some information that's not here yet. and so they need information provided just if you had a security consideration section that was waffly on stuff that someone in Sing thought was important and say wait a minute you sort of handwave at this but this isn't good enough.

Joe Andrieu: That's the kind of feedback I would expect from Singh. So I realize there's a conflation between those two and it can just be hard to have the convers both conversations are happening at the same time which is a bit of a challenge. the last thing we actually just talked today about in the community group about this notion of linking back to the spec. and we do need good examples. And so there one of your GitHub comments man it was right on the money can you show us what good is and one of the things that we've picked up to be ready for TAC is a set of examples of good threat models and I don't think any of them out there are good right now. one of the things that they don't do well is link back to the spec and there are places where they can and we just haven't established that as sort of how you do it. specifically, you can say, "Hey, we have a response."

Joe Andrieu: that uses a signature in this manner and the signature can be a link to elsewhere in the spec that defines where that signature happens. so it's within the respect threats architecture.

Joe Andrieu: It's relatively trivial to put in links to elsewhere in the spec. and that doesn't feel like a heavy burden to me to wrap a link in square brackets or an a tag or what have you. So, in terms of the linking between the threat model and the rest of the specification, I think hopefully that's a lighter load than maybe you were imagining and that gets through my list of things I wanted to chime in on.

Kayode_Ezike's_Presentation: Thank you,…

Kayode_Ezike's_Presentation: One more comment from Monu then got to move on.

Manu_Sporny: Yeah, thanks Joe for all that helpful. I guess I mean regardless of me complaining about threat models every single week for the past several months, I do still think it's a better way to do what W3C is doing than the security and privacy consideration section. I do think it, results in better outcomes, which is why it's so frustrating that Nick is pushing back on it. I think he is absolutely wrong. You can do privacy stuff in the threat model. We have done that. We have converted existing security and privacy consideration section entirely into the threat model. It unifies it and it allows us to talk about other types of threats like market threats and things that we typically don't get to talk about which are good.

Manu_Sporny: So I am very no we should unify in the threat modeling thing as a better way to do privacy and security consideration sections which is why I am very very much in favor of getting rid of the privacy and security consideration sections because I don't find them very useful. I find them far less useful than the threat model. and that's why I don't want to keep both of them around. if you want to be all prosy about pontificating about, privacy considerations, I guess that's fine. But the whole reason the threat model is there is for you to identify a threat very clearly and talk about the responses that you have very clearly and you can do that just as well for privacy concerns as well as security concerns as well as market competition concerns.

Manu_Sporny: So hopefully Joe, you're able to convey that to Nick when you talk to him. I'll certainly chat with him at TAC about it. But I think they're doing themselves a great disservice, meaning ping if they, push back on this being a legitimate way to do privacy considerations. on the second point, thank you about the way Simone is responding. It was not clear to me where the comments were coming from. It seemed like the security review has found all of these things that you have to change and I was half of these are editorial and questionable on whether or not the spec would benefit from so it is confusing to know what we need to respond to get to candidate wreck.

Manu_Sporny: clearly I don't think we have to respond to every single editorial issue except one of the editorial issues was linking between the threat model and the main spec right and so it's like is this really editorial or do we have to respond to this or do we have to do all of these things it's confusing as far as responding in contrast to the internationalization review where there were very clear asks and it was easy to respond to and they were responsive to it. So, what needs responded to from a threat modeling community group and a Singh review confusing today as you mentioned Joe.

Manu_Sporny: Finally, I get your point about that we in order to do a good job on the specs, we've kind of been passing the buck for years by writing privacy security consideration sections and threat modeling and doing a very good thorough job at threat modeling makes the spec better. 100% totally agree. I think ITF would disagree heavily, on that. and my concern is that I'm speaking as a vendor right now. Our customers tend to not care about this stuff. is they should care absolutely right. But not even other SDOs's care about this.

Manu_Sporny: ITF doesn't seem to care to the level that the modeling community group cares. and so from a vendor perspective there's a dollar figure that goes into each of our time when we work on threat models. it is a dollar that does not seem to be recouped from the customer caring and paying for this stuff. and I totally get the arguments that hey, what, a massive security compromise, there are untold dollars that are lost there. I get that argument. but there's got to be some way of doing a progression and not requiring perfection in the threat model in the first iteration. And that really feels like what we're trying to push at least the VCWG towards, which is problematic.

Manu_Sporny: So again, this goes back to the question of how much of this stuff do we really need to respond to to at least get into candidate wreck? because right now it doesn't seem like we can get into candidate wreck without making the threat model near perfect, and I know, more than likely Simony Fast would say that's not what I'm asking for." But it's like, there is a serious amount of work that needs to go into this thing to get it to the level that the review is requesting. And there's a questionable return on investment there versus working on issues that are core to the specification.

Manu_Sporny: That's it.

Kayode_Ezike's_Presentation: Thank you,…

Kayode_Ezike's_Presentation: Thank you, you can't tell this is a very contentious topic. Obviously, this is early phases of threat modeling. So, we'll be going through some growing pains. Very receptive to all the concerns voiced by everyone here. And hope hopefully we'll get better guidance as we continue to interface with Simone, Nick, and others in their modeling working group. moving on to our next topic which is reviews. Okay. And we will just be going through the list of PRs.

Reorganization PR Review

Kayode_Ezike's_Presentation: I wanted to first go through Nate's reormalization one because it does feel like it's foundational one that others should be based off of. So, let me just subtopic that really quickly and can prepare to give a brief overview of that. need. Yeah.

Nate_Otto: Thanks. yeah, last time we had a 705 that we discussed and there were a couple extra odd line endings that were sort of partial files that hadn't gotten reormalized. So, this is just a clean pull request that modifies those files. And I did not see the comment about the modification to one of the three files…

Nate_Otto: which happens to be in the transitions folder prior to the meeting today. so there is one line changed in JSON it looks like where there was a different line ending.

Kayode_Ezike's_Presentation: Yeah, it's not a huge deal.

Kayode_Ezike's_Presentation: I was just saying that traditionally we don't change stuff in that folder because it represents a lock state in the past, but for a case like this, I don't think it's too big of a deal. So, I approved it so we've got four green check marks. I know that we wanted to get this in soon. Do we want to give folks time or are we comfortable just merging this in today? As you can see, There's nothing sort of material outside of just changing the CRLF to thing there. So go ahead whoever that is.

Kayode_Ezike's_Presentation: Sorry Mon.

Manu_Sporny: It's purely editorial.

Manu_Sporny: We can merge it.

Kayode_Ezike's_Presentation: Yeah great works for me. Okay we have a clean history here. usually ask me to write something. Guess not this Great. Thanks a lot, te, for putting the time into that. Let's move on to the So, next I wanted to look at Eric's exchange data PR.

Exchange Data Field PR

Kayode_Ezike's_Presentation: I know that I saw a recent comment that you put I think last week. would you want to give us a brief update on this PR?

Kayode_Ezike's_Presentation: Yeah, you had a comment for Dave, too.

Eric_Schuh: Sure.

Eric_Schuh: Yeah. So, a couple weeks ago, we looked at this PR which adds a new field and this new type exchange verifiable presentation that includes the exchange data field. the request a couple weeks ago was that we also need to include so last week I did include a new context file. I'm not confident that this is accurate necessarily. it is the first time I've dealt with context. I did my best. but especially this URL, I'm not sure if that's the proper form.

Eric_Schuh: So it'd be nice if someone that's a little bit more familiar with context could take a look and suggest where I may have gone wrong. or not, I suppose. but yeah, Dave, I do think I pinged you.

Eric_Schuh: It's okay if you obviously haven't had time to take a look at this, but I think as soon as we get this context settled, this should be good to go. Manu, I haven't been able to keep track of the issue that you raised, I believe, on the VC data model,…

Kayode_Ezike's_Presentation: Yes. Yeah,…

Eric_Schuh: tracking this. so I'm not sure if there's anything we need to do to sync up there at the moment.

Kayode_Ezike's_Presentation: that was going to be my next question too. But go ahead Dave first here.

Dave Longley: So, minimally we should put RC1 on the end of the V1 so that this context does not escape into the wild and then make it so we can't make any other changes to it. I'm also not sure if it needs to be aw3id.org term. I think we're looking at I'd have to kind of defer to you, Manu, or if Avon were here, where we want this term to actually land. and it maybe doesn't have to be perfect to get this PR in, but this needs to land somewhere. And I don't know if the context also needs to have some other, name preceding it, that says VCOM. guide.

Manu_Sporny: Yeah. Yeah. It shouldn't be a VCOM URL. I am trying to get to the W3 C name space and it is not giving me anything. right. hold on. unfortunately this is the base URL…

Kayode_Ezike's_Presentation: Right. Go ahead,…

Manu_Sporny: if we want to put it in the verifiable credential data model which we should do vocabulary. We date stamped it. We did the wrong thing. But we're stuck with that forever now.

Kayode_Ezike's_Presentation: Okay,…

Eric_Schuh: Yes.

Eric_Schuh: So just make sure so mono should be that base URL and then after the pound the new term Okay,…

Manu_Sporny: That's correct.

Manu_Sporny: And then you will have to modify that vocabulary. you'll have to put in a pull request to that vocabulary. It's not a big deal if you don't do it at the same time, but we just have to remember to do that.

Eric_Schuh: just going to leave myself a comment on this PR with those instructions. Kayode Ezike's Presentation:

Kayode_Ezike's_Presentation: I'll let you do that and I guess the second part of that comment maybe is something to do with your second point, Eric, which is what do we do about this issue that Manu raised here? it's on the queue for PCWG working group calls. I guess at some point we will need to discuss it. But do we see this as a blocker or is it okay to happen after we do this change to the vocab so I guess that'll be the second part of that comment.

Manu_Sporny: We need to raise an issue somewhere to track it because we will all collectively forget, I'm afraid.

Kayode_Ezike's_Presentation: Eric, if you can also create an issue for that as well.

Eric_Schuh: Sure, I can do that.

Kayode_Ezike's_Presentation: Okay, Thank you, And let's take a look at this swim lane PR that you've put up, Eric, as well. Oops. I might be in the middle of writing something right now, but whenever you get a chance,…

Kayode_Ezike's_Presentation: go ahead.

Manu_Sporny: Sorry. Cody,…

Manu_Sporny: I didn't realize you were pointing to the issue in VC data model that says to do this. So, it's already recorded and we need to do it.

Manu_Sporny: 1649. No, no, no, no.

Kayode_Ezike's_Presentation: I thought you were saying to add a VCOM issue to track that issue.

Kayode_Ezike's_Presentation: Okay.

Manu_Sporny: That's too many issues. I just want to make sure that we're tracking in the VC data model to add it to the vocabulary in the context, which we are.

Swim Lane Examples PR

Kayode_Ezike's_Presentation: Yeah. Great. So, move on to this adding appendix with swim lane examples.

Kayode_Ezike's_Presentation: This was by you, Eric.

Eric_Schuh: Yeah, I can take this one.

Eric_Schuh: So I think it was two weeks ago that we looked at this so this adds I think it's four examples sequence diagrams one for issuing one for verifying and then for presenting a verifiable presentation and one for presenting a verifiable credential in person. so this would be like using a phone and displaying a code. when we last talked about this, Dave, I think you had requested a change to the presentation example because the old one was using a presentation instead of a credential and the expectation is that credentials will be presented in person at least as frequently if not more frequently than presentations.

Eric_Schuh: So the latest update I pushed the presentation of a verifiable presentation in person to be after a new example that is presenting a verifiable credential in person. sorry there's some overloading of presentation terminology there, but as long as the new example fits what Dave was looking for, I think I also cleaned up the old example to make it clearer that it was a verifiable presentation being displayed that in place of a credential. I don't believe there were any other …

Eric_Schuh: content changes requested. So,

Kayode_Ezike's_Presentation: Thank you,…

Kayode_Ezike's_Presentation: Only concern for me is that there's only one reviewer at the moment. So, if folks could please take the time to review this, it would be great. I guess I did give a review two weeks ago. Interesting. I just probably have to take a second look. but thank you, If just get some more eyes on this, that would be great.

Kayode_Ezike's_Presentation: Okay, move on. Shoulder surfing. okay, let's touch back on this. It's already been two weeks since this PR monized that, but you got to give us an update on this one.

Manu_Sporny: I have not been able to do anything with it because I have been busy with other things unfortunately.

Internationalization Horizontal Review

Kayode_Ezike's_Presentation: Don't worry, there's only one reviewer at the moment So, I'm just going to encourage folks to take a look at it when they get a chance. This is just basically adding warnings about how somebody looking over your shoulder if you have a QR code can be problematic as far as threat goes. So, capturing that in a threat. So, just get some eyes on that. and now we're getting to the horizontal review from the internationalization group. So there were three issues which I mean I guess we can call this issue review now technically. So let's go ahead and do that topic issue. All right.

Kayode_Ezike's_Presentation: So, we were able to get some reviews from a Phillips, I forget his name. and basically some of it is familiar. for example, this one over here, which I'll get into soon, which has to do with using localizable text, which we've seen in other specs. Before I get to that one, that's probably the heavier load one. I wanted to touch on two others that there are currently PRs open for. So, the first of this is really light. it's just like an example. Let's put a topic here. And this is just basically an observation from a Phillips that there was the usage of the phrase first name which is not very internationally friendly because it's often a given name that's used in that context.

Kayode_Ezike's_Presentation: And so just like a one or two line change was what was requested here which is reflected in this very basic. So folks get a chance. This is PR 727. And so that was a simple one. And then the next one. sorry issue is this one. 725 topic. this has

Kayode_Ezike's_Presentation: to do with the fact that we are giving a very broad sort of definition of the skate the type for created in presentation when we create one it's just a string I think a phillips is looking for a little bit more detail for example the xsd daytime stamp that's used for all of our daytime strings and so there is a PR that's open for this where I did that and I also added it for the valid from invalid until as well. Some reason I can't find this there it is. Sorry. Yeah. So, pretty much just adds pearls in the description to say, hey, it's not just a string.

Kayode_Ezike's_Presentation: This is actually XSD date time stamp value that we use from invalid and did the same thing for those properties as So these are fairly simple updates thankfully I think to quickly move on to the third one. It's fairly simple or rather it's familiar. I haven't got a chance to dive into it yet, but effectively it sounds like what if Phillips is pointing out is that we need to give language direction metadata for fields that are just open strings, which we don't currently do. the standard that we're adopting across our W3C specs at the moment is these language value object term that apparently was there for a while, but we just weren't really using.

Kayode_Ezike's_Presentation: But there was a point made down here that a little bit uneasy about, which is, potentially creating an international consideration section. It came from a good place. Aphos was saying that if we were to do it everywhere, it might be distracting because it's so many instances of it, I guess, is what he's saying. But I wonder if it's just worth doing that instead of adding a new international edition consideration section. So that's the only thing about this I'm not sure if the other specs had the same decision to make but I don't know if you want to do this. Go ahead.

Manu_Sporny: Yeah, I think this is challenging in a variety of different ways. so it is true we can give this guidance in one place in the spec. That's what the internationalization consideration section is about. plus one to that. we are hitting the same problem again meaning because the API is not JSONLDLD we

Manu_Sporny: don't have a clear multilingual story. And so now we have to decide how we're going to support internationalization with a variety of these fields. Some of them might be in the JSONLD. actually no, this wait a second. Is this only in problem details? how much? Yeah, this is only in problem details.

Kayode_Ezike's_Presentation: All right.

Manu_Sporny: Which is an RFC problem details in I think internationalization they don't talk about internationalization at all.

Manu_Sporny: I think they're basically like you need to negotiate at the HTTP level if you want a particular language and then the server may give that back to you or not. I mean F they sort of do internationalization but not really. and this thing that we're reusing is an ITF specification and I'm looking in that spec and it basically says you can accept language and negotiation might still result in the non-preferred language.

Manu_Sporny: And when you get the thing back, you'll have the language field set. And that's the entirety of how you use problem details.

Kayode_Ezike's_Presentation: …

Kayode_Ezike's_Presentation: I guess should we spell that out in Right.

Manu_Sporny: No, because it would be repeating something that specification says already. I think we say problem details has to be something in the form of RFC 9457.

Kayode_Ezike's_Presentation: Okay.

Manu_Sporny: And so I don't think he might want us to say something to that effect.

Kayode_Ezike's_Presentation: All right. So, it sounds like the response to this just be, this is already covered by the spec that we're referencing, but do I guess we may have to explicitly you're saying no, we shouldn't have to do that. I want to know what's the best way to respond to this and have good confidence that we'll get back a good response. Go ahead Nate.

Nate_Otto: I think Patrick was on the queue before me. Is that still up? Okay.

Kayode_Ezike's_Presentation: That go ahead.

Kayode_Ezike's_Presentation: But you still have a question Patrick Okay,…

Patrick_St-Louis: No, I was just going to pretty much the same thing like defer to the ITF place and…

Patrick_St-Louis: then there's two or three location they talk about localization and they just say to use the HTTP negotiation I think that's good enough.

Kayode_Ezike's_Presentation: thanks Patrick. Go ahead and eat.

Nate_Otto: Yeah, I mean it seems to me like perhaps the HTTP negotiation is an appropriate broader approach to bring into this specification. And I don't think pointing specifically to the problem details spec is going to be very clear here because the problem details is just one property of various different responses that we might give. And there may be some other fields where the language is relevant as well as besides this specific error message.

Nate_Otto: I'm scrolling through some things and not necessarily seeing anything popping out at me. But I would probably minus one just pointing to the problem details RFC directly and would be interested in considering adopting the same mechanism for this specification as well. I do not want to see giant language maps in responses. if the client is looking for a specific language and…

Nate_Otto: I think it could be a reasonable approach to have the client request a particular language and get that language.

Kayode_Ezike's_Presentation: And I mean I should also clarify that we are from my recollection referring to the RFC in the spec.

Kayode_Ezike's_Presentation: I guess it's just a question of is it enough what we're doing now? go ahead.

Manu_Sporny: I agree with Nate that we are going to have to say something in the spec just to make it crystal clear. And by doing that, I think we're effectively going to use the language in RFC 9457 verbatim. because it's only a sentence or two and it's pretty straightforward. so what that means is we can have an internationalization section. We can selecting the default language in there and we can say this is how you negotiate for the language.

Manu_Sporny: I will mention that it does not cover text direction at all and I don't know if that is going to be acceptable to him. That's it.

Kayode_Ezike's_Presentation: …

Kayode_Ezike's_Presentation: you do recommend adding that new section and I guess just having that one entry about problem details in there and calling Got you.

Manu_Sporny: It's not just about problem details. It's about if you want your HTTP API to respond with human language strings of a particular language, you accept language to do it. that's what that section should say. And it just so happens that that's exactly what problem details does as well.

Kayode_Ezike's_Presentation: Thanks. go ahead, Dave.

Dave Longley: I just want to point out I was hoping to find an issue or something to link to but I failed. we've been through this discussion already around problem details because it's already used in other W3C specs. There are already sections that have gone to wreck that use problem details and…

Dave Longley: I imagine we should be able to have our do what those sections are doing. There's nothing new that's happening.

Kayode_Ezike's_Presentation: Yeah, including the VC data model spec by the way.

Dave Longley: Yes, I did put the link to problem details in the 2.0 wreck for BCDN.

Kayode_Ezike's_Presentation: Okay, So, at least I have a path forward with this. It's just going to be I thought I may have to adopt some of the stuff that was done with the other specs. but it looks like this is maybe slightly different. so just add this new section and make a general comment about language and direction metadata and how to handle that which I guess that answers that question generally for the spec.

Kayode_Ezike's_Presentation: Any other questions, comments, concerns about this? So, again, this is the first of our three or three to five reviews. relatively light. so it's good news. We've got four minutes. I don't know if it's worth. There was one issue I thought about getting through for Ben. I don't think Ben is here.

Kayode_Ezike's_Presentation: Me And also I don't think we have enough time So unless there's anything urgent that folks really want to touch on last minute, I can wait a few seconds. Otherwise just close out today. Once twice. So great. So thanks everyone for productive call today. we will see you again next week. And in the meantime, have a great rest of your week. Cheers everyone. Meeting ended after 00:56:07 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.