All roads lead back to the only people who can stop the problem they created.This report was assisted by:Nick Devor at Barron's - https://www.barrons.com/art...
Now you are starting to sound like you know what your talking about. But I’m not convinced yet. So when the app sends just the requested data to the site, how does the site verify that the data is legit. A person could fork the app and hack it. I am sure they thought of this, I just don’t know what thier solution is. And I can’t read german.
Yeah, something like that. But while your device can validate the cryptographic sig for the app, the site requesting proof of age can’t, since it isn’t running on the same device as the app.
The best I can guess, the app could request verification from the state run site, and specify what information it wants (based on what the requestor site asked for). The state site could use a private key to encrypt the response and give it back. The app could use a piblic key the state makes available to decode and confirm that only the intended information is present. Then the app can pass that to the requestor, who can get the public key from the state site and decrypt the information.
But, the gap there is how does the requestor know the app it is talking to hasn’t been modified. I don’t think there is a way that it can. Only the device the app is on can verify that. And the requestor can’t trust the device either.
Some Authentication that I remember has a component where the requestor would then talk to the state to confirm the info it got from the app was requested from the state by the same app the site is talking to. This prevents using someone elses response as your own. But in this case, that would tie the site to the request which means the state would have both peices of info, who and what site. So I don’t know what there solution here could be that wouldn’t result in the same problem.
They could (but didnt) do it with zero knowledge proofs as well. Then the website could go back and verify against the state site and no private information would be leaked.
The state would know the site requesting it via IP, but they wouldn’t know which proof they were validating.
It’s often talked about in the blockchain crypto space, but it’s not the only way to use them. You could use it in a centralized system like this too.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Now you are starting to sound like you know what your talking about. But I’m not convinced yet. So when the app sends just the requested data to the site, how does the site verify that the data is legit. A person could fork the app and hack it. I am sure they thought of this, I just don’t know what thier solution is. And I can’t read german.
(NotOP) these things will usually use cryptographic signatures and if the app has been altered, it’d fail the check.
No clue what they are specifically doing though.
Yeah, something like that. But while your device can validate the cryptographic sig for the app, the site requesting proof of age can’t, since it isn’t running on the same device as the app. The best I can guess, the app could request verification from the state run site, and specify what information it wants (based on what the requestor site asked for). The state site could use a private key to encrypt the response and give it back. The app could use a piblic key the state makes available to decode and confirm that only the intended information is present. Then the app can pass that to the requestor, who can get the public key from the state site and decrypt the information. But, the gap there is how does the requestor know the app it is talking to hasn’t been modified. I don’t think there is a way that it can. Only the device the app is on can verify that. And the requestor can’t trust the device either.
Some Authentication that I remember has a component where the requestor would then talk to the state to confirm the info it got from the app was requested from the state by the same app the site is talking to. This prevents using someone elses response as your own. But in this case, that would tie the site to the request which means the state would have both peices of info, who and what site. So I don’t know what there solution here could be that wouldn’t result in the same problem.
They could (but didnt) do it with zero knowledge proofs as well. Then the website could go back and verify against the state site and no private information would be leaked.
The state would know the site requesting it via IP, but they wouldn’t know which proof they were validating.
It’s often talked about in the blockchain crypto space, but it’s not the only way to use them. You could use it in a centralized system like this too.