VCWG VCALM

Patrick_St-Louis: Hey, we're Ron, welcome to call. We'll get started in a minute.

Patrick_St-Louis: Okay, let's get started with today's welcome everyone to the VC API for life cycle management task force call. Today is 15 September 2026. this is a W3C verifiable credential group meeting. So all W3C policies are into effect. this call will be recorded and be mindful of this. If you have any objections, please let us know.

Patrick_St-Louis: In this call we will discuss the life cycle management for verifiable credentials over an API and everything that relates to this when it comes to parties interacting around credential exchange. small agenda today. as usual, we'll give some room if people have a spec special topic they would like to add. so I will let some time for any introductions or reintroductions, any community updates or special topics that people would like to cover before we get into pull request reviews.

Patrick_St-Louis: Yes, mate.

Nate Otto's New Role

Nate_Otto: Hey topic of reintroductions. I just wanted to reintroduce myself because I have a new role. I have joined the digital credentials commons which is a division of strata education foundation and I'm going to be a standards architect and a software developer there. So, I've got even more time on my schedule for the upcoming year or two to focus on standards contribution and…

Nate_Otto: implementation in our open-source JavaScript TypeScript stack that really focuses on verifiable credentials.

Patrick_St-Louis: Congratulations,…

Patrick_St-Louis: Thanks for sharing this. standards. I would assume this goes broader than just W3C. We'll also look at other standardization bodies, correct?

Nate_Otto: Yes, I am also currently the work group chair of the open badges and work group at 1D tech and I'm also contributing to various standards at open and…

Patrick_St-Louis: Thanks a lot for this clarification.

Nate_Otto: open to some other work as

Patrick_St-Louis: This is great. you've been a key participant in this call and this role will I think allow you to keep playing this role and make really relevant contributions here as well as implementation from what I can hear. anyone else has anything they would like to share? So, in this case going to get in PR reviews. I know usually we spend a bit of time talking about threat model and the horizontal review process.

Pull Request Reviews

Patrick_St-Louis: I figured today if there's anything to discuss these should be highlighted in R reviews or someone would have brought it. So we will skip the topic So PR reviews we will go from the oldest to the new one again. I need to get back to these. I've not had the time. but I can see that Eric put in one of them here I think we'll need to spend some time on. it's been open ago, but there's quite a lot of history.

Patrick_St-Louis: But why don't we start with this credential offer which I think the last time we said we might be okay to merge.

Patrick_St-Louis: Just needed to address the comments. would you like to give us an update on the state of this VR? Eric

Eric_Schuh: Sure.

Eric_Schuh: I don't believe I've done anything with it since last week. So, talked about last week is where this stands. and Sorry, I don't remember if I had an outstanding task.

Eric_Schuh: I don't think I did. as far as I'm concerned, this was ready to merge. I guess, need to address comments. yeah, I thought we talked about this last week and said that it was good to go because the comments were nonblocker, but I might be misreme remembering, I suppose.

Patrick_St-Louis: I remember the same thing as you,…

Patrick_St-Louis: Coyote.

Kayode_Ezike: If I recall correctly,…

Kayode_Ezike: there was an the GitHub issue with the spaces or CRF versus LF in this one. Yeah, I think that was the only thing that was blocking it.

Patrick_St-Louis: do you want to expand a little bit that okay and…

Kayode_Ezike: So basically deleting adding every line that issue in GitHub is I believe why we didn't merge it last time.

Patrick_St-Louis: has this been resolved?

Kayode_Ezike: It …

Patrick_St-Louis: Is this a problem? Okay.

Kayode_Ezike: and if I was changed, I'm not sure if it Looks like it's doing the same thing still. it's something we've been trying to fix. I think that's the only reason that was blocked from last week if I recall correctly. But I know we generally try to prevent

Ted_Thibodeau_Jr: Do we know what fix was applied here? Because I thought the solution I posted a bunch of places did the job.

Kayode_Ezike: Could you repeat that?

Ted_Thibodeau_Jr: Yeah, I'm wondering what was attempted to fix and prevent this cuz I thought I had posted the correct solution in various places. Maybe I didn't bring it here yet.

Kayode_Ezike: You did. we implemented that even before that. There was a get attributes file that we added that should have prevented this.

Kayode_Ezike: Apparently it didn't. I So yeah, not really sure what next steps are aside from.

Ted_Thibodeau_Jr: There are two configuration files and…

Ted_Thibodeau_Jr: there's also a command that needs to be run by somebody who's running a local git.

Kayode_Ezike: The editor config one maybe is what you're talking about.

