VCWG Confidence Method

VCWG Confidence Method Meeting

Joe Andrieu: Howdy, Scott.

Scott Jones: Hey, how are you?

Joe Andrieu: How are you doing?

IIW Experience Discussion

Scott Jones: Very well. with regailing everyone with my wild stories of IIW and how mind-blowing it was.

Joe Andrieu: I was going to ask how you enjoyed it.

Scott Jones: Yeah, it made my head hurt. Every day at 5, I was throbbing in my brain. But, I had the realization this morning.

Joe Andrieu: Yeah,…

Scott Jones: I don't think I've ever learned since college probably. I've never had such compressed learning across so few days. It was really awesome.

Joe Andrieu: it is really an you leave you tired and exhausted. …

Scott Jones: Sorry, you got cut off there again. Can you say that again?

Joe Andrieu: I was just saying I don't know…

Joe Andrieu: what I was saying How it really stimulates you and leaves you completely exhausted, but it's I don't know if you run, it's like having a good run. When I'm out of shape, I don't like running. When I'm in shape, it's great. That sort of exhausted, satisfying feeling.

Scott Jones: That all resonates.

Scott Jones: I was like, man, I don't know if my brain can take it,…

Joe Andrieu: Hey Dank,…

Scott Jones: but I'm learning so much. Yeah, I loved it.

Denken_Chen: Hey there.

Joe Andrieu: how have you been? We were just chatting about the IIW experience.

Denken_Chen: Wow. How's that?

Joe Andrieu: It was good.

Scott Jones: I've been hearing about it for about a year now and no one could really describe it.

Scott Jones: They're just like, You should be there. Here's let me try to describe it." it doesn't quite make sense and now I get it.

Scott Jones: Mhm. I

Joe Andrieu: Welcome Dave.

Denken_Chen: I heard about that for a few years but I haven't got a chance to join IW always just reading the proceedings. Yeah, it's already very fruitful every single time.

Joe Andrieu: Okay, I see man who also joined. Welcome, Annie.

Manu_Sporny: I don't

Joe Andrieu: I don't know anyone else in particular who might be showing up, so I think we could probably get started.

Joe Andrieu: D because of IW last week, Dank and I I did get some edits to the PR that's outstanding to put at risk marker.

Denken_Chen: Right.

Joe Andrieu: So we could maybe look at that and merge it and then I'm guessing we just go through the issues today.

Scott Jones: Yes.

Joe Andrieu: Does anyone else want to add something to I see man raises hand. Go ahead, man.

Confidence Method Production Prioritization

Manu_Sporny: Yeah, I think it's more of a kind of a priority thing. We have some opportunities to take some, and this is going to sound scary, confidence method stuff into production.

Joe Andrieu: Yep.

Manu_Sporny: It's either we do this or something bad gets put in place. and it's really around the did off portions of confidence method. I'm trying to figure out what we can do short term to put some of these customers on a good trajectory instead of a trajectory that other vendors are trying to put them on…

Scott Jones: I didn't wait. Manu Sporny:

Manu_Sporny: which is very clearly bad. so I think what I'm saying is we need help getting the spec into at least a base level,…

Manu_Sporny: state that we can point to. and that means getting something so we can do an FPWD and so on so forth. and at a very minimum defining that did stuff.

Joe Andrieu: wait just to clarify we are in FPWD it's not meaningful…

Manu_Sporny: I thank you.

Joe Andrieu: but we are in that Okay.

Manu_Sporny: Sorry, I totally forgot. That is excellent. I think then the only delta is did off stuff like getting that in there and then potentially getting a release candidate context published which we might also have. Anyway, sorry that's just an agenda plus for I'd like a little bit of time to chat about what that could look

Scott Jones: Thank you.

Joe Andrieu: I'm keen to just talk about that now as you brought it up. thank you Neman.

Denken_Chen: Yeah, no problem. Message.

Joe Andrieu: So I agree with you. I think right now the main thing that we need is the schemas and properties for the two types of verification methods that we have talked out that being a verification method by reference, a DI URL that points to a key in a C document or did document and the embedding directly, right? Those were the two that we talked about wanting lish. we actually used that manual to speak to the demand for this. This is in our demo that we did at IW for the fair witness ceremony and…

Scott Jones: We don't want

Joe Andrieu: I just juryrigged something up. I'm like, Will and I kicked it around for a bit and we made something up. And clearly that's exactly what we don't want the rest of the world doing looking at this stuff. so I can get a stab of that in the next week unless Mano, I don't think you're signed up to do a PR. but go ahead, man.

