Meeting minutes
Meeting Recording And Minutes Sharing
Denken_Chen: I think we should start it by claiming that this meeting will be recorded and…
Discussing Meeting Time Slots
Denken_Chen: the meeting minutes will be shared in our mailing list. so if there's any concern you can raise it and since this is the first time we are meeting at a different time I think we should start by discussing about the meeting time we are open discussion for everyone initially we proposed two time slots here and we could pick one of them or alternating between them
Denken_Chen: We started by pitting this time and it's a little bit in the night for the east or west coast. it's in the morning in Asia. so we would like to know whether it's a good time for most people. so firstly I have been connecting with most guys. they are very interested in joining our standardization for the biometric stuff as well. but given the time zone issues, they will probably only be available for the first one the UTC 2 p.m. and that'll be in the morning for the west and east coast of America and in the night for Asia.
Denken_Chen: So, I think we probably should move to another time slot or alternating between these two. I so like to learn more about how the community knows opinions about these two times not. Yeah, please. Many
Manu_Sporny: Yeah, I think we can see from the attendance some of the other calls have 11 to 21 people and it's just us here today. I mean plus one to doing friendly times. I think that's good. I don't so I alternating is probably fine. but we're going to have to get the rest of the working group with more eyes on the spec I think to make the type progress that we want especially based on the type of stuff that we're working on. so maybe we alternate right age Pacific this time slot at least once a month and then the other time slot just my two cents.
Manu_Sporny: I know basically everyone from our company was like,…
Denken_Chen: Let me paste here.
Manu_Sporny: I'm not showing up for the call. which is unfortunate, but that's what happens when you go outside of East Coast business
Scott Jones: I just had a quick hand raise.
Scott Jones: What was the morning time for the alternate in the east coast? What time would that be?
Joe Andrieu: I believe it was 10 a.m.
Joe Andrieu: It was same time slot of the two that we had considered, right, Den? The earlier time, which was 7:00 a.m. Pacific, 10:00 a.m. Eastern. Right.
Scott Jones: got it.
Scott Jones: That's very friendly to me. I support alternating
Joe Andrieu: Yeah. I want to also endorse alternating. it's a little annoying, but I think it's important to try and get as wide an audience as we can. I want to moderate a bit what you suggested, Manu, just because as someone who's potentially being asked to go to all these task forces, I do not have the time to go to all these task forces. So I don't think it is a healthy goal to think that we're going to get a majority of the VC working group to show up here. plus one for alternating
Joe Andrieu: One of the things that happened and maybe we can just go with this decision that we've made here. but one of the things that happened unfortunately was in the VCWG was suggested hey go to GitHub and raise an issue and that's where we can figure out who wants to be in the task force and what the times are. But I don't think that had very good visibility and certainly this call doesn't have good visibility for all the people who don't like this time. so do we think it would be worth it to bring this question up to the rest of the group or just provide the two times as alternating as what our plan is and ask for feedback? Bad
Manu_Sporny: Certainly let's at least suggest alternating times to start off and then we could do a poll like everybody else is doing right noting that we are going to have an Pacific friendly time that at least one of the meetings will be that and This other poll is for anybody else that wants to participate, just so we can get a count of the number of people that want to participate in the task force from the entire working group. and then kind of, figure out what that other time's going to be. that works for them. I think Elaine and Patrick have already sent out doodle polls.
Manu_Sporny: I'd suggest we kind of do the same for this task force as annoying as having to fill out six different doodle polls is.
Joe Andrieu: Right. Hey,…
Joe Andrieu: Ted. Go ahead.
Ted_Thibodeau_Jr: Yeah. …
Ted_Thibodeau_Jr: I'm terrible at the mailing list content. I may or may not have seen the messages that included these links, but I know that I haven't gone to doodle polls in quite some time, so I probably haven't seen these. it would probably be worth sharing those links in whatever issues exist on GitHub.
Ted_Thibodeau_Jr: They're more likely to be caught just because of workflow.
Joe Andrieu: cool. …
Joe Andrieu: so I think we can be responsive to that for this at least, Ted, which is, I'll go create a doodle poll and we'll send it out to the mailing list and we'll attach it to the issue that you already responded to. So, if you're tracking that,…
Joe Andrieu: I think you get a notice. Does that work for you, Taken? Okay,…
Denken_Chen: Yeah, that sounds great.
Joe Andrieu: then Denin, I want to defer to you. Do we want to talk about the realize issue first or the PR?
Denken_Chen: I think we should talk about the first. it's more important for so the minute I should study by subtopic and all right okay yeah please Joe have a brief introduction for
Manu_Sporny: Yes, you can do that. subtopic colon and…
Joe Andrieu: …
Manu_Sporny: then the link to the issue.
Assurance Method Vs Assurance Level
Joe Andrieu: so this was our first pass at framing sort of our shift in scope with regard to when this was first ideiated, it was just going to be confidence method. and as we went through chartering, we said, "Hey, there's this assurance thing. Maybe it's assurance method." and so this was an attempt to draft that and try and clarify how would we be approaching that. some of our initial feedback if you look at the PR there Dave made a comment that we also talked about it on last call.
Joe Andrieu: he wasn't as big a fan of the assurance method, but I think he also wasn't necessarily a fan of it being assurance level, but what came together for Denin and I as we were kicking this around was that there is, I believe, a distinction that is valuable between confidence level, assurance level, and evidence. So, I added a paragraph, it's more than a paragraph, it's a whole section with a little table to try and explain that distinction.
Joe Andrieu: And that's where the PR stands right now. and I'd love to get feedback because think if we can merge this in I'd like to ask the group then to endorse it because I think this will settle the properties hopefully. and then there is another interesting thing that I just went over today that I'm tempted to push to the PR. if I was 15 minutes ahead of where I was when I realized this, I may have gone ahead and pushed it anyway. but I want to check the sense of the group to see if this is just editorial and it was what we expected or not, which is as I started looking at a schema for what we've been calling the verification confidence method and there's a bit of a problem with the language there.
Joe Andrieu: if it's type were verification method then we've got a name collision with that property value in controlled identifier documents and DID documents. and I think we are not in fact putting the whole verification method in there in the way that it shows up in DID document. I think at least my intention was just to have the DID or the CD URL that points to a verification method. And so I think the right term is probably verification method reference or something like that. And I just wanted to get feedback, if anyone else thought we were actually putting the full verification method in there instead of referring to some sort of controlled document. then maybe we could have that conversation.
Joe Andrieu: Go ahead, That's right.
Manu_Sporny: I'm only following about 60%.
Manu_Sporny: I think is this for where the confidence method are we putting the entire verification method in there meaning public key and all that kind of stuff and not just a reference is that what you're okay okay so here's an argument for not a reference one of the ways people have been kind of issuing these digital credentials
Joe Andrieu: I think it should be a reference.
Manu_Sporny: is they have been for better or worse they have not been modeling like people and things and vehicles. They've been like ing the driver's license itself. So they've been treating the data model as we're not talking about the individual. We're literally talking about the piece of plastic and it's its properties and all that kind of stuff. so one type of verifiable credential would be a driver's license with some kind of cryptographic authenticator embedded on the piece of plastic.
Manu_Sporny: So that is the subject of the verifiable credential is it's not the person there is an authenticator that exists and for those types of credentials having confidence method and having the confidence method fully describe the verification method this is a public key that is on
Manu_Sporny: card and…
Manu_Sporny: the card can generate digital signatures if you give it a challenge. In those cases, you would need the full verification method. Does that make sense?
Joe Andrieu: Yeah, actually I really like that.
Joe Andrieu: What I'm picking up. So that use case is really solid. I also really like the other use case. So maybe what we should do is specify you can specify it with a reference or you can embed it directly.
Manu_Sporny: Yeah. Yeah, I think both are valid. We just have to make sure both are valid.
Manu_Sporny: I want to make sure we can explicitly say this public cryptographic key that exists on the
Joe Andrieu: And…
Joe Andrieu: then if in fact we are using the sort of embedded notion then I think the type as verification method still works and we would just refer to that type wherever it's coming from. I forget if it's C did or…
Manu_Sporny: Yes, agreed. Yeah. Joe Andrieu:
Joe Andrieu: data integrity or So, That's helpful. and I guess I need to look at this text to see if I would want to change this, but we could accept this PR and then when we come back because my next chunk of work here is to draft up the language about the verification method. so maybe we can address these idiosyncrasies with that PR. so let me ask if there's any concerns or questions about this as it stands. Go ahead, Ma.
Manu_Sporny: I did have a chance to very briefly read over it, not in depth. Dave's concerns resonate. I'm wondering and this is something like if we put a little issue marker on assurance level and say hey we're still kind of discussing this we're just kind of trying it out. I'd be fine with merging the PR but not without a warning. the concern I have is the assurance level it's at a point in time potentially so that's one concern is that maybe this assurance level needs to be bound to kind of an event or a point in time rather than saying Joe has an assurance level of NIST 863
Manu_Sporny: three, four or whatever. so that's the other concern was the assurance levels. I get that, we have NIST 863 and IDIS LOA and those sorts of things. It wasn't clear to me what the values would be.
Manu_Sporny: in the assurance level property would we have assurance level and it would quite literally be the string 863 -4 LOA or would it be an object where that's a type and there's evidentiary examples of these are the things that I did to reach this assurance level or does that go in evidence it's not clear to me, and maybe it's just…
Manu_Sporny: because I haven't done a thorough read, what that object would look like.
Joe Andrieu: Yeah,…
Joe Andrieu: part of that is because we haven't written it up yet. so that level of detail is still TBD. my sense of it is I don't think we want to put the evidence in. I think the evidence for many assurance levels are not possible to put in there or they would be untenable to put in there terms of biometrics or whatever. You can't put the evidence that we met this person in we can't have the recipient meet them in person if that was what was required for that UA.
Joe Andrieu: The distinction I'd make to how he framed it is I think there's a type that is like NIST 863 UAL but then it has a value because there are different levels and so those levels will probably be like I123 for NIST I think EIS uses high low and medium or something but whatever the strings are that those specifications tell us to use I think are the values that would go in there with the type to tell you which other assurance level we're using
Denken_Chen: I think in the beginning I would like to introduce assurance level things is when the government started to issuing credentials for example driving license. we got questions a lot about how do we make sure the digital driving license is issued to the exact subject to his hand or her hand so there has to be something with the assurance level that the issuer claimed what it has checked.
Denken_Chen: So for example for usually in our case the physical driving license is issued in person. so the issue will be verified the face other identity document materials in person. check his face. so he'll be making sure that for example the photo on the driving license is exactly the subject and the holder. But for the digital version of it, it's more possible that it's issued only online and without a lot more else checking.
Denken_Chen: So in this case there will be level two because it's issued based on previously identity verification stuff but through online so there will be no inperson seriously checking procedures. so for us it will be much easier to communicate to the citizens that the digital version of it is one level less than the physical level is not equally the same. So that would be reasonable for other verifiers to know that the digital version of it should only be used in not very serious scenarios.
Denken_Chen: for example, just checking your age or your driving license status, but should not be used for serious ID verification scenarios like the banking stuff or government related stuff. so that's why this assurance level I think it's quite important for the issues to communicate and I also recall that from Ical their digital travel credentials has similar structures they have three type of it and…
Joe Andrieu: I s***.
Denken_Chen: for the most digital equals to the physical one type three
Denken_Chen: it has to gone through a lot of details including how the hardware software is probably certificated without the need to bring a physical passport again. but for now I think they're also just doing things like type one and type two like u the digital version is not directly equal to the physical one. So you have to so this claim is very similar to the assurance level. it communicate that you should still check the physical one if you are very seriously need to identify this person. That's it. And may you please
Manu_Sporny: Yeah, I mean plus one for needing something like this. that's certainly not what I'm saying. So yes, we need a concept like assurance level. Yes, we should put it in the spec. plus one to that plus one to the alignment between digital credentials and their physical counterparts and things of that nature. we have had these discussions with the US federal government and state governments like California DMV around what is the assurance level of the individual. the digital credentials are supposed to have as high of a assurance level as the physical cards do when you hand them out.
Manu_Sporny: if not higher ideally. plus one for it to exist. I think what I'm kind of talking more about is the data modeling around assurance level. So I think Joe you said this is probably an object. the type is probably going to tell you what kind of assurance in
Joe Andrieu: Yep.
Manu_Sporny: what is it definition you're IDIS is it NIST 863 or something else and then you're going to have some piece of data that tells you whether or not you're level one through or one through three whatever whatever that type what the range is for that so that's fine I think
Manu_Sporny: Yes, the object itself, makes sense. assurance level, one of the it feels like the data modeling is a bit off, right? because we're using, JSON LD link data the way that we look at all of these things is like what is assurance level bound to? It's bound to the subject. And what happens when you have a bunch of different credentials about the same subject and you merge those graphs together? what does the resulting document look like? if we had assurance level, I guess hanging off of a subject like a person, then you end up merging all those things together and the person has every single possible u associated with them in the merged object.
Manu_Sporny: versus maybe putting the assurance level on the credential itself or saying that this credential is good…
Manu_Sporny: if you are attempting to do this below wondering what your thoughts are on that Joe on the data modeling
Joe Andrieu: Yeah, I think it's actually a context error.
Joe Andrieu: the way you described putting everything in your Uber knowledge graph. you lost the fact that I was performed by a particular issuer for a particular claim. it was not establishing that for the verifier because we can have an I level three which requires inperson verification and a remote verifier who never has anyone in person. So the IIL doesn't sort of get to propagate up to the verifier. It's just a statement that the issuer before they issued satisfied some regulatory regime about identity assurance. So I think in your use case you should retain …
Joe Andrieu: why you have this assurance level and that should include both the issuer and the credential. Okay.
Ted_Thibodeau_Jr: that graph merge is the thing that's been at the back of my head.
Ted_Thibodeau_Jr: Every time I look at this, it has a problem. because either we have to hang the assurance level and the related method off of every single claim to which they're connected.
Ted_Thibodeau_Jr: or we have to have a way to hang those two key pieces off of the collection of things to which they relate. And somewhere in here, there has to be a way to not merge statements that aren't accurate, I looked at somebody's driver's license and so I believe that their date of birth is accurate and I believe that their eye color is accurate, etc. But I don't want that to mesh with somebody else's observations, no matter how they verified them, no matter how they confirmed them, whether they looked at the person in front of them.
Ted_Thibodeau_Jr: I mean, I'm looking at them, too, with their license. And yes, their eyes are blue, and that's what it says on the plastic, but the next thing that happens is somebody else is less rigorous in their data, and suddenly their eyes are blue and…
Joe Andrieu: Okay, Ready?
Ted_Thibodeau_Jr: brown and assured by the driver's license, which does not work. There it is.
Manu_Sporny: I guess plus one to that. I am a bit concerned about associating assurance levels with claims. I don't know the best way to got some ideas on how we could do that, but I don't think what's in the spec right now is any of those. but going back to what you said earlier Joe I wasn't suggesting that this propagates to the verifier although based on the types of discussions we've had inside government agencies they are very much
Manu_Sporny: trying to match the incoming IAL to their own IAL. so okay,…
Joe Andrieu: Let me load it.
Joe Andrieu: Let me interrupt you because I'm not sure this is a property that's in the VC that's going to the verifier. So, I'm not sure how the verifier isn't using this. the point is for them to see that.
Manu_Sporny: I thought you said Okay, I misunderstood then. I thought you were saying the verifier is not going to use it or…
Joe Andrieu: Okay. No,…
Manu_Sporny: shouldn't use it. yeah.
Joe Andrieu: no, no. My point was you shouldn't collapse it if you're done with your point, I can try and respond. I didn't want to cut you off.
Manu_Sporny: Yeah. Maybe we need to be a bit more interactive here because what do you mean my expectation is that the assurance level is a statement by the issuer of I got to this level when I analyzed this particular subject in the credential.
Manu_Sporny: So your puppy the person your spouse whatever you hang assurance level off of like I did as an issuer I did an NIST 863 and…
Joe Andrieu: Yep. That's right.
Manu_Sporny: achieved an IL of three with that subject. Is that correct? Okay. All right.
Manu_Sporny: And then as the verifier is going to look at that subject and basically be like, okay, this subject has anal level three four. yeah.
Joe Andrieu: for that VC.
Joe Andrieu: You cannot take it out of the context.
Manu_Sporny: Yeah. Yeah. I'm agreed. I'm not arguing that.
Joe Andrieu: Okay.
Manu_Sporny: the verifier is going to basically say okay for this VC they reached this IIL and what I was trying to say before we've talked with federal agencies is the way the state agencies think is they're like if there's this other agency federal or state and they may reached IIL 2 and three I'm going to vet their processes and if I out of band agree with their processes, I'm going to treat that credential as having the same level of I mean meaning meaning if I go through my process and I reach I3 then I have high assurance
Manu_Sporny: 3 that they did and the IL3 that I did are equivalent and therefore I can do an IL3 process. Clearly the verifier has to go through that process themselves. but there's a lot of what did they do to reach I2 or IL3 and sometimes these organizations don't agree of the level of that the remote agency got to. So I guess what I'm trying to say is this information in and of itself is usually not good enough for the agency unless they do a lot of stuff out of band to understand what the assurance level is from the other agency. Hopefully that made sense.
Manu_Sporny: versus confidence method where you're just kind of like they did a cryptographic proof like that's a lot easier to reason through than are your 2 processes the same as my IL2 processes that's
Joe Andrieu: So, two things there. One is I don't believe at least my intention isn't to require that the issuer execute the confidence method beforehand. So, I think there's a bit of I understand the motivation that the verifiers want to magically skip the work they previously have to do and I think they still have to that's the goal. if I could get this magical credential and then I don't have to do an in-person ceremony. But if it's I3, you have to do an IAL3. You have to do an in-person ceremony.
Joe Andrieu: And so I don't think it meets policy directives to take an incoming digital credential and then assume that they did things correctly precisely because of your last comment that the agencies disagree about whether or not particular practices met a particular that's fine because I don't think we're trying to transfer and say hey if social security did something at IL3 then DoD has to accept it as I3. I don't think that's accurate at all. I think what they're going to get is a credential where they can accept a credential that was issued by Social Security Administration, except that the Social Security Administration believed that they had a chain achieved 3. if they care about understanding what that means, they could talk to the Social Security Administration, If there's disputes about what is 33 in this context.
Joe Andrieu: But I don't think we can literally satisfy in that use case DoD's getting IL3…
Joe Andrieu: because they didn't see the person in person. Thank
Denken_Chen: I agreed manual that saying that even the N standards I could be inter interpreted very differently across different parties and…
Denken_Chen: I even saw that some government taking that framework work and define 2.5. that's interesting, Right. So most of the identity framework is very roughly stated and I remember that Ted mentioned that it's too rough. It's not appropriate to derate using in our framework.
Denken_Chen: but on the other hand I think we should add forum field to that issuer to fill in their own policy for the details of how they issues things. It probably will looks a little bit like the certification practice statement from the PKI world. they will have a detailed document describing how they are issuing stuff. so for example if we are using the N standards IL123 but probably there will be some little details not very the same across different parties we can outline the details in the document.
Denken_Chen: I'm not sure whether that would be a great move and another part is I think we basically agree that the insurance level things should exist but the data modeling or where it should exist what it should be expressing is still under discussion so I will suggest that supporting manu's opinion that we adding
Denken_Chen: warning onto the assurance level to discuss it in details in the future but making the consensus that this assurance table should exist and we will continue to discuss it. Yeah, that's it.
Manu_Sporny: Yeah, plus one to that. I'd be fine with merging with that issue marker in there. so a couple other thoughts on issues. one of the things that struck me as I was, I mean, I was thumbing through this. we don't have the use cases on where you would use assurance level. And I think explaining that would be useful because we just teased out, quite a bit of nuance in what should a verifier use assurance level for, what should they not use it for?
Manu_Sporny: there were some privacy and at least security implications there that should probably be spelled out in the spec or in the threat model when someone uses assurance level. So that's not for this PR. I'm just noting like it sounds like we've got to do some work around it. I would imagine same thing for the realized issue. we're going to have to highlight the use cases and security and privacy and things like that So having those things previous to this PR would have been helpful but whatever it's certainly not expected at this stage. the other thing about assurance level I was thinking is there would be another way to model it would be as an event to say that this subject experienced an assurance event at this point in time and you'd still have the same properties. the assurance event was a nest 863.
Manu_Sporny: this is the entity that participated or applied the assurance event and this is the result of that assurance event as an example for an alternative way that we could do this. I just want us to put an issue marker saying that we're still going to explore the data model around assurance level.
Denken_Chen: Make sure you're muted.
Manu_Sporny: That's it.
Joe Andrieu: Yeah, thanks. Sorry about that. plus one for the issue marker. So, amongst the five of us, I think we have consensus to try that out. so I think we can move forward with that. I want to push back a little bit on the point in time. Although I'm fascinated why it feels important here. maybe we can discuss that as this unpacks maybe when we have a draft of the assurance level with a particular, spec text for a schema. because a driver's license is also at a specific point in time and we're willing to accept that the certificate itself the VC embodies that timing correctly and we don't have a separate sort of temporality other than the from valid until mechanism. but we can talk about that and…
Joe Andrieu: I think that will be fun in the future. with that Denin do you want to introduce the realize thing or do we just hand it off to Scott? I don't know which issue it is that we are which issue
Denken_Chen: Okay, I will paste it.
Client-Side Biometrics Specification
Denken_Chen: Welcome Scott and we've seen your presentation at In this issue 31, there has been some amazing discussions along there. so probably you could give us a introduction about the whole issue and recent discussion so can continue to join it.
Biometric Confidence Method Spec Details
Scott Jones: and the concept is to define collectively a spec for how we could achieve the notion of a privacy preserving clientside biometric. the idea being that it's vendor agnostic. So an open framework where multiple vendors could participate and in fact you could even use an open- source tool if you didn't want to use any the conversation thread covered sorry this is obviously my first time presenting to this group I'll get smarter on talking into these things but we were trying to define what an input and output spec could look like the output format the notion of what a high level flow could look like for issuance and presentation trade-offs between
Scott Jones: online versus physical verification because there's different risk profiles for both and different attacks you might expect. and there was a lot of great feedback and I have taken that feedback. the summary of it includes an ID based confidence method. So the confidence method has its own UYU ID not tied to a person's DID. adding the notion of an input type. So distinguishing a static image from video for security implications and potentially other inputs in the future. I could imagine a nested biometric model field which would a cleaner data modeling as Dave Longley suggested. adding the notion of assurance class so a vendor neutral tier system as air suggested.
Scott Jones: an expanded security section that covers things like vector inversion where that's a concern someone raised where it's theoretically a nonzero possibility but under real world conditions very difficult to handle but there are methodologies to deal with that and I'm happy to describe them. we included open- source references. So, as I mentioned at the be beginning of my discussion here, the idea of it doesn't have to be a specific vendor's model. It could even be an open source model to validate that this would work and to use it in production if you wanted. and then the output is really about the confidence method.
Scott Jones: where this field that I've written as credential subject id points to the confidence method uu ID not the person and then adding the notion of a match date separate from a credential validity window.
Scott Jones: So I've got an updated version of the proposal reflecting all these things that I did not update yet until this call, but that's kind of where it is. Apologies. Maybe not speaking your language accurately yet.
Joe Andrieu: Cool. No,…
Joe Andrieu: you're doing great. I'm not seeing anyone jumping on the queue. I had not read through all this. I'm stoked by how detailed this conversation is and I've not been able to process any of the nuances here. but one thing that triggers for me is I think you're trying to define three things which sounds awesome.
Scott Jones: Good.
Joe Andrieu: One is what's going to be in the VC itself and then I hear you talking about inputs and outputs of the actual biometric challenge itself if I'm understanding that which feels right for the spec to say, "Hey, we're going to use this biometric. This is the information you get from the VC. This is the input you should get from whatever your device is." And when you're done, you get an output. And what that teaches me for the other methods is that maybe we really need to be clear that these are not binary answers.
Scott Jones: Fascinating.
Joe Andrieu: And so I think we haven't talked about the potential sophistication of the results of evaluating a confidence method. and we should. So that's very interesting. Go ahead, Manny.
Manu_Sporny: Go ahead first, Dankan. I'll go after
Denken_Chen: I'm very interested in introducing this back into competence …
Denken_Chen: because it's really a use case that whether the biometric is from eventually the verify will use that information to doing some checks. so firstly I would like to understand how the hosting could start. I mean for example without any device integrity checking stuff that would be simply a self claim from the holder to do the client side biometric and understanding it correctly.
Denken_Chen: Yeah, because by putting all of the biometric vectors or some software from the client side to generate the whole for other verifiers to using it started looking like a self claimed credentials. so if there's other proof that that could be believed or checked against the whole verifiable credentials is ensured or that integrity has been ensured and there has not been tempered with for example
Denken_Chen: The threat model in stop will the security consideration mentioned that it could be defake or other many nuculation of the video stream or the photos data. how does the verify check that? Yeah.
Scott Jones: Yeah. some of the concepts in my mind I think that would address aspects of this would be like how you on board to this system. So, I could imagine day zero I'll make it up and say there's IDV or something like that to ground somebody just as one example of how to possibly do it. Ground someone to a residency of a government ID, a livveness check and a selfie to say great one of these IDV vendors says you are that person. Great. Now you are sort of onboarded to this system with the client side metrop biometric where the same or a very similar in time selfie is captured to say when that verification happened now I've got an embedding of you.
Scott Jones: So that to kind of manage the integrity of the day zero onboarding is a methodology I'm familiar with as it relates to what you're saying what you're describing is inherently the risk of a client side approach and it's trade-offs that we're balancing because as you noted you you liked my thank you for the feedback you like that presentation I gave very few companies are talking about client side because it can open up the risk profile of has this phone been hacked? Has it been broken? Has the OS been I'm forgetting my hacking terms right now, but I think you get and the idea that you have this balance of risk where somebody is trying to buy beer versus somebody's trying to access a million dollars in their bank account.
Scott Jones: And you can just a very crude example but those are very much in opposition ends of a spectrum of risk profile where it feels like you could accept the risks of potentially someone in an online scenario and I don't know how you would do this live in the moment. I can think through it how you'd hack your device, bring it into a convenience store for example to attest your age. But generally our thinking is that the risks of that would balance out against the exposure of what's at stake being able to buy beer for example versus the level of effort you'd have to go through to do the same in the payout of accessing inordinate amounts of money or committing large scale fraud.
Scott Jones: So thinking about all of that, I think there are ways we're thinking about where depending on what's on the client side, you can tell if the OS has been broken. You can tell and I can't remember all the talking points, but there's ways to get into the telemetry of do I think a human's in charge of this system. there's stuff like that that I think could be on the table to address it,…
Scott Jones: but the risk will be non zero when it is client side. So then it becomes this kind of matrix of what's at stake with where this is being deployed. those are the thoughts we've been trading about it internally. Does that resonate at all?
Denken_Chen: Yeah, sure. menu Peace. Denken Chen:
Driving Use Cases For Biometrics
Manu_Sporny: Yeah, I mean plus one to all of that. I think the threat model that has to be done for this document is going to go into those things like what are the trade-offs what are the threats both to the individual and to the holder and to the verifier and so on so forth. So I think we'll have plenty of time to kind of go into those details. I wanted to go back to kind of the beginning the core driving use cases for this. So Joe, this kind of also goes back to kind of the assurance level thing. we probably do need to at least identify a couple of highle use cases at the top of the document so people really understand what are we trying to solve for with these properties.
Manu_Sporny: So for example, one of the driving use cases in the convenience store industry is this concept that you have a clerk that's behind a counter that's going to check your ID. The way it is done today is when you as a customer approach the clerk the retailer and you want to buy a bottle of beer, that clerk is going to look at They're going to make a determination of if you're close to 21 or not. And if they think you're close enough, they're going to ask you for your ID. And then you're going to reach into your pocket. You're going to get your physical ID out. You're going to hand it to the clerk who then gets to see all this information, all this PII on your ID. this can be particularly dangerous for some people because your address is on there.
Manu_Sporny: the clerk could take a photo, they could scan it, they could do a whole variety of things that would lift that PII and then endanger the customer in some way to raud to identity fraud and even physical attack. The person shows up at your house, right? So those are the types of risks that exist with the current identity proofing process. If we had this mechanism in for example convenience retail we might be able to shift it so that the clerk doesn't ever touch the ID. They never see your PII and they never have to make a judgment call on whether or not that document's fake or not or whether or not you look really close to your brother or your sister or if the image on the document was lifted and it had another one put on it.
Manu_Sporny: it just kind of removes all of that burden from the clerk and it removes all of the risk to the customer as well if we can move this on device. so that is at least one of the driving use cases is can we figure out a way to shift this process onto the individual's device such that the level of assurance can be raised to a certain level that the transaction can proceed without having to send any biometric photo any PII none of that to the retailer system or to the clerk out of hand.
Manu_Sporny: So I think we should put that one of the use cases that we're trying to address with this technology. and then how it's done on the client device on the holder device. There are multiple approaches as Scott said, right? So the ideal case is we do it in zero knowledge through some kind of mechanism that does not excfiltrate any of that data from the phone. but what you get out of that zero knowledge virtual machine is a proof that the myometric vector matched in real time against a person that was standing in front of a clerk. That's the ideal case.
Manu_Sporny: If can't get there are other things we can do at least if it's on the client, the person could say, "I trust X over company Y." So, for example, when we go to an airport, we have zero say in who's capturing our biometric, where it's going, how it's being processed, all that kind of stuff. It's pretty opaque, versus if we had this on a client device and you're using one of 10 providers and you personally have said,"I trust vendor X because I've gone to their site. I've seen what they've written. They've got a different approach to this. I trust them to make a biometric statement about me versus anybody else. I don't want my biometrics going to just some random vendor.
Manu_Sporny: I want them going to the one I picked that I trust and have a relationship with. So those are other things that we could talk about that are better than the state of play today.
Manu_Sporny: Again that's for the use cases. I think that's for the threat model. That's it.
Denken_Chen: …
Denken_Chen: we are running out of time and I think the last part we should definitely continue to discuss it in the future course. before we end it I would like to making sure that I just pasted our event series and as we agree in the beginning we will switch into alternating between the two times to see how it works.
Denken_Chen: So next time in two weeks April 29 or 28 depends on your time zone we will switch into another time that will be UTC 2 p.m.
Denken_Chen: and hope to see you then. Is there anything else Joe would like to add it?
Joe Andrieu: Yes.
Joe Andrieu: I guess I just wanted to give some guidance to Scott. I think, what you're presenting here, I think, has been very wellreceived. I think we'd like to get, a next iteration. I don't know, I want to see if you have a recommendation how much more do you think we want to talk about this as an issue versus getting some spec text into a PR that we can talk to directly?
Manu_Sporny: I think Scott you said that you've got kind of a revision that you'd posted the issue. let's all take a look at that and if it looks pretty good then we can raise it as a PR. And I think we should do it in chunks not introduce the entire thing all at the same time but try to get some basics in there. I don't have a good idea of what those I haven't had a chance to think about it but there's a way to do this where we kind of slowly introduce the high level concepts and…
Manu_Sporny: then we get down into details. that's what I'd suggest happy to do other
Joe Andrieu: Okay, that sounds good to me.
Joe Andrieu: Scott, is that clear for you?
Scott Jones: I'll have it posted.
Scott Jones: And is it cool? I imagine it's the next comment in the chain is the updated version of it.
Scott Jones: Is that accurate?
Joe Andrieu: Yeah, that's great.
Joe Andrieu: I'm going to have a brief note just saying we discussed it today and…
Scott Jones: I'll have it there tomorrow.
Joe Andrieu: there was general support and we need some better. I'm going to note this thing about the general upgrade to confidence methods needing clarity around a return type. and then I'll say and I'll tag you that you have some iterations to propose. You can just put it right in the issue there for us to talk about. Awesome. Okay, that's all I had, Nan. So, we'll get a doodle poll out. Den, and I'll sync up with you on what times we want to propose because it doesn't make sense to put times in that you and I can't make. So, but we also want to provide, at least some flexibility. we should consider other days than Wednesday,…
Joe Andrieu: for example. Even though I like that we found a time on Wednesday since everything else is on Tuesday. So, Dank, you and I will take that up and I think we'll get a doodle poll out by this time next week.
Denken_Chen: Making sure that we are doing a poll and…
Denken_Chen: based on the result to decide our meeting time or we just switch into alternating next time.
Joe Andrieu: It's a good question.
Joe Andrieu: One thing I did maybe this was an oversight in how we presented this. Denin and I had been planning on the confidence method group only meeting so that would mean roughly, every month, four weeks, we're doing one in each time zone. but I see a thumbs up for Manny. That makes it easy for Dankin and I to use the time slot in the off week for editor's rather than to double up and have an editor's call every week and a team meeting every week.
Joe Andrieu: So unless someone really wants to do a weekly meeting, this is your chance to speak up if you think you'd rather move at a faster pace. I think we've done good so far with the GitHub conversation. So, maybe can we have that arbitrary ask?
Denken_Chen: We could also include that in the pool.
Joe Andrieu: Dan, you and I will take that offline. Let's go ahead and…
Scott Jones: Yeah. Bye.
Joe Andrieu: wrap the meeting so folks can go.
Denken_Chen: Yeah. Sure. Thank you.
Joe Andrieu: All right.
Manu_Sporny: Thanks Have a good one. Ch.
Denken_Chen: Thanks.
Joe Andrieu: Take care, folks.