Ted_Thibodeau_Jr: Maybe manual has clue. Yeah.

Kayode_Ezike: Okay. yeah, go ahead.

Git Renormalize Command Fix

Manu_Sporny: Yeah, it's the renormalize command, Coyote. So, Ted, we did put the fix in place in advance of this thing happening. Get changed GitHub changed something yet again that broke things in different ways. but in theory, Coyote, you should be able to get something renormalize a command on your local branch. And in theory, that might work. And then you'd have to do a force push or something like that. You have to go to the commit that broke everything and do a renormalize and that might fix it.

Kayode_Ezike: So should I Okay, I guess I can look into this. Yeah, that's

Manu_Sporny: My I Eric will have to do that from the command line.

Patrick_St-Louis: So…

Patrick_St-Louis: what does Eric has to do?

Manu_Sporny: Something like that. Get Full disclosure, I have not actually ever run this command. get add-malize is the command I think and just

Ted_Thibodeau_Jr: I just put a link to the full details…

Ted_Thibodeau_Jr: which I posted in another thread someplace else.

Patrick_St-Louis: Do you think you'll be able to run this, ic? All right.

Ted_Thibodeau_Jr: It's …

Eric_Schuh: Yeah. …

Eric_Schuh: just to be clear, it's just the terminal command that I should need to run. I don't need to touch any of the git attribute files in theory.

Manu_Sporny: Correct.

Eric_Schuh: Depending on how much I get pulled into other discussion I should have that before the end of this call hopefully but if not shortly after.

Patrick_St-Louis: Perfect. Okay.

Ted_Thibodeau_Jr: note that it's a bit more complex to be sure it does the right thing. I'll just paste into the three steps. It's actually four line commands.

Eric_Schuh: Perfect. I will take a look. Thank you.

Patrick_St-Louis: While Eric is doing this, maybe we can quickly just chat about Manu's R here about threaten mitigation for document code shoulder surfing. so do you want to take us through the…

Manu_Sporny: Yeah.

Patrick_St-Louis: what is happening here ma'am? Yeah.

Threat Model: Shoulder Surfing QR Codes

Manu_Sporny: Happy to. This was actually an issue that Dave Longley noted a while ago. Dave, you're more than welcome to go through this if you want. but I think the general concern here is that when you show so we have these things called interaction URLs in VCOM and it's just a regular HTTPS URL it's just a link to a website and we can encode that website link as a QR code.

Manu_Sporny: And when we put that in a QR code and we put it on screen, what we expect will happen is somebody that has a secondary device, mobile phone, tablet will use their digital wallet to scan the QR code and if it understands interaction URLs, the software understands interaction URLs, it will kick off a VCOM a workflow and a bunch of exchanges and all that kind of stuff. So these QR codes are used to initiate That process can go into a variety of different protocols. it can redirect you to a website. it can do a variety of different things.

Manu_Sporny: But one of the things that could happen that we're concerned about is that it kicks you into a credential pickup flow and it allows the digital wallet to just go through the entire VCOM flow and pick up the credential. and this can be dangerous if, for example, you are on a computer in your library and you're sitting there and you've got somebody behind you also with a digital wallet that is going to shoulder surf over you and take a capture of that QR code.

Manu_Sporny: You can also replay this over the internet if you're screen sharing and somebody could, basically use that QR code to basically pick up your credential, right? that's the attack that we're concerned about. there have been a number of attempted mitigations for this attack. in the open ID protocols there's strong credential wallet binding bouncing the individual back to reauthenticate and that can be there are variety of downsides with doing those things ultimately they don't really solve the problem at hand and so what this is doing is it's documenting the risk it's providing a couple of mitig

Manu_Sporny: ations things that you could do. and one of the things it is suggesting is if you have a super high value credential and you're worried about somebody shoulder surfing, an individual and picking the credential up through that mechanism, don't do the pickup through a QR code. don't do the cross device thing and so on and so forth. so there are other mitigations if you get two pickup attempts within a short time frame just revoke the credential and tell the person to pick it back up again.

Manu_Sporny: you can using the QR code redirect the individual to a website where they have to again just for that purpose reauthenticate and do a same device pickup there are variety of different ways of addressing this but we're trying to suggest one of the ways open ID has decided to do this is just not a good user experience and it doesn't actually address the problem so we're trying to be clear about you how this should be mitigated if you're use going to use a interaction URL QR kit. that's it. Back over to you, Patrick.

