VCWG VCALM

Welcome And Introductions

Kayode_Ezike: Everyone just wait for a minute or so to get started.

Kayode_Ezike: All right, I think that we can get started here. hello everyone and welcome. Today is June 16, 2026. This is the weekly BCOM task force Happy to have you all here today just before we dive into things a quick note on process keep in mind that we are subject to the disclosure the processes and code of conduct for W3C that folks here should be part of BCWG. You have any questions about that? Let me know. and just reminder that these calls are recorded and transcribed.

Kayode_Ezike: And I think that we are all familiar faces here. No, I do see a new name. I think Rodrigo would like to allow you if you're comfortable to introduce yourself. yeah, just anyone else who

Rodrigo: Yeah for it's not my first time here. I've come sometimes but as I have really a lot of work to do with my master degree and the work I haven't been able to come this much…

Kayode_Ezike: Happy to have you here.

Rodrigo: but I'mma try now to keep a steady pace and come more often.

Kayode_Ezike: There you go. Thank you. and before we dive into agenda, would like to know if there's any, community updates that we should all be aware of from anyone? Go ahead, man.

Community Updates

Manu_Sporny: Semi-related there is the first public working draft for the quantum resistant crypto suites was made today.

Kayode_Ezike: Okay.

Manu_Sporny: So that's good. some of the postquantum work is moving forward. it's of relevance to this group because having quantum security over VCs that are issued is also we announced this oblivious witnessing service on the public credentials mailing list as well which I don't think we need to do anything about it in this group but it is another kind of API I think it could be around verifiable credential life cycle management. So what does it mean to blind witness a credential?

Manu_Sporny: you could blind witness the fact that the credential existed at a certain point in time. so just noting that I don't think we need to talk about it at all in this group…

Manu_Sporny: unless somebody else feels like there's some overlap there. I think that's largely it.

Kayode_Ezike: Great. …

Takeaways From Face-To-Face Meeting

Kayode_Ezike: just going to share my screen really quickly so we can dive into the agenda. So as many of you all are aware we had our annual ECWG 2026 face toface a few weeks ago in Brussels. I was not there myself but was able to attend a few calls including of course the VCOM report out call and that's kind of where I want to start off is kind of just a takeaway from that. I had these slides that I presented but then I had takeaways that I added at the end of them.

Kayode_Ezike: First post slides And there's that. Then also just wanted to brief my check in thing a little bit and was also sort of water discussion pick up on the agenda item I wanted to discuss with the

Manu_Sporny: Hey, Coyote,… Kayode Ezike:

Manu_Sporny: your audio is breaking up really badly. we can hear maybe every other word that you're saying.

Kayode_Ezike: It's going to be to push really quickly. Wow.

Kayode_Ezike: I think actually or is this actually better?

Manu_Sporny: Yes. What do you

Kayode_Ezike: Okay, it turned out I did not mean to add a device to but I know speaker so sorry about that. okay so I guess where I left off is just basically wanted to do a quick update on how that two face to face went from my perspective and also invite others to chime in and then do a quick check in on the threat model. We don't have to spend too much time on that but would be nice to a little bit on some takeaways from the F2L and then just discuss the general path to candidate wreck.

Kayode_Ezike: I know that we have big comments not I'm blaming on the name of TP I believe where want to be by that so discussing that a little bit would be great and then see if we can get through some PRs and categorize some issues there were some issues that I've created both ahead of the face to face but also after face to face based off of this a little bit but also off came from the face to face. So that's generally kind of the plan for today. Anything else that folks would like to touch Great. yeah, feel free to have a chance and everything that we're familiar with. This is basically just an update on but also an update on where we are, status, and such.

Kayode_Ezike: But what I wanted to do and focus on today was just take away some from the call and so the first of them is that when I was delivering or rather on day one so this was before the VCOM call there was a discussion during the threat model call where while man would get a brief overview of BCOM in order to enable the productive of exercises that they were doing with there was a question from Ivon about whether or not why we don't have potential life cycle diagram Bill

Joe Andrieu: Yeah, I thought this was interesting from Ivon. he mentioned this a couple of times and he eventually expounded with a different nuance that I hadn't heard and you haven't reflected here. So I think what one of the things he would like to see is here's a super simple VC that's just trying to say something simple and then show how that gets augmented by all these different task force things right there might be a render method a confidence method and so it feels confusing to him to understand how this all fits together so starting with a VC that…

