Meeting minutes
Kayode_Ezike: Hello. Good. How are you?
Patrick_St-Louis: Hey, how's it going?
Patrick_St-Louis: Pretty good. Just having a look at the results for the survey.
Kayode_Ezike: All right. Point
Patrick_St-Louis: Welcome guys. We'll get started in a couple minutes.
VCAPI Life Cycle Management Task Force Call
Patrick_St-Louis: Okay, we're going to get started with the call today. So, welcome everyone to the VCAPI for life cycle management task force call. Today is the May 12, 2026. so this is a reoccurring weekly meeting during which we discuss verifiable credential API for life cycle management. this is a W3C meeting. So all W3C policies are into effect. This meeting is recorded and transcribed. So today for the agenda I have proposed a couple of topics.
Patrick_St-Louis: But before we get started, I will leave the floor if anyone would like to reintroduce themselves, share some community updates, or propose a new agenda item for today. I'm going to leave a minute for you to do so. Yes, Manu.
Manu_Sporny: Eric might be getting ready to say this, but threat modeling, we definitely need to keep moving forward on that.
Patrick_St-Louis: Perfect. So, we're going to add threat modeling to the topics. if it's okay, I'll do it as a third item. It sounds like we might spend a bit of time on this. And these two topics here should be very quick to cover. Eric
Eric_Schuh: Yeah, I guess I'll just speak to that real quick. I've been sick for the last half a week or so, so I didn't get as far with the diagram as I had hoped for this call. so I don't think the discussion needs to be long today on the threat model. but I would like to get the group to review the proposed user flow and make sure there aren't any interactions that I missed that we want to highlight as part of the threat model.
Patrick_St-Louis: Awesome. …
Eric_Schuh: So it should only take hopefully 10 minutes for that. no,…
Patrick_St-Louis: did you mention so there's a PR open for this that you want us to review? sorry I missed that part in the issue.
Eric_Schuh: it's just in the threat model issue. Yeah.
Patrick_St-Louis: Okay, perfect. So we can review this when we approach these subject Any other community announcements? I suppose I have a community announcements I should share which kind of relates to the multi-protocol topic. So there's been a announcement at the decentralized identity foundation.
Patrick_St-Louis: So they're just doing a sort of census on everyone uses so there's a little survey that people can fill if they do support didcom in their solution. I believe there's a desire to move didcom to a standardization body.
Patrick_St-Louis: So this is sort of a little update on this. I did hear the sound of someone raising their hands. Is someone raising their hand?
Eric_Schuh: No,…
Eric_Schuh: I just put a message in the chat.
Patrick_St-Louis: Perfect. I'll keep that in there. so yes, I'm just sharing this. if anyone is a Did fan such as I am, please just fill out this survey.
Meeting Time Poll Results
Patrick_St-Louis: Okay so let's get into our topics unless anyone has something to add. so the first thing we want to review the poll review. So we had circulated a second poll which has a little bit more responses. so in red here we can see the time slots that people cannot make it.
Kayode_Ezike: Please.
<Eric_Schuh> Link to the flow in question if anyone wants to read ahead: Create Threat Model for VCALM · Issue #628 · w3c/vcalm · GitHub
Manu_Sporny: You might not be sharing, Patrick. We can't see your screen. Manu Sporny:
Patrick_St-Louis: Sorry.
Manu_Sporny: At least I can.
Patrick_St-Louis: I just shared my mistake. I want to share the window. Hold on.
Patrick_St-Louis: Is this better?
Manu_Sporny: Yes, but little tiny text. hard to read.
Patrick_St-Louis: Am I zoomed in? Manu Sporny:
Manu_Sporny: Much better. Yep. Yeah.
Patrick_St-Louis: So in red here is the amount of people that did not select that date. we can see the individual responses. so it seems that most people are available in the 400 p.m. time slot. there doesn't seem to be a strong preference towards a day.
Patrick_St-Louis: However obviously the current time is still the one that has the highest convergence of people that end. there are some people that are in different time zones that have signal interest to attend the meeting. so this is the current situation. the highest number of vote were to keep it at the time it is now. the second highest was to move on Thursday at 300 p.m. and there's definitely less interest in moving it in the morning. so this is the results.
Patrick_St-Louis: So I would like to open the floor if anyone wants to provide their feedback based on these results. suggestions could be either to leave the meeting at the current time and make that as a decision or to move into a alternate meeting from week to week to enable people from different time zones to participate. so I'm happy to hear what everyone's thoughts are on this. Yes, Manu.
Manu_Sporny: I mean, it feels like we're at meeting at the time that works for most people. So, I mean, that's fine. I think it's good to see, if we changed, but I mean, I think we'd lose a lot of people if we switched to the morning. And then …
Manu_Sporny: what is that four red dots mean the number four or does that mean the best choice four?
Patrick_St-Louis: It's the best choice.
Patrick_St-Louis: Or…
Manu_Sporny: And it's also Yeah.
Patrick_St-Louis: maybe it's four. I don't know. I guess it is four.
Manu_Sporny: And then what's Thursday at 3 p.m. Who do we lose then? Basically the same kind of people. I mean, it sounds like we're already at the best time, so we should just keep it.
Patrick_St-Louis: And I want to say we've been running this weekly for four or five years now at this time. And I think we have a pretty good attendance. we have anywhere from six to 12 people attending the call, which I don't attend many call, but that is a pretty good amount of a lot of people have been following the call for a long time.
Patrick_St-Louis: changing this people will need to adapt their calendar so I think it's a good time the only reason would be interesting to change is to get new people on the call that would like to attend but however currently we have one or two new mentions in there and based on two people I'm not sure it's worth the change we can always revisit in six months send another will as the specification gets a bit more recognition. so unless people have objection, I'm going to propose to keep the call at the same frequence and the same time as we are currently doing and revisit in six months, maybe run another pool, see what everyone's situation is like. Any objections?
Patrick_St-Louis: Do we need to officially record this somewhere or do we need to share this on the mailing list?
Patrick_St-Louis: Maybe we can share the results. what is this a formal thing we need to decide? I do.
Manu_Sporny: No, just having it recording recorded in the minutes is fine,…
Manu_Sporny: which will happen today when the minutes are published. no, we need to show that we did try and it turns out that we're already meeting at the best time for everyone.
Patrick_St-Louis: Okay.
Manu_Sporny: So that and we can move on.
Patrick_St-Louis: So, is it worth it to send a message on mailing list or it would be
Manu_Sporny: No, I mean there we have the invitations.
Manu_Sporny: I mean it never hurts to kind of close the loop on something. So you could just send a quick response to the mailing list but we also have the calendar entries and…
Patrick_St-Louis: Yeah. Yeah.
Patrick_St-Louis: Okay. Yes.
Manu_Sporny: the calendar entries say very clearly when we're meeting. No. Yeah.
Multi-Protocol Discussion (Didcom)
Patrick_St-Louis: If it would change, maybe it would be more relevant to share it on the mailing list, but since we're seeing at the same time. so I wanted to touch a little bit on multi-protocol. I don't know if it was the last call or the one before. I think man you sort of put the word here about multi-protocol to know what a bit people are doing. so I can share some information about some work I'm doing. So we are implementing VC API and OIDC for VCI and we are also implementing didcom
Patrick_St-Louis: So our goal currently is to be able to issue W3C credential over all three channels. we have implemented some of the interaction URL mechanism in our wallet. my main thing I wanted to share is I would like to put in a didcon protocol in the specification somewhere. it would be very similar to how we include oid for VCI in there. from what I've seen the VCON spec itself doesn't go into too much detail about what to do with this oid for VCI because this just relates to an external specification.
Patrick_St-Louis: So I would probably have a similar thing with Ditcom in which you receive a gatecom URL and the wallet is expected to be able to process it. If they choose to engage with the Ditcom protocol, it would make sense that they know what to do with it. And this can be used for either establishing a connection, issuing a credential or requesting a presentation. there are a lot more didcom protocols available. There's some really interesting things that are being worked on such as didcom vaults yeah, there's a lot of different things. Didcom even has its own workflow system. one thing we've been discussing if is this idea of subworkflow.
Patrick_St-Louis: So you have your main workflow which is a ongoing interaction with someone and then at some point you want to serve them a mini workflow perhaps as a requirement for another step. so I don't want to get too much into inception level but what we are thinking is a model that you have a persistent didcom connection and through this didcom connection you can serve vcom workflows to the wallet or sort of these kind of features so you can serve a mini vcom credential issuance for example So that's kind of the approach I was thinking. so yeah, I was curious what are people's thoughts on multi-protocol.
Patrick_St-Louis: It's always interesting that it kind of adds a decision making point on the wallet right if they have a workflow presented to them and there's multiple protocols selected which one can they choose to interact obviously with VCAPI and the VCOM right we have these workflows and exchange that we define these templates. They can be multi-step. I'm not sure if this is possible with oid for VCI or I'm just starting to get a bit familiar but this seems to be very scope around I'm issuing you a batch of credential and there's not much multiple sequential step that is possible to do.
Patrick_St-Louis: So one of my question I had is if I'm giving an interaction is do I need to assume that regardless protocol I choose will lead to the same outcome. so let's say we define a multi-step workflow with VCOM. I don't see how this could be served over oid for VCI and maybe this is where this kind of subworkflow idea comes from.
Patrick_St-Louis: So yeah that's kind of my discussion had to do because across these three different protocols yes they're just an exchange protocol but some of them they have different capabilities and features and when a service is offering a choice of protocol do they absolutely need to all have the same amount of features supported or maybe the VC API has a little bit more interesting things it can offer and vice versa. yes, David.
Dave Longley: The short answer that to your question, do they all have to be identical offer the same identical flow and style and so on? And the answer to that is no. And we shouldn't aim for that be specifically for one of the reasons you raised which is there's no reason for us to believe that every protocol will be exactly feature compatible.
Patrick_St-Louis: No.
<Dmitri_Zagidulin> +1, totally agreed w Dave
Dave Longley: what you're looking for, what you don't want is for users to have to know about protocols where they have to make a selection on a page like a NASCAR choice of protocols, that would be awful. and so you have to design your workflows such that if you were to offer an interaction L that would support for example VC API and OID for VCI and maybe the V VC API lets you do a little bit more gives you a better user experience because you can stay in the wallet for example and maybe ask for other credentials and issue other things. You want to make sure that whatever you're doing with oid for VCI lets you redirect back out to a website and…
Dave Longley: you'll have to continue a flow there or something along those lines. You'll be taken to a different place if the wallet elects to choose that protocol, but you have a path forward to keep going.
Patrick_St-Louis: interesting. yeah,…
Patrick_St-Louis: that's really interesting. definitely one thing we're trying to do with these didcom workflows is to move away from this QR code scanning which is what most credential exchange do and like you say have the workflow itself be able to redirect the user without them leaving their wallet. Right.
Patrick_St-Louis: This is very much what we do withcom is you can offer a selection of actions to a user and some of the action could be to start a new workflow right or connect with the new entity that is a partner of the first one and then this new entity could serve their workflow to the user. So this is kind of the navigation we want to do, which seems to reflect a little bit what you're explaining here that you don't want to have the user to need to leave the wallet, right?
Patrick_St-Louis: the wallet can become not a browser but almost right the wallet becomes where all the information gets related and how the information reach the wallet whether that's overcom over VC API that becomes an implementation for the thing you said about yeah no I wouldn't say the user needs to make a selection unless you have a developer wallet and it's more like a tool to test
Patrick_St-Louis: things right because if I want to say implement with the VC playground with a wallet and I'm always just selecting the first protocol I see maybe I'd want a developer mode I want to make sure my wallet can do for that one interaction URL it can do both the OIDC for VCI and the VC API so those situation yeah it might be nice to have here are the protocols which one you want to do but Yeah, for most people this should be transparent in the wallet, and whatever how the wallet makes its selection is up to the wallet to code this
Patrick_St-Louis: Yeah. Dave Yes.
<Benjamin_Young> we have that in the UI on the Playground fwiw
Dave Longley: Yeah. definitely agree that if your audience is developers or yourself as you're developing things, you want to have tools that let you test different things and so on. that audience is quite different from an enduser audience that will not have the knowledge and they're not working on your code to help you fix things and there's also as Benjamin mentioned in the chat here the in between audience of playground user interfaces where you not you might be a developer or you might be looking at demo things and you have slightly different context in your head and you're a slightly different kind of user. all of those different audiences should be supported.
Dave Longley: Now I'm trying to remember. we have an issue that it GitHub issues in the repo where we wanted to do a better job of highlighting something that's built into VCOM with interaction URLs which if you send a redirect URL that is itself an interaction URL.
Dave Longley: This allows you to stitch together different flows that might need to go to different places that might need to have different business logic and…
Patrick_St-Louis: Yes. Yeah.
Dave Longley: And all of those things can using that mechanism can have you stay in a wallet that at least understands interaction that might even apply to a wallet that for example might only understand oid for VP. It might do some kind of presentation and then be given a redirect URL. That's an interaction And as long as it can understand an interaction it might be taken somewhere else to go do some other protocol that they understand, even if they don't yet know how to do VCOM, the delivery, the BC API portion. And so, I just wanted to highlight that that's something, that we need to do a better job of highlighting in the spec to allow that sort of, composition of different flows.
Patrick_St-Louis: And so follow question on that.
Patrick_St-Louis: So let's say your scenario you give another protocol UR could you see a feature that you give a protocol URL that comes from someone Someone you have a partnership with and you kind of serve your protocol interaction URL to do something and then at one point in your workflow you're like I've issued all what I need to issue you. Now you can go to see my partners protocol interaction URL and they will serve you things that you will be able to do with mine. Right? So is that kind of the idea here? Okay.
Dave Longley: That is one of the ideas. Absolutely. this is all supposed to be composable and allow end users and wallets to get an entry point where they have some trust signal, some origin that they're going to start with. And once they get into that,…
Dave Longley: it's just delegation all the way to wherever you want to go. And there's a whole variety of different ways you can put the sort of Lego blocks Lego bricks together to accomplish what you want to accomplish.
Patrick_St-Louis: very interesting.
Patrick_St-Louis: So okay so that's really really good like I said we are doing some stuff with didcom and the more I learn about vcom workflows and these discussion the more I realize it's all with a very similar purpose it's just a bit different JSON data model but all the sort of components the intention are very similar. so this is great to know.
Patrick_St-Louis: Yes, Mario.
Manu_Sporny: Yeah, to respond to one of the first questions that you asked Patrick about should we add a didcom section or add didcom properties in the spec. yes we should because we have places for OID4 VP and OID4 VCI and for example section 364 which is where we talk about the exchange protocols at a very minimum so that's 3.6.4 at a very minimum we should have didcom listed, in there as a potential protocol that you can bootstrap into.
Manu_Sporny: We also have sections where we like highlight here's how you do ID4 VCI. so let's see where is This is in getting the exchange state in 3.6.6. If you scroll way way down there's a bit for open ID the results from the oid4 VCI interaction.
<Manu_Sporny> VCALM v1.0
Manu_Sporny: I don't know if there's a similar thing we could do there for didcom. but that's
Patrick_St-Louis: I'd love to see…
<Manu_Sporny> VCALM v1.0
Patrick_St-Louis: because you could put many things in these URL usually you have an autoban invitation and then the autoban invitation could either have an attachment that you're going to process could have an endshake to do a connection. what a lot of people do is they're going to create an invitation for a specific purpose and then when that invitation gets actioned on, they will then push other content to it, Whether that's a workflow or a credential offer or a presentation request or anything.
Patrick_St-Louis: So I want to try and I will still think about how this would look but ideally if we put didcom in here it wouldn't put limitations on what you can do with the didcom right that's up to the person serving the URL I wouldn't want to limit this so this only accepts this specific type of URL instead it should refer to the specification the only thing I would maybe include
Patrick_St-Louis: is versus didcom v2 right kind of put that in the profile key. but the didcom message itself you resolve contains the information about what to do with the invitation. yes.
Manu_Sporny: Yeah. Yeah. And there's also the examples that we have in here about oid4 what you can do with oid4 but I think for those things we're trying to move some of these really verbose examples out of the core specification right we're trying to figure out a way to make the specification a little easier to read…
Patrick_St-Louis: Yeah. No.
Manu_Sporny: which means don't expand all the variations of every object an endpoint can try to minimize that and then try to move examples to a separate document. that's kind of like an implementation guide. if you're really interested in seeing a fullyfledged super complex workflow example, go over here to this other document. but
<Manu_Sporny> VCALM v1.0
Patrick_St-Louis: And for the 90% of use case for I say 90% maybe it's less but the 90% which is just like I want to issue your credential or I want to verify your presentation. these are fairly simple and you can get fairly simple example of this.
Patrick_St-Louis: The only problem I could see if you get too descriptive and then you're going to go out of sync with the other specification and it can become a bit of a mess, looking at oid for VCI. I'm just now starting to understand the history of all the drafts and the kind of minor things that wallets sometimes need to dance around to be able to properly exchange with the server. so I don't think in the VCON spec we'd want to impose a specific way of doing oid I think this just needs to be left to the oid for VCI implementations. maybe I'm wrong. Maybe we do want to limit we must use version 1.0 and everything else you should reject it.
Transition Document Updates
Patrick_St-Louis: But I'm not really sure that's the best idea. so that's for protocols. Any other comments on this? Very good. is there any objection if I just approach a quick topic before we go into thread modeling? It will be very quick. It's about the transition documents that we have pushed in the spec and what we can do with this. so we have tried to fix that.
Patrick_St-Louis: I know I guarantee we have tried to fix this or maybe we left it by intention but there's still VCDM 1.0 things in the spec here for example I thought we had done a clear pass of updating to 2.0 but currently there are still some reminders of 1.0 0 and sometime there's some pretty normative text around it. so I raised an issue I open a PR we'll get to it later if we have time.
Patrick_St-Louis: But some of this text has made it into the transition documents and I'm wondering is changing the transition documents a big no no or if it's for something like this is it reasonable like we just say we're just fixing some examples we want to have VCDM 2.0 menu I mean the CG final and…
Manu_Sporny: define transition document. Do you mean first public working draft and CG final?
Patrick_St-Louis: first public working draft.
Manu_Sporny: Yeah, we never change those.
Patrick_St-Louis: Yes. Okay.
Manu_Sporny: So those are snapshots and moment in time. It is very frowned upon to ever change those even if they have mistakes or anything of that nature. but that's okay.
Patrick_St-Louis: That's Yeah. Yeah. Manu Sporny:
Manu_Sporny: But that's okay. what matters is the latest document that we have out and…
Manu_Sporny: what really ends up mattering is what we publish as a global standard for 1.0.
Patrick_St-Louis: Yeah. Yeah.
Manu_Sporny: Everything before that is just a working draft. It was just, the working group working their way through what the final document would look like. And nobody's expected to pay too much attention to those historical documents unless there's some kind of historical sleuththing that we have to do why did this When did it end up there? stuff like that.
Patrick_St-Louis: Yeah, that's totally fine. I'll just remove these. It's just like updating some of the text like the links and the things like that. it's not something I consider a major problem. but it's nice that everything is consistent. Not some places 2.0.
Patrick_St-Louis: even if that's kind of what things will be like in the world,…
Manu_Sporny: Yeah. Don't change it.
Patrick_St-Louis: but okay.
Manu_Sporny: That's changing history, right? And
Patrick_St-Louis: Yeah. I'll just remove these two documents. That's fine. I also had a bit of a feeling, but I thought I would ask here. So, I'll just remove these. And, it's not changing a lot of lines, but we still want them to be snapshot intact for just because. Marvelous. Let's talk about threat modeling now. so Eric,…
Patrick_St-Louis: you had put something in the chat. do you want to lead the conversation, do you want to share your screen? Do you want me to open the issue? how would you prefer to do this?
Threat Modeling Discussion
Eric_Schuh: I think…
Eric_Schuh: if you just open the issue, we should be good for today. So I'm still in process of working on the DFD. it's quite large and it's taking a little bit of time and I haven't been feeling the best. So, I do hope to have that in I guess just as an update for the group before the end of this week. So, at least having images in the Google doc and probably comments on the issue with a first pass of that.
Patrick_St-Louis: What happened?
Eric_Schuh: That being said, we do need to kind of settle on a use case that walks through the DFD that kind of shows the API in action. so Joe and I put together kind of this second pass at a flow that you're seeing on screen here last week. Manu, I made a couple of small updates just to clarify that there is an in-person presentation of from your comment last week. and just kind of having a version of this settled will help me as I finish up the DFD work. just to cut down on some iterations. because if we do want to change anything in the flow, it very well might change kind of the breakdown of the different diagrams. just in terms of what is relevant to include for which part.
Eric_Schuh: So I was hoping the group could just take a quick read through this and see if there is any interactions that are obviously missing or in particular I did want to ask about revocation and if we think it's worth including that in this flow. it is part of a verifiable credential life cycle. but it also kind of adds complexity. and Joe, maybe if you want to just take a second if you're here to talk about kind of the ideas around revocation and how it's different than status updates. just in terms of functionality I
Patrick_St-Louis: Very good. Manual, you had your head up.
Manu_Sporny: Yeah, the only thing I read through this right now, Eric, and the only thing that does jump out is the credential status, being inactive and retired. We may want to talk a bit about that. It makes me a little uneasy. and then revocation on top of it, I mean it's all kind of statusless management, but curious as to why we're talking about inactive and… Manu Sporny:
Joe Andrieu: Thank her.
Manu_Sporny: retired and not just, revoked.
Patrick_St-Louis: Yeah. …
Patrick_St-Louis: sorry I had my hand up. I put it down. I'm just going to chime in if that's okay, Joe. yeah. I also had question why do we keep talking specifically about revocation? it's more about status management.
Patrick_St-Louis: Bitstring status list does say you can have any kind of status purpose. I know this is kind of opening the pandas box because we don't know what other status could be but they definitely include revocation suspension. I know I added something about this credential needs to be refreshed. There's a new version available. so I'm wondering why specifically revocation is where we put the infases on. and…
Patrick_St-Louis: I know definitely there's some discussion with revocation and linkability. I think there's probably something to be mentioned there. so yeah that those were my question comments. Joe.
Joe Andrieu: So the reason for the distinction is actually a privacy matter in that for example this is a distinction that Ela Wooten was really pretty adamant about in some of our conversations and…
Joe Andrieu: so I've adopted her view because she understands driver's license very well. revocation in that context means that it was incorrectly issued or it's cryptographically compromised like that you cannot trust it because at its core it appears to potentially be compromised. Whereas status is possibly a bit of PII that shouldn't be publicly available. So, for example, if I'm checking a driver's license, it's not appropriate for me as a consumer to know that your license is suspended or not. but it may be important to know that it is a fraudulent credential. And so, that's the distinction between revocation and status because revocation means something pretty particular. I would like to simplify the status here.
Joe Andrieu: So I'm not sure if inactive retired versus revoked …
Joe Andrieu: but we were trying to highlight that distinction between there's a cryptographic question about this credential versus there's some state in a system that we want to check. That's it.
Patrick_St-Louis: So I have an issue with this.
Patrick_St-Louis: So it's something you mentioned about revocation. You seem to infer that we should deduct some reasoning for the revocation. as far as I'm concerned, the pitching status is you don't give a purpose for the revocation. you don't give a reason for the revocation. this would be outside of this mechanism. so I'm wondering if this is really something that we should take into account here.
Patrick_St-Louis: I'm also not sure if we're talking about one discussion that there was in BC a while ago is let's say you have a digital driver's license and a physical one and the user loses their physical driver's license. they might revoke the physical driver's license but that does not correlate in revoking the credential because you still want them to be able to use their mobile driver's license.
Patrick_St-Louis: So I want to make sure I understand the scope when we say revocation here we are only talking about the credential and the credential we're issuing there's no sort of expectation about the system or the real driver's license being revoked I think that is reaching a bit too far for threat models u so that would be my kind your comments here.
Eric_Schuh: I'll let Joe respond first.
Patrick_St-Louis: Eric,
Joe Andrieu: Yeah,… sorry. Something you said just threw me revocation is okay sorry let me get back to the beginning I don't know what you said that threw me off or I would ask about that but one thing is we definitely don't need to fact putting the reason in the status list or whatever would be detrimental to privacy protections Joe Andrieu:
Joe Andrieu: So I agree. We don't say why it's revoked, but revocation semantically means something different than this is a valid credential. It's just that they are not allowed to drive anymore. some states continue to allow a suspended or revoked driver's license. I'm sorry, shouldn't say revoked, but suspended license to still be used as IDs. And so the status of my driving privilege is distinct from the credential that I'm using. And revocation, at least in the digital context, means that digital credential is revoked. when your driver's license is revoked, that actually is even more complicated. And I wish I don't think Elaine's here, but maybe she can chime in, if she were.
Joe Andrieu: Driver's license have at least in California, I think most states do this, but again, I could be wrong. I have a driver's license number that is mine for my life and it has a distinct life cycle from the card which has a different control ID and that card can be independently revoked from my actual driving privilege. So, there's a lot of nuance here that I'm not sure the best way to unpack, but I know Eric, you had your hand up as well.
Patrick_St-Louis: Eric Yeah,…
<Kayode_Ezike> Worth noting that purpose does have implications about whether the status can be reversed, among other things: Bitstring Status List v1.0
Eric_Schuh: Yeah,…
Eric_Schuh: I think Joe covered it, but I was just going to comment that, in this case, the revocation, I think, is more of a functional aspect of the particular credential, I think, is what we're trying to get at. that there's some reason that this particular credential should be considered no longer valid, whereas the stat I guess I feel like I'm just repeating some stuff Joe said. So Patrick, go ahead.
<Kayode_Ezike> Additionally, I think there is generally a mapping needed between status as defined in the spec vs. what the use case demands.
Patrick_St-Louis: I think what I'm wondering if it's not going overboard is to create this concern about what the
Patrick_St-Louis: Deal document status is So we could be any credential. I know we talk about mobile driver's license but the VCOM is not about driver's license. It's just about credential. they have a status and when a verifier wants to verify a specific credential they should know what to do with the status right different verifier might have different interpretation of the status. but when I'm looking at a credential and there's a status on the credential, I should know if it's revoked Then this happens could vary from one verifier to the next.
Patrick_St-Louis: I'm wondering if because it seems like we're trying to talk about revocation and the broader sense here of what the underlying data of the credential means and some other system and how this all links together. And I feel like this is a bit out of scope here and it could broaden our threat model around revocation quite significantly. I think approaching this as just the credential status right instead of whether it's revocation suspension and what threat model around this maybe is a bit more reflective of
Patrick_St-Louis: what we should be looking at. Eric.
Eric_Schuh: Yeah,…
Eric_Schuh: I guess I was going to speak to something similar, Patrick. my motivation for including revocation here was simply to try to be exhaustive in some ways about the life cycle that a credential can go through.
Joe Andrieu: Excellent.
Eric_Schuh: But I do think that it's a reasonable choice for the group to make to say we could effectively remove steps five and six here right which gets rid of this revocation and effectively I think Patrick what you were saying is the verifiable credential specification and its threat models should probably speak to revocation.
Eric_Schuh: But it's not clear to me that there's anything inherently special in terms of this API that revocation is meaningfully different than other types of status updates. the actions that someone might take around revocation might be different, but I guess I'm leaning your way,…
Eric_Schuh: Patrick, and I think Joe, this was your initial sense as well before I pushed to include it. no. Okay. I won't speak for you then.
Joe Andrieu: Nope. Nope.
Joe Andrieu: I'm going to speak from the other side of your argument.
Eric_Schuh: Here. …
Joe Andrieu: But were you done?
Eric_Schuh: yeah. Yep.
Joe Andrieu: Sorry. …
Eric_Schuh: Go ahead.
Joe Andrieu: I actually think there's an important distinction here that is specifically relative relevant for threat modeling, which is that allowing my status of my driver's license, for example, of or anything to be publicly accessible. in most cases is however checking the validity of the credential i.e. is it revoked was it compromised in some way that it's fundamentally should not be deemed to be a valid utterance from the issuer at any point in time that is something that is publicly relevant. And so part of the threat modeling is to say hey if the status reveals personal information about the subject it should not be available to the public.
Joe Andrieu: And if we don't make this distinction here, then we're going to have a hard time illustrating that threat.
Patrick_St-Louis: and I think this is why I think this fits in seeing status as a whole right especially because there's ways with the status to have specific message associated with status and there's other status that are at a higher risk of revealing personal information rather than just a revocation flag. there's other status that could add a bit more information as the reason why it's revoked or so on. yeah, that's a menu.
Manu_Sporny: Yeah, to add on to what Joe's saying, I think at a high level, I agree. Meaning let's say bitstring status lists that expose PII are a bad idea. and we should not be suggesting that, people do that. I know with some of our customers it's taken us a lot of discussion with them to convince them to not do things like that and even then at the end of it they don't quite understand plus one to taking I guess a little bit of a harder position on that. the only point where I get a little concerned about it is when it's not necessarily PII. So let's take shipping containers.
Manu_Sporny: There could be commercially sensitive stuff that you end up exposing over a status list that would also be a bad idea, So, it's not PII, but it's commercially sensitive. and maybe that falls into a similar or the same category of just do Don't publish that stuff, publicly. Joe, I'm wondering what other things this is tied up in because we're talking about threat model and we've got little bits and pieces of this all between multiple specs. So we've got bitstring status list that talks to some of this we're talking about maybe the core data model needs to speak to some of this and then we've got API things that are going on that are somewhat related.
Manu_Sporny: I'm wondering if there's a unified strategy of …
Manu_Sporny: where are we pushing what part of this in what threat model.
Joe Andrieu: Yeah. …
<Dave Longley> i.e., when do you need to put authz on a status list (or not publish a link to it in a VC at all)
Joe Andrieu: and seeing no one else's hands up, I'll just respond. Man, I think that's a really good question. maybe the threat that I'm concerned about here is really something that's baked into to did, BC data model. and not really something that is VCOM specific. but I also think that at where we're at in this stage and it probably isn't even about this stage is it I think identifying relevant threats is or it's the start of the hard part. So the fact that we can identify a threat here doesn't necessarily mean that it needs to live in the VCOM threat model but we don't have another threat model to go put it in if it's a better place over there.
Joe Andrieu: So I think just keeping track of the threat we had some threats in the the did resolution threat modeling conversation that really were threats about the binding of an identifier to a human person which resolution has nothing to say about there is no human in that loop in the conversation we don't know that the VC is about the person at all like it's just at a different layer in a different spec but since that came up in the convers We want to track it and see that it makes it to the right place.
Joe Andrieu: So, I think we're in a little bit of a triage here as well where it's good to track this stuff and if we can move it around to refactor it later, then that may improve readability, but I'd rather grab the threats when they come to our attention rather than lose them.
Manu_Sporny: Plus one to that. Meaning no matter what group we're in, we'll just land the threat where we think it's best tracked and make sure that we're tracking it primarily and then, figuring out where it should go ultimately as a secondary thing. while we're talking about kind of the status stuff, I know we're talking about threat model and kind of the core flow for the threat model. maybe status management is something there are two reasons that it may be weird to talk about status management. One, I don't think we normatively define how to manage status in the spec. we have a suggestion in an appendix, but it's not normative yet.
<Dave Longley> +1 ... this in particular sounds like it should head to a thread model for status lists
<Dave Longley> threat*
Manu_Sporny: hadn't made that decision yet, and two, as Eric, mentioned early on, I don't know how it really changes the threat model around the API. it's really business rule stuff that we're talking about, not really like, API usage. that said I think the only reason we put it in there is to exercise the status management API and show yeah that is something that your clients end up doing. So, that said, I'm looking at the bitstring status list stuff and we do talk about suspension in there, And maybe that wasn't a good idea.
<Dave Longley> (or maybe VC "design")
Manu_Sporny: And we do talk, there's this message thing that I really dislike in there where you have this status message and it's this bit string and you can have all types of different, messages around, why you flip the bit and that sort of thing like that really came from the supply chain area and in theory there's not, any PII there, but that again is potentially commercially sensitive stuff. So there are things that exist in that spec where it's probably best that we not talk about in this group. I'm just highlighting it there are bad code smells coming from over there and…
Manu_Sporny: I don't know when we talk about anyway'
Eric_Schuh: Yeah, I was just kind of keeping an eye on the time and…
Eric_Schuh: wanted to try to get something closed out to just give myself some direction going forward. so what I'd like to propose is that this has been a great discussion. Joe and I have a call together to kind of push this threat modeling work forward here in a couple hours. So I think what I'd like to do is have Joe and I kind of take another pass at considering these questions around status and revocation and if it should be included in this particular threat model.
Threat Model Document Location
Eric_Schuh: And then Joe kind of as a side part of the work it might be warranted for us to start collecting threats that we don't think necessarily apply directly to this threat model as a section within the threat model itself, these are other things that were identified that should go somewhere but they don't necessarily belong here. and that would give at least a way for other groups to come in and, hopefully easily triage threats that we've come up with that apply better to other work. and eventually that maybe gets cleaned up or not, we'll see. I did have one final question though, just in terms of process. Manu, I know this is this threat model is I think kind of our blocker at the moment for moving forward.
Eric_Schuh: to recommendation. and I did want to ask kind of as I get the DFD diagram finished up hopefully this week and we start to actually index threats based on that. what is the first kind of PR version of this supposed to look like? do we want to put this in an appendix? Does it go in a completely different repo?
Eric_Schuh: Because I'd like to as I kind of start going through this work start prepping for an actual push to somewhere. I just am not quite sure where this is supposed to go.
Manu_Sporny: If I could jump Q real quick.
Manu_Sporny: So I had thought that across multiple groups we had agreed that the first iteration would be a directory called model in the vcom spec and then we put a whole bunch of files in there and we iterate and then if we want to break it out later we do that but we just keep it with the vcom repo for now if we're doing a va vcom threat model. Von said he wasn't so sure that we agreed to that and so he wants to talk about it at the face to face. But that's what I'd suggest Eric is just like let's just keep it in the current repo just subdirectory threat model and…
Manu_Sporny: then we can break it out after that. That's
Ted_Thibodeau_Jr: So that's part of…
Ted_Thibodeau_Jr: what I was going to speak to. I would ordinarily suggest that the stuff which is not applicable to the VCOM work explicitly go into a note. having thought about it a little bit more, I would say that it should go into an appendix of the VCOM. And the reason why is that gets the same IPR protections that the main wreck does, which a note does not. and that appendix should hold threats which are in other realms while the main wreck has a threat modeling section that is directly applicable to VCOM.
Ted_Thibodeau_Jr: The stuff about driver's licenses and whether revocation or suspension or whatever else is the thing, that's business logic, period. it doesn't even apply to verifiable credentials. A driver's license is a verifiable credential and it has stuff in it and there are things that might be said about that verifiable credential and it's all business logic and I do not think that it should get special handling in the specifications. I think that's most of what I wanted to say and we're really at time so I'll leave it at that.
Dave Longley: Yeah, I'll try to be super fast. just want to be responsive to bad code smells sort of thing. I don't know that we have that problem. The bitstring status list spec says there's a list at some URL. What's missing there is a threat model that says how to protect that URL beyond using some authorization rules and that would apply whether you're using VCOM to manage status or something else. So I don't think it belongs in the VCOM place. and if there are any data modeling concerns around what to put in status or not, that also seems like it's maybe a VC data modeling threat or…
Dave Longley: design threat modeling concern.
Joe Andrieu: Okay, I'll jump in so we can wrap up.
Joe Andrieu: I do want to track these threats that we find. some of them we maybe should just make issues on other repos. so I think we can triage between what do we want to keep in our document, but also we could just put it if it's clearly a VCDM threat that should be considered over there, then we can go make that an issue. and then at least the community has tracked it and hopefully it'll get into a formal threat model. but Ted, I wanted to politely push back. I think business logic can definitely cause threats. so if our technology enables business logic to violate someone's privacy, I think we should be open to enumerating those kinds of threats. And that's it.
Patrick_St-Louis: Thank you all for the conversation. we are sort of a middle of a very important topic here. unfortunately we are at time and we'll try to be conscious of other people's schedule in case they are interested in hearing more about this. I will stop my share. so yeah very good discussion. I think we'll have to backend the threat model sometime when we come back next week.
Patrick_St-Louis: And maybe we can try to leave some space to view some of the PRs. it's been a while we didn't look at those. so thank you for attending everyone.
Ted_Thibodeau_Jr: Quickly so people are aware I will be offline for the next two sessions of this group.
Patrick_St-Louis: We will meet again next week at the same time. Thank you for all your contributions and have a great rest of your week.
Joe Andrieu: Cheers, folks.
Patrick_St-Louis: Okay, I will take note of that. Thank you very much. Hey Meeting ended after 01:02:43 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.
<Olvis_E._Gil_Ríos> Thank you so much!