Patrick_St-Louis: Yeah, you kind of touched on my question at the end. I was just going to ask exactly in the case of open ID or oid for VCI how is this mitigated? That was my question. or it sounds like it's just the same classic cuz we very often see in demos a QR code initiated exchange that's been kind of one of the main thing that's been done for interrupt demonstration or any kind of these things even with withcom it works in a similar way at least to kickstart the connection.

Patrick_St-Louis: So this is a problem that's apparent across the different technologies. but my specific one was about oid for VCI specifically what is done there? How is it different etc.

Dave Longley: So, some of your options,…

Patrick_St-Louis: Little nave if you wanted. Yeah. Okay.

Dave Longley: yeah, some of your options there are to include an additional PIN code that is displayed on the screen anyway and then enter that into your wallet. But that doesn't solve for shoulder surfing for anyone who could read could enter the same PIN code. because anyone who can see your screens that you're interacting with can do whatever you're doing. So, that doesn't necessarily solve this problem. it might help close some gaps. and then o other options that get a little bit more invasive include redirecting you back to the issuing website where you would be shown an oath style authorization page to authorize your wallet and register your wallet with the issuing website.

Dave Longley: And so you're taken back to a screen which may not result in potential fishing problem if the QR code that you can bring in other threats in this situation that can now become more likely to happen because you're scanning codes. but ignoring that, you go back from your wallet back to the website to authorize the use of your wallet at this issuing place and then you're bounced back to your wallet again. Now all of that also involves potential moving cross device.

Dave Longley: It also means that there's a lot of extra complexity involved in trying to solve this problem, including registering and including issuers having to register and know about your digital wallet, which can create other threats that are linked to in the threat model, including closing up the wallet centralizing the wallet ecosystem, creating barriers in gatekeepers. and then when you're done with all that, it might not necessarily even end up solving your problem. There are other ways that the bad software that could be running on your device that could get access to whatever it is. whether that's get access to authentication cookies that you can use to get into the website so they could get your credentials through some other means.

Dave Longley: whether it's being able to read the traffic that's going across the wire through a variety of different software attacks. And so a lot of these things are hard create other dependencies and other threats and don't necessarily close the gap where the gap that's involved here is mostly don't be picking up a high value credential using screens where people might be looking over your shoulder or recording what you're doing.

Dave Longley: And it's a much simpler fix without all of these additional threats that come into the mix to just not put yourself in that situation or as an issuer offer the ability to get into a same device scenario which mitigates it again not completely but it mitigates the shoulder surfing aspect of it but there still I've got bad software installed on my device and…

Dave Longley: those are other threats.

Patrick_St-Louis: Okay. …

Patrick_St-Louis: yeah, that's really interesting. so the pin code is an interesting one. Reminds me of it's not quite the same quite similar. if you are try to sign in on a website and basically when you use a 2FA application that they ask you to scan the QR code and then enter the pin that the website shows. So it sounds like a very similar process than this.

Patrick_St-Louis: I could see this working in a way that before showing the pin it ask the user to confirm that their wallet has engaged and is asking for a pin and then you reveal it on the screen. So the user would then reveal the pin before their wallet has cut up and if the wallet has cut up it means that they're the one that ingested the invitation. But that could be interesting. Yes, m

Manu_Sporny: Yeah, I was going to mention your first comment. p entering a pin code is a far more complex process than I think a lot of people realize. so for example, when you do Bluetooth pairing and you enter a pin code, that has a very different attack model than someone doing P for a PIN code which has a very different attack model from the thing that you just outlined, so saying we could do a pin code we have to get very deep into the details there.

Manu_Sporny: this response stuff doesn't get into, those details. I guess we could, but I guess that the fundamental point here though with this threat model edition is effectively saying all of the complexity that Open ID has around this stuff doesn't actually work in a wide variety of the cases.

Manu_Sporny: So instead of doing all of that extra, complexity in the protocol and all that kind of stuff, just don't do it, …

Patrick_St-Louis: What's up?

Manu_Sporny: if you have a cross device, you have the capabil the issuer, have the capability of deciding whether or not you're going to do a QR code or not. If you are issuing a passport or a driver's license or some other high-v value credential like that, don't do it cross device using these things, do it same device. So if you create a …

Patrick_St-Louis: Come on.

Manu_Sporny: if you create a scanning that QR code should push the person scanning it into a flow…

Manu_Sporny: where they have to reauthenticate with the issuer website and…

Patrick_St-Louis: What's this?

Manu_Sporny: then do the pickup same device. One other I think I don't know if we should talk about in the threat model is DC API and how that kind of comes into play. I don't think you can use DCPA DC API on a library computer unless you pair your device with the machine. I don't know if that's true, I don't know if Dave. go ahead Nate.