Manu_Sporny: Unfortunately, I'm not. But, I'll be desperate enough to do that at midnight or 2 am within a week or two. no, I don' we're in FPWD. That's good. I think the only thing we need in that release candidate context file is the, verification method. probably by embedding we're probably going to end up using did key and that's it and the security and privacy considerations threat model could look a little better…

Manu_Sporny: but I think that's a much more involved thing. largely we just need a working context to Yeah,…

Joe Andrieu: By which you mean the JSON LD context?

Manu_Sporny: that's right. Yep. Yeah.

Joe Andrieu: That sounds right to me as well.

Manu_Sporny: And then since Ivon's here, we can also talk about where it goes in the vocabulary, So I think we would want to put at least the verification method stuff if it's not already there into the VC data model context. So it's broadly available across all types of VCs. Yep.

Joe Andrieu: I think this is a generic thing. so then that I'll hand it to you in just a second, Ivon.

Joe Andrieu: I guess my question is then the context file for confidence method are we go so now I'm confused which are we creating a separate context file that someone using VC confidence method would link to or is what you just proposed man to get that into the generic VCDM context I lost a thread between the context file and…

Joe Andrieu: the vocabulary which there's a subtle relationship Go ahead, Ivon.

Ivan_Herman: two things…

Ivan_Herman: then I am just in the process of writing up where we are exactly with the various vocabularies as we agreed yesterday so let's postpone the decision on that once I have that fully done on the context versus vocabulary yeah the two things are In theory, we could create a separate context file for confidence methods only. I would prefer not to over complicate our lives and just use the same context file for all the vocabulary including confidence methods. The only thing that happens is that for doing someone doing only confidence method, the context file will be too big. But who cares?

Manu_Sporny: right on that.

Joe Andrieu: Go ahead,…

Joe Andrieu: man. Y

Manu_Sporny: Ivon, I think the pattern we've been you might have missed the beginning of the call, Ivonne. We are probably going to push confidence method into production. I know that it's scary and we shouldn't be doing that, but it's either that or something much worse gets put in its place. and so we're trying to work with some of our customers on a DIDbased confidence method. we cannot in that situation depend on the VC data model 21 context like that we are having to deal with other vendors that will push back that VC data model 21 is not final and

Manu_Sporny: all that stuff and for that reason it would be much easier for us to use a separate context file just for confidence method just for the release candidates so for the next year or so and then we will upgrade once VC data model 21 gets published as a wreck so going back to your question Joe the typical thing we have done is we have published a separate context file just for the extension specs, a confidence method. So if anybody wants to fold it into a VC data model 111 thing, they can do that.

Manu_Sporny: And in addition we can just pull in the confidence method stuff into this customer environment while we get the full thing done in VC data model. So the first one is a very concentrated context file just for confidence method. That's one change that we can do and in parallel to that we can merge it into the VC data model 21 context file which is broader in scope as Ion was mentioning.

Manu_Sporny: So it's in there kind of by default the whole batteries included approach that we're trying for the base context. and then the third thing is the actual vocabular Where do we put these terms and I'm suggesting we put them in the vocabulary.

Manu_Sporny: We don't have a separate vocabulary just for confidence method. we put them in the base context. So three things that we can do mostly in parallel.

Joe Andrieu: Okay.

Joe Andrieu: Before you go, Ivan M, you confused me at the end because you called the vocabulary context file. but you just described you.

Manu_Sporny: Sorry, I probably misspoke. Pure vocabulary.

Joe Andrieu: Okay. Yeah,…

Manu_Sporny: So I don't know if I have a link to the vocabulary file. BC Yeah.

Joe Andrieu: that was my question. I don't know what you mean by vocabulary file. The place where we define these things normatively is in the spec.

Joe Andrieu: So I think there are now three things to keep track of, The spec where we normatively define it. You're saying there's a vocabulary file that's not a context and then that there's of course a JSON LD context file. Is that am I understanding?

Manu_Sporny: Yeah. The thing I'm pointing to right here is the vocabulary that defines everything.

Joe Andrieu: I see.

Manu_Sporny: And then if you go to each one it says the formal definition is in VC data model here right so we publish this thing…

Joe Andrieu: I see.

Ivan_Herman: It's not at

Manu_Sporny: which is the vocabulary which is nonnormative I think of okay yeah it's non-normative and then it points to the formal definition in the specs right here. So what we would do here is we would add property definitions for confidence method and things like that and then class definitions for verification method maybe and…

Ivan_Herman: Actually there is only one there is already a confidence method property.

Manu_Sporny: then we would point to the that's correct…

