3 ms·

There are (at least) two problems to solve. The first is to anonymously verify properties about the user (e.g. age) and the second is to only allow the legitima

There are (at least) two problems to solve. The first is to anonymously verify properties about the user (e.g. age) and the second is to only allow the legitimate person verify themself. An national electronic id would provide users with the possibility to verify their age, that they are a physical person and so on, but in the basic case it gives their identity away to any system they use. Letting someone else use your id-card is in many countries illegal and comes with possible negative consequences. Share access to my e-id would allow them to access my bank account, take loans in my name, file for tax returns and a whole bunch of other stuff. So: e-id is not anonymous but usually kept from unauthorized use. One solves the anonymity part. Is the document in the encrypted blob accessible by the user? Can my identity be shared with websites? Basically: what stops someone from sharing their One passkey? What stops me from letting my AI agents use it, share it with my younger cousin or sell it online?

0xedwen 1mo ago
[flagged]
mikeysight 1mo ago
[dead]
skybrian 1mo ago
The main problem that age verification is solving is that we want children to be using child-locked devices, and those devices need to identify themselves. In theory this could be solved simply by locked devices sending an HTTP header. Then it's up to parents (and the stores that sell devices) to make sure that children are using devices with a child lock turned on. This technique allows the opposite: the id is used to validate a device as not child-locked. It's a whitelist instead of a blacklist. But maybe that's more practical in the short run? Preventing unlocked devices from being used by children isn't a software issue. Someone could just give them the device. It's up to society to not do that. Determined teens will certainly circumvent it, but it doesn't have to work perfectly to change the culture.
- tomveber 1mo ago
  [dead]
- mikeysight 1mo ago
  Thanks for the thoughts here! The whitelist vs blacklist association is spot on, and despite being practical I think there's an argument to be made that it's a strength, since it takes the onus off of the minor in this case and addresses the issue of unintentionally identifying underage users by forcing them to declare themselves. I also shared my thoughts about device-level enforcement in my reply to Scaled, would be curious to hear your take on some of those ideas there, if you get the chance. Really appreciate the feedback.
mikeysight 1mo ago
as promised, wanted to circle back on a few last items: > Is the document in the encrypted blob accessible by the user? Currently, verified elements of the document are encrypted and persisted but not the entire document. I do think in the future the encryption and persistence of the full document could be justified for reusable ID presentation during KYC. In these cases, selfie or liveness check would likely need to be re-completed and validated against the existing document, but would still save the user a document upload. > Can my identity be shared with websites? No. As I mentioned above however, in the future I do believe it could make sense for a user to optionally share their identity document with an application requiring KYC (like a bank or other regulated entity) to improve that user experience across multiple applications. > Basically: what stops someone from sharing their One passkey? What stops me from letting my AI agents use it, share it with my younger cousin or sell it online? The passkey itself is device/ecosystem - bound, so it's not something that can be sold or transferred, but more importantly, the passkey is not ultimately the proof of personhood in this case. That comes from the identity document, which needs to recently match the presenter at time of verification. I hope that helped clarify, let me know if there's anything else I can answer!

0xedwen 1mo ago

[flagged]

mikeysight 1mo ago

[dead]

skybrian 1mo ago

The main problem that age verification is solving is that we want children to be using child-locked devices, and those devices need to identify themselves. In theory this could be solved simply by locked devices sending an HTTP header. Then it's up to parents (and the stores that sell devices) to make sure that children are using devices with a child lock turned on. This technique allows the opposite: the id is used to validate a device as not child-locked. It's a whitelist instead of a blacklist. But maybe that's more practical in the short run? Preventing unlocked devices from being used by children isn't a software issue. Someone could just give them the device. It's up to society to not do that. Determined teens will certainly circumvent it, but it doesn't have to work perfectly to change the culture.

tomveber 1mo ago
[dead]
mikeysight 1mo ago
Thanks for the thoughts here! The whitelist vs blacklist association is spot on, and despite being practical I think there's an argument to be made that it's a strength, since it takes the onus off of the minor in this case and addresses the issue of unintentionally identifying underage users by forcing them to declare themselves. I also shared my thoughts about device-level enforcement in my reply to Scaled, would be curious to hear your take on some of those ideas there, if you get the chance. Really appreciate the feedback.

mikeysight 1mo ago

as promised, wanted to circle back on a few last items: > Is the document in the encrypted blob accessible by the user? Currently, verified elements of the document are encrypted and persisted but not the entire document. I do think in the future the encryption and persistence of the full document could be justified for reusable ID presentation during KYC. In these cases, selfie or liveness check would likely need to be re-completed and validated against the existing document, but would still save the user a document upload. > Can my identity be shared with websites? No. As I mentioned above however, in the future I do believe it could make sense for a user to optionally share their identity document with an application requiring KYC (like a bank or other regulated entity) to improve that user experience across multiple applications. > Basically: what stops someone from sharing their One passkey? What stops me from letting my AI agents use it, share it with my younger cousin or sell it online? The passkey itself is device/ecosystem - bound, so it's not something that can be sold or transferred, but more importantly, the passkey is not ultimately the proof of personhood in this case. That comes from the identity document, which needs to recently match the presenter at time of verification. I hope that helped clarify, let me know if there's anything else I can answer!