Nate_Otto: I don't know if we want to go into a full discussion right now, but there is a proximity detection is part of the phto handoff. and DC API more or less inherits the same security as pass keys for cross device handoffs. And so the devices do not have to be paired and known to one another but they have to be proximal as part of the transition.

Patrick_St-Louis: I don't

Nate_Otto: And Android and Apple have implemented this differently.

Manu_Sporny: Yeah. Yeah.

Manu_Sporny: So, there is what is it? a black hat conference you've got an antenna in Bluetooth where you could do the attack from across the library if you wanted right so there's all this to kind of say is the QR code process is fraught in a variety of different ways there are a couple of ways to mitigate it and we may want to talk more about if you really really want to use a QR code Here are two ways that are fairly, decent. One of them is redirect the person to the website and have them do it same device. The other one have the individual present a known good strong credential to get the other credential.

Patrick_St-Louis: side of the cards certificate.

Manu_Sporny: I don't know not that a library card is high value but if they're picking up what's a semi highv value credential if they're picking up a credit card so sorry if they're picking up a credit card have them authenticate with a driver's license in the protocol before they pick up the credit card as an example example, So, you can go cross device, but you're not going to end up picking up somebody else's credit card if you have the wrong driver's license. but I don't know. I mean, even those things might be a bit fraught. Anyway, just some background on this PR.

Dave Longley: Yeah, I think one of the main things we wanted to highlight in this PR hopefully we're doing it is some risks if realized can be significant problems but even in those cases some of those risks are really unlikely to be realized and if such a risk is really unlikely to be realized and it can be mitigated by simple user behavior including intuitive user behavior That might be better than trying to build complex solutions to close gaps that are unlikely to happen where the complex solutions create more problems than they're worth. There are a number of these potential solutions that attempt to close the gap, whether or not they successfully do, that can create more harm and more prevalent harm than Give.

Dave Longley: a user were instead instructed to check over their shoulder before they pick up their credential or redirected into a flow it redirect to a same device flow where it matters or an an extra presentation is required during the pickup. All of those things don't change any of the fundamental ways that the existing protocols work. They don't add anything new. they are a difference in the user experience. and that's different from adding additional complexity that can create these gatekeeping, centralization problems, market problems that end up actually harming users much more because they lose their choice in the ecosystem.

Patrick_St-Louis: Yeah, I think this is all interesting, all valid. I like the idea of the same device flow, and the example of scanning a QR code to kind of initiate the same device flow. I'd be interested eventually to discuss exactly how this looked from a workflow templating perspective. it sounds like it would be a redirect URL towards a second workflow kind of situation, at least the way I understand it, where the first QR code would still need to be scanned with a wallet and then the wallet would embed a web view to serve the redirect URL or however this needs to happen.

Patrick_St-Louis: If the intention is that this QR code can be scanned with anything I' again bring up the issue of wallet selection on device which is another thing that has caused a lot of complications with OS behavior when it comes to selecting apps to process something. yeah, these are some of my thoughts I had. as for this PR here, there's still some comments that can be looked at. I'm not getting the sense that maybe we want to merge this right away. I think we just had a lot of discussion.

Patrick_St-Louis: I don't know if the intent was to get this in right now or if we're okay with letting it one more week so we can think about it and maybe make it a thing so that next week once all this has been addressed and we have a clearer idea of the solution we'd like to see mentioned or the proposed solution we'd like to see and the VCOM would be a good thing. quick question use case that R code could be valid. So, I'm going to the office to renew my driver's license, right? I have an appointment. I'm I pick up my little ticket with the number. I'm being called on the kiosk. since this is a controlled environment, there's a person I'm interacting with. they potentially have a device that can show me a QR code.

Patrick_St-Louis: Maybe the device has some kind of protector around it. A bit like how numpads right on the payment terminals they have protector around it. Could that be then a good use case to show a QR code or even then would you see this risk being elevated? yes manu.

Manu_Sporny: Yeah, I put myself on the queue to say it's fine to let this sit another week. but to the question you asked yeah I mean I don't know how likely these shoulder surfing QR code attacks are in real life what's the chances that somebody is picking up their driver's license through a public library computer. that said there are populations where that happens.

Manu_Sporny: And so, in those cases, I think it's good advice. as far as the pin pad protector stuff, yeah, I mean, the other thing that, DMVs, is, I mean, they're all trained in watching out for people that are trying to lift other people's information in the DMV. that's, part of the training of being an employee there, as well as, showing information. And so those devices that they sometimes show on purpose have the screens pointed up instead of towards the lobby or the individual or they're always shown with the person that's standing there. not everyone pays attention to their training.