Ivan_Herman: I'm sorry to interrupt in the reserve terms category. I

Manu_Sporny: where is that thing yep yep yep so here's

Manu_Sporny: confidence method and it still points to the CCG so we need to update that …

Confidence Method Vocabulary And Context Files

Manu_Sporny: but we'd have to add a couple of things to this vocabulary is all I'm saying and then the normative definition as you mentioned Joe is in the confidence method spec and…

Manu_Sporny: we would point There.

Joe Andrieu: Okay, thank you for that clarification.

Joe Andrieu: Ivonne, your hand got auto turned off, but did you get what you wanted to say yet?

Ivan_Herman: Yeah. the point is that this…

Ivan_Herman: how should I say dual JSON RD context file for the same vocabulary or portions of the vocabulary we already have that because there is a separate context file for the multi key as far as I know and also for the W key. so those already exist right now. So it's not an unheard of setup that we have. And as I put in the chat, I will hold my nose and do it.

Joe Andrieu: All right, we appreciate that. Ivon Dave

Dave Longley: And Mono, you keep saying the verification method, but I think the simplest, quickest one to do is actually did a decentralized identifier or did document or something. One way to even model that that might even be simpler because it wouldn't take any new vocabulary terms would be if a confidence DID document. So right now in the confidence method spec we list verification methods which would be bound to specific keys which is a useful utility.

Dave Longley: But we also have sort of just as a placeholder something that says type decentralized did document. If you didn't put a type in that confidence method at all, and you just reference the ID, you wouldn't need any new vocabulary terms. I think confidence method is in the existing 20 spec. So that's something to consider.

Manu_Sporny: Joe, you might be muted.

Joe Andrieu: Thanks, I didn't understand something you said there, Dave, but I thought you were talking about what I've been calling a verification method reference as opposed to an embedded verification method, which to me is just a URL that points to a verification method. And that could be in a CID or it could be in a DID and that should all work. I think that's the hook you were talking about. But I think at the end you nuanced it such that we could minimize the vocabulary bit. So maybe I didn't understand that Many of you were next on the queue.

Manu_Sporny: Plus one. I don't have a strong opinion about what we do other than let me just highlight the use case. So this is largely around a customer wants to provide a way of providing a verified email address or a verified phone number or verified mailing address, right? And this verified property email, phone or address kind of lives on its own. and we

Manu_Sporny: One of the proposals is let's tie it to their high assurance identity document. So every time they want to prove that they have this email address they have to submit and this is not the document but they have to submit their passport because their email address is tied to their passport and that is terrible right we do not want that happening in the ecosystem. and the argument for that is like we have strong binding to the document and the document is tied to a key on their mobile phone and for that reason if we want to do verified email address you have to provide your terrible from a privacy perspective. So instead we're trying to no just use a confidence method. You can use a key binding there if you want to.

Manu_Sporny: And that's what we're trying to establish here is what's the minimum we can do the key binding could be done did document or verification method something of that nature. it's kind of think of it the tap to pay credit cards that you have today. you have that card and when you tap there's a cryptographic authentication that happens along with kind of the account information that goes over. We're trying to do effectively the same thing in digital form. So that's the use case is we want to send over preferences and some verifiers want there to be some kind of cryptographic binding and

Manu_Sporny: So, we're trying to do that in a way that doesn't require them to submit their entire identification document. Hope that made sense.

Joe Andrieu: I think it's me, Dave. Go ahead.

Dave Longley: So, just trying to be responsive to what you said, sure, one of the confidence methods that could be done here is just a reference to a verification method. It would not necessarily have to be embedded, but it could be embedded. But what I was trying to get to, which is what you have highlighted on the screen there, is the only thing that's preventing us from using a did as a confidence method today is lack of specification for how it works, which would be in the spec. and a statement in the VCDM 2.0

Dave Longley: 0 spec that says that there must be a type property in the confidence method. if that were not a requirement the confidence method property is already defined and all that you would need to do is did as a value for a confidence method. So there would be no new vocabulary, no new context for a VC 2.0 VC. You could do all of those things and immediately did confidence method support mechanically.

Manu_Sporny: And I think I'm okay with that. It feel is that the proper long-term solution? Right. I feel like we are trying to get something working versus versus having a type. I don't know if the needing another context is that big of an ask. but maybe it is. I mean I totally get it, Dave.

Manu_Sporny: The shortest path is remove this requirement for there to be a type field or say You move it from must to a should and then use a did URL as the ID for the confidence method and then you can use any what are we assertion method out of there to do the authentication like we'd write text to that effect.