Kayode_Ezike: Mhm. Right.

Joe Andrieu: then becomes this huge VC is one of the ways he was talking about this credential life cycle diagram which isn't what I thought of when I heard him ask for a diagram

Credential Life Cycle Diagram Discussion

Manu_Sporny: Interesting. I probably heard what you originally heard. Joe, and Coyote, your audio is still kind of dropping out. we can kind of more or less make it out, but just noting what I heard Avon say, Joe, was that we didn't even have the most kind of basic version of a credential life cycle in there. So we keep talking about credential life cycle, but we don't have a, life cycle of a plant or life cycle of a molecule, diagram in the document. I thought that's what he was asking for.

Kayode_Ezike: Okay.

Manu_Sporny: And I think Wes produced sort of something like that. No, was it Someone produced No, Coyote, you produced the life cycle diagram. Sorry. you produced that diagram and I thought it was a good start but it was still missing a couple of things. So there are two p and I agree Joe there could be multiple paths we could take to this one of them is start with a simple credential and then enrich it as it goes through the process. The other one is it possible for us to have kind of like the circular life cycle of pick an animal? or is this more kind of like a branching thing like a decision tree a state floor diagram where, in some states you're going to end up revoking the credenties you're not.

Manu_Sporny: I think one of the things coyote your diagram I don't think it covered was the collection of the data from multiple systems before you issue the credential at all in the back end before you hand it off to delivery right so I think that was one aspect that might not have been there and then I forget if it was Avon or someone maybe it was Bran maybe it was Phil asked for where does the oid4 stuff happen and what's different about what you're doing here and the oid4 stuff. So yeah that diagram coyote that you're sharing right now.

Manu_Sporny: So that kind of has this straight line path whereas maybe we have something that is a little more complicated than that when we enrich it but at the same time I don't think we want to get super complicated with it because it then kind of defeats the purpose of trying to show people here's a typical life cycle of a digital credential. That's it.

Kayode_Ezike: Yes, thank you First of all, is my audio better now?

Manu_Sporny: Yes.

Kayode_Ezike: Okay, sorry about that. yes, agree to what you both Manu and Joel said. I think it became clear that there's multiple different ways that this can be developed and I know that we have a history of these large diagrams that can start to get a little bit complex just because of the nature of what we're trying to tackle in this spec. and so yeah, this was just the first tab. basically the idea here was just to show the different states were stated defined as basically whether or not the or which party most recently received the credential so issuer holder etc. the proof state and then the status state. and then it became clear as I was presenting that obviously there's things like selective disclosure.

Kayode_Ezike: you asked about and things related to packaging a credential like you said mono that is not here and I mean we could add many of these steps as I mean it's kind of arbitrary in a way to do the status one and you can do whatever with that I guess it's just a question of how complex do we want this to be so this would just like I guess I'm keeping this I don't know if we have to figure it all out today I figured this probably could use more discussion but at the

Kayode_Ezike: very least I documented all the feedback that was given during the call here. I believe this captures everything. so I can continue to look into this and invite others to also make comments on this issue too as in terms of ways we can improve it. I know that it seems like there's an appetite to somehow include other specs like you mentioned is somehow showing how render method gets into play. I'm sure we can also show how

Kayode_Ezike: a refresh service, is appended to a credential things like that. So, I'll see if there's a way that I can improve this and maybe even use something different than mermaid if necessary. But this is an open issue that I'm going to continue to refine and invite others to give feedback as they see any other comments on this before we move on? go ahead, Dave.

Dave Longley: Yeah, just a quick comment. The thing I always struggle with, I think these are useful diagrams. but these sorts of diagrams are always insufficient when you go to try and implement anything. it's like, you can't even begin the issuance process until you've gotten some other piece of information from the holder, for example. And that's what you end up having to implement in actual protocols. And so I always struggle with trying to understand who the right audience is for this. And if you are just coming to this ecosystem you're like I want to go implement stuff and you come across I'm going to start with the simple diagrams you immediately get the wrong idea for how you're going to actually write the software you're going to write.

