13 ms·

Show HN: Anonymous age verification with passkey-powered encryption

45 points by mikeysight 2mo ago

This project has been kicking around in my head since I first heard about the webauthn PRF extension in early 2024. I've slowly chipped away at it since, and finally got things to a shareable state over the summer thanks to a very fun parental leave. Headed back to work tomorrow, so I figure there's no time like the present. tldr: A client-held encryption key derived during passkey authentication encrypts all sensitive user data prior to persistence so that only the user is able to decrypt and reuse that data on their device. This allows short-lived, privacy-preserving age proofs to be issued to requesting applications (18+, no PII shared) without requiring users to re-upload their documents. The SSO user experience is built on top of the OAuth 2.0 Authorization Code Flow. https://loginwithone.com https://loginwithone.com - demo video + high-level architecture + FAQ I also made the parody demo apps from the video public if anyone wants to play around with the user experience: https://demo.brainrot.loginwithone.com https://demo.brainrot.loginwithone.com https://demo.dgnrt.loginwithone.com https://demo.dgnrt.loginwithone.com https://demo.kirby.loginwithone.com https://demo.kirby.loginwithone.com I suspect most will choose to pass on the ID stage for now (no offense taken, doing so is low reward in this context) but if you navigate to https://app.loginwithone.com https://app.loginwithone.com after onboarding you can demonstrate the passkey-powered encryption on your email via the lock/unlock button. Very open to feedback and happy to answer any questions! I plan to pull the client-side encryption functionality into an open-source typescript library for general use, so any thoughts or suggestions on what you’d like to see out of that interface would be supremely useful. Thanks all, Michael

deleted 2mo ago
[deleted]
akshay_akula 2mo ago
If you could combine this with the google oath experience somehow like age verification of my google account? I would def use that.
- mikeysight 2mo ago
  also google if you're reading this don't even think about it, patent is pending and my uncle is a lawyer
- mikeysight 2mo ago
  check out the demo video! I think you'll like it :) that's the exact user experience (it's built on the same OAuth protocol) but with all underlying data encrypted to your device.
tangotaylor 2mo ago
> When identity documents are uploaded, they are encrypted using a master encryption key derived from the user’s passkey during authentication. ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes. Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement. Anyway I appreciate the consideration given to privacy.
- mikeysight 2mo ago
  > ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes. Yes that's correct, the identity documents are validated alongside the selfie before the selfie is discarded and the identity documents are encrypted by the passkey-derived encryption key prior to persistence. > Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement. Yes this is a great callout. ONE does know the client and relying party on each verification transaction and could theoretically store these records (and your point about strict avoidance of logging PII is very important), but implemented properly, identifying the "who" behind a user after initial verification (the coerced by law enforcement example) would require modifying the server or client-side code to capture plaintext during a future passkey-bound decryption. This is also why I have a goal of open sourcing the server side code that processes the plaintext identity payload and running it in an enclave with verifiable attestation. > Anyway I appreciate the consideration given to privacy. Thank you! I appreciate the questions.
  - tomveber 2mo ago
    [dead]
  - quadhome 1mo ago
    I wonder if you could have the verification use something like the Privacy Pass protocol to emit a bunch of spendable anonymous login tokens.
mikeysight 2mo ago
I wrote up more of the thinking behind this here for those interested: https://loginwithone.com/blog/the-internet-should-be-more-like-a-liquor-store/ https://loginwithone.com/blog/the-internet-should-be-more-li...
thcr 2mo ago
"One stores ciphertext: encrypted blobs created with a key held by the user. Never the underlying identity data. This includes government ID and selfie data, as well as the verified email associated with the account. " Why does it need to store even encrypted data after the result is +18, for example? Does ONE need to keep validating against the same documents every time?
- mikeysight 2mo ago
  Great question, and also thank you for calling this out, because "selfie data" shouldn't be included in that description, since those images are not persisted at all, encrypted or otherwise (editing now). You make a very good point about being able to reissue valid proofs based on a previous verification (and I think that could even be a viable user opt-in down the road) but the identity data that is persisted serves two main purposes: 1. reusability across applications that require a proof scoped to a valid government ID for legal purposes (non-expired, for example) or with a recency requirement (fresh photo matching the ID photo to validate you're the person holding the ID), and 2. as a means for users to self-custody their identity documents for presentation as needed across the web (future KYC ambitions for the project).
  - tomveber 2mo ago
    [flagged]
    - dang 1mo ago
      Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079 https://news.ycombinator.com/item?id=47340079. Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
    - mikeysight 1mo ago
      the recovery flow is scoped to the account but not the encrypted data. if the passkey is lost, the encrypted identity data is lost (by design) and the user has to upload again before new verifications. the account and associations with previously linked applications remain.
