ARC-52 Contextual Wallet API

[ehanoc]

Embracing wallets ability to be (or use) a KMS for more functions that are web3 friendly / compliant.

This also addresses problems for some projects in the ecosystem where wallets aren't able to generate, hold and recover keys that related to something else than transactions (i.e Identity / DIDs, Authentication, Secret Sharing, etc)

[joe-p]

One thing that needs to be considered when it comes to signing is that currently the Algorand SDK does NOT support signing arbitrary bytes unless they are prefixed with MX. All the current signing contexts (txns, messages, lsigs, etc.) have their own prefix for domain seperation. It seems like we want more general signing capabilities, in which case the SDK should be expanded to support signing ANY arbitrary bytes. I imagine this function should still check to ensure that the bytes being signed are NOT a program/txn.

[ehanoc]

One thing that needs to be considered when it comes to signing is that currently the Algorand SDK does NOT support signing arbitrary bytes unless they are prefixed with MX. All the current signing contexts (txns, messages, lsigs, etc.) have their own prefix for domain seperation. It seems like we want more general signing capabilities, in which case the SDK should be expanded to support signing ANY arbitrary bytes. I imagine this function should still check to ensure that the bytes being signed are NOT a program/txn.

I think this is okay. I think we can just defined the API (or Data Models) that any wallet could, if it chooses to, implement. The SDK can choose to update (or not). But there's not really specific to Algorand about key-generation, bip39/32/44 derivations or signing. In fact i think most Contextual keygen/signing past transactions (&logicsigs maybe) will be done with dedicated keys, not directly associated with addresses / accounts. Which i think it would make cryptographic sense to have dedicated keys for dedicated purposes; but still all of them recoverable from the same seed.

[k13n]

I think method sign should take some extra parameters that allows an application to communicate to the wallet & user what is being signed. This additional information can be structured or unstructured. If we consider the example of signing logicsig templates (ARC-47), how would the dapp communicate the ARC-47 template and the necessary placeholder replacements to the wallet?

Why is it only possible to export GPG keys but not any other kind of keys? It seems like we should either support exporting all keys or no keys.

Why is the interface written in typescript? Not all wallets are web-wallets written in TS/JS. How is a mobile wallet supposed to implement this ARC? Maybe this is meant as some abstract pseudo-code, but if so, it seems too specific to typescript since promises are returned. This also applies to many other ARCs that are typically written with some JS runtime in mind.

[pbennett]

One thing that needs to be considered when it comes to signing is that currently the Algorand SDK does NOT support signing arbitrary bytes unless they are prefixed with MX.

The SDK has a sign bytes function but IT prepends MX prior to the received bytes and then hashes it. The bytes passed into it can be anything.

[emg110]

Great ARC Proposal! So excited to see how it goes!

[ehanoc]

I think method sign should take some extra parameters that allows an application to communicate to the wallet & user what is being signed. This additional information can be structured or unstructured. If we consider the example of signing logicsig templates (ARC-47), how would the dapp communicate the ARC-47 template and the necessary placeholder replacements to the wallet?

Why is it only possible to export GPG keys but not any other kind of keys? It seems like we should either support exporting all keys or no keys.

Why is the interface written in typescript? Not all wallets are web-wallets written in TS/JS. How is a mobile wallet supposed to implement this ARC? Maybe this is meant as some abstract pseudo-code, but if so, it seems too specific to typescript since promises are returned. This also applies to many other ARCs that are typically written with some JS runtime in mind.

Taken this into account @k13n . Thanks for this.

I've removed the GPG bit. Might introduce too much confusion.

[HashMapsData2Value]

Bip-44 includes the change type but we are not incorporating it?