Dave Longley: So, I don't know what to do about that problem, but that is something that just seems to come up all the

Kayode_Ezike: Yeah, I agree.

Kayode_Ezike: And also you reminded me there's one thing as I was creating this that I realized and I'll try to make this my last comment but there was a comment about status about the desire to see status and I had thought about it but the only issue with it is that the way this is modeled like that would require basically having some other entity or sub diagram somewhere else that points to a different service whereas this is focused on who is currently holding the credential and what's the status of the credential and so yeah you're right there It's kind of hard to capture everything, but yeah, I'll probably try to capture or if you can also try to capture that point you made to in this issue. Let me also just post this in this chat here so that folks have it quickly. great. So, I think we have a good understanding of the challenge here.

Simplifying The Specification Text

Kayode_Ezike: The next takeaway from the call was I think this one came from Wes and he's not the first person that I've heard the sentiment for from even before the face to face which is that there's a desire to reduce the complexity of the spec from his perspective he's somebody who's obviously deeply embedded in this stuff and he's implemented a lot of related systems he himself can see how even the technical individual might get tripped up by the way it's laid out. so I think and there actually were some issues that I created even prior to that comment that related to this a little bit. I mean there's some diagrams that I think can be simplified and I think there's generally a need to do a passover of the spec just like to read it all the way through just to have that discipline.

Kayode_Ezike: I'm taking that upon myself to just read through and see this is something that is very vCom coded so to speak that if you're not already sort of primed with certain concepts that you wouldn't really understand. So I think there's a need to do that both for the spec text as well as for the diagrams additionally with the diagrams there are some things that I noticed going through it a few weeks ago that are not entirely up to date or clear and so that's another so this is why I've started to create these and you tell me if it's not useful or not but these sort of longunning issues that I want to make sure that we don't forget certain things

Kayode_Ezike: And so this seem like something that sorry I keep clicking on to the wrong issue but generally what I wanted to do was to make sure that we don't forget certain things for example to fix any issues that I might see in diagrams and I can imagine there can be sub issues that address the different diagrams. So that's kind of the idea that we can maybe create these sub issues if that's useful. But I imagine this being a longunning issue that wouldn't be complete until all the diagrams are complete for example. And the same thing maybe can be applied to the spec text as well. those are my thoughts. Go ahead. Okay.

Manu_Sporny: Yeah, longunning open-ended issues are usually bad because they never get closed, So, this one is I think a good example of we should not have this issue because it'll never close until we're past CR and into wreck. if there are diagrams that need to be refined each one of them should have an issue and ideally the editors just raise PRs to refine the diagrams right so my concern here is that we are at 41 issues now we were down to 27 and our issue list is growing and our PRs per week is dropping you

Manu_Sporny: way that is not good. I know we're going to talk about later, but just pointing out Coyote that I would argue against, issues like this because they just never get closed, so the other one you raised refine credential life cycle diagram, that's fine. to track it and that one's specific enough. the other thought here would it be the end of the world if we shipped 10 with the current credential life cycle diagram? I think we should refine it just to be clear, but it would not be end of the world if we shipped with it, right?

Manu_Sporny: I don't think it would be the end of the world if we shipped with a u a without this life cycle diagram. So I really do think that we need to start making some decisions in and…

Manu_Sporny: what we really need to be focusing on at this point is getting into CR. that's it. and again, this is just, thoughts and I'm not saying,…

Kayode_Ezike: What the f***?

Manu_Sporny: any one of these with a super strong conviction, but, we do have a ticking clock. It is the charter. we need to move this thing towards at least a V1 that is workable. book.

Kayode_Ezike: totally well taken. And when we get to that part of the pile, I definitely would like to sort of discuss what a reasonable timeline looks I again kind of new to this process, but I understand that obviously a very concrete date is the October Type, but obviously we don't want to, push it off to the day before that, right? So it'd be good at that point of the call to discuss what's standard sort of leeway room that we put ahead of that date. and also I would like to visit if appropriate that you mentioned this is the idea you had to basically maybe there's a way we can create tags for the issues that indicate whether it should or should not be included in one things like that. so we can get into that as great. So the next item this is something that came up in a few ways.