icermann 1mo ago
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
jay0073 1mo ago
[flagged]
sixtiethutopia 1mo ago
When a user reuses a previously saved government ID is that ID decrypted and sent in plaintext to your service? (Ie. does your service see the ID in plaintext every time a user uses the service?) Do you use zero-knowledge proofs in any way?
- mikeysight 1mo ago
  the service doesn't see the document itself on subsequent verifications but it does receive a signed verification payload containing derived fields in plaintext currently. No ZK proofs at this stage but agreed it would be a great future improvement!
bitwize 1mo ago
This wouldn't pass muster for the "age verification laws" that various governments are implementing or have planned. Even if the laws currently on the books or being proposed do not have the requirements, "KYC to touch a computer or communicate over the internet" is the goal. People are crying out for their children to be kept safe online, and the solution the government knows is a full auditable trail of who communicated what to whom when. This also nicely solves the problem of "anyone can set up a new online service", allowing the big players to entrench themselves...
- mikeysight 1mo ago
  Interestingly enough, many of the age verification laws passed recently in the states and EU explictly require or suggest anonymous or otherwise privacy-preserving technologies in their wording. I share a healthy dose of skepticism and cynicism around the ability of institutions to competently enact law and not to overstep, but I also believe that innovation drives legislation more than the inverse, and that if great tools exist that can address many or all of the core concerns around user friction and privacy, the law will be informed, shaped and clarified by those capabilities.