Manu_Sporny: But even then that use case specifically Patrick if you're renewing your driver's license if they're going to do cross device they might ask you for you to present your old driver's license right and that is something that the attacker wouldn't be able to do and that would allow you to show a QR code and then get it automatically right so that's an example where it's in that case if this is driver's license renewal and they click on driver's license renewal. then they should have their old driver's license in some way either they scan their physical driver's license using their mobile phone or they present their digital driver's license before they pick up the new one. So, all that to say, there are ways of using a QR code safely, and we're just trying to document what some of

Manu_Sporny: those ways are that's

Patrick_St-Louis: Yeah, I think this made sense. As for the question, if this is something you see out there, my gut feeling, it would be probably not right now, but give it a few years when this technology gets knowledgeable, people that do fraud are just going to try to look at ways to do this. Then if they see that people tend to go to the library to request credential it could just become a thing that happen. So I think with new technology risk is low but as these things are used and critical system more the knowledge is making it out there maybe this attack vector could become a bit more something to pay attention to. Dave

Dave Longley: Yeah, other approaches like the one I put in the chat here.

Dave Longley: If you're picking up a driver's license, you might be in a situation…

Patrick_St-Louis: Yeah. Yeah,…

Dave Longley: where that issuer already knows your phone number. You're willing to share your phone number with them. You could have a phone, you could have a link texted to you and to get it onto your device. So, there are other ways to get links onto devices where you can do the pickup. And so there's probably a lot of space for people to experiment with doing secure pickups where they're worried about codes being read off of screens.

Patrick_St-Louis: I agreed. Okay. yeah, this was a good discussion. is there any further comments on this before we're going to leave it open and next week should be in a good place.

Patrick_St-Louis: once these comments have been addressed and we can do a sort of a roundup discussion next week and have it merged in. Any closing thoughts on this topic?

Patrick_St-Louis: Yes, ma'am.

Benjamin_Young: Yeah, I was just thinking through all this.

Benjamin_Young: Is it explicitly tied these attack vectors to the capability Dave saying yes. but we're calling it out in the threat model as the risk I guess oid and…

Patrick_St-Louis: Is capability URL the same as interaction? Okay.

Benjamin_Young: other things don't use capability they require authentication which of course moves things around in different often bad ways. but it is kind of implicit in capability URLs that if somebody gets one that they shouldn't have then bad things can happen by definition of what they are. So, it was great they were calling it out in the threat model, but I didn't know if there was more we could do to protect them or if it's something we should consider modeling for in the future.

Dave Longley: We might want to do a better job of explaining how these URLs are all capability URLs, but this is a layering situation. the fact that other mechanisms have URLs that are not capability They're discoverable just means that anybody can find them and use them. The capability URL means that it's not a discoverable URL. You have to be given the URL to use it. But that doesn't preclude additional protections being used on top of that. It just gives you yet if you don't need additional protections, it's good enough. but it's giving you the capability feature itself is an additional protection above and beyond discoverable URLs. So if we were to draw this as an onion or something, the discoverable URLs have the least amount of they have protection whatsoever.

Dave Longley: Then you can layer capability URLs on top of that and then you can layer additional things like asking for VCs or did off or whatever it is you want inside of the protocol of choice. And so each one of those things can make it more and more challenging for someone to successfully p pass whatever gates you've set up.

Patrick_St-Louis: Very good. Okay, let's try to get to some PRs. not that we're not, but get to the other ones. Eric, I see I didn't quite follow the text.

Patrick_St-Louis: you've been trying to run the commands. is it okay?

Eric_Schuh: Yeah, I ran the commands and…

Eric_Schuh: it ended up changing every single file. It looks like so don't know. I'm not sure where things fell apart, but I think the clean Yeah,…

Patrick_St-Louis: This is not what we want, right?

Eric_Schuh: the cleanest way is maybe for me to just redo this from scratch.

Patrick_St-Louis: Okay. …

Eric_Schuh: I'm not sure unless someone has a better suggestion.

Benjamin_Young: No, I think your plan is right.

Benjamin_Young: I think what it's surfacing is that the line endings were probably inconsistent the whole time and now it's making them consistent. although it does look entire.

Patrick_St-Louis: we're starting to spec over.

Benjamin_Young: So, maybe what was selected was super different. I don't know.

Patrick_St-Louis: That's what's happening at night.

