alt Hacker NewsShow HN: Anonymous age verification with passkey-powered encryption
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 - 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.dgnrt.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 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
Comments
"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?
I wrote up more of the thinking behind this here for those interested:
https://loginwithone.com/blog/the-internet-should-be-more-li...
> 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.
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?
If you could combine this with the google oath experience somehow like age verification of my google account? I would def use that.
[flagged]
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?