4 ms·

I actually do not have a problem with digital IDs, as long as my personal identity isn't being shared alongside it. Not to the site operator, not to the governm

I actually do not have a problem with digital IDs, as long as my personal identity isn't being shared alongside it. Not to the site operator, not to the government. This might seem contradictory, but I believe this is technically possible? What I don't think is this is how these solutions actually work currently. Like to basically prove that I am indeed a unique visitor who's a person according to the govt, but wouldn't reveal the person info to the site, and wouldn't reveal the site info to the govt, even if they collude. Same with the whole +18 goof. I'd actually quite like to try age gated communities, like +-5 years my age. I feel a lot of conflict stems from people coming from a bit too different walks of life sometimes. Could even do high confidence location based gating this way, which could also be cool (as well as the exact opposite of cool, because of course).

fluoridation 1y ago
Assuming a person can only have a single ID, how would that be enforced without a unique party having a 1-to-1 mapping between person and ID?
- perching_aix 1y ago
  The party to hold a gov id - site id mapping would be you. The rest can then be facilitated using zero-knowledge proofs, I believe. I'm not super well-versed in crypto though, so I confess this is a lot more conjecture than knowledge.
  - fluoridation 1y ago
    So the user generates the ID for each site he visits? What prevents them from generating arbitrary IDs? The only way I can imagine this working is: 1. You go to the government and request to have a digital ID generated. 2. The government generates a random number. 3. The government issues a request to an NGO to generate a new cryptographic object based on the random number, and receives back a retrieval number. 4. The government gives you the retrieval number, which you can use to get your digital ID from the NGO. This way, the government only has the mapping between your identity and a random number, and the NGO only has the mapping between the random number and the generated object, with no possibility to deanonymize it because you don't present any ID to get it. Obviously, there must be no information exchange between the government and the NGO.
    - perching_aix 1y ago
      > So the user generates the ID for each site he visits? What prevents them from generating arbitrary IDs? The construction would go basically like this: pseudonym = VRF(secret_key + site_id) The expectation is that you would have only one valid secret_key at any time, and it would be unknown to the government. This kind of scheme is called anonymous credential generation in literature I believe. It can be established the secret_key got govt backed, but that's it. The site_id would be e.g. domain cert public key or similar (domain ownership is a moving target, so just the domain name imo is not sound). VRF is a verifiable random function. This is the magic ZK part. Pseudonym is what you present to the site, i.e. the identity you go by. This way the site can verify that this pseudonym was specifically issued for it (making it site unique), and that it belongs to a govt certified identity (of which there should be only one issued at a time per person). The VRF is deterministic, guaranteeing that it's the same person every time. Revocation is annoying so I didn't bother thinking that through but should be fairly okay I think? I believe this is robust to people forging arbitrary IDs, to sites colluding with each other in deanonymization, and colluding with the govt in the same. The only kickers I can think of are secret_key misuse (e.g. via duress) / theft / loss / sharing, and the trust anchor (the govt) being untrustworthy (forging invalid or duplicate identities). Would also need to handle people dying, but that would be pretty much just revocation. I consider trust anchor issues out of scope. The remainder doesn't sound too bad to try defending for, and I think is also basically out of scope. Potentially important edit: I'm not accounting for timing side channels here, which might be relevant during revocation or else. Another: didn't mention but in my humble opinion cryptographically attesting people is unsound. People can't calculate crypto in their head, and can't recall long arbitrary strings of hex. What is appropriate to attest (if anything) is their devices instead. But that's a layer of complication I didn't want to deal with here.
      - fluoridation 1y ago
        >The expectation is that you would have only one valid secret_key at any time Why, though? If you're the only one who knows it, nothing prevents you from creating as many identities for the same site as you wish.
- altairprime 1y ago
  Why assume that? Person W is welcome to have thousands of unique IDs if they want to, so long as when site X bans identity Y, that ban is applied to all of Person W’s present and future identities. Whether W has a single Y or a thousand Y makes no difference to me. I suppose some sites will care to restrict participation to a single Y per W, but e.g. in the general browsing a site with crawler/bot/AI shielding such as Anubis today, it’s completely irrelevant to them what your Y is so long as rate limits and bans apply to all Y of W rather than to the presented Y alone.
  - fluoridation 1y ago
    Uhh... Sure, I suppose. I don't think it'd be possible to have that without also making it obvious that two different IDs are controlled by the same person, but sure.
altairprime 1y ago
The core of the identity problem is, “how can someone ban you personally without being able to identify you?”, and so far as I know, “a trusted third-party checks your identity and issues you an identifier” is the best we’ve got - but of course those identifiers can be enriched, so you end up needing a single centralized third-party that can issue identities and also honor bans for “the individual behind identity X” from specific sites by site request, while being audit-proven to actually enforce those bans upon me regardless of how many anonymous identities I choose to generate and use. (If you don’t run this as a monopoly, either they all pool their user-operator banned identities lists to prevent ban evasion, which will eventually leak, or they will be compelled to someday later down the road when they lose the inevitable monopoly lawsuits.) It’s not difficult to solve this problem — the database schema and queries are dead simple! — it’s just exceedingly difficult to succeed if you're not a passport-issuing entity or an authorized monopoly of such.
- AstralStorm 1y ago
  Specifically, only something government sized is trustworthy enough to not plainly sell your data later... Or perhaps get it stolen. Scratch that, this happens all the time. With a third party there's no way to revoke, government you can usually physically handle this.