Nate_Otto: There should just be a separate issue open for inconsistent line endings or just a separate PR open that resolves them outside of the context of adding a new feature and then this PR can be rebased on successfully merged line ending fix. It looks like a few files are mixed up. I wasn't able to do adequate research to determine if it was all of them or just three of them initially. seen Maybe it was just three, including the file that the PR renames to exchange verifiable presentation.

Patrick_St-Louis: Is someone able to create this issue?

Nate_Otto: I can do

Patrick_St-Louis: Thank you. Thanks a lot, I'm just going to put in an objection here for good pending fix to let's leave this one then. okay.

Patrick_St-Louis: We got to tackle this one. let's do it. We got a lot of time. So, this is an issue. It's been open three weeks ago. There's been quite some discussion on it. We have probably discussed it before.

Patrick_St-Louis: A lot of it is suggestions. why don't you give us a little status update for this?

Threat Model Translation PR

Eric_Schuh: Yeah. …

Eric_Schuh: since it's been open a while, I'll just give a quick refresher. this, PR is attempting to translate from our old privacy and security consideration sections into the threat model. So I took the existing text of the privacy and consider privacy and security considerations and did my best to translate them into threats with responses to capture these same concepts. ended up with 11 new threats here. I see there's maybe some new comments since I last looked at this earlier today. but I think maybe pending hopefully just some editorial changes that are being suggested there. I don't have any more content here. I believe Coyote has been able to take a pass and did an update. we also resolved kind of the two outstanding sections of the security consideration that weren't transformed into threats.

Eric_Schuh: One of those was added to the conformance section of the main specification as a note and the other was added to the introduction of the threat model itself. so yeah, unless someone has other content revisions that they'd like to see. I think pending I guess looks like there was some duplication. I think that resulted from some weird GitHub behavior at some point, but Coyote, go ahead.

Kayode_Ezike: Yeah, again thanks a lot for your work on this. Yeah, that was one of the issues was that it was duplication for some of the suggestions but also I think one of the bigger ones is that in the latest version of the spec we started to basically outline all the threats in line from the main landing page. So before it was just like we just linked to the external document and now we're outlining it. So that used to be added here. I know we discussed eventually having a solution…

Kayode_Ezike: where we wouldn't have to actually do that ownorous work but now just for consistency we would have to also add that section …

Eric_Schuh: those should already be added.

Eric_Schuh: When we merged your PR which was the threat model revision itself that added those inlines. I did resolve the merge conflicts here and I believe I did add the new threats to that inline list on this PR already.

Kayode_Ezike: interesting. I didn't see that. Okay, I'll have to Maybe I didn't expand it.

Eric_Schuh: Would have been in the main index.html.

Kayode_Ezike: Maybe that's what it was that case. Never mind. the only other thing I'll give a comment about it. first let's just look at what Patrick's looking at. Yeah. Anyways, the only other thing that I was going to say, there's one of I think T38. Yeah. Mish handle status. If you click on that one, there was one comment I left there. I don't see the comment anymore. But basically, this was one of the ones that I felt was a little confusing and I think the new language you have there is better, but the import of the actual threat is not what I I thought it was a privacy concern. It sounds to be more like a denial of service.

Kayode_Ezike: For example, basically whenever you delete a credential and you also delete the status entries for that credential, what happens in the verification flow? And it's a similar that I think threat T7 is not in this PR, but it's a similar thing where if the status service is down what do you do? So it's a similar flavor to that. That's more of like a denial of service attack. I left the suggestion for that earlier but I don't see here anymore. Basically that would change that taxonomy class and that can be added but also would change both the name of the threat as well as the file name which is important because it want derived from the other and in the actual render rendering but that's the only other thing that I think stood out and…

Kayode_Ezike: I can I guess just read the comments that I added earlier. I'm not sure what happened to them, but go ahead.

Eric_Schuh: Yeah.

Eric_Schuh: That sounds good. So I guess in my head the only thing left is it looks like there was some duplication so that needs to be resolved. that coyotes pointed out And then Coyot if you could get your suggestions, I guess, back in from whatever happened. I'll go through those and, ping you again, Coyote, for a final review. And hopefully we can get this merged maybe before next week's call if, no one else has any content changes.

Eric_Schuh: it's kind of just been out there for a few weeks and we have other people pushing threat model updates that are somewhat dependent on the threat indices. and since the tooling doesn't handle the reumbering of the threats automatically as of yet, it's going to cause more headaches the longer we leave this u languishing. So, …