Manu_Sporny: Sorry that's right an authentication method.

Dave Longley: To be clear,…

Dave Longley: you would use an authentication method out of there.

Manu_Sporny: But I don't know if specifying a type is, that much more. I could go either way. I, interested in your thoughts if we're taking a shortcut or if adding another context is really that big of a issue. That's it.

Joe Andrieu: I think I'm more with you, Manu, than Dave. because it seems like part of your main driver, Dave, I think you're correct, but I'm not sure it's the right driver, which is to minimize our necessary changes to these other things. if we have to change those other things then I think we should do it in the way that's the long-term architecture that we're trying to set up which doesn't feel that far away procedurally I'm not sure we're getting much by doing this different thing that isn't what we've had already been talking about just for the sake of making the paperwork easy.

Joe Andrieu: Go ahead, man.

Manu_Sporny: And the other thing that we might do is I mean,…

Manu_Sporny: this is largely if the other vendors push back they're like, " it's a new feature. It's not, standardized, yada." we can then I think fall back to Dave what you said but maybe not change the core spec and just be a willful violation temporarily while we get this thing through the standards process. Meaning digital bazaar would be a willful violation of this spec I was sharing my screen. We would be a willful violation of this specific text until the context were in place and it was through the full standardization process. If that makes sense.

Dave Longley: There's also a weasel wording way to get out of that which is to avoid collisions regarding how the following properties are used. the confidence method spec could say there are no collisions when did identifier for a confidence method.

Joe Andrieu: Go ahead, man.

Manu_Sporny: Yeah, plus one to that. So, I think we've got ideal state and we've got a couple of backup states. and, we're being very clear and public about what we, intend to do. largely it's going to be driven by other vendors pushing back or not. we clearly want to do this the right way. So I think we're good. we have multiple paths to get to where we want and it sounds like the group is okay with moving forward on a variety of these and…

Joe Andrieu: Go ahead, dude.

Manu_Sporny: and being flexible as we bring feedback back to the group from implementations.

Dave Longley: I would say the main so the thing that is missing most immediately is a description the confidence method spec for how one would use did to increase a level of confidence. perform a proof on a verifiable presentation, for example. so I think that's the main thing that's missing. And then the other dressings, having some kind of type that you could refer to a statement that says if the s there still are no collisions because did it itself eliminates the potential for collisions if there is no other type getting stuff like that.

Dave Longley: The secondary. first part saying, this is how you actually do it in that spec so it can be pointed to I think that's the more important piece.

Joe Andrieu: So, I don't think this is quite the right way to do it,…

Joe Andrieu: The current thinking for me about the verification method that's leveraging the DID URL that points to a key so you can specifically say this particular verification method is the one you should use.

Joe Andrieu: It's a different beast that I haven't thought through to say we just want a did and we're going to let you choose any of the authentication methods that authentication relationships that may be specified within that did. but I think that's what you're proposing and maybe I don't know if you caught my feedback before, but my suggestion was injecting that into the architecture feels like it is chasing the paperwork reduction act rather than finding what's the ideal way to do it. but let you respond.

Dave Longley: Should I jump Q?

Joe Andrieu: Go ahead.

Manu_Sporny: Yeah, go ahead.

Manu_Sporny: Yeah, go ahead.

Dave Longley: I had always envisioned that you could just specify a DID to allow for key rotation and so on for whoever it was that had successfully gotten an issuer to DID somewhere to a VC that issuer saying, I did some kind of process. I'm okay with putting this confidence method here on this did and probably that would be the way I have always conceptualized that is it's really for the benefit of the holder of the credential or whoever the subject might happen to be as two-factor authentication when presenting that VC. and so it's really up to them to be in control of that did in an appropriate way to be able to manage their own keys and decide whatever authentication methods they want to put

Dave Longley: DID document associated with that

Manu_Sporny: Yeah, a plus one to that. I'm looking at the use cases here. Ultimately, it's the issuer that decides what amount of flexibility they want to give to the holder. in that case, they're going to be certain jurisdictions that are going to basically lock it down to a private to a public key that they absolutely, saw at the time of issuance. So that's I think Joe the use case you're talking about where it's locked down to a very specific verification method. but there may be other entities I'm thinking of the Utah's state endorsed digital identity stuff where some of these credentials are supposed to live beyond key crypto periods.

Manu_Sporny: And in those cases for specific types of DIDs they may want to give the individual the choice. So for example let's look at like a driver's license that's issued for seven years.

Joe Andrieu: Yeah.