Kayode_Ezike: It first came up during the VCOM call and it came up again on the vendor method call created an issue for it as well. But the idea here is that there seems to be a desire for I guess it would be an additional sort of protocol type that would go into the protocols object for a type of credential exchange that involves really not much of an exchange but more of like a remote vendor. so basically the idea is that you would hand over a URL and then a reference maybe an encoding that's included in it. But basically a query parameter in the URL that points to a credential in some way either inline reference.

Kayode_Ezike: This came up I think that Steve Capel was the one who proposed it with strong consensus agreement from Demetri. I think also DS1 Phil believe he also said it works. There's some system that has a similar sort of workflow. So, created an initial issue for that just to track it because I mean in the spirit of kind of being open to use cases and make sure that we cover as much of the useful ones as that it could be cool to include him there. So, I did add that and kind of tagged Steve as well. Not saying it needs to be in one, but it's I think worth tracking at least.

Kayode_Ezike: Considering how much agreement there was there. Go ahead.

Manu_Sporny: And personally I think this is out of scope. but fine for it to be track again when we get to the discussion we need to start labeling some of these things. It's like we do not expect this to happen in 10. So this is like a v1.1 tag would go on this potentially. and…

Manu_Sporny: it may be that this really belongs in render method maybe. I'm not saying again that group should take it on either. but it has way more to do with rendering than API. You think that's

Kayode_Ezike: Okay. …

Kayode_Ezike: And it's unique in a sense that it's not exactly an exchange. Again, it kind of is a little bit aligned more with the two-party model in the sense that I think I would expect the issuer to host that URL. And so there's a unique aspect of it too. Go ahead, Dave. Okay,…

Dave Longley: One way to align it with an exchange is to just set a redirect URL to whatever this other re URL is that they want. And that would even allow you to include a request for other credentials if you wanted to get to that redirect URL. So there are ways and that wouldn't include any new space in this VCOM spec. You could do stuff like that just with primitives that are in the spec today. But I don't know the full use case, but that might be something worth exploring.

Kayode_Ezike: sounds good.

Nate_Otto: plus one maybe or rather I'll say I think this is out of scope. it makes sense more to me in the data model itself of an claim made about a credential by someone else somewhere else. rather than something that I understand so far to be in scope of our APIs. Maybe something in scope for our APIs which seems like a different thing rather than some kind of query parameter. or maybe you're talking about is a render much like a verification endpoint…

Nate_Otto: where it produces some kind of rendered format.

Kayode_Ezike: Okay. it's Great.

Kayode_Ezike: Thanks for that feedback. this last point I think this applies more to everyone than just become I overheard like Manu and Joe's talking about generally a good approach for threat modeling where just only one person sort of creates the foundation of it and others contribute just to reduce the drift and confusion that could come up from that. I don't think it's worth diving too much into that but it was a takeaway that I thought just it's like a water cooler discussion. before we move on any other comments, questions about the face to face any other report outs people. Yeah.

Manu_Sporny: Just on that general point, I mean, I think that the people are Eric and Joe for this group u right they're actively working on the threat model and I think you have a check-in about that later on. So I think this group has that particular one handled. other takeaways from the face toface it was a really good meeting like the verifiable credential working group in the past had incredibly contentious everyone's miserable style meetings that was fairly early on. I think things are settling down more and everyone's a bit more aligned on philosophy.

Manu_Sporny: I think we got a lot of really great new engagement from European union we build the surpass program and these are large scale pilots that are doing digital credentials in the EU and we're very supportive of the work that we're doing largely around supply chain but business wallets and things like that as well. So, I think that was another, good outcome. And then, of course, it was always great to see everyone. the other really, great thing that at least I learned at the meeting was that GS1 is going to be deploying, verifiable credentials in a fairly big way.

Manu_Sporny: it's the use case that they've been talking about for years, but they're at the point where they're deploying it and that's a huge deal because, they're in just about every major country doing commerce and…

Manu_Sporny: trade in the world. so that was another kind of good outcome there. that's it.

Threat Model Updates

Kayode_Ezike: Back to our agenda. so just talk a little bit maybe call it five to seven minutes about the threat model. I know Joe and Eric have been having a running task on that.

Kayode_Ezike: Any updates you care to share?

Eric_Schuh: Sure.