Scaled 1mo ago
These solutions will never be viable, and I'll explain why. Fundamentally, there's three sets of the population: 1) Those who are clamoring for age verification (generally on sites they never interact with themselves.) 2) People arguing fiercely against age verification and won't engage with any site who uses it 3) Most significantly, the large majority of people in the middle who can't be bothered to do AV and will just use another overseas website instead. Even if the privacy can be solved (and I don't believe it can as someone fundamentally unwilling to upload my ID even once), that balance is basically the problem with trying to outsource the work to people who don't want to do it. We can already see that even privacy preserving solutions will not be used by adult site visitors in multiple adult site attempts to roll it out. The ONLY viable solution is parental filters on device. Anything that pushes the work to people who don't want it fails because the sites will just move overseas instead of losing the vast majority of their actual users. Or they roll it out and the traffic moves overseas, like data analysis has shown happened in UK. You just can't solve the problem by pushing the work onto everyone instead of tackling it at its source. Rather than try to lock down the entire Internet, which will never happen, lock down child devices.
- mikeysight 1mo ago
  I forgot to include this but sincerely, thank you for the comments and for giving me an opportunity to answer some very important questions that motivate me.
- mikeysight 1mo ago
  I obviously totally disagree (otherwise there'd be no reason for me to keep building), and I'll explain why. Working backwards, I think the device is exactly the wrong place for enforcement. Devices are not individuals and individuals are not their devices. Devices are tools for interacting with the open internet. Multiple people can share one and most persons own multiple. Additionally, we don't treat any aspect of our society with this attitude. Would it be preferable for 16 year olds to be provisioned cars that were unable to turn into the parking lot of a liquor store so that the work of verifying the customer's age would not be "outsourced to people who don't want to do it"? I like the real world, and I think we have done a pretty good job at organizing ourselves as a society, and it's my sincere belief that our interactions online would benefit by closer reflecting those that happen in the material world. I wrote about this at length in the essay in comments below. Second, while it is admittedly a very difficult challenge, the privacy can be solved, and I'm very excited to be working on it. I don't accept that the status quo or a dystopian alternative are the only two outcomes, but I do sincerely respect those in bucket 2 and their prerogative to avoid any site utilizing age verification technology. That being said, I do plan to earn the trust of many in that bucket with a bit of integrity, transparency and cryptography :) As for bucket 3, that's exactly who this was made for.
mikeysight 1mo ago
https://krebsonsecurity.com/2026/09/fbi-probes-service-selling-153m-drivers-licenses/ https://krebsonsecurity.com/2026/09/fbi-probes-service-selli... fun times

45 points by mikeysight 2mo ago

deleted 2mo ago

[deleted]

akshay_akula 2mo ago

If you could combine this with the google oath experience somehow like age verification of my google account? I would def use that.

mikeysight 2mo ago
also google if you're reading this don't even think about it, patent is pending and my uncle is a lawyer
mikeysight 2mo ago
check out the demo video! I think you'll like it :) that's the exact user experience (it's built on the same OAuth protocol) but with all underlying data encrypted to your device.

tangotaylor 2mo ago

> When identity documents are uploaded, they are encrypted using a master encryption key derived from the user’s passkey during authentication. ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes. Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement. Anyway I appreciate the consideration given to privacy.

mikeysight 2mo ago
> ONE still sees identity documents in the clear the first time when it verifies them, right? Otherwise we could upload fakes. Yes that's correct, the identity documents are validated alongside the selfie before the selfie is discarded and the identity documents are encrypted by the passkey-derived encryption key prior to persistence. > Also I'm not familiar with Oauth 2.0, but doesn't ONE know the client and relying party on each verification transaction? So ONE could theoretically store records of who accessed which website, perhaps by mistaken logging configuration or because they were coerced by law enforcement. Yes this is a great callout. ONE does know the client and relying party on each verification transaction and could theoretically store these records (and your point about strict avoidance of logging PII is very important), but implemented properly, identifying the "who" behind a user after initial verification (the coerced by law enforcement example) would require modifying the server or client-side code to capture plaintext during a future passkey-bound decryption. This is also why I have a goal of open sourcing the server side code that processes the plaintext identity payload and running it in an enclave with verifiable attestation. > Anyway I appreciate the consideration given to privacy. Thank you! I appreciate the questions.
- tomveber 2mo ago
  [dead]
- quadhome 1mo ago
  I wonder if you could have the verification use something like the Privacy Pass protocol to emit a bunch of spendable anonymous login tokens.

mikeysight 2mo ago

I wrote up more of the thinking behind this here for those interested: https://loginwithone.com/blog/the-internet-should-be-more-like-a-liquor-store/ https://loginwithone.com/blog/the-internet-should-be-more-li...

thcr 2mo ago

"One stores ciphertext: encrypted blobs created with a key held by the user. Never the underlying identity data. This includes government ID and selfie data, as well as the verified email associated with the account. " Why does it need to store even encrypted data after the result is +18, for example? Does ONE need to keep validating against the same documents every time?

mikeysight 2mo ago
Great question, and also thank you for calling this out, because "selfie data" shouldn't be included in that description, since those images are not persisted at all, encrypted or otherwise (editing now). You make a very good point about being able to reissue valid proofs based on a previous verification (and I think that could even be a viable user opt-in down the road) but the identity data that is persisted serves two main purposes: 1. reusability across applications that require a proof scoped to a valid government ID for legal purposes (non-expired, for example) or with a recency requirement (fresh photo matching the ID photo to validate you're the person holding the ID), and 2. as a means for users to self-custody their identity documents for presentation as needed across the web (future KYC ambitions for the project).
- tomveber 2mo ago
  [flagged]
  - dang 1mo ago
    Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079 https://news.ycombinator.com/item?id=47340079. Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
  - mikeysight 1mo ago
    the recovery flow is scoped to the account but not the encrypted data. if the passkey is lost, the encrypted identity data is lost (by design) and the user has to upload again before new verifications. the account and associations with previously linked applications remain.

icermann 1mo ago

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

jay0073 1mo ago

[flagged]

sixtiethutopia 1mo ago

When a user reuses a previously saved government ID is that ID decrypted and sent in plaintext to your service? (Ie. does your service see the ID in plaintext every time a user uses the service?) Do you use zero-knowledge proofs in any way?

mikeysight 1mo ago
the service doesn't see the document itself on subsequent verifications but it does receive a signed verification payload containing derived fields in plaintext currently. No ZK proofs at this stage but agreed it would be a great future improvement!

bitwize 1mo ago

This wouldn't pass muster for the "age verification laws" that various governments are implementing or have planned. Even if the laws currently on the books or being proposed do not have the requirements, "KYC to touch a computer or communicate over the internet" is the goal. People are crying out for their children to be kept safe online, and the solution the government knows is a full auditable trail of who communicated what to whom when. This also nicely solves the problem of "anyone can set up a new online service", allowing the big players to entrench themselves...

mikeysight 1mo ago
Interestingly enough, many of the age verification laws passed recently in the states and EU explictly require or suggest anonymous or otherwise privacy-preserving technologies in their wording. I share a healthy dose of skepticism and cynicism around the ability of institutions to competently enact law and not to overstep, but I also believe that innovation drives legislation more than the inverse, and that if great tools exist that can address many or all of the core concerns around user friction and privacy, the law will be informed, shaped and clarified by those capabilities.

Scaled 1mo ago

These solutions will never be viable, and I'll explain why. Fundamentally, there's three sets of the population: 1) Those who are clamoring for age verification (generally on sites they never interact with themselves.) 2) People arguing fiercely against age verification and won't engage with any site who uses it 3) Most significantly, the large majority of people in the middle who can't be bothered to do AV and will just use another overseas website instead. Even if the privacy can be solved (and I don't believe it can as someone fundamentally unwilling to upload my ID even once), that balance is basically the problem with trying to outsource the work to people who don't want to do it. We can already see that even privacy preserving solutions will not be used by adult site visitors in multiple adult site attempts to roll it out. The ONLY viable solution is parental filters on device. Anything that pushes the work to people who don't want it fails because the sites will just move overseas instead of losing the vast majority of their actual users. Or they roll it out and the traffic moves overseas, like data analysis has shown happened in UK. You just can't solve the problem by pushing the work onto everyone instead of tackling it at its source. Rather than try to lock down the entire Internet, which will never happen, lock down child devices.

mikeysight 1mo ago
I forgot to include this but sincerely, thank you for the comments and for giving me an opportunity to answer some very important questions that motivate me.
mikeysight 1mo ago
I obviously totally disagree (otherwise there'd be no reason for me to keep building), and I'll explain why. Working backwards, I think the device is exactly the wrong place for enforcement. Devices are not individuals and individuals are not their devices. Devices are tools for interacting with the open internet. Multiple people can share one and most persons own multiple. Additionally, we don't treat any aspect of our society with this attitude. Would it be preferable for 16 year olds to be provisioned cars that were unable to turn into the parking lot of a liquor store so that the work of verifying the customer's age would not be "outsourced to people who don't want to do it"? I like the real world, and I think we have done a pretty good job at organizing ourselves as a society, and it's my sincere belief that our interactions online would benefit by closer reflecting those that happen in the material world. I wrote about this at length in the essay in comments below. Second, while it is admittedly a very difficult challenge, the privacy can be solved, and I'm very excited to be working on it. I don't accept that the status quo or a dystopian alternative are the only two outcomes, but I do sincerely respect those in bucket 2 and their prerogative to avoid any site utilizing age verification technology. That being said, I do plan to earn the trust of many in that bucket with a bit of integrity, transparency and cryptography :) As for bucket 3, that's exactly who this was made for.

mikeysight 1mo ago

https://krebsonsecurity.com/2026/09/fbi-probes-service-selling-153m-drivers-licenses/ https://krebsonsecurity.com/2026/09/fbi-probes-service-selli... fun times