mikeysight

I think we just hold a different mental model of the problem, and that's fine. I view the internet as a digital world of destinations, and devices as the vehicles we use to visit those destinations. In the physical world, children share the same environment that we do. A school, casino and a liquor store can all be found on the same street, and we would never suppose that the latter two establishments have no responsibility to verify their customers are of age simply because they were able to drive themselves there. This model works shockingly well in the physical world, and I believe it's the most intuitive for the digital world as well.

I do actually think there's still a role for device-based parental controls in certain contexts for many of the reasons you mentioned (the portal is a cool analogy for this), and I like both your ad and cookie blocking ideas. Thanks for taking the time to share your thoughts.

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.

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.

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!

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.

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.

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!

I wasn't familiar with this protocol, thank you for sharing. I have something similar to this in the works right now along the lines of passkey-bound session keys that can be used without the user being present.

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.

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).

> 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.