Eric_Schuh: So after the face to face Joe and I had a call last week where we discussed some things. if you look at the image I've posted a refactor of the DFDS that we had. Mostly this was aimed at simplifying the various entities and processes that were shown. So effectively I've removed all of the system coders, the boxes that were to represent the code and the local data stoages.

Eric_Schuh: simply to try to simplify these diagrams a little bit and not have our dictionary take up five or six pages in a document. so, what I'm doing right now, and I've actually been working on this during the call if you want to follow along with what I've been doing, the Google doc, I am now essentially fleshing out the descriptions of the flows. And I'm just about done with the first pass on that. and effectively by the end of today, I think I will be ready to go to possibly APR in terms of just take what's in this document, turn it into add the W3C headers. and we'll have a draft in there.

Eric_Schuh: I did have some questions just for the group in terms of what might be the best way to get feedback on this. once there's a PR, I'm fine working through that. but there is a world where it might be cleaner…

Kayode_Ezike: Sorry. Go ahead.

Eric_Schuh: if people could read through the Google doc and just leave comments or suggestions there. I'm not sure. I don't really have a strong opinion. I'm happy to follow the lead of the group.

Manu_Sporny: So we talked a bit about this at the face-toface Eric and I think at least my suggestion and I feel pretty strongly about this is that somebody takes lead for each spec and puts together what they believe a good baseline threat model should be. and we go from there, I mean, we know that both you and Joe are you guys are very good at this, and I don't think we need to nitpick all of the things that you're doing and working on. how to put put together something cohesive to the group. Let's get it in there in document form and then if people want to comment on it and modify it, great. I do think we should review it, but we should review it after you feel like it's in a cohesive state.

Manu_Sporny: So I'm suggesting that's fine, put everything into a PR, but I don't think we need to take weeks going through the PR and modifying every little bit of language and all that kind of stuff. In fact, I would really like to avoid doing that. and then, you present it as a here it is and then go from what I'm hoping for is that you can get that threat model in there. a couple of us can just review it on a plane flight or a drive or whatever. and say "Yeah, I took a It looks more or less" And then we can kick off horizontal review. Right. So, that's what I'm hoping we can get to.

Manu_Sporny: And what I'm hoping we can avoid is spending the rest of the summer giving you comments on that P,…

Manu_Sporny: that initial PR. so just a suggestion, some thoughts on how to move a bit quicker on the threat model

Kayode_Ezike: Go ahead.

Eric_Schuh: Yeah,…

Eric_Schuh: that all sounds good to me. I think that means my goal will be to have that PR in by the end of today. And I do think that if you're seeing my presentation now, sorry Coyote, I think so effectively what I've been doing is taking each of these DFDs and writing up kind of the detailed description of the flows. So I'm hoping that yourself, Manu or Dave or anyone else on the call that has implemented this could read through here and basically give pretty salient feedback of where the flows are currently wrong. and kind of do most of that in one pass is my hope.

Kayode_Ezike: Yeah. Sure.

Eric_Schuh: Have two or three people read through where things are wrong and need to be updated and then I can do one more iteration. in terms of candidate wreck, I don't know if we could do that before or after kind of that process is done. that's broader considerations. the one other thing I did want to share was one second we did take our list of threats here kind of cleaned up and I had ini generate a structured kind of just textbased list for all the threats including trying to come up with responses.

Eric_Schuh: Joe and I think will probably be going through this afternoon as well. some of the responses seem fine. Some of them probably just need to be removed because AI didn't do the best. but at least this gives us a starting point on responses was my thought. and then it also just fixed up, titling and descriptions and things of that nature. Gave all the threats an ID. so my hope is Joe, however we end up tying this into your respect work, this should be a pretty easy …

Eric_Schuh: format to translate into the JSON files for these threats. so yeah, that was my last thing.

Kayode_Ezike: Thank you,…

Kayode_Ezike: So, I guess pass forward is just to sync with Joe after this and the initial PR that we can review later. Right. Thank you, So, let's move on then. go ahead, man. Sorry.

Manu_Sporny: Yeah, plus one to that. and noting the AILLM usage. I think that's fine clearly as long as that, you guys review it very carefully and the presumption is that that's happening, I also used some of the LLM stuff to eliminate duplicates in so one of the things that we did in some of the groups is we all brainstormed in and then we were starting to painstakingly go through and categorize them as internal threats and external threats and dependency threats and that kind of stuff.

