Biometric-side input: two refinements (nullifier dedup + issuer independence) #12
Replies: 1 comment
|
Accepting both refinements; both are the missing half of work already on the bench. (if this is already included in the spec, we should sync this discussion in) - ill do a run to add this as an item to the mage 1 (enrolment dedup carries the teeth): yes to the write-up. The narrowing being ratified. Scoped reuse detection, not "one unique human," was written to leave room for this: the math gives same-secret-same-nullifier, and everything between "one human" and "one secret" is enrolment governance. The open enrolment-root discussion (whether the enrolment root belongs in the nullifier preimage) has been missing exactly this biometric-provider grounding. FMR/FNMR, re-enrolment resistance, capture conditions. The write-up would give that decision its evidence base. 2 (biometric dependency axis): agreed, and it is a small executable change. The multi-issuer independence register already models correlated issuers collapsing to one component over declared dependency classes, and the classes are deliberately open-ended. Adding |
Uh oh!
There was an error while loading. Please reload this page.
Ran the research cycle on Mitchell's lab (https://github.com/mitchuski/dtgwg-zkp-mage/tree/main) and walked the path map. Two refinements from the biometric and product side, where I can add signal. Filing here under my name so they are on the record.
1. Uniqueness (nullifiers): the dedup enrolment is where the teeth are.
Ratify the "scoped reuse detection, not one unique human" narrowing. Worth making loud: a nullifier only gets its anti-Sybil strength from a deduplicating enrolment. The math gives you "same secret, same nullifier." Whether one human maps to one secret is a biometric and governance property, not a cryptographic one, and it depends entirely on enrolment dedup quality: false-match and false-non-match rates, re-enrolment resistance, capture conditions. Happy to write that up as concrete input to the enrolment-root discussion, drawing on real biometric-provider experience.
2. Multi-issuer independence: in biometrics, "independent" issuers often are not.
On the multi-issuer and collusion work: the position that correlated issuers collapse to one component is right, and the open item is grounding the dependency-class taxonomy in how issuers actually share infrastructure. From the biometric side, issuers that are separate legal entities can still share the same underlying model, vendor, or training data, which makes their attestations correlated even when they look independent. So the dependency classes need a biometric-specific axis (shared model, shared vendor, shared enrolment data), not just corporate ownership. I can bring deployment knowledge to ground that.
Both are "refine and build" from me. Happy to turn either into a fuller write-up if useful.
All reactions