Yup! Which is why institutions that already handle identities (governments, banks, etc) should be involved.
The way I see it: an institution verifies your identity as a human and has your personal details (such as DoB). A tool (similar to, e.g. Sweden’t BankID) is available to the user. When a website says “you must be 18 years old to access this”, a QR code is generated. You scan the code with your tool, and agree to send only the information about whether or not you’re an adult. Not the DoB, not anything else, just a token of “yup, adult”. If a website has a strong anti-bot policy, same same goes for your “proof of human”.
This can be set up in a way that guarantees the user’s privacy (e.g. by just not storing any logs).
Yes but how does that prevent the authority, in this case a govenment, from being able to link the token that was used (QR code) back to what it was used for?
Depends on how you create it. It could be set up that your app talks to the website, and the identity provider, but the identity provider never talks to the website. As in: you get a token from the IP, store it locally, send it out to he website, the website confirms retrieval and logs you in, and then all the logs get purged on your device so they can’t be retrieved.
The IP side would only see that someone has requested access to some of your data (e.g. proof of age, proof of human, maybe citizenship, if the content is region-locked), and that you have agreed to share it.
The website would only see the tokens of proof, but not who you actually are.
Ironically, the tech behind NFTs might be super helpful with this.
If I am understanding this correctly, I guess the only problem I see with that is both entities need to trust that the user is indeed being truthful and not sharing a token. I think a system with a neutral third part that takes a token from the identity provider and a token from the webite, validates them and sends a result. Or maybe that is what you said.
Ironically the only thing that will ever work is identifying a user to a person in one form or another. Otherwise it’s just a never ending arms race.
Yup! Which is why institutions that already handle identities (governments, banks, etc) should be involved.
The way I see it: an institution verifies your identity as a human and has your personal details (such as DoB). A tool (similar to, e.g. Sweden’t BankID) is available to the user. When a website says “you must be 18 years old to access this”, a QR code is generated. You scan the code with your tool, and agree to send only the information about whether or not you’re an adult. Not the DoB, not anything else, just a token of “yup, adult”. If a website has a strong anti-bot policy, same same goes for your “proof of human”.
This can be set up in a way that guarantees the user’s privacy (e.g. by just not storing any logs).
Yes but how does that prevent the authority, in this case a govenment, from being able to link the token that was used (QR code) back to what it was used for?
Depends on how you create it. It could be set up that your app talks to the website, and the identity provider, but the identity provider never talks to the website. As in: you get a token from the IP, store it locally, send it out to he website, the website confirms retrieval and logs you in, and then all the logs get purged on your device so they can’t be retrieved.
The IP side would only see that someone has requested access to some of your data (e.g. proof of age, proof of human, maybe citizenship, if the content is region-locked), and that you have agreed to share it.
The website would only see the tokens of proof, but not who you actually are.
Ironically, the tech behind NFTs might be super helpful with this.
If I am understanding this correctly, I guess the only problem I see with that is both entities need to trust that the user is indeed being truthful and not sharing a token. I think a system with a neutral third part that takes a token from the identity provider and a token from the webite, validates them and sends a result. Or maybe that is what you said.
Yeah, that’s essentially what I meant. The validation could happen much like with PGP keys and passwords.