Manu_Sporny: And I had the AI take a quick stab at is this external, dependency. Did a fairly decent job, categorizing it. It was clearly wrong in a number of different ways there. as well as, cross-linking, all that stuff in the document and then refining and eliminating things like what's a duplicate is, three people typed in these things. It would say, this looks like a duplicate.

Manu_Sporny: and then had the human say yeah that's duplicate or no that's not a duplicate so I have found that it is useful to use LLM for some of this but half the time or most of the time you're going to end up spending actually rereading and rereading and rereading again each one because all the threats were split up in the way that it made it a little easier to do that kind of review and just wholesale delete or remove threats that were there. So anyway just acknowledging the usage there and think that's fine as long as there's significant human review going into the cycle. the other thing is group review has to happen on these things. and internally Benjamin's going to love this.

Manu_Sporny: I don't know Benjamin if you suggested that DJ should use Hypothesis to do any markup on spec review…

Benjamin_Young: I did not suggest that he found it on his own.

Manu_Sporny: but it was super helpful and useful. and he totally found it by himself and I was like you do realize that Benjamin actually worked on this.

Benjamin_Young: Fear some blame.

Manu_Sporny: Yeah. No, it was great and it was a really great process. primarily because the threat model has a ton of stuff and commenting on a PR, that's really really big is a pain.

Kayode_Ezike: Okay.

Manu_Sporny: But using hypothesis to do it and hypothesis is basically just like you highlight some text on the screen and you type in some words and it stores that as a comment on the web page that you're looking at. So, it's totally detached from the web page.

Manu_Sporny: It's a plugin that you use totally detached from the web page, but then you can share comments with the original author. So, ic, Joe, we'd be able to while we're just doing a review top to bottom, highlight the bits that we disagree with and you'd have a full list of kind of comments. then again, you could, go in and decide whether or not you're going to reconcile them or not. I'm only suggesting that because it would reduce the amount of work the reviewer has to do. we don't have to raise an issue for every single thing that we find problematic and we don't have to raise a PR for every single thing that we find problematic. We can just highlight these are the things we didn't agree with to the editors and then the editors can decide whether or not they're going to act on that.

Manu_Sporny: Just suggesting that I am definitely going to do that for my review on this and hopefully that'll reduce the load on everyone. that's it.

Kayode_Ezike: I don't know.

Kayode_Ezike: Where's the one second? Eric, go ahead.

Eric_Schuh: Yeah,…

Eric_Schuh: that all sounds good. And I'm happy to use the plugin if that's the way we're doing this. I guess it does sound somewhat similar to me in terms of just staying in the Google doc where people can come through and comment and suggest through there. but I understand being in has its own value. So I guess I'm easy in terms of that. just whatever if I'm the one to make the decision, I'll make a decision, right? But if the group wants to use something, I'm happy to follow lead. I guess my last note on the AI refactoring was that I reviewed so far what it produced in terms of names and descriptions and that all seems pretty good in terms of translating what this group provided when we did the initial threat gathering.

Eric_Schuh: I still have to read through all the generated responses because those are I think more problematic. so yes, we'll be going through all of that. and I'm not sure if there's going to be another time here where, maybe it would be worth taking 15 minutes once I have everything structured for people to come in and add responses in a similar way to the way we added threats. Not sure. I'm open to suggestions there. but we'll have a first pass between Joe and myself. And, while it may not be complete, it'll be in the repo.

Kayode_Ezike: Thank you, Go ahead, jump.

Joe Andrieu: Yeah, I'm just curious about the workflow over here with hypothesis and went to their website. We just create an account over there. Is there a free version that we can all use or…

Joe Andrieu: is it

Manu_Sporny: It's all free.

Manu_Sporny: And at least Benjamin would know better. Just hand it over to you, whatever I did I did was easy to set up and…

Benjamin_Young: Yeah. …

Manu_Sporny: free to Benjamin Young:

