Meeting minutes
Joe Andrieu: How do they take it?
Denken_Chen: Okay, Yes, we do have tech some issues for these meetings.
Joe Andrieu: Yeah, I saw that.
Denken_Chen: Yes and…
Joe Andrieu: That was great. I'm glad we did that.
Denken_Chen: so there will be some issues to discuss and if Scott is presenting he can update those for us. And then your threat modeling. G.
Joe Andrieu: welcome, Scott.
Scott Jones: Thank you.
Joe Andrieu: I like your creek flag.
Scott Jones: Yeah, I wave it proudly.
Joe Andrieu: That's awesome. Are you ready to talk about which one was it? the privacy preserving client side.
Scott Jones: Yep. What's that?
Joe Andrieu: We've got time on the agenda for
Joe Andrieu: assuming even if no one else shows up, I would love to walk through what you're doing with that. All right, welcome Ted. We'll give folks another minute or so.
Joe Andrieu: Welcome, Elaine. Now we can get started.
Elaine_Wooton: Hello. Get the party started.
Elaine_Wooton: Wait. We're recording and transcribing. Sorry.
Joe Andrieu: That's right. Now we all know you're a party animal.
Scott Jones: No parties on the record,…
Scott Jones: please. Beautiful.
Joe Andrieu: All it's just coming up on 5 minutes past 7, so let's go ahead and get started. Den, I guess I'm just going to queue up the issues here and work through that. anything else we want to touch on agenda wise or…
Denken_Chen: Yeah. Heat.
Joe Andrieu: opening comments?
Joe Andrieu: Go ahead.
Elaine_Wooton: Yeah,…
Elaine_Wooton: just real quick, if you remember, we had discussions a while ago about this young man in France who's going to work on small face vector stuff.
Scott Jones: Okay. It's
Elaine_Wooton: We got an email from him that he's making progress and once we find out what that is, we'll let you all know. But it looks like he's making progress. For anybody who doesn't know about the conversations, this young man is working on making a small face vector matcher system that will fit in a barcode and it's actually part of his PhD. So, he's greatly motivated to actually do it. once we've actually taken a look at what he's done, we'll come back and feed it into the group.
Joe Andrieu: Okay, great.
Joe Andrieu: Thank you. Did you have anything to kick us off?
Scott Jones: Let's go.
Denken_Chen: Yeah, I believe that Scott's update would be more important,…
Denken_Chen: So could have Scott first to have some update on that biometric conf vectors particularly from the progress of zero knowledge proof scheme standardization part.
Joe Andrieu: Okay.
Denken_Chen: Yeah, I'm looking forward to this.
Joe Andrieu: Let's kick off with that. So, Scott, you have the floor. Feel free to screen share and you can take it from here.
Scott Jones: Yeah,…
Scott Jones: I can't credibly screen share zero knowledge proof content because it's so over my head,…
Joe Andrieu: Fair Yeah. Scott Jones:
Progress On Zero Knowledge Proofs
Scott Jones: but I can speak to it. so off this is under trust as a branch off of the decentralized trust graph working group and we really kicked this off in July. significant progress since we last discussed this where I've been pushing as a chair. We now have a first proof running end to end built on Berkeley's open-source PCS library predicate credential system. the proof size is about 1.4 kilobytes roughly 12 milliseconds to prove and 12 milliseconds to verify on Apple silicon. 426 library tests passing. we have a reproducible reference run that anyone can execute and get the same results with fresh signatures.
<Phillip Long> zkBricks | Cryptography for Privacy, Safety & Trust
Scott Jones: So it doubles as a shared test vector set. the normative reference we're using for it is a Berkeley paper, a cryptographic framework for proof of personhood. and the Berkeley cryptography team is actively building deployable code through their open-source ZK bricks effort. and then we just pulled in the EU digital identity wallet benchmarking group with the Ciros Foundation and they're engaging as well.
Scott Jones: Two days agoish, Glenn Gore from Affinity did a live demonstration at the Linux plumbers conference. and Hart Montgomery was endorsing that as well, the CTO of the Linux Foundation. so the idea is this this became very real. We stopped just talking about it and have something that's actually demonstrating it. there's some honest boundaries though that most of the spec records are still drafts. The end to end run is a proof engine working in process.
Joe Andrieu: Thank you.
Scott Jones: It's not a fully wired product and the signature scheme still needs to be postquantum, but the pattern is now buildable in practice. and just to the kind of spirit of what we're doing now is we're looking to make a cookbook, if you will, of and the proof that Glenn is now running is essentially the first item in that cookbook where we will have use cases, constraints, things you're trying to solve for, compromises you're not willing to make, etc. and the cookbook would determine which sort of proof would be the most appropriate fit. so this is the first entry in that cookbook that we're working on.
Scott Jones: For the biometric confidence method specifically, the thought would be that this means a verification result can be presented as a proof that a real live human was verified to a stated confidence level by an accredited issuer without exposing the biometric, the identity or anything that links one presentation to the next. So the thought could be that we could update the ask at risk language from largely theoretical to something like early but demonstrated inactive integration. the example biometric ZKP 2028 placeholder that we have would still be correct, but the narrative around it could reflect that this is no longer conceptual wish list,…
Scott Jones: but something that's becoming real.
Joe Andrieu: Plus one to updating at risk.
Joe Andrieu: I guess I don't yet know what so you had mentioned this stuff from Berkeley. but the actual approach yet isn't something that's referable,…
Joe Andrieu: in the sense that the W3C likes to have, equivalent standards if we're pointing to something, That's part of the reason that this is at risk. something from IETF or ISO or whatnot. we're still a ways away from any kind of standardization like that, right? which is say we need to keep the at risk, but we can update the narrative. cool.
Scott Jones: Yep. that resonates with me.
Joe Andrieu: I'll add that as an issue.
Joe Andrieu: I think that's an easy fix. do you want to draft that language? I mean, I'll put the issue in, but then if you respond to it with a PR, we can just adopt it. All right.
Scott Jones: Okay, cool.
Denken_Chen: Yeah, let's go through these shoes.
Joe Andrieu: What do we want to talk about next?
Joe Andrieu: Stinking. I'll I guess go through our issues. I'll go ahead and pull that up.
Scott Jones: Come on.
Scott Jones: Excuse me.
Biometric Model And Vector Data
Joe Andrieu: So we just have a couple that are marked for next meeting. Shall we talk about this first one? Biometric model and vector data. All right. So this is issue 50. right now in the example we have the model and vector are separate properties and it was suggested that they might be mergeable. Let's pull up that sex. no that.
Joe Andrieu: Let me get to the section of code in our spec that we're talking about.
Scott Jones: There's something Let's see.
Joe Andrieu: So, we have this note that we might combine this model and vector data. I believe that was something that Dave Longley brought to the conversation. and that is basically here the idea I believe he's talking about combining the biometric vector with the model label is that your understanding Dan
Denken_Chen: Yeah, I remember that they've mentioned that it's tightly find it through the model and let me see the vector information and the model is tightly binded. So in this sense these two things can be defined together but we are not sure whether it makes sense. So we need some input from Scott or anyone that have implemented such features…
Denken_Chen: because we know that in the market it seems that current currently the model and the vector is strongly binded related to each other All right.
Joe Andrieu: Yeah. my concern with merging them is I think the pattern of merging that Dave had in mind was like…
Joe Andrieu: how multibase and multiash work where we encode at the beginning of the vector which model it is but that feels like it makes it hard to match and specifically hard to match with a query by example kind of VPR
Scott Jones: Thank you.
Joe Andrieu: because it'd be kind of weird to have a string that says, I want a credential with a biometric vector that starts with these couple of characters.
Joe Andrieu: as opposed to saying, "Hey, I want a biometric model that has this matching model of example biometric 2026 V3.2." to me, that feels more useful in terms of the back and forth process of negotiating what models are acceptable. that's just my take. I'm curious what other people think.
Joe Andrieu: Scott, do you know if you guys have considered something like this sort of multibase approach?
Scott Jones: We have not broached this subject matter yet in our work.
Joe Andrieu: Yeah, fair enough. Sorry.
Scott Jones: Yeah I brought it to our CTO a while back. our CTO confirmed it's technically sound that the queryability question is real but it's a design detail not a blocker. it's the idea like if queryability is Wait, where is that line? Yeah, the queryability question is the key. Yeah.
Joe Andrieu: Does that capture…
Denken_Chen: Yeah, actually it was very rough.
Joe Andrieu: what we talked about? I'll just summarize it. I think it is doable. We agree technically you could put those two together. and then I raised this issue that it might make the queryability a little bit harder. but I want to check in with Dave. what was Dave getting at? Maybe he was getting at something. we're not seeing here.
Denken_Chen: of ideas. So we can continue to discuss that
Joe Andrieu: That sounds good. All right, I'm going to post this comment and we can go look at our other issues.
Verifier Constraints For Biometrics
Joe Andrieu: Evaluate constraints that verifiers might request for biometrics. And so we talked to so when I open this we raised some examples of hey I need a biometric from a particular matching provider. I need a biometric with a particular model. Dave chimed in although he wanted to map it to one or more abstractions to avoid gatekeeping which I think makes a lot of sense. and then ting there's note regarding model maybe that's not granular enough. and I think he might be right.
Joe Andrieu: But what else would we select for And Amir chimed in about focusing on the criteria rather than acceptable models. that's an interesting wrinkle,…
Scott Jones: Thank you.
Joe Andrieu: So he's suggesting a set of criteria that providers can attest their implementation satisfy. And so the request from the verifier might be I need a biometric that satisfies these sets of criteria. it's interesting. I'm a little worried in this context about let me keep refreshing the conversation rather than diving into it.
Joe Andrieu: Dave liked that D verifier concerns and restractions. I think that is good. and we do have this at risk section. So what do folks think about what verifiers might care about and how we might abstract that so that it doesn't become a gatekeeping mechanism?
Scott Jones: There we go.
Joe Andrieu: No one's chopping at the bit. one of the weird things that is true today is that a lot of these models are proprietary. So if you pick the model, you're picking the service provider.
Scott Jones: Cool.
Joe Andrieu: And so I'm sensitive to that. But, that's also true for just about every emerging technology, The first company that comes up with it before they standardize it, and get other people to start using it, they're the only ones who are doing it. so I think to me one of the boundaries of what we want to advocate for is freely usable models and open standards around those. And so I do think it would be nice if we understood for a proprietary model what it characteristics are that we could pick.
Joe Andrieu: Scott, I'm curious if you guys have thought about,…
Joe Andrieu: if we're not picking I don't know what you would call the realized model. but, I understand you do have a proprietary model. Is that And what's your ambitions with regard to standardizing?
Scott Jones: That is right.
Scott Jones: Yeah. Are you saying open sourcing our model?
Joe Andrieu: Obviously, you're here to help standardize it so that the underlying VC can use it. do you have any plans to open up the proprietary model? If not, that's good. I want to work with you to say, "Okay, how do we best support that?" But I just want to make sure I'm understanding your strategic goals. Correct? letting other people implement the same algorithm,…
Scott Jones: Potentially Yeah,…
Joe Andrieu: but not necessarily open source, It's more about a patent license.
Joe Andrieu: I think you could have your own implementation that's better and more awesome but the algorithm itself would be something that if another implement could make then now we have two choices right
Scott Jones: I don't think we've explored exactly this question. We do have the idea of different levels of our models that could be released in different ways and to your point having our best-in-class being something only operated by us but then other flavors that could be more opened up. so that is part of our thinking.
Scott Jones: We weren't necessar I know you said it's not necessarily open sourcing but we were thinking about open sourcing things around the model but not necessarily the model itself. that's probably as far as I could take my response now.
Joe Andrieu: Yeah, that's fair.
Joe Andrieu: Take it home and see what the rest of the team thinks. I think, …
Joe Andrieu: part of where I would like to go to kick around this idea of, you've got a proprietary model that's not an evil thing. how do we support it within this architecture in which we do want a verifier to be able to say hey I want a model…
Scott Jones: Thank you.
Joe Andrieu: where realize would be one option but there's some other option that could also satisfy it and so right what's the criteria and I don't know what that would be ZKP might be one of them or…
Joe Andrieu: a particular approach to ZKP I'm just spitballing like what criteria would the verifier
Joe Andrieu: Hey.
Scott Jones: So I guess sorry just going through my notes here.
Scott Jones: Where we landed I believe the spec is deliberately model agnostic. the matching model field lets any vendor declare what they're using. From our perspective, we obviously don't need everyone to use our model. We need the framework to let multiple providers participate and let verifiers decide who they trust. the criteria could include things like what biometric modality is supported. So we do faces, others do fingerprints, some do irises. the assurance level the provider can demonstrate accuracy, livveness detection, audit certifications. whether the provider is on whatever recognized entities list the verifier accepts,…
Scott Jones: things like that. so it's kind of an analogy to TLS certificates where you don't mandate one certificate authority. You have a trust framework where CAS get certified and browsers acting as verifiers decide which ones they accept.
Joe Andrieu: I was not typing when you started that wonderful list.
Joe Andrieu: …
Scott Jones: I can put that in the chat.
Joe Andrieu: what am I missing here?
Scott Jones: Yeah, I can put it in the chat.
Joe Andrieu: I like the biometric modality, right? They might say, "Hey, I need something that's fingerprints. I might need something that's face." …
Scott Jones: Yep. The assurance level.
Joe Andrieu: I certified,…
Scott Jones: Assurance level the provider can demonstrate inclusive of accuracy, livveness detection, audit certifications.
Joe Andrieu: So, that was like livveness.
Joe Andrieu: So was certification part of the assurance level?
Scott Jones: Yeah. And…
Joe Andrieu: An accuracy.
Scott Jones: then accuracy.
Joe Andrieu: Who gets to decide accuracy? or…
Scott Jones: It's published.
Joe Andrieu: rather right I like that…
Scott Jones: Everyone's publishing various flavors of it.
Joe Andrieu: but I think we'd need to eventually get more detail about…
Joe Andrieu: what are you measuring right because there's false positives situations in context are you at a first responder situation…
Scott Jones: Yep.
Joe Andrieu: where you're in the wild outdoors and there's a blizzard or are you, in an airport in a secured area and someone can sit down and, have a deep interaction.
Joe Andrieu: those would all affect accuracy and…
Joe Andrieu: I don't know how we would start to talk about it but those are the sorts of things that I think we could
Scott Jones: And the last one was whether a provider is on a recognized entities list that a verifier accepts.
Joe Andrieu: Yeah, I think that one's very very likely to be used in practice.
Joe Andrieu: What about timeliness? no, when did you get it done? does it have to have been done within five minutes?
Scott Jones: The speed of the response.
Joe Andrieu: Does it have to be the evaluation of the biometric against this template? how old Can be something that was done 20 years ago. that's what I mean by aspects of timeliness, right?
Scott Jones: Yeah,…
Scott Jones: I call that freshness. I like timeliness, too. Yep.
Joe Andrieu: And that could be both of the biometric in the credential and of the evaluation credential. on that note that speaks a little bit to some of the things I was getting into with the data flow diagram and…
Scott Jones: Let's keep going.
Joe Andrieu: the threat model. is the expectation, let's just talk about for you Scott and then we could open it up to more generally. But with realize is the expectation that I go let's just say the DMV is using realize and they put this biometric in my driver's license this is all fictional, But let's imagine that feature and so I'm taking my driver's license to go buy some alcohol and they want to verify that biometric.
Joe Andrieu: is the expectation that the verifier would say okay you are right now giving this credential now as a result of this interaction go get an evaluation and I'm going to give you some sort of challenge string or whatever so I can know that you did this because of my request or are we imagining that someone might be able to go and satisfy a biometric evaluation and potentially use that at multiple providers within some period like an hour or 24 hours. is it an interactive go get this because we need it or can these be reused and don't sort of need that challenge replay protection?
Scott Jones: If I'm understanding you correctly,… I could go and I could be verified once and then 30 minutes later I go to another store to buy more alcohol. Scott Jones:
Joe Andrieu: Or one of the So,…
Joe Andrieu: one of the use cases that I've been exploring is the USCS I9 form, which is how you prove eligibility to work in the United States. and traditionally that is done separately for every employer you're interacting with. they have one of their agents who are performing this function of checking your passport or driver's license or birth certificate, social security card there are a number of credentials they could check as part of that. but there is an easy notion that if you have a third party service bureau who is performing who's checking the passport or the driver's license, like all that stuff that the employer would do, they could create a credential that then this person who's in the job market, pays for once, whether it's 100 bucks or 10 bucks or whatever it cost them to get that check and then they could use it at multiple potential employers.
Joe Andrieu: That's just one example of that kind of use case where the reuse may make it economically feasible where before it was not Okay. Mhm.
Scott Jones: Yep. …
Scott Jones: just digging through my notes on it. the spec supports both and it would think it would be a verifier policy decision. So the interactive pattern that you described, single use tied to a specific request. That's the high security use case. reusable, the verification credential has a valid form and valid until window. and if you could say it's valid for 15 minutes or whatever is risk appropriate for monitoring alcohol purchases. and the spec has three knobs that control that. The challenge field ties it to a specific verifier request.
Scott Jones: The domain field binds it to a specific verifier so couldn't be replayed elsewhere. and valid until window controls the freshness concept.
Joe Andrieu: Okay, very cool. And that's both for So I think all that just makes me feel that this sentence I typed is a good one because we're talking both the biometric and…
Scott Jones: Yeah. Yeah.
Joe Andrieu: the credential and the evaluation thereafter. Any other criteria that worth talking about that might constrain the verifiers request?
Joe Andrieu: Dan, how are you guys thinking about this with your work in Taiwan?
Denken_Chen: Yeah,…
Denken_Chen: we don't have lots of similar implementation here in Taiwan. I've only heard one vendor is doing this kind of metric vector identification for a very sensitive activity and…
Denken_Chen: that's it. So I think just having this vector confidence we have now. So when you push two standards, so we can use that to convince more verifiers to take that into consideration…
Scott Jones: There's So,…
Scott Jones: and It's not to take into consideration.
Denken_Chen: because for now I think most of the verifiers only knows about using the image and…
Denken_Chen: compare the face or iris or any other biometric information. Yeah. So we are at very early stage.
Joe Andrieu: And the presence on the recognized entity list we're talking about of the biometric evaluator,…
Joe Andrieu: right? not the issuer.
Scott Jones: Yes. Yeah.
Joe Andrieu: That's a orthogonal thing. We're saying go get this taken at a company that we trust, a service bureau that we trust.
Scott Jones: Another one that just bubbled up in my brain could be cost where that's why you'd want to have open- source things like that as an alternative for free with the idea being those will not be as accurate as fast etc as those that could cost more. Yeah.
Joe Andrieu: Yeah, it's interesting. I'll list it because I'm a big fan of sort of brainstorming mode and capture what people say. but if I try and translate this literally to what might be happening, then it feels like the verifier would be saying, "Hey, you need to go get me a biometric evaluation that cost you at least 100 bucks." and so they can get their friend Guido, who isn't doing a great job, but he'll charge them a hundred bucks and give them a receipt that said that he charged them that. and so interesting idea. Not sure in practice what signaling it gives us.
Scott Jones: The thinking that I came up with was verifier policies that constrain provider choice have economic implications for holders and overly restrictive requirements can create access barriers.
Scott Jones: So it could be like a gatekeeping thing.
Joe Andrieu: Interesting.
Joe Andrieu: I guess they could require be free. That's maybe more interesting than require that it cost at least 100 bucks.
Joe Andrieu: It's more of an ecosystem advocacy, I think. But Elaine, how about you? Are you seeing any criteria that might sort of align with the kind of things you care about in the document world?
Scott Jones: My god.
Elaine_Wooton: No. I'm not appropriately skeptical at this moment,…
Scott Jones: Hold on.
Joe Andrieu: …
Joe Andrieu: …
Elaine_Wooton: so I have to turn on my skepticism.
Joe Andrieu: thinking through some of the things I put myself in the world I think you're in a little bit about, securing physical documents with signed QR codes, that kind thing requiring a particular crypto suite hey they need to sign it with this thing that's postquantum because I'm not taking anything that's pre-quantum as an example like a threshold where a verifier might say look I need to get the credential coming back in a particular cryptographic way might be because they're federal right and they need to have NIST certified cryptography in that credential
Elaine_Wooton: Yeah. Yeah.
Elaine_Wooton: And I think what the verifiers would actually group that in, but I guess it goes with a lot of these things. They actually go into this greater category of just trust, right? Yeah,…
Joe Andrieu: I mean of…
Joe Andrieu: who you trust or why you would trust them? Yep, I think that's right.
Elaine_Wooton: I mean I mean that's what all our discussions are about, right? So
Joe Andrieu: And so crypto suite is one of those factors like if you don't trust the RSA algorithm anymore then you may not accept it. I think did methods also because when used typically they are a step in between to get to the crypto.
Joe Andrieu: So if you don't trust a particular DID method, for example, if you don't trust DID PLC because it's just running in blue skies database, I could see that a verifier might say, "Hey, I'll take any provider who's using a particular data suite and a particular set of DID methods." That Technically, it's not unreasonable. what about languaging stuff or location and jurisdiction? I think at the brainstorming level,…
Elaine_Wooton: Yeah.
Joe Andrieu: we should put it in there. I need someone who's based in the United States or…
Scott Jones: Pretty much.
Joe Andrieu: subject to the laws of California. that seems pretty reasonable. it seems a little lamer to require language.
Joe Andrieu: So I'll put a question mark on that as an editorial comment like you must use a service provider that uses English. That doesn't seem useful to me. But jurisdiction does. Okay. Anyone else have ideas? Phil or Ted? If not, we can look at the next issue.
Phillip Long: No, I Yeah,…
Joe Andrieu: Yeah. Go ahead, Phil.
Phillip Long: I just No,…
Scott Jones: That's something else.
Phillip Long: I just want to say I like your attention to both the DID methods and the intermediate states, so to speak, that need to be taken into account because I think those will be perhaps more fastmoving than some of the others. right?
Joe Andrieu: Our logger conversation …
Elaine_Wooton: Yeah.
Joe Andrieu: because you and I have talked a lot about what's going on in Utah and SETI might just be a regulatory compliance, So if you're in Utah, SETI is going to be implicated for certain transactions. but also you could be SETI compliant in any state on some level like we'll get there…
Joe Andrieu: where there's a way to say hey as long as you're a provider under this regulatory framework then I will accept it and that
Phillip Long: And there's going to be a coalition announced at the meeting upcoming in November of about 10 states that are describing their interest in implementing it.
Joe Andrieu: Cool. And that ends up being a little bit different than the certification,…
Joe Andrieu: right? Being on a recognized entity list. you could be steady compliance…
Phillip Long: Correct. Yeah.
Joe Andrieu: but not on somebody's list. So those are slightly different constraints.
Scott Jones: like a little kid.
Phillip Long: And I don't know what's the right way to say it?
Phillip Long: Strength or confidence that's associated with being one on the other would be. but I'm not sure how you judge
Joe Andrieu: Right. Some of this is going to be self attested,…
Joe Andrieu: I think.
Scott Jones: Okay. Yeah.
Joe Andrieu: Because a lot of it won't be testable.
Joe Andrieu: I think accuracy is going to be hard to even nail down.
Phillip Long: Yeah, It's
Joe Andrieu: What do we mean by that?
Elaine_Wooton: But also I think the whole SETI compliant thing it kind of goes in the reverse way.
Elaine_Wooton: So if an entity relying party verifier whatever says they want something that's steady compliant they've already decided that whatever confidence level or whatever is associated with that's what they want. So yeah, right.
Joe Andrieu: Right. that the regulatory compliance could speak to many of these different points.
Joe Andrieu: It's not just a checkbox. It may use fingerprints and…
Joe Andrieu: not iris. You must have livveness detection and it has to use this crypto suite or whatever like that. A regulatory framework could define all of those requirements.
Phillip Long: Right? because it will define for example did webs …
Phillip Long: if you're in that space or NID for a carry self certifying credential identifier etc.
Joe Andrieu: very cool. that was a pretty good conversation. Any other constraints or we'll move on to our next issue.
Phillip Long: Go for
Add Verifiable Presentation Request Examples
Joe Andrieu: All Thanks, folks. All right. Add VPRs. So, this is something I think that came out of our conversation, Benin, right?
Scott Jones: Thank you.
Joe Andrieu: To add some examples.
Scott Jones: Yes. Okay.
Joe Andrieu: It also as I was coming up with the data flow diagram which we'll be reviewing we won't get to it today but maybe we should be able to some of the back and forths between the different parties probably should be VPRs or credentials themselves. such that for example if there is a challenge string from the verifier that could be presented in a credential that is given by the holder to the evaluation provider so that they know it's a legitimate challenge string to use in this ceremony as opposed to a challenge string that the holder might just be making up or…
Scott Jones: That's good.
Joe Andrieu: his software might be making up.
Joe Andrieu: I don't know that that attack has any value. making up a challenge string doesn't seem like it would actually do anything for you. but right, we need to add some examples. let me actually pull up that diagram and ask that question. So, this is now what I hope is a unified component diagram. It doesn't have any of the flows. That's the next stage. but when Dankin and I reviewed this last week, we came up with things like, hey, I need a request for a biometric template that you would give to the evaluator to say, hey, this is what I need back from you.
Joe Andrieu: and an evaluation request which I think in most of our flows we were thinking of you put it in a VPR but it could be a VC on its own. in case you were not in a VPR based A verifiable presentation request that goes from the verifier to the holder and then is filled up with credentials. and sent back. does that notion strike anyone as weird? Does that seem like I'm catching this knee that we do need to specify at least have examples even…
Scott Jones: Instruction.
Joe Andrieu: if they aren't signed credentials? Any thoughts on that?
Phillip Long: Does this have any relationship to things like an MDL verification? Correct.
Joe Andrieu: Interesting. Do you mean could an MDL satisfy this flow?
Joe Andrieu: I think in this case we don't have the biometric in the MDL we might have the image right so we could maybe do the biometric image flow someone correct me if I'm wrong I mean does the ISOMDL have a place for an issuer to have a biometric template
Scott Jones: Thank you.
Joe Andrieu: is it a point of extensibility they could add? To my notion, it's no, but I'm not a deep expert on the MDL data fields.
Elaine_Wooton: I think that no because I think the whole biometric thing is device not in the MDL itself. Am I wrong? I don't know.
Joe Andrieu: I think it's Go ahead. Yeah, it would be interesting…
Phillip Long: I can look at the spec.
Phillip Long: I've got it on my machine somewhere here. So, give me a minute or two and see if I can make any heads or tails of
Joe Andrieu: if MDL had an extensible data field that could be used in that way. maybe they weren't thinking of using it that way. That's how some of the early signing PDF 417 stuff,…
Joe Andrieu: sort of happened was looking at these extensible fields and…
Scott Jones: Thank you.
Joe Andrieu: and putting signatures in there.
Joe Andrieu: So I don't know. It would be interesting to find out. so I'll add that here,
Scott Jones: Thank you.
Joe Andrieu: Is there should be a way to get to a did off kind of thing. except that they aren't using DIDs and we're fairly specific. do MDLs have a counter sign by the user mechanism? here's how the user counters signs the MDL upon presentation.
Elaine_Wooton: They click unlock on the phone,…
Scott Jones: Okay. Elaine Wooton:
Elaine_Wooton: don't they? That's Apple from the device.
Joe Andrieu: But is it bound to the device in a way that when the user presents it through the wallet, the credential is countersigned by some sort of key. I mean, it seems like it should, but I don't know if it does. I'm not familiar enough with that workflow.
Elaine_Wooton: I have the explanation on my screen and I don't even know enough to understand what I'm reading. So anyway,…
Scott Jones: That's right.
Elaine_Wooton: okay. what this says is for TSA, which is a special case,…
Joe Andrieu: Mhm.
Elaine_Wooton: the officer's reader captures a live photo and compares it against the portrait stored in the MDL. so it's saying that the MDL has an image. And we know it does because when I use my verifier app to check somebody else's MDL, what I get in response is the picture and the date and their date of birth. So we know it can present the picture,…
Scott Jones: What's the potential?
Elaine_Wooton: the file picture. So, it has that in order in order for the wallet to release the credential, the individual has to unlock the phone, face touch ID or fingerprint or a passde. So, passcode.
Joe Andrieu: a passcode. Yep. That's a get out of jail free card that Adar used as well.
<Phillip Long> holder and runs a 1:1 facial recognition algorithm comparing the live camera capture to the cryptographically signed portrait extracted from the mDL.
Elaine_Wooton: Yeah. says it proves the person holding the unlocked phone is the enrolled holder of that device,…
Phillip Long: Yeah, I'm also reading that it says the facial recognition algorithm compares the live camera capture to the cryptographically signed portrait extracted from the MDL right does not say it's signed counter signed
Scott Jones: It's
Elaine_Wooton: not that the phone's owner is the person named on the license. So, right,…
Joe Andrieu: It actually doesn't do what you just said. It just said that they could satisfy whatever that is. They might know the pin. Elaine Wooton:
Elaine_Wooton: and that's…
Joe Andrieu: Yeah. That's right. Elaine Wooton:
Elaine_Wooton: what it says specifically. it does say it proves that the person holding unlocked phone is enrolled holder, which is not true because anybody can have the PIN. Yeah.
Joe Andrieu: It's a challenge, right?
Joe Andrieu: So the portrait's definitely there and the portrait is signed over by the issuing authority. but I don't think it's counterigned and I think that for me pulled up this other note that I wrote is that the MDL I think is very prescriptive about the transport mechanism. so, putting an MDL in a verifiable credential workflow when the MDL is a ISOM doc,…
Elaine_Wooton: Yeah.
Joe Andrieu: might be a mismatch.
Joe Andrieu: Which I think is why California has both data models, which I think ultimately is what many of us are going to be doing, multiiformat capable wallets and transports and such. So this was largely add some examples but I think the MDL conversation was also quite interesting.
Scott Jones: There we go.
Threat Model Development Status
Joe Andrieu: All right let's look at our second last issue. So start a threat model. So we have in fact started on that. it does not exist in a repo form. I want to get the data flow diagrams here.
Joe Andrieu: Basically how this tool is working is I've got the top level. I think these are the components that all of the flows can be implemented with these components. Many of the flows do not need all of the components. some of this never needs to talk to DIDs and…
Scott Jones: Which one?
Joe Andrieu: did resolvers and whatnot. so each of these other flows are going to be trimmed down or situations are going to be trimmed down and…
Elaine_Wooton: I will say we are fortunate to have Joe Mr. the threat model so that we all don't have to invent this.
<Phillip Long> From Claude: "The device authenticates the session, but it doesn't countersign the credential, and the biometric comparison isn't part of the cryptography."
Joe Andrieu: we will have the flows for each of those. So, that's in process. I'm not quite ready for review yet. but I'm hoping to have something on our next meeting. That's a short update on the threat model. thanks.
Phillip Long: Plus one to that.
Scott Jones: What else?
Joe Andrieu: Thanks, I appreciate that. it's an interesting and at least for me, fun challenge.
Joe Andrieu: I mean, luckily I like my job and my job is often teething out sort of these nuances. and although I may not be as smooth as Manu at arguing over the nuances, I do really enjoy trying to understand them and, figure them out.
Scott Jones: Thank you. Okay.
Privacy Concerns Of Biometrics
Joe Andrieu: Privacy concerns of using biometrics. So, Dan, you added this. Of course, we do need a privacy consideration section.
Joe Andrieu: Having some shoulds about prompting the holder is good.
Joe Andrieu: What else do we have in here? Selective disclosability is good. Go ahead, Denin. You want to introduce us to where we're at?
Denken_Chen: So I think the only thing we need to make sure is once we started the thread modeling stuff the process and…
Denken_Chen: what's left for a security and privacy considerations is such description that we should supportive disclosure or some wording around this be left in the privacy considerations also.
Scott Jones: Happy music.
Denken_Chen: Yeah so I think at our next meeting it will be our last meeting before TAC so we can focusing on threat modeling and how will we draft the privacy and…
Denken_Chen: security considerations of course and then when in t we can kind of finish up the threat modeling discussion and really prepared for horizontal review. Yeah.
Joe Andrieu: Yep. Yeah.
Joe Andrieu: In fact, so I appreciate that. one of the things that I think we can get to I think we can start horizontal review either at TPAC or before what we need to do is make sure we have enough meat in the spec itself. And I do think we have a good draft for each of the three items we've talked about. We've got issues we're still working through. So, we're not done, but that's not the threshold for horizontal review.
Joe Andrieu: So I think once we get a draft even of an incomplete threat model then we can say hey we've got this spec it's young but we would like to start getting input. and so I think that's a matter of leg work for you and me Denin to go create the issues on the different horizontal groups. but I would like to try and have that in horizontal review by the time we're done with TAC. do we actually to speak to that just for a few minutes as we're wrapping up? do we have any particular topic that we want to get on the VCWG agenda? because if we have something we want the rest of the group's buy in on that we feel might be controversial, then we absolutely
Joe Andrieu: They should get in there and grab a half hour,…
Denken_Chen: I don't have one for now.
Joe Andrieu: an hour, or whatever it might be to raise that issue.
Joe Andrieu: I don't offend either. I think of the folks on this call, I think. Scott, are you planning on being there? that I'll take that as a no.
Scott Jones: When is it?
Scott Jones: Yeah. …
Joe Andrieu: It's in a couple of weeks in Dublin. So yeah,…
Scott Jones: I wouldn't be there in
Joe Andrieu: you probably already would have dealt with it. we always do for remote participation. and I think that's how Denin's planning on attending. Tell Ted I hope you can join us that way as well. Although I know time zones are kind of a pain in the butt. and…
Elaine_Wooton: I'll be there in person.
Ted_Thibodeau_Jr: It is my plan.
Joe Andrieu: then I think Sorry, what was that?
Ted_Thibodeau_Jr: It is my plan.
Joe Andrieu: Okay, great.
Joe Andrieu: And I think Elaine and I are going to be there in person. I think Elaine is, So, let's Denin, let's think about that in our next editor's call. and see if there's something we want to propose to get on that agenda. I know we are going to have a moment to report out as a task group. So, it may be that we have a five minute or 10-minute update. and here are the hot issues and see where that goes. But let's thank and see if we want to request more time if we've got some hairy issues.
Scott Jones: Thank you.
Joe Andrieu: Okay, I think that's a wrap. I actually wish I had ended a few minutes earlier. but thank you all for your time and attention today. we're back here in two weeks and as Denin mentioned, that will be our last group session before TPC.
Joe Andrieu: All right.
Elaine_Wooton: Sounds great.
Elaine_Wooton: Thanks y'all.
Joe Andrieu: Thanks all. Cheers.
Phillip Long: Cheers. Meeting ended after 00:59:08 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.