Eric_Schuh: yeah, Coyote, I'll keep an eye out for your suggestions and try to follow you quickly, to get the last few changes in.

Kayode_Ezike: Great. Thanks a lot.

Kayode_Ezike: And I did notice that you added the inline outlining.'m about that. So, thanks for that.

Eric_Schuh: Yep, no worries.

Patrick_St-Louis: Okay. yeah. Okay. …

Patrick_St-Louis: just need to Yes, man.

Manu_Sporny: U plus I wanted to merging this as soon as possible…

Manu_Sporny: but because we're talking about threat models I had a question given that both I thought Joe and Eric are here but I wanted to wait until we move on to the next topic.

Patrick_St-Louis: Yeah, all I was going to say is yeah, so there's just some rebates needed address the last comments and we'll get this merge as soon as possible. There's something failing with the CI here. Not too sure. Maybe I'll look at that. I'm not sure you did you want to just talk about something or was it related to another PR?

Security Review Of Recognized Entities

Manu_Sporny: It was related to what Eric said and it does involve this PR but this is not to say that we should modify this PR in any way before merging it other than what we've already t talked about. I wanted to talk about so we got a security review on one of the VC data model the recognized entity specs and there is some guidance in there Joe Eric that I'm curious to hear your take on so specifically let me just do a new topic and provide a link to this commentary this is the security review that was done on recognized entities. and it is a significant amount of feedback. I don't know if Simone spent this much time doing this or this was AI assisted.

Manu_Sporny: But in one of the things he basically says that we need to put the security and privacy considerations back, make it show up in the appendex, and then put the thread model in that single section. he did note this is an editorial suggestion. I don't know how much of a suggestion is. It seems like he's got some pattern in his head on potentially something that the threat modeling group has decided on and it would require us to redo all of our kind of references the way we're referencing the threat model in across all the specs. So Joe, do you know what's going on here? Is this like a new Yeah,…

Joe Andrieu: Which section in the comment are you referring to?

Manu_Sporny: Let me grab the screen real quick.

Manu_Sporny: So this section title and purpose thing where we have this boilerplate language where we're like hey W3C is moving to a holistic threat modeling approach here are the threat models here's the high level sections threats identified in the threat model and brief descriptions of them and then in the security and privacy consideration section We're like, "Hey, you should take a look at the threat model because that's where we talk about security and privacy considerations now." but Simone is asking us to put it back. and so I don't know what to do here because if we have to do this for recognized entities, we're going to have to do it for VCOM and all the other specs.

Manu_Sporny: So do you have any insight into why he's asking us to put this back they're just not No,…

Joe Andrieu: I'm pulling up the version that he's commenting on.

Joe Andrieu: I think so I was a little confused when you introduced it about the appendix and not the appendix. So right now the threat model is in the appendix but there is no security and privacy consideration sections right

Manu_Sporny: they're not put in the table of contents, So, you can go to them. We had to put those anchors in there because the, security and privacy review documents haven't been updated and they asked for them. So, I created them. So, if you go there, you can see here there's security security and privacy considerations, but we say hey, you should look at the threat model. And then you click here and that takes you to the threat model thing.

Manu_Sporny: and that describes …

Joe Andrieu: Yep.

Manu_Sporny: what this thing is. it points to other documents security and privacy or threat models you should take a look at and then it goes into highle descriptions of target implementation threats and stuff like that. And I think he's saying put it back. combine security and privacy into one section. and then dump this text into it. I'm pretty sure I disagree strongly with that approach.

Manu_Sporny: Because it doesn't use the old format, It's yet another new thing. and then it kind of buries the threat model in something called security and privacy considerations.

Joe Andrieu: So, one thing I know,…

Joe Andrieu: not because I've talked to him about this particular feedback, I specifically said, " don't talk to me about it, Simone. I want your input as a security guy independent of me as a threat modeling guy because I'm too close to the data. So I have not spoken with him about this in detail. But the process does require the security considerations and privacy considerations. and I think they should be in the table of contents because I think people do use a table of contents to jump to those sections. so I agree with them that was a minor error, to make those no talk for whatever reason.

Joe Andrieu: The sense that I had of how a group might navigate this is that in the security considerations and privacy consideration section and it's interesting that he proposes merging them together that I really don't have an opinion about whether or not they're merged but we do need sections and in those sections to introduce the threat model and what it means to introduce I think is an open issue. and so I don't think there's clear guidance there. One of the things we've talked about and that respspec threats tried to provide as a mechanism but I think it's only halfway there given how I've seen you use it I think in maybe a version of this where you had an alternate table of contents that had a little bit more detail in it. as opposed to the talk that was just the name and the tag.