Benjamin_Young: So, the accounts are super free. we used to call it the public fire hose but it is more or less an annotation social network on the public facing side of it. They currently sell the education so they can set up a closed space. I don't think we need one at this point. we had put this in a number of specs in the past. not with tight integration just made it available for people to comment on revisions and essentially that's all we would need to do here. there is a browser extension that you can add and use on any web page and you can do it that way too Joe and then you don't have to ask for permission. but there is a JavaScript widget that can be injected into specs or anything really.

Benjamin_Young: And then the hypothesis sidebar just loads. we could potentially set up a group within Hypothesis that's specific to editorial staff. So editorial commentary could stay internal, but we don't do that on GitHub. So I don't know that it would be needed here. happy to answer more questions. the ease might have moved from what I just described, but generally that's how it used to work. Yeah, it's again the

Joe Andrieu: Okay, I'll reach out to you or them. I'm just the getting started isn't getting me started, but I'll take that offline. Fine. We don't as a group need to talk about it.

Benjamin_Young: the public side of things has been reduced and reduced as they focused on selling into education. yeah, let's talk Joe. Just reach out.

Joe Andrieu: Okay, cool. Thanks,

Path To Candidate Recommendation

Kayode_Ezike: Great. Thank you,…

Kayode_Ezike: Thank you, January. Everyone, the contributing network, of course. so what I did as we were discussing this, I decided that it would be useful just to have some ideas of things that we can do to make the path to a little smoother. so just quickly going through them, I think it could be useful potentially to institute an issue freeze. there's been a concern that they've just been ballooning. Obviously, there's no way to do that. I think programmatically on the app, but I think just understanding that could be useful unless it's a critical thing that we know is missing and that it's just incorrect. is Another thought is sort of categorizing issue. not well continues to categorize issues.

Kayode_Ezike: Obviously, there are still a few out there that have not yet been categorized. consider adding a new tag for versioning. U make sure that people are signed in. I think probably the guiding star for all of us would just be agreeing on a timeline for when we want to be just ready to pass it off to CR and just kind of deal with the processes attending to that. those are my general first thoughts. go ahead, man.

Manu_Sporny: Yeah, plus one to all of those. I think those are good ideas and things to do. we can't really freeze issues per W3C process, but we can decide to feature freeze. does it have all the features in it that we think we're going to need for a 10, if so, anytime someone's like, hey, I want a new feature, we're like, no, sorry, one one, right? That doesn't mean that we can't accept new issues into the thing. It's just we'll mark it as a one thing because the group has decided that we feel good about the feature set. and that kind of goes into your second one categorizing issues. We need to decide if we are going to do the issue if we're going to punt it to version 1.1. Right?

Manu_Sporny: So it would help for the meeting coordinators chairs of this task force which would be you coyote and Patrick to go through and just very clearly mark are we doing this during CR or version 1.1. I mean we can go through as a group to do it but it's faster for editors and chairs to just go through and make a quick pass and see if anybody disagrees with their finding.

Manu_Sporny: And then of course the agreeing on the timeline I'll suggest that it would be really nice to make the call to go into CR at TAC and in order to do that we have to be more or less through horizontal review which means that we have to start the horizontal review very soon now right setting a so so I'm suggesting that let's get into CR by TAC that would be great if we can do that. and of course none of this means anything if we don't start getting more PRs in to address issues, So we really need to, shift into a PRs. People need to be submitting PRs and we need to be closing issues that are prec to do that transition. that's it.

Kayode_Ezike: Okay, thank you Manu.

Kayode_Ezike: And remind me again, so if I recall correctly, it's October, I don't remember the exact date, but from Phil recently.

Manu_Sporny: I believe so.

Manu_Sporny: I'll look it up right now.

Kayode_Ezike: So we're going to propose to the current idea proposed by monos to be ready to propose a CR advancement at TAC in October.

Kayode_Ezike: I assume maybe a month or two in advance of that is what we would need is we need to get it out to our review. I don't have a sense of six months. Okay. Okay.

Manu_Sporny: six months.

Manu_Sporny: Yeah. …

Kayode_Ezike: right. got you.

Manu_Sporny: we're already late.

Kayode_Ezike: All right, that's

Manu_Sporny: We are not going to get the hor I will be very surprised if we have our horizontal reviews done before TAC but we can still say we're just waiting on horizontal reviews and as long as soon as the horizontal reviews are in and we've responded to the horizontal reviews we're going in CR but we might get lucky but yeah it can take anywhere from six to nine months to get horizontal review unfortunately. way.

