RFC 0009: Wallet API - Storing & Requesting Objects

[teddyjfpender]

🚀 Introduction to the Innovation

Here is RFC-0009! It's about extending the wallet provider API to allow for storing objects, like identity credentials and proof objects.

🤔 Why This Is Important

A wallet's ability to interact with certain zkApps may depend on data it knows and stores, this can include credentials. In those scenarios, it is necessary for a wallet to receive credentials from issuers and provide them when requested.

💭 Seeking Your Input

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

[es92]

What does it mean to "store objects from a zkApps"? I'm imagining that some zkApps would have public state - and others would store hashes of private state, and the private state is the thing that this is storing? Or something else?

[teddyjfpender]

A zkApp can produce a well-formed credential that has a Kimchi proof in it, in that case, the zkApp would be the issuer of the credential and can allow the wallet to store that object for future use like in a smart contract method argument.

If one were to assume that these objects could be fetched, or rather requested from a zkApp, this response can be stored much like how transaction history or current account information is stored in the wallet. The objects the wallet stores don't have to be private information but they can be.

A wallet storing credentials they can use in smart contract or provable-program methods is more about how to improve the interaction design between wallets and zkApps. If it is beneficial for a wallet to hold those credentials then they can use this API as a way of enabling that, there of course exist other designs that don't require the wallet to hold credentials but that design pattern is outside the scope of this RFC :)

[lvshaoping007]

But how can users ensure these credentials are beneficial ?

[teddyjfpender]

But how can users ensure these credentials are beneficial ?

That is at up to the wallet user, the requested storing of those credentials must detail what the credential or object being stored is to the wallet user for them to determine the benefit. The real benefit of storing credentials in the wallet is that it gives the wallet user the ability to utilise them as and when they need/desire, without relying on central parties.

[es92]

Is it possible this is not a pattern we would want to allow? It seems if the information is private, we might not want to release the information to the website at all (vs releasing proofs to the website ie the attestation standard API)

Or are there cases where there is private data, that we do want websites to be able to request directly, and can't / don't want to just share a proof?

[teddyjfpender]

This pattern would be for public, not sensitive information. Instead of a KYC credential that might contain personally identifiable information, a wallet might store a zkOracle attestation that makes a claim about some Web 2 data, in that case the user doesn't need to attest to that data again, it can just provide the original attestation proof it knows of.

In any case, a wallet should communicate to the user what a zkApp is requesting to ensure the user is completely aware of what data they are sharing. Data stored in a wallet should be encrypted at rest to prevent unauthorised access to it, and partitioned well enough to separate concerns and not accidentally provide private data.

[Pfed-prog]

From my understanding the data could be stored as:

app_id - data

potentially on a merkle tree with app_id as index,
this could enable even easier data provision into an app that waits for a merkle witness and data

[teddyjfpender]

@Pfed-prog a wallet can certainly be indexed by an app_id! But there could be some concern when the wallet writes that new data it overwrites something else that should not be overwritten. How a wallet stores data is an implementation detail beyond the scope of this RFC, the point of the provider API is to allow the zkApp to provide enough data such that any wallet can index the data as they desire, app_id can be one component of that!

[lvshaoping007]

How does zkApp know whether the wallet has the information he needs? And how does the wallet know what information zkApp needs?

[es92]

This pattern would be for public, not sensitive information. Instead of a KYC credential that might contain personally identifiable information, a wallet might store a zkOracle attestation that makes a claim about some Web 2 data, in that case the user doesn't need to attest to that data again, it can just provide the original attestation proof it knows of.

In any case, a wallet should communicate to the user what a zkApp is requesting to ensure the user is completely aware of what data they are sharing. Data stored in a wallet should be encrypted at rest to prevent unauthorised access to it, and partitioned well enough to separate concerns and not accidentally provide private data.

What would "the original attestation proof it knows of" look like? Is this caching proofs from the attestation API? Or something more general? Think I"m missing what other kinds of things this would want to expose.

[teddyjfpender]

How does zkApp know whether the wallet has the information he needs?

@lvshaoping007 A zkApp must request that data (or proof) from the wallet along the lines of "do you have a valid credential issued to you by Issuer ABC?", a wallet can only provide that credential if it knows of a credential issued by Issuer ABC, else it should deny the request.

And how does the wallet know what information zkApp needs?

That should be defined in the request message. The request message/params are agnostic enough to allow for flexible indexing of that credential, this is only a first attempt at this standard and I believe it would evolve over time as more issuers realise their solutions in production, hence eliciting their requirements in this RFC.

[TyrellCorp2020]

Moving to draft as will need further review before progressing