Joe Andrieu: So you could put a talk in here, a table of contents, for the security related threats, right in the security consideration section. which is then linking to the actual threat model that has a detailed discussion of those threats. and how much information you put in the security consideration section is to my view an editor's choice. how do we want to direct people to understand what the major threats are? And it may be that I mean my sensibility is if you just throw the threat model at them depending on the sophistication of the threat model people may be able to follow it. but it may also deserve a couple of paragraphs.

Joe Andrieu: I think in one of our bits of work, Manny, we were talking about, there are a bunch of threats that happen on the web, you should be familiar with how the web works, Something along those lines you have to have good robust software that's conformant, and in addition to that, this spec has these particular considerations. I don't know if that helps.

Manu_Sporny: I mean it kind of right this is the things that are confusing are he's suggesting something that we don't do at W3C per process. So that's issue one. if he's suggesting do a separate security considerations and privacy considerations section then the editors have to go in and I mean I guess hand place these target threats implementation threats into their own you end up duplicating the talk in that case or you lose the fact that it's a target threat or an implementation threat

Manu_Sporny: Yeah.

Joe Andrieu: So hold let me…

Joe Andrieu: if I could interrupt man I didn't follow why I didn't follow what was not processed like what is process is you need a security consideration section and

Manu_Sporny: A separate security consideration section and a separate privacy consideration section per the W3C process. and per the review requirements, the horizontal review forms all give us a link to your security consideration section,…

Joe Andrieu: I Yeah,…

Manu_Sporny: give us a link to your privacy consideration section.

Joe Andrieu: …

Manu_Sporny: Are they separate? Right.

Joe Andrieu: plus one to that. I agree that merging them is pushing the process a little bit and I don't think there's benefit to us to try and do that. we have enough complications with process about this threat modeling to let's try and keep it simpler but if we have a separate security considerations and privacy considerations which maybe have a short version talk like what's happening here is you actually have two different threat models or you have this extended table of contents that you are calling a threat model I think

Joe Andrieu: That's a misnomer,…

Joe Andrieu: A threat model should have all the structure that the threat modeling guide talks about. And these table of content listings is just a listing. It's not the threat model itself. if you scroll down, are the actual detail threats in that appendix?

Manu_Sporny: No, no,…

Manu_Sporny: no, no. This is just linking to the threat model. It's summarizing. So, this could say, table of contents for threat model or something like that, right? …

Manu_Sporny: but if we separate this into a separate security considerations and privacy considerations section, we're going to end up repeating target threats, implementation threat. Do you see what I'm saying? they're Going to list target threats twice.

Joe Andrieu: I don't…

Joe Andrieu: because I think you would move it from here to security considerations like No,…

Patrick_St-Louis: We're at the top of the hour. sounds like this discussion is very engaged. so I will just propose to resume it on next week.

Manu_Sporny: Yep.

Patrick_St-Louis: I have a meeting to go sorry too. I didn't want to intervene.

Joe Andrieu: no, that's a good chair's call.

Patrick_St-Louis: Okay.

Joe Andrieu: I appreciate it actually.

Eric_Schuh: Yeah, I'm here.

Patrick_St-Louis: We'll make sure to put this on the topic for next week.

Joe Andrieu: Cool. Cheers.

Patrick_St-Louis: Thanks everyone for attending. Really good discussions today and we'll resume these next week. Bye.

Kayode_Ezike: Eric, if you're there. Yes. So, I found the comment. For some reason, it got buried in the review that it was a response to a comment I made in a previous review. But in any event, this is the comment I'm posting in chat right here that has the suggestions that I had for threat T38.

Kayode_Ezike: So basically just to rename it change the tags and the taxonomy class and the file name change as well. Let me know if you can see that.

Eric_Schuh: Yeah.

Eric_Schuh: Okay, there it just loaded.

Kayode_Ezike: Okay. Awesome.

Eric_Schuh: Okay. Yeah, I will take a second look at that. let me save that somewhere so back to … Kayode Ezike:

Kayode_Ezike: And that's in addition to of course all the other comments that I just left throughout the last hour or so. But thanks again.

Eric_Schuh: Yep, sounds good. Yep. just so I'll probably try to do this first thing tomorrow morning. So, I'll ping you when I'm done.

Kayode_Ezike: Okay, perfect. Thank you.

Eric_Schuh: Have a good one. Bye.

Kayode_Ezike: You too. Cheers everyone. Meeting ended after 01:01:59 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.