Manu_Sporny: The likelihood that the individual is going to do a key rotation in that those seven years is I think pretty high. and you don't want to have to as the issuing jurisdiction, if you believe in this approach, you don't want to have to recall the individual to come back and get a new credential for every single key rotation that they do. you just want to basically you either trust the did and the key management, processes behind, that did and the individual you don't. so I think we do need to have both options is…

Joe Andrieu: Cool. I'm convinced …

Manu_Sporny: what I'm saying. that's it.

Joe Andrieu: what this tells me is that we actually have three different verification method sort of subtypes. it's just a DID. You will use any authentication method in there. and that allows for long-term confidence method through key rotation.

Joe Andrieu: it can be a It's pointing or really it's any URL which could be DID URL or a CID but the point is it's a reference to a veri or we can embed the verification method directly in the VC so that there's no need to get out on the network. We're basically putting a key directly in the file. So those three things that's a new discovery today Dave so I hadn't been thinking about it that way. but I appreciate that all three of those are valid and interesting use cases and I'm seeing a bunch of thumbs up. So, I think we can take that topic as resolved and we don't have an issue to attach it but it will be in our minutes. and hopefully we've socialized that there are now three different ways we're going to use verification methods and we just need to write some of them up.

Manu_Sporny: Do you want me to raise an issue, Joe? I'm happy.

Joe Andrieu: Sure.

Manu_Sporny: It feels like we should track this as it's like that is kind of the core of what we would love to see in the next, two to three weeks. like a PR that puts that in. Okay.

Joe Andrieu: That would be great. And feel free to assign me to it. I think I want to take a stab at what I did with the fair witness demo. and just see how that language looks unspec, So that would be helpful. that was Any other agenda items? Otherwise, I think we can look at that and then walk through issues. hearing none. I will just share my screen real quick, assuming I can get the preview up and working.

Joe Andrieu: So, relatively simple adjustment since the last conversation which was simply to wrap an at risk marker. theres So, there are now two at risk issues. this is in the wrong place. It bubbled it out of this table. So, I guess that's a question for the respect folks.

Joe Andrieu: Yeah,…

Manu_Sporny: You have to,…

Manu_Sporny: I think, use a span if you're going to put it in a table instead of potentially a div or it auto autoblocked it to move it out might be what's going on.

Joe Andrieu: I do think that's what's going on.

Joe Andrieu: What happened is it's in a paragraph in the TV and it got pulled up. Is that right? No, I see what Okay, so this is not ready. I think I can fix it but I'm not going to waste our time on the call. but let me ask This was so out of our last call we said hey if we put the at risk things in the right place then this is good to move. is there any objection to that because then I'll just fix where this is showing up and Denin and I will merge it in since I created I'll let you do Denin but I appreciate the thumbs be good to move that forward. So I'll get this today. It should be a small edit.

Joe Andrieu: I was excited because I got this one working. The second one. but obviously I didn't see the first one was not quite the right place. thank you for the feedback on that. and then let's look at our issues. I think, Scott,…

Joe Andrieu: did you update the issue that your input? I think it was 31 here.

Scott Jones: I did.

Scott Jones: Yep. Sure.

Joe Andrieu: You want to introduce us to it? Let me hand the mic over to you. And where are we in the conversation?

Client-Side Biometrics For VCs

Scott Jones: So, hi everyone. I'm Scott with Realize. we do privacy preserving biometrics at very large scale. we were exploring I came into the conversation here with Manu looking at opportunities for commercial needs for privacy preserving biometric holder binding in verifiable credentials. and I drafted an issue framed around that looking at if client side biometrics is possible. and there were rounds of feedback with the initial draft I put up there.

Scott Jones: I heard things from the group including Dave Longley on this call. Nice to see you here. he Amir suggested something about assurance class abstraction. Joe gave feedback on use case framing. there was an ask to give more insight on open-source reference implementations rather than using any particular vendor's model. and so I drafted an updated version as the last comment that addresses many of those things. And then there's still some open questions that I believe we would get into with the R strategy.

Joe Andrieu: Okay, this is definitely a long comment thread. I'm just making sure I got through the tail end. So, I think you are right in that it feels like this is ready for a PR. certainly it's hard to track the conversation in the issue thread at this point. has anyone else had a chance to review this update? I mean, I think we can review it in PR. So,

Scott Jones: Yep.

Manu_Sporny: plus one. Sorry, I'm still typing out this other issue, so my focus is split. could we take a look at the latest code looks like?

Joe Andrieu: Which code do you mean?

