RFC 0010: Wallet Attestation API

[teddyjfpender]

🚀 Introduction to the Innovation

Here is RFC-0010! It's about extending the wallet provider API to enable the wallet to provide attestations of private data, like credentials, it knows about.

🤔 Why This Is Important

Much like in RFC-0009, a wallet's ability to interact with certain zkApps may depend on data it knows and stores; this can include credentials or privately proving knowledge about certain data. In the latter scenario, it is necessary for a wallet to receive a request for attestation that binds a wallet to a specific scenario to prove it knows about certain data within its application context and not in the browser context.

💭 Seeking Your Input

Your expertise, feedback, and perspective are needed to make sure all requirements for a standardised wallet provider and any implementation of it!

[es92]

How does this program selection work? Is it something already hardcoded into the wallet, or does it make it in another way?

If hardcoded, maybe we should consider something that operates over json records? Like instead of a string being able to specify proofs over statements on records? (Like I think we talked about at an early version of this, getting a field and proving its type and basic things about it like for strings checking if it matches another string, for numbers inequalities, etc)

[teddyjfpender]

The binding is part of the request the application makes to the wallet. So the program field tells the wallet which provable program to use, this naively assumes the wallet knows what program that is and it's background script can fetch/compile the program such that it can execute the program with the defined inputs (public or private).

This certainly needs inputs from wallet providers to understand what is possible to implement. Holistically, I see these provable programs as little zkApps that are modules in the wallet that can be added & removed.

[es92]

I would propose then,we do something that operates over records, so that people can add new attestations without needing to re-coordinate and get updates from wallet providers? I think we should add that to this spec as well (lmk, if needed I can find the older doc I think we had on it too somewhere...)

[es92]

Thinking about this a bit more, I think that one option could be:

• Have attestations be json records (with extra types for different crypto primitives; and maybe flat json records)
• Make a DSL that operates over json records, and can be safely sent to the wallet to be executed in the wallet's context without security risks
• Have the DSL able to provide the following:
  • Binary statement over whether an attestation passes the check performed by the DSL, to compute the proof
    • this can also check which attestations would pass the DSL, to ask the user which to use if they have multiple attestations that would pass (or let them know if they have none)
  • Detail so the wallet can notify the user what information the DSL is asking for from the attestation (eg this will check [ Age > 20, proof of unique identity wrt nullifier X, etc ]

The DSL could be like is done for o1js, where its just a typescript library;

Maybe something like

(attestation) => {
   const verifier = new AttestationVerifier(attestation);
   return verifier.check_equal("field1", "value")
              .and(verifier.check_signature("field2", verifier.get("data_field"), "publicKey"))
              .and(verifier.check_gt("field3", 20));
}

I think ideally we'd want an ecosystem of attestations, so hopefully this could help make it easier to produce / consume attestations permissionlessly. Curious on any thoughts!

[teddyjfpender]

The bindings should satisfy those requirements -- they're about constraining the wallet to attest to something specific:

• Which provable-program to use
• Who the expected issuer of the private data is
• What the expected logic gate is (e.g. age > 20)

Since a wallet at it's core is just a key management system, it is not impossible to imagine an attestation management system that can sit next to the KMS or integrate into it. Much like a generic api.sign(params) can be one API of that key management system api.prove(params) could be too. That params argument is the bindings and should serve the purpose as might a api.sign(TransactionBody) might. Wallet users can already attest to statements in the browser context like constructing transactions (they are the spender/fee payer of that transaction), only to pass to the wallet for signing/submission, the key difference with this attestation API is the wallet is asked to use the bindings as context for producing the required proof within its own application.

In that sense, the attestation API could be used as a way for a zkApp to give context to the wallet about how to construct a transaction, sign it, and prove it before submitting to the network. I drew a little diagram to show the shift in responsibilities:

For this attestation context it is about giving the wallet context on how to construct arguments for a provable-program method and prove it.

[es92]

What does bindings look like exactly in this model? I'm still a little confused exactly where the proof if computed, and how exactly it is computed?

I was thinking it probably needs to be computed in the wallet, so that the attestation data doesn't leave the wallet to the unsafe webpage, but then the wallet needs some specific way of knowing how to compute the proof.

[es92]

In particular, we say above the wallet would be told "Which provable-program to use" - to me that sounds like wallets would have a fixed set of programs they can use - which seems limiting if we want new attestation producers and consumers to come along and build new attestations and consume them in their own way (and then I think we would still need something like the above DSL, so that we can allow dynamic proofs over new / existing attestations).

[teddyjfpender]

What does bindings look like exactly in this model?

The bindings are defined here.

where the proof if computed, and how exactly it is computed?

The bindings define what program and what inputs are expected via ClientData and publicInputs, proving should happen in the wallet application (or any secure enclave). bindings is the data structure that this RFC needs the most feedback on as it defines what provable-program and what inputs the wallet should use. For example, a wallet should be bound (hence the name bindings) to prove a specific Issuer created a credential for their PublicKey; they shouldn't be able to prove that any Issuer created that credential.

"Which provable-program to use" to me that sounds like wallets would have a fixed set of programs they can use

It should be read as "which provable-program to use for this attestation". There is no limit on the set of provable-programs a wallet can know about. As long as a wallet can know (a.) where to obtain the specific program, (b.) compile it, and (c.) cache the program to prevent always re-compiling when attesting, there isn't a limitation (modulo browser/service worker constraints).

I think we would still need something like the above DSL, so that we can allow dynamic proofs over new

The attestations created can be stored as credentials in the wallet's storage for re-use, but this somewhat can conflict with the considerations section where attestations may require a TTL.

[es92]

Ah I see - so can the bindings can define a series of operations constituting a claim (which could be constructed via DSL, or could be statically defined as done here)?

I think then I'm not understanding the role of the provable-program? Like what does changing that done?

I think I'm proposing then, in this new context, to

• Only provide information on the claim, as a statement over the fields of attestations (and not have provable-program? Unless I'm probably missing why its necessary)
• Maybe use a DSL to construct claims to make it easier? Though probably not necessary, especially for a first version.

[es92]

Just to share context here from speaking offline, we met and confirmed it does make sense to have "provable-programs" - but that provable-programs should be probably added via the standards process, and this standard should include a first provable program, “RecordCredentialAttestation” or something of the like, that operates with boolean statements over structured json-like attestation objects. If I have time later, I’ll make a PR on this one with what that could look like.

[es92]

Would claim be a function on the zkApp, that takes in a Proof type? (like here?)

[teddyjfpender]

Yes! It would be a method on the contract, or possibly another provable-program!

[es92]

Should the request include information on what information will be revealed to the website? Maybe if so, programs should include data about what information they are proving for the UI?

[teddyjfpender]

Indeed -- that's an important component, a wallet user must be able to understand precisely what they are attesting to and with what inputs. I'll add a section on this.