Evaluate constraints that verifiers might request for biometrics

[jandrieu]

Some examples:

• Acceptable Matching Providers
• Acceptable Models

[dlongley]

+1 to producing a list of everything a verifier might care about -- and then figuring out how many of those things should/could be mapped to one or more abstractions. Creating too many things that a verifier can select from can create harmful gatekeeping and can require the verifier to have to do too much analysis work, work that might be better delegated to a provider.

Verifiers might like to be able to just say "I'll take anything from provider X, Y, or Z" or "I'll take anything from provider X, Y, or Z where the provider says the security level is 1/2/3".

Note that regarding "model", we might find that "model" isn't granular enough or includes additional information that the verifier shouldn't need to select for/on. If it's important that a particular "mode" of input be used, we might need to surface that differently / as some independent constraint from "model".

[amir-hameed-mir]

I wonder if we should focus on defining the criteria a verifier cares about rather than "acceptable models." Models are implementation details that change over time and can introduce unnecessary coupling to specific vendors or versions. If we identify the underlying assurance and capability criteria (e.g., assurance level, liveness requirements, biometric modality, Presentation Attack Detection (PAD) level and False Acceptance Rate (FAR) thresholds., certifications, freshness, etc.), providers can attest that their implementation satisfies those criteria, allowing verifier policies to remain stable even as models evolve. This also seems to align with the idea of letting providers abstract away implementation-specific details where appropriate.

[dlongley]

@amir-hameed-mir, yes -- totally agree, you captured what I was trying to convey very nicely, thank you!

[amir-hameed-mir]

@dlongley Thanks,Your earlier comment about focusing on verifier concerns and appropriate abstractions was the key insight. I was just trying to build on that by framing it in terms of capability and assurance criteria rather than implementation details. Looking forward to refining this further with the group.