Manu_Sporny: That might help us focus on changes that you might be able to make in the PR. Scott, I don't know where I think for the input format what's on screen right now that basic structure thing just to look at for example that version I don't think we want to use that but the rest of it looks good. The IDs I don't know why we're using I forget. maybe I suggested we use a UU ID for the ID.

Manu_Sporny: Yeah,…

Joe Andrieu: So there was a suggestion to have an ID.

Joe Andrieu: I remember that going around.

Manu_Sporny: which is fine.

Joe Andrieu: What about the version don't you like for the biometric matching model?

Manu_Sporny: It feels like it should be in the matching model realize 2026- version 3.2.0. It feels like something that the model needs to just express there. It like no need to break it out.

Joe Andrieu: Right. In the same way that it's in this URL has both of those pieces as well. Right.

Manu_Sporny: I don't think it does anything what's the wallet going to do with that data? Nothing. It's just going to, …

Scott Jones: Yeah. Question.

Manu_Sporny: I don't think Yeah. And I'm guessing the purpose of the URL, Scott, is so there's a human readable something or another identifier or globally. …

Scott Jones: I think

Manu_Sporny: and then it's kind of like, why do we have the matching model in the URL? because both of them kind of identify the model, And so maybe the matching model should just be a URL and then we get rid of version and URL as an example. there are three pieces of information there that are duplicative of each other. So, we should try to figure out…

Scott Jones: Mhm. Isn't that …

Manu_Sporny: what we're trying to get down

Joe Andrieu: Isn't it also …

Joe Andrieu: because we have a JSONLDD context here, this type is in fact going to reduce to a fully qualified URL? Sure.

Manu_Sporny: Correct. yes.

Scott Jones: I have Sorry, just to jump in. I had to interrogate my notes. Sorry.

Scott Jones: The URL goes back to a feedback from Manu a while back for wallets to know where to send the biometric data for server assisted verification if that's relevant. Mhm.

Manu_Sporny: So that's not just so sorry Scott it's just minutia on the way URL means something different in this kind of data model we're using. It's like here's my website. That's what URL means typically. what this is really is it's a service It's a service endpoint, I think, is what it is. so it may be Joe that we're, reuse the service definition stuff out of documents here as an example.

Joe Andrieu: Yeah, I agree. It is shaped like a service endpoint rather it feels like but it's not yet shaped like so that's intended to say,…

Scott Jones: Mhm. Yep.

Joe Andrieu: hey, this biometric model, this is a service endpoint that you might go to have it That right, I agree. URL doesn't tell that to me in a way that if you literally had service endpoint as a property, that would be more aligned with how the DID documents do it. my only hesitancy menu is do we want to pull in the whole specification of a service endpoint and in…

Joe Andrieu: which case it would be fine to use that property otherwise we should probably call it a service or something else if we just want a there a URL go ahead

Scott Jones: Thank you.

Biometric Service Endpoint Modeling

Manu_Sporny: I think we might want to pull in the full thing. I totally agree that it would be nice if we could get away with just a URL, but there may be other things that you need to bundle with the URL.

Scott Jones: Thank you.

Manu_Sporny: So my suggestion would be to just pull in the whole service definition. the reason I say that is because there are other things that we may want to pull service endpoints into. So for example,…

Scott Jones: Get the

Manu_Sporny: refresh service has nothing to do, with anything here, but refresh service would be another thing…

Manu_Sporny: where we might want to reuse service phone.

Joe Andrieu: And…

Joe Andrieu: what I think you and I both really meant here, Manu, just to clarify, because I just pulled up the actual definition from didcore. I put that URL in the chat. is to have this be a service with the ID type and service endpoint. I think I conflated things by suggesting maybe it's just service endpoint but then that doesn't give you the type and the ID.

Manu_Sporny: So there are two choices here, It could be service endpoint. And the thing that Scott has in his example, if we could go back to the other tab, the biometric model could contain a service, that could be a service description,…

Joe Andrieu: All right, Dave.

Manu_Sporny: but I don't think that's what it is. So in biometric model is effectively the service property and then the thing inside it has an ID type and service endpoint. So the type would be a biometric mashing model serviceish thing and the service endpoint would be the URL. We could model it like that, but I don't know if that Go ahead, dude.

Dave Longley: is what we're trying to model here a set of parameters that will be sent to a service and maybe we could get some more mileage out of trying to make it seem like that is the biometric presumably so I hearing you guys talk about this I'm getting a better understanding of it it sounds like you would take what's in the URL property here and you would transmit the biometric vectors to it as a parameter of some kind to that URL Is that correct?

