https://github.com/google/longfellow-zk
Virtually everyone gets their internet from an ISP that is regulated in the country that the user lives in. There are no technical barriers to implementing a permitting system in the United States.
Linking connections to real people is self-enforcing when there is a usage-based tax.
[1] https://www.africanews.com/2018/04/13/uganda-s-social-media-...
https://blog.cryptographyengineering.com/2014/11/27/zero-kno... was a good intro for interactive ZK proofs but I haven't been able to find something for non-interactive ones.
This blog post comparing ZK-STARKs to erasure coding is in the right flavor but didn't quite stick to my brain either: https://vitalik.eth.limo/general/2017/11/09/starks_part_1.ht...
I just pushed this idea as a "solution" to see what others think, but I don't know. Again perhaps educating the parents about how to educate kids about the dangers of internet, and perhaps a web filter for kids.
This is actually one place where AI could be useful, to do dynamic local content classification (instead of a blocklist), especially if integrated directly in Android / iPhone.
Like https://support.apple.com/en-us/105121 but more dynamic.
That doesn't explain the way this scheme works, but it's a nice start.
It's also an unfathomably complex solution [1] which only a few people in the world will grok, and far more complex than existing solutions such as Idemix or BBS+, which lack such a hardware binding on existing hardware.
Age verification in a privacy preserving way is a really hot topic at the moment, but it will always be possible to bypass it – as will any commonly held anonymous boolean – in quite trivial ways. For example by setting up an open proxy to disclose genuine attributes. There are some privacy preserving mitigations, for example cryptography that'll make you linkable when disclosing more than k times per time period, or detecting slower-than-near-light-speed disclosure in a face-to-face disclosure scenario.
However, these mitigations will never be completely secure. That might not be a problem if it's admitted beforehand so expectations are correctly set: it's a barrier to protect the naïve, not an impenetrable fortress. However, if the expectations are that only age verification that cannot be bypassed is "adequate", we only have to wait for the first incidents in production apps after which the open source and privacy story will be abandoned in the name of security.
[1] https://eprint.iacr.org/2024/2010.pdf and https://eprint.iacr.org/2022/1608.pdf
The form are eg things like the JSON Web Token (JWT), Digital Credentials, and the Federated Credential Management API (FedCM).[1][2][3][4][5] The software can be anything since they're expected to use open protocols, so yes, web browsers.[6] Per the Commission, "For remote presentation flows, … the Wallet Instance implements the OpenID for Verifiable Presentation protocol OpenID4VP in combination with the W3C Digital Credentials API."[7]
[1] https://en.wikipedia.org/wiki/JSON_Web_Token
[2] https://github.com/w3c-fedid/digital-credentials
[3] https://w3c-fedid.github.io/digital-credentials/
[4] https://github.com/w3c-fedid/FedCM
[5] https://w3c-fedid.github.io/FedCM/
[6] https://github.com/w3c-fedid/FedCM/blob/main/explorations/HO...
[7] https://eu-digital-identity-wallet.github.io/eudi-doc-archit...
https://blog.cryptographyengineering.com/2014/11/27/zero-kno...
The Sparkasse network is not very well known outside of Germany but is actually Europe's largest financial services group by assets.
What is interesting is that until the 90s the membership banks were public institutions backed by municipal and state guarantees that made them virtually bankruptcy-proof, unlike private banks. EU competition rules then forced Germany to phase out these state guarantees, making Sparkassen subject to normal banking regulations and deposit insurance like other banks.
Current benchmarks for proving costs are 33k txns per dollar and we expect this to go down x10-x100 over the coming months/years.
Do you still feel that way knowing that it introduces a hard requirement for all users to have their private data managed by one of Apple, Google, or Microsoft[1]? I want to be excited about this, and about Passkeys, but the people working in this space keep fumbling this ball :(
[1] "Using the MDOC requires a signature from a hardware security key in the phone" >>44458417
Where’s Waldo as presented isn’t even a proof of knowledge
> To be very honest here, you risk having KeePassXC blocked by relying parties
Even if the bigtechs don't "officially" make the passkey standards require bigtech involvement, it seems very likely to me that conservative businesses like banks will only accept bigtech implementations. And then you're sunk.
Similarly, look at how OpenID turned into "Sign in with AppleGooFaceSoft".
This ZKP+hardware secure element stuff seems even worse, because how are you going to make it work on old hardware, or with free software, or with open devices?
However, the timing attack resurfaces once you allow the DMV to revoke credentials. Exactly how the revocation is done matters. We are actively pushing back against solutions that require the DMV to be contacted to verify that the credential has not been revoked at presentation time, but this is a very nuanced discussion with inevitable tradeoffs between privacy and security.
I should also remark that the above is a western-centric perspective, whatever "West" means. For example, I heard the architect for a similar system already deployed in India remark that in his jurisdiction many households share one phone across many family members, and India chose to accept more possibility for fraud in exchange for wider usability by the population. In that context this choice looks like the correct solution.
You can read the docs and whitepaper here: https://docs.reclaimprotocol.org/ And also take a look at all usecases built on top of this tech: https://reclaimprotocol.org/ecosystem
I'll just say that the b-systems solve a different problem, and for the problem solved by our system there is currently no other solution available.
We spoke with Ying Tong and her colleagues from the Ethereum foundation. They have a project investigating which ZK technology would be best for digital credentials, and they have ran a few benchmarks at https://hackmd.io/@clientsideproving/zkIDBenchmarks For reference, our implementation runs the benchmark in about 200ms on the same hardware. The ETHF folks have had access to our code for a while and they agree with this result, but they decided not to publish numbers until the Google code was open-sourced for all. Our system is thus about 10x faster than the closest contender for this problem.
I don't want to make any general claims about who is better than whom. Our system is designed for our problem, and it's not a surprise that another system designed for another problem would perform worse on our problem. We are big fans of the Binius system of Diamond and Posen at Irreducible, and there is a chance that Binius may eventually work better than our stuff. That's however not the case today.
You also have to be careful about which hardware to use. Our implementation is single-threaded no GPU because it has to run on all phones everywhere in the world. Whether or not one can do better on a high-end GPU is irrelevant to us.
Either way, "stale" is not a word I would use. The word I would use is "works today".
If you think you have a better idea shoot me an email.
Indeed. It's not a theoretical concern, either. The spec authors themselves actually maintain a "naughty client list": https://passkeys.dev/docs/reference/known-issues/
> This ZKP+hardware secure element stuff seems even worse, because how are you going to make it work on old hardware, or with free software, or with open devices?
I don't love it, but I actually do see an argument that this kind of proof-of-property stuff really does belong in a secure area, backed by approved software. It is making government-backed, legal claims about a person or entity. Unlike with Passkeys, it's not really "your" data, rather it's a way for the government to provide legally-backed information to someone, without the government actually having to be in the loop. I'd probably argue the solution to the big-tech dependency here is the government should be required to provide its own, verifiable solution (such as a physical ID card with open software) for users who do not want to trust big-tech.
Where the ZKP spec authors goofed was in not considering the wallet provider to be a party in the transaction. That third party may have interests that are not aligned with the user's.
> You are correct. The property that the colluding website and DMV still cannot identify you is called "unlinkability" and as far as I can tell cannot be achieved without zero-knowledge proofs.
Well, no. This is true only if you trust the unverifiable wallet software on your phone, which was provided by a for-profit, American big tech advertising company. In this protocol, the wallet may secretly leak the transaction details back to the DMV or whoever else they wish[1].
[1] "Yes, a malicious wallet could leak your information." >>44458549
[1] See section 33 here https://www.european-digital-identity-regulation.com/Preambl...
If only the recipient doesn’t have access, a certain amount of trust can be delegated to the strength of the proof presented in the spend. In an ecash model, the proof would be in the form of a signature made by the mint (assuming the recipient was able to get the public keys the mint was using).
Active research is being done on the ecash model with the resurgence of the concept in the Cashu and Fedimint projects. Cashu takes the online sender, offline receiver approach[2].
[1] https://chaum.com/wp-content/uploads/2021/12/Untraceable_Ele...
^See paragraph in the introduction ending with:
“But if Alice reuses a coin, the bank can trace it to her account and can prove that she has used it twice.”
I can also move the funds into a connected debit card so I can spend it in the real world.
This wallet is powered by Bridge.xyz which was acquired for $1B+ by Stripe in Fall 2024 - would encourage you to try the new stuff!