- perching_aix 1y ago
  I wrestle with this by just separating this concern. In the model I described, the trust anchor would be the govt, so basically a centralized model like domain certs. This resolves the issues you list off, but brings others: what if the trust anchor isn't trustworthy and starts forging identities? The alternative to that would then be web of trust stuff. But this is why I consider this to be a separate problem. If the core protocol could be laid out and standardized at least, then layering on another that makes this choice between centralized vs web of trust could be done separately.
  - altairprime 1y ago
    https://www.w3.org/TR/vc-overview/ https://www.w3.org/TR/vc-overview/

fluoridation 1y ago

Assuming a person can only have a single ID, how would that be enforced without a unique party having a 1-to-1 mapping between person and ID?

perching_aix 1y ago
The party to hold a gov id - site id mapping would be you. The rest can then be facilitated using zero-knowledge proofs, I believe. I'm not super well-versed in crypto though, so I confess this is a lot more conjecture than knowledge.
- fluoridation 1y ago
  So the user generates the ID for each site he visits? What prevents them from generating arbitrary IDs? The only way I can imagine this working is: 1. You go to the government and request to have a digital ID generated. 2. The government generates a random number. 3. The government issues a request to an NGO to generate a new cryptographic object based on the random number, and receives back a retrieval number. 4. The government gives you the retrieval number, which you can use to get your digital ID from the NGO. This way, the government only has the mapping between your identity and a random number, and the NGO only has the mapping between the random number and the generated object, with no possibility to deanonymize it because you don't present any ID to get it. Obviously, there must be no information exchange between the government and the NGO.
  - perching_aix 1y ago
    > So the user generates the ID for each site he visits? What prevents them from generating arbitrary IDs? The construction would go basically like this: pseudonym = VRF(secret_key + site_id) The expectation is that you would have only one valid secret_key at any time, and it would be unknown to the government. This kind of scheme is called anonymous credential generation in literature I believe. It can be established the secret_key got govt backed, but that's it. The site_id would be e.g. domain cert public key or similar (domain ownership is a moving target, so just the domain name imo is not sound). VRF is a verifiable random function. This is the magic ZK part. Pseudonym is what you present to the site, i.e. the identity you go by. This way the site can verify that this pseudonym was specifically issued for it (making it site unique), and that it belongs to a govt certified identity (of which there should be only one issued at a time per person). The VRF is deterministic, guaranteeing that it's the same person every time. Revocation is annoying so I didn't bother thinking that through but should be fairly okay I think? I believe this is robust to people forging arbitrary IDs, to sites colluding with each other in deanonymization, and colluding with the govt in the same. The only kickers I can think of are secret_key misuse (e.g. via duress) / theft / loss / sharing, and the trust anchor (the govt) being untrustworthy (forging invalid or duplicate identities). Would also need to handle people dying, but that would be pretty much just revocation. I consider trust anchor issues out of scope. The remainder doesn't sound too bad to try defending for, and I think is also basically out of scope. Potentially important edit: I'm not accounting for timing side channels here, which might be relevant during revocation or else. Another: didn't mention but in my humble opinion cryptographically attesting people is unsound. People can't calculate crypto in their head, and can't recall long arbitrary strings of hex. What is appropriate to attest (if anything) is their devices instead. But that's a layer of complication I didn't want to deal with here.
    - fluoridation 1y ago
      >The expectation is that you would have only one valid secret_key at any time Why, though? If you're the only one who knows it, nothing prevents you from creating as many identities for the same site as you wish.
altairprime 1y ago
Why assume that? Person W is welcome to have thousands of unique IDs if they want to, so long as when site X bans identity Y, that ban is applied to all of Person W’s present and future identities. Whether W has a single Y or a thousand Y makes no difference to me. I suppose some sites will care to restrict participation to a single Y per W, but e.g. in the general browsing a site with crawler/bot/AI shielding such as Anubis today, it’s completely irrelevant to them what your Y is so long as rate limits and bans apply to all Y of W rather than to the presented Y alone.
- fluoridation 1y ago
  Uhh... Sure, I suppose. I don't think it'd be possible to have that without also making it obvious that two different IDs are controlled by the same person, but sure.

altairprime 1y ago

The core of the identity problem is, “how can someone ban you personally without being able to identify you?”, and so far as I know, “a trusted third-party checks your identity and issues you an identifier” is the best we’ve got - but of course those identifiers can be enriched, so you end up needing a single centralized third-party that can issue identities and also honor bans for “the individual behind identity X” from specific sites by site request, while being audit-proven to actually enforce those bans upon me regardless of how many anonymous identities I choose to generate and use. (If you don’t run this as a monopoly, either they all pool their user-operator banned identities lists to prevent ban evasion, which will eventually leak, or they will be compelled to someday later down the road when they lose the inevitable monopoly lawsuits.) It’s not difficult to solve this problem — the database schema and queries are dead simple! — it’s just exceedingly difficult to succeed if you're not a passport-issuing entity or an authorized monopoly of such.

AstralStorm 1y ago
Specifically, only something government sized is trustworthy enough to not plainly sell your data later... Or perhaps get it stolen. Scratch that, this happens all the time. With a third party there's no way to revoke, government you can usually physically handle this.
perching_aix 1y ago
I wrestle with this by just separating this concern. In the model I described, the trust anchor would be the govt, so basically a centralized model like domain certs. This resolves the issues you list off, but brings others: what if the trust anchor isn't trustworthy and starts forging identities? The alternative to that would then be web of trust stuff. But this is why I consider this to be a separate problem. If the core protocol could be laid out and standardized at least, then layering on another that makes this choice between centralized vs web of trust could be done separately.
- altairprime 1y ago
  https://www.w3.org/TR/vc-overview/ https://www.w3.org/TR/vc-overview/