Manu_Sporny: you would Let me try and explain this Scott so that I've got how this works in my head. this thing on the screen the input types of video. So you would take a video stream and you would take the biometric vectors and you would send both of those.

Manu_Sporny: You would send the biometric vectors and the video stream to the URL that's provided there. And that URL would let you know whether or not the video streams matching the vectors. Is that correct, Scott? Yeah.

Scott Jones: I believe so.

Scott Jones: Let me just confirm here.

Manu_Sporny: I mean, in fact, it might be the biometric type as well that's transmitted. And you might take this entire object and just post it to the URL.

Dave Longley: while we sort out if that's right. It seems to me like the confidence method itself is a service with parameters. and those parameters would be encoded here as data. But there's some biometric matching service and this is the service endpoint for it and these are the parameters you send to the service plus some other meta information that would tell you things like you need to also be capturing a video to because there are some other computed parameters that need to go to it.

Joe Andrieu: A minute.

Dave Longley: So It's got parameters that are embedded here as static data. And then you have the endpoint where the information goes.

Manu_Sporny: Yes, in one of the use cases, So, the use case we're looking at is the individual have selected your biometric vetting service and you're okay with sending a video up there and that is an example of you sending data to an online service. But we also have a use case where nothing leaves the phone.

Manu_Sporny: I mean, you could argue that the service is local in that case. but I don't know if that's the right way to model it. go ahead Yeah.

Joe Andrieu: Yeah, one of …

Joe Andrieu: what you just said, the individual subject doesn't get to choose that service endpoint, right? This is the issuer defining the service endpoint.

Scott Jones: I think he's recording. Perfect.

Manu_Sporny: Yeah, that is true. I guess the theory is the individual would consent to the use of that service through their digital wallet would not open up a video stream to that service…

Joe Andrieu: Sure though that I totally agree with…

Manu_Sporny: unless they ask the individual do you realize to do biometric vetting for you. yeah.

Joe Andrieu: but you had presented a flexibility that's not quite here the issuer could have asked the user which service to use but that's not necessarily what is going to happen in practice.

Manu_Sporny: And I think what we actually want is the individual through their digital wallet to be able to pick the service,…

Scott Jones: Mhm.

Manu_Sporny: I'm wondering if another way to model this is the individual is I trust realize to be my biometric provider and then the issuer would say these are the biometric providers that I'm okay with right and here are the vectors I captured and yada so in that case you could argue that you don't need a URL because it's the digital wallet that's going to make the suggestion to the individual and let them pick. the downside there being that there's logic there that goes in the wallet that's probably not good to put in the wallet.

Joe Andrieu: Okay, there.

Manu_Sporny: I don't know. I'm very much on the fence about that part of

Dave Longley: Yeah, I had a lot of different thoughts. there different contexts and things to respond to. I'm also thinking about what the query language is going to look like when a ier wants a biometric confidence method to be Presumably, they would say, I will take a confidence method of this type. they might not care about anything more than the type.

Dave Longley: They'll probably care about who the model or matching provider is though or that the matching provider is on a recognized entities list that sort of thing from the other work.

Joe Andrieu: Attack

Dave Longley: And then ideally all the wallet needs to do is present that to the user of here are your choices that would work for the verifier. Do you want to choose Pick one of these. And even if there is some kind of local service that does something,…

Scott Jones: Listen.

Dave Longley: I would imagine you would still want to identify that it is a local service in some way or another. you could still use a URL to express that information. I don't know how you would get away from that or how you would design it architecturally even if you have a wallet. Ideally, a wallet would not have to embed that functionality itself, but could call out to some service through that URL, whether it's local service or not. Hopefully, that's making sense. and I would also hope this is kind of coming from what render method does a little bit where it says these are the pointers for the properties in a VC that are going to be rendered if you hand this over to a render method.

Dave Longley: and that render method more or less runs locally. This is a very similar model to that.

Scott Jones: That's good.

Dave Longley: If you had this biometric service running locally, you could say these are the parameters from this thing I'm going to pass over to this service and it gets nothing else and the wallet could do that part some piece that the wallet trusts could do that part. And so this is why I was saying I have a lot of different thoughts swirling around here, but this feels very similar to render method in the concepts around announcing what's going to go somewhere and where it's going to go and making sure that the user can make choices about that and making sure that the verifier can request and state the type the things that it would accept if you made those choices.

Joe Andrieu: Let me frame a question for you, Scott. I think we've identified three different ways that we could make this more flexible than this particular schema. One is to enable purely local. So we're not going to an external service but we're letting an app on the phone or on the device do it. the second one is that the user gets to pick their wallet is going to manage that there are service endpoints of certain types and…

