[MINUTES] VCWG Confidence Method 2026-04-15

This meeting of the VCWG Confidence Method focused on establishing optimal
meeting times, clarifying key concepts like assurance levels versus
methods, and discussing the development of specifications for client-side
biometrics and its driving use cases. The attendees agreed to alternate
meeting times to accommodate different time zones and decided to create a
poll to gauge broader community preferences. Significant discussion
revolved around the nuances of assurance levels, including their
definition, data modeling, and application in verifiable credentials,
leading to a consensus on their inclusion in the specification with further
refinement planned. The biometrics discussion explored the technical
details, security considerations, and potential use cases, with a
commitment to developing a more detailed specification.

*Topics Covered:*

   - *Meeting Recording and Minutes Sharing:* The meeting was announced as
   being recorded and minutes would be shared on the mailing list for feedback.
   - *Discussing Meeting Time Slots:* The group agreed to alternate meeting
   times between UTC 2 PM and another slot (7 AM Pacific / 10 AM Eastern) to
   improve accessibility across different time zones. A doodle poll will be
   used to gather broader community input on meeting times.
   - *Assurance Method Vs Assurance Level:* The distinction between
   assurance method and assurance level was discussed, with a PR addressing
   this distinction being reviewed. Consensus was reached that an assurance
   level concept is necessary, though its data modeling and specific
   implementation require further discussion and will be marked with an issue
   marker for future refinement.
   - *Client-Side Biometrics Specification:* The initial discussion focused
   on the concept of a privacy-preserving, vendor-agnostic client-side
   biometrics specification, with an emphasis on defining input/output
   formats, high-level flows, and trade-offs.
   - *Biometric Confidence Method Spec Details:* This section delved into
   specific details for the biometrics specification, including the use of
   UUIDs for confidence methods, input types, nested biometric models, an
   assurance class, and expanded security considerations like vector
   inversion. An updated proposal is to be posted.
   - *Driving Use Cases For Biometrics:* The core driving use cases for
   biometrics were explored, with a particular example of convenience store
   age verification highlighting how shifting the process to a client device
   can reduce PII exposure and risk to the customer. The ideal scenario of
   zero-knowledge proofs for biometric matching was also discussed.

*Action Items:*

   - *Joe Andrieu and Denken Chen:* Create and send out a doodle poll to
   the mailing list to gather feedback on preferred meeting times and days.
   - *Scott Jones:* Post the updated version of the client-side biometrics
   proposal as the next comment in the relevant issue.
   - *Joe Andrieu:* Add a brief note to the issue indicating that the
   biometrics discussion had general support and that Scott Jones will provide
   iterations.
   - *Joe Andrieu and Denken Chen:* Sync up on proposed meeting times for
   the doodle poll, considering options beyond Wednesday and ensuring at least
   one can attend.
   - *All attendees:* Review the updated client-side biometrics proposal in
   the issue.
   - *Manu Sporny:* Propose a PR for the biometrics specification in
   chunks, starting with high-level concepts.
   - *Denken Chen:* Continue the discussion on client-side biometrics and
   its use cases in future meetings.

HTML:
https://meet.w3c-ccg.org/archives/w3c-vcwg-confidence-method-2026-04-15.html

Video:
https://meet.w3c-ccg.org/archives/w3c-vcwg-confidence-method-2026-04-15.mp4

[image: W3C] <https://www.w3.org/>
VCWG Confidence Method 15 April 2026 Attendees

Present

Denken Chen, Joe Andrieu, Manu Sporny, Scott Jones, Ted Thibodeau Jr

Regrets

-

Chair

-

Scribe

transcriber
Contents

   1. Meeting Recording And Minutes Sharing <#b750>
   2. Discussing Meeting Time Slots <#c804>
   3. Assurance Method Vs Assurance Level <#6a6d>
   4. Client-Side Biometrics Specification <#86c9>
   5. Biometric Confidence Method Spec Details <#279d>
   6. Driving Use Cases For Biometrics <#06f0>

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.

This transcription was generated by a large language model (LLM) and might
contain errors. When in doubt, check the audio recording. This page was
formatted by scribe.perl <https://w3c.github.io/scribe2/scribedoc.html>
version 248 (Mon Oct 27 20:04:16 2025 UTC).