4 ms·

Yeah I'm also interested in some of the details here, but the linked library repo is a bit too low-level for my current understanding. For example, in the usec

Yeah I'm also interested in some of the details here, but the linked library repo is a bit too low-level for my current understanding. For example, in the usecase of providing a proof-of-age to a website: who provides the verification data (the government?); what form does that take (a file in a standard format?); who holds/owns the verification data (the user?); who runs the verification software (the end-user's web browser?). Can the user use any implementation to provide the proof, or must it be a "blessed" implementation such as Google Wallet?

MatteoFrigo 1y ago
The specifics depend on local regulations, but roughy speaking: the government gives you a document in a standard format (eg MDOC). Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof. The government gives documents to whatever wallet they want, which may be a special government wallet. They may or may not give the document to Google Wallet.
- coldpie 1y ago
  Thank you. > Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof. So it does require a "blessed" implementation, and I have to trust Google or Apple to handle my data? I cannot own the document myself and use an open-source client that I trust to provide the proof?
  - MatteoFrigo 1y ago
    It depends on local regulations. As far as I can tell Europe will require some sort of blessing of the wallet. To be clear, governments will develop their own apps and it's not clear that Google will be blessed. We (Google) are giving them the code pro bono to improve privacy.
    - deleted 1y ago
      [deleted]
    - coldpie 1y ago
      Hmm. This introduces a third party to the protocol, right? Specifically the developer of the wallet. So we now have three parties: the user, the wallet developer, and the relying party. Does this zk protocol protect the user's privacy from the wallet developer as well as the relying party? In other words, does the protocol give the wallet access to information about the relying party? For example, could this wallet that I don't control tell its owner, or the government, that I am using it to access a certain website?
      - MatteoFrigo 1y ago
        Yes, a malicious wallet could leak your information. This is why some governments will insist on using only blessed wallets. However, wallet+zk is strictly better than sending the plaintext MDOC to the relying party. There are no solutions in this space, only tradeoffs, and elected representatives have picked one tradeoff.
        coldpie 1y ago
        That's too bad :( I wish the protocol had been designed with that in mind. Requiring users to trust proprietary software from Google & Apple to be in complete control over their digital identities is a pretty crummy direction to go in.
        MatteoFrigo 1y ago
        See https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework https://github.com/eu-digital-identity-wallet/eudi-doc-archi... for a reference to the nuances on all these topics, at least in the context of the European Union. Other locales have different problems and different solutions. If you think you have a better idea shoot me an email.
  - miki123211 1y ago
    In principle, you could use an open source implementation, but not a user-modifiable implementation. Nothing stops a government from making their code open source and providing you with reproducible builds. You just won't be able to change the code to do something the government doesn't deem legal.
- deleted 1y ago
  [deleted]
abhv 1y ago
(1) in this case, an identity issuer provides the source of truth identity information. Examples include state DMV, your passport (you can try "Id pass" in Google wallet), etc. (2) One of the goals of this project was to layer ZK on top of current identity standards that DMVs already issue, so that gov orgs don't have to change what they currently do to support the strongest user privacy. One example format is called Mdoc. (3) The user holds the identity information on their device only. No other copies. The user's device makes the zkp proof on-device. This was one of the major technical challenges. (4) The relying party (eg a website) runs the zk verification algorithm on the proof that is produced by the device to ensure soundness. (5) Yes, the user can use any compatible implementation to produce the proof. We have open-sourced our implementation and we have a spec for the proof format that others can also reimplement.
- coldpie 1y ago
  Thanks for the reply. So in theory, I could get this MDOC file and store it on my desktop computer, and use an open-source library whose behavior I can verify, to provide the proof to the website via my web browser. Yeah? This sounds good to me.
  - MatteoFrigo 1y ago
    No. Using the MDOC requires a signature from a hardware security key in the phone, and a lot of the complexity is how to avoid leaking the private key, which would identify you.
    - coldpie 1y ago
      Well, that's not great. My phone is closed-source and its software is provided by an ad company. I do not trust it to always behave in my interests.
      - MatteoFrigo 1y ago
        An alternative would be some secure chip in a credit-card size plastic document, but nobody seems to like that idea. We (Google) don't make these choices.
esbranson 1y ago
It is decentralized. The holder provides the data, which was ultimately provided to them by the government, they're the client. The verifier is the entity that wants to know how old the holder is, the server. 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 https://en.wikipedia.org/wiki/JSON_Web_Token [2] https://github.com/w3c-fedid/digital-credentials https://github.com/w3c-fedid/digital-credentials [3] https://w3c-fedid.github.io/digital-credentials/ https://w3c-fedid.github.io/digital-credentials/ [4] https://github.com/w3c-fedid/FedCM https://github.com/w3c-fedid/FedCM [5] https://w3c-fedid.github.io/FedCM/ https://w3c-fedid.github.io/FedCM/ [6] https://github.com/w3c-fedid/FedCM/blob/main/explorations/HOWTO-chrome.md https://github.com/w3c-fedid/FedCM/blob/main/explorations/HO... [7] https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/ https://eu-digital-identity-wallet.github.io/eudi-doc-archit...