Joe Andrieu: the users involved in picking one. and the third one would be what feels like the started with, which is that the issuer is specifying the service endpoint. I think those are all possible sort of ways to advance this work. I'm curious which of those is do all three of those sound good to you or do you have problems with any of them or how are you thinking about this kind

Scott Jones: The thank you for that.

Scott Jones: The first one was kind of the original spirit of intent. sorry, I've had a lot of coffee, but I'm still not speaking as well as I'd hoped for that. the original impetus for this was that we are working on client side capabilities. we're delivering to a big tech company capabilities compatible with wearables and have a very unique capability there. So, the original intent was to explore that.

Scott Jones: To your second point on the user getting to pick options. that was also kind of the spirit I picked up from Manu of avoiding vendor lock in avoiding making it seem like somebody owns this and no one else. So the idea of how you want to express that whether it's present it I put the user in control and otherwise kind of merchandise you have options and then even on the developer side working with this kind of the expression of the open source options you don't need to use any vendor there's open source capabilities that might not be as great but they're available and then the third one where the issuer specifies the service endpoint I'm

Scott Jones: still learning so much so quickly. So, I can't tell you that that's not a good idea anymore, but I'm happy to hear from others that it's not.

Joe Andrieu: Okay, thank you Scott.

Joe Andrieu: That's good to hear. It wasn't clear to me if which of those sort of was your initial intention. So that's great because I agree. I like the local biometric is figuring out and I think frankly I'm not a fan with my chair editor hat off or whatever that the issuer specifying one and…

Scott Jones: Thank you. That's

Joe Andrieu: only endpoints feels like a control framework and not a framework of choice and I think we're trying to create a framework of choice here. Go ahead.

Manu_Sporny: Yeah, I mean I agree with the only and we have to figure out where we're comfortable. there are use cases that is very much what the issuer wants to do. if you'd look at a military ID used on a military base, that's very much the type of, ecosystem they deal with. certainly we do not want to expose the general population to something like that. so is it a legitimate use case? I think yes it's a legitimate use case with a whole bunch of concerns and warnings that if we decided to support that would put into the threat model and so on so forth.

Manu_Sporny: I think one and two is very much where we're wanting to focus though the purely client side one and then the individual gets to pick who their biometric provider is. if we focus on both of those I want to just make sure that the data model supports definitely the first two and…

Scott Jones: Thank you.

Manu_Sporny: pro and at least the third one. to make sure that we've got a data model that's flexible enough that it can support all the use cases and then we try and nudge the ecosystem towards the first use case ideally and then the second use case is probably more realistic near term next two to three years that's

Joe Andrieu: Okay, thanks. I do want to move towards wrapping up as there was a window with the W3C where we anchored to finishing 5 minutes early. So we have time to transition to whatever our next standards call is. it may be manu that with the user selected the type restriction may be able to support the use case of the DoD situation.

Scott Jones: All right. There

Joe Andrieu: Because the user can select those things that actually offer that type. and I guess we'd have to think through that but there may be an opportunity with that same data model to say nevertheless there is a type here which we know goes to an authorized DOD biometric verification service endpoint.

Scott Jones: point. All right.

Joe Andrieu: So maybe we can do that without sort of inviting issuers to think they can lock it down in a way even though they could with the extra work of defining a custom type etc. so with that, I'll give you the last word on the top.

Manu_Sporny: Yeah, plus to all that I think Scott, raise a PR, please. And if you could have two examples at least in the one for the purely local and then one for the individual gets to choose use cases. I think we can refine the PR after you raise that. And try to keep the very small. don't raise one that has multiple paragraphs of text because those have a very hard time getting achieving consensus.

Scott Jones: Cool.

Manu_Sporny: The more you add the more there is to disagree with. So, keep it really tiny and really focused and really tight. and just on the core of what you're trying to get there. and it may just start with examples two examples and then we can, work on that. That's it.

Joe Andrieu: Thanks, plus one to brevity, but also I think you're going to need more than just one paragraph. It sounded like that was part of Manu's advice. but definitely minimizing it, making it concise makes it easier for people to review and engage with that, let me ask for any final thoughts. and Dacon, if you wanted to add anything. I know we haven't, had much input from you today. but otherwise, we'll move to wrapping. thank you very much. I appreciate the input. I will get that at risk marker fixed.

Scott Jones: Cool. Thank you very much everyone.

Joe Andrieu: And Scott, we look forward to a PR from you. That would be great. All right. Cheers. Meeting ended after 00:57:30 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.