Kayode_Ezike: edit that later. So, that's useful feedback. So, I think then the takeaway for me and I guess Patrick is we have to go through all the issues that's currently There are some that we haven't even opened as a group yet. it has been there for a while because we haven't had a chance to get to them. So, he and I will have to look through those and decide where do we stand on where they should be placed. Maybe we add a new tag. I think I have the permission to do that if appropriate. I'll confirm and can you go offline if not manu and then yes I plus one to the fire hose sort of mentality.

Kayode_Ezike: trying my best to find time to get back into the flow of that I was earlier in the year. So that's definitely I'm taking that upon myself and I'm just automatically assigning to myself. but obviously if folks feel that they want to pick things up as they're available they should just feel free to do and after paying the person that already been assigned to it just to make sure there's no conflict there. yeah, I think generally have a good feel about this. Again, we have currently 41.

Kayode_Ezike: some of these for example there was one I sometimes had to say whenever I create issues because I have the same mindset where I don't want to add too many but there's sometimes for example just a quick example where with the ZCAP stuff right I noticed that there wasn't a way to actually specify the scopes and we have that for OATH we don't have ZCAP but it is important to have a profile otherwise it sort of limits interperability and so it's things like that that come Sometimes they're like, I know you have a lot, but it is important to at least make a nod to it. So, I'll be going through each of these again and just kind of seeing how we can categorize them and if there are any questions, I can sort of ping people in the issue that were created. But yeah, I think we have a good direction.

Kayode_Ezike: We're at 5 to the time. We could potentially go under some PRs that were, I don't know if you want to sneak one or two in, but I'm flexible there.

Kayode_Ezike: Go ahead, Ted. …

Agenda Enhancement Suggestion

Ted_Thibodeau_Jr: I put this in chat earlier,…

Ted_Thibodeau_Jr: but I'll just say it so it's logged. a meta request for the agendas to link to the appropriate listing of PRs or issues or whatever else is going to be discussed. It saves us time and make sure that we actually look at the right page if we're doing prep.

Kayode_Ezike: got So, basically just in the agenda to include the issues that we plan to go through.

Ted_Thibodeau_Jr: Yeah. or if it's going to be, triage, the page that lists the PRs in whatever issu order, orders, sorry, PRs or issues. sort of last touch to newest touched is usually the best…

Ted_Thibodeau_Jr: because it forces churn and gets us through everything on a fairly good basis. Thanks,

Kayode_Ezike: Right. Right.

Merging Pull Request

Kayode_Ezike: That's a good idea. Thank you for that, anything else? Do we want to sneak in one of these? This one has been approved already by a few people. So happy to end early. and Pat's not here. so I mean we do only have considering that pass here, we can leave this for now, but I guess we can maybe sneak this one in from Par has been here for 3 weeks now before we ad so Park, why don't you just quickly remind us this R sport?

Kayode_Ezike: Not sure if you're speaking. Okay. I'm not sorry that happened. Sorry.

Parth_Bhatt: I'm not sure…

Parth_Bhatt: if you're sharing but I think I remember the PR. here is the one 641. yeah. So this PR addresses the issue 640 mainly concerning about fixing all the URLs in the entire changing from W3C CCG to W3C.

Parth_Bhatt: And that is basically all the links I have updated in the entire spec and I have not updated the links in the transition directory…

Parth_Bhatt: which is Ky I think you already confirmed that those should not be changed. So yeah that is it.

Kayode_Ezike: Okay.

Kayode_Ezike: Just kind of quickly. So, I'm comfortable merging this if folks are as well, share my screen. let me do this. If there's no objections to it, or are there any objections to it? Because I can't share my screen now. It looks like there's a lot of consensus. I'll just go ahead and merge it then. looks like we're back. So, you guys can see it now. Right. So, I'll just go ahead and do that. Then have a clean history.

Kayode_Ezike: Hey, have one less PR to worry about. Great. Thank you, Parth for that Appreciate you and we are three minutes ahead of the hour. thank you all for the productive call today. Looking forward to making some good progress on threat models and the path to CR and everything else. cheers. Meeting ended after 00:57:10 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.