MatteoFrigo 1y ago

The specifics depend on local regulations, but roughy speaking: the government gives you a document in a standard format (eg MDOC). Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof. The government gives documents to whatever wallet they want, which may be a special government wallet. They may or may not give the document to Google Wallet.

coldpie 1y ago
Thank you. > Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof. So it does require a "blessed" implementation, and I have to trust Google or Apple to handle my data? I cannot own the document myself and use an open-source client that I trust to provide the proof?
- MatteoFrigo 1y ago
  It depends on local regulations. As far as I can tell Europe will require some sort of blessing of the wallet. To be clear, governments will develop their own apps and it's not clear that Google will be blessed. We (Google) are giving them the code pro bono to improve privacy.
  - deleted 1y ago
    [deleted]
  - coldpie 1y ago
    Hmm. This introduces a third party to the protocol, right? Specifically the developer of the wallet. So we now have three parties: the user, the wallet developer, and the relying party. Does this zk protocol protect the user's privacy from the wallet developer as well as the relying party? In other words, does the protocol give the wallet access to information about the relying party? For example, could this wallet that I don't control tell its owner, or the government, that I am using it to access a certain website?
    - MatteoFrigo 1y ago
      Yes, a malicious wallet could leak your information. This is why some governments will insist on using only blessed wallets. However, wallet+zk is strictly better than sending the plaintext MDOC to the relying party. There are no solutions in this space, only tradeoffs, and elected representatives have picked one tradeoff.
      - coldpie 1y ago
        That's too bad :( I wish the protocol had been designed with that in mind. Requiring users to trust proprietary software from Google & Apple to be in complete control over their digital identities is a pretty crummy direction to go in.
        MatteoFrigo 1y ago
        See https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework https://github.com/eu-digital-identity-wallet/eudi-doc-archi... for a reference to the nuances on all these topics, at least in the context of the European Union. Other locales have different problems and different solutions. If you think you have a better idea shoot me an email.
- miki123211 1y ago
  In principle, you could use an open source implementation, but not a user-modifiable implementation. Nothing stops a government from making their code open source and providing you with reproducible builds. You just won't be able to change the code to do something the government doesn't deem legal.
deleted 1y ago
[deleted]

abhv 1y ago

(1) in this case, an identity issuer provides the source of truth identity information. Examples include state DMV, your passport (you can try "Id pass" in Google wallet), etc. (2) One of the goals of this project was to layer ZK on top of current identity standards that DMVs already issue, so that gov orgs don't have to change what they currently do to support the strongest user privacy. One example format is called Mdoc. (3) The user holds the identity information on their device only. No other copies. The user's device makes the zkp proof on-device. This was one of the major technical challenges. (4) The relying party (eg a website) runs the zk verification algorithm on the proof that is produced by the device to ensure soundness. (5) Yes, the user can use any compatible implementation to produce the proof. We have open-sourced our implementation and we have a spec for the proof format that others can also reimplement.

coldpie 1y ago
Thanks for the reply. So in theory, I could get this MDOC file and store it on my desktop computer, and use an open-source library whose behavior I can verify, to provide the proof to the website via my web browser. Yeah? This sounds good to me.
- MatteoFrigo 1y ago
  No. Using the MDOC requires a signature from a hardware security key in the phone, and a lot of the complexity is how to avoid leaking the private key, which would identify you.
  - coldpie 1y ago
    Well, that's not great. My phone is closed-source and its software is provided by an ad company. I do not trust it to always behave in my interests.
    - MatteoFrigo 1y ago
      An alternative would be some secure chip in a credit-card size plastic document, but nobody seems to like that idea. We (Google) don't make these choices.

esbranson 1y ago

It is decentralized. The holder provides the data, which was ultimately provided to them by the government, they're the client. The verifier is the entity that wants to know how old the holder is, the server. 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 https://en.wikipedia.org/wiki/JSON_Web_Token [2] https://github.com/w3c-fedid/digital-credentials https://github.com/w3c-fedid/digital-credentials [3] https://w3c-fedid.github.io/digital-credentials/ https://w3c-fedid.github.io/digital-credentials/ [4] https://github.com/w3c-fedid/FedCM https://github.com/w3c-fedid/FedCM [5] https://w3c-fedid.github.io/FedCM/ https://w3c-fedid.github.io/FedCM/ [6] https://github.com/w3c-fedid/FedCM/blob/main/explorations/HOWTO-chrome.md https://github.com/w3c-fedid/FedCM/blob/main/explorations/HO... [7] https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/ https://eu-digital-identity-wallet.github.io/eudi-doc-archit...