-
Notifications
You must be signed in to change notification settings - Fork 9
2024 08 07 Meeting Notes
Organizer: Tim Cappalli
Scribe: Heather Flanagan
- Administrivia
- Next call (A) dedicated to payments use cases
- ZKP presentation from Google
- Issuer identity in selective disclosure cases (#139)
- Tim Cappalli (Okta)
- Heather Flanagan (Spherical Cow Consulting)
- Benjamin VanderSloot (Mozilla)
- Manu Sporny (Digital Bazaar)
- Dave Longley (Digital Bazaar)
- Lee Campbell (Google Android)
- Wendy Seltzer (Tucows)
- Rick Byers (Google Chrome)
- Sam Goto (Google Chrome)
- Mike Jones (Self-Issued Consulting)
- Hicham Lozi (Apple)
- Dirk Balfanz (Google)
- Matthew Miller (Individual)
- Ted Thibodeau (he/him) (OpenLink Software)
- Ben Piercey (?)
- Simone Onofri (W3C)
- Brian Campbell (Ping)
- Tobias Looker (MATTR)
- Helen Qin (Google Android)
- Hiroyuki Sano (Sony)
Group discovers the joy of AI-generated Google Meet backgrounds
Note that there are guests on the call; they are welcome as observers (and are encouraged to join)
Next call (A series) will finish up Issuer Identity topic and talk about Payments use cases
(Lee) talked about ZKP at last in-person meeting and wanted to invite Abhi from the cryptography group to talk about what Google is doing in this space
[Slides]
(Lee) problem space — today’s credential formats have a couple of linkability problems: if the same MSO is reused across RPs, it can be used to track the user; if the RP and Issuer collude, full identity of the user can be obtained. What we want is selective disclosure, so that only the info requested by the RP is shared with no additional info leaked that may be used to uniquely identify the user. ZKP can do this, and there are different ZKPs out there, but we think Google’s can do what we need.
(Abhi) VC with ECDSA — design goal is to build a ZK system that allows a user to prove the value of up to 5 attributes from an issued credential from one of the currently deployed identity protocols (e.g., mdoc, sd-jwt, W3C VC; note: still need to research W3C VC, but it is a design goal, so we will). Note: we can’t change what the issuer does; ZK needs to work with existing signature schemes. (Abhi) User on-boards digital ID; no changes required of the issuers. All signatures must be ECDSA.
(Abhi) The secure element is at the hardware layer (device secret key). The KeyChain API is on top of that and is in the Android OS layer. Application level is the wallet; it makes use of the Android layer API. The only changes Google can make are in the application/wallet. Credential is signed by the issuer.
(Abhi) Needs to work within the current way credentials are requested.
(Abhi) ZK-MDOC — mdoc is a binary format to represent an mDL. If you parse the doc, there are two parts: the witness part and the signed MSO. The signed-by-the-issuer MSO parses down to the salted hashes of attributes.
(Lee) This doc is shared with the RP at every presentation, and everything here is a linkability problem.
(Abhi) If this MSO is re-used, the linkability problems get worse as the deviceKey is shared, other attributes, etc. Want a protocol that allows something to say, “I want to prove I have a signature on something that looks like 'this' and shows my age is over 18.”
(Abhi) There is a complex ZK statement to express the desired statement. What is needed to send a commitment to the values without sharing the details and still prevent cloning?
(Abhi) We do this by expressing a particular layered polynomial with specific constraints.
(Hicham) Do you need to have a different circuit for each request?
(Abhi) The parameter for the circuit is the number of attributes we show.
(Tobias) Related questions — does it allow building value comparisons?
(Abhi) You can. You do need to find a uniform way of expressing something like “4th attribute with the following constant". If the predicate is too complicated for the general case, you may need to create secondary cases and a library of circuits.
(Tobias) Is negotiation required within the protocols?
(Abhi) Yes, there is some standardization required. Figuring out the canonical circuit(s), how to specify the operation if it’s not quality, etc., needs consideration. It can be done from a cryptography point of view, but the protocol standard itself needs work.
(Ben) The public key of the issuer is part of the public parameters. Would it be significant complexity to put it in the hidden parameters as well?
(Abhi) We’ve talked about that internally, and it is indeed possible. If we want to hide where the mDL comes from, we will include the issuer among a list of 50. The complexity is that the circuit depends on the list of 50–100; the circuit has to hardcode the keys that are acceptable (or there needs to be an external mechanism to agree upon the set of valid issuers). So, whenever one of the 50 states rotates a key, that list has to change. Figuring this out is on the roadmap.
(Ben) The cost of rebuilding the circuit — does that have to appear at protocol definition time or query time?
(Abhi) Good question. The time it takes to make a circuit is seconds; it’s not computational overhead. It’s trust overhead.We currently hardcode it, and a protocol can be built around that idea (a governing body that controls the list). The ZKP system sees the circuit as a run-time parameter.
(Matthew) Fascinating, how ZKP works. Is the complexity involved in the wallet generating the ZKP and the verifier verifying it somehow? Will that become a feature of the Digital Credential API at the OS layer? Or will it need to be incorporated into a product? Or does it need to be a feature of the doc format?
(Lee) This will be a new format. You’ll request a ZK-MDOC rather than a regular mdoc. So Android would need to give you a library, which isn’t an unusual pattern. On the device side, you could put this into the wallet, as the thing that runs the code. Where it gets standardized is interesting. We could say use regular ISO mdocs, and then the proof system builds the ZK-MDOC out of that.
(Matt) So individual wallets wouldn’t need to implement it; it could be done at the OS layer?
(Lee) It could be.
(Matt) What is its resource consumption like?
(Abhi) That’s a parameter that can be adjusted. The proof systems can be configured to use more/less resources. Can demo this, and would love feedback on how to make it cleaner.
(Abhi) [demo]
(Lee) We think we can do this with existing mdocs and SD-JWTs, but we think we can make it faster if we can change the formats. We would like to go back to ISO and ask for an “mdoc-lite” to optimize and take out things like the un-needed salted hashes. That would offer a big improvement in performance.
(Abhi) The checking of signatures takes less than 10% of this. 90% is hashing and parsing. There’s a lot of redundancy in the format. It takes 2.2KB to handle what the state licenses are producing, but it would fit into 220 bytes, if condensed correctly.
(Tobias) If we could tweak the format and the computation related to the session transcript
(Abhi) The session transcript, used for liveness, is not expensive at all.
(Tobias) So we could preserve current behavior where session transcript is independently considered by both parties.
(Brian) The session transcript is specific to ISO mdoc. Is the rough equivalent of that the key-binding JWT?
(Abhi) I believe so, but I am not sure.
(Tobias) In general, it kind of is, though it has slightly different properties. It’s not quite an assertion; it’s more independently computed by both parties and forms a shared secret that both parties agree upon. So, similar but different.
(Matthew) Unlinkability is a benefit of this approach. Is there enough of a gain in incorporating this that this group sees adoption of this on that merit alone, or is there regulation driving wallets and verifiers to incorporate this?
(Lee) Both. There are still transactions that are required to be linkable. This comes down to cases where unlikability is important, such as proof of age. From a UX point of view, we can tell the user that they’re only presenting their age BUT they might also be presenting information that could uniquely identify them. We don’t want to do that — we’d like to solve that without regulation. It wouldn’t be surprising if regulations push to solve thos.
(Matthew) Is this the current best solution to unlinkability, or removing linkability from these ceremonies?
(Lee) AFAIK, it’s the only one that would let us do it with existing protocols and credential format. (Abhi) There are more efficient systems in the literature, but they would require a different secure hardware architecture. The type of proof system Google is using is based on “sum-check”, an interactive protocol that allows a prover to do crazy math. Once we get this working for simple things like date verification,I would like to see it used for more complicated use cases like mortgage applications.
(Rick) The industry is going to have to grapple with understanding how much ZKP is required and what kind of confidential computing might do this instead.
(Abhi) That’s fair to say. No one knew when we started the work what the cost would be. When you can get to the point of your phone making the proof in seconds, then why would you delegate to an external party?
(Hicham) Thank you for the presentation. From the protocol point of view, need to allow RP to specifically ask in the request what circuits they trust.
(Abhi) Agree.
(Matthew) If an entire credential is handed over, the device public key can become a tracking vector. Is this ZKP also asserting device identity that makes it unlinkable? Where will device binding come in?
(Abhi) in the status quo, the device key is sent to the verifier. In the ZKP, the only thing the verifier learns is much more limited information that doesn’t include the device ID. They learn that the statements are true, but not what the statements are.
(Lee) You get the assurance that the credential was bound to the device, but not necessarily that it was the same device (as last time).
(Abhi) in ZKP you only learn the proof is true, not what the information is.
(Simone) What is your idea of quantum-proof algorithms?
(Abhi) Our ZK system (itself) only relies on hash functions, which are not known to be broken by quantum computers. Changing MDOC to use pq-signatures would make the entire system purportedly secure against the basic quantum adversaries (this is a tricky statement to make without getting into details).