Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-30: Permission Sets #557

Open
Crypto2099 opened this issue Jul 20, 2023 · 4 comments
Open

CIP-30: Permission Sets #557

Crypto2099 opened this issue Jul 20, 2023 · 4 comments

Comments

@Crypto2099
Copy link
Collaborator

As we move as an ecosystem towards a world where things like signing multiple transactions with a single signature are expected behavior for user's ease, I believe we need to introduce the concept of permissions for specific dApps/domains when it comes to CIP-30 wallet connections so that users can granularly control what permissions or access a given dApp has to interact with their wallet.

@rphair
Copy link
Collaborator

rphair commented Jul 26, 2023

@Crypto2099 good idea to have an issue for this requirement. I agree it will be important: maybe important enough to create a CPS for it.

@Ryun1 something seems familiar about it... didn't something like this come up when discussing hierarchies of CIP-30 functions? (Apologies for not being great in this field; just trying to connect with prior discussion in the many PRs we have for CIP-30.)

@Ryun1
Copy link
Collaborator

Ryun1 commented Aug 9, 2023

This feels like wallets asking users which CIP-30 extensions to enable for a given dApp?

@Crypto2099
Copy link
Collaborator Author

Perhaps but could also be taken a step further and higher to even the "core" CIP-30 functionality such that:

  • I am a user who wants to connect my wallet to a site to signData with my wallet but DO NOT want to give that website access to create a transaction on my behalf
  • I want to give a site the ability to read my wallet state getUTxO without the ability to generate and request signature for a transaction on my behalf

etc :)

@Ryun1
Copy link
Collaborator

Ryun1 commented Aug 29, 2023

So adding optional permissions per endpoints?

I do quite like this as an idea, but I don't really see a backwards compatible way to integrate this with existing CIP-30 implementations. I think we would be better off pursuing this as an extension, to something like a CIP-90?. I did have this in the rationale at some point... that CIP-90 would allow for "privacy preserving connections" but I must have removed at some point.

The counter argument is; does not sharing public info from wallet to site that useful? because if not then what are they sharing? why connect? - if they are signing (signData or signTx) then they are revealing their public keys where the dApp can index chain for the wallet's public info.

I believe we had the discussion somewhere about IF users should have the ability to explicitly permission dApps based on extensions -- but this was decided against - I will try and find the thread.

I am a user who wants to connect my wallet to a site to signData with my wallet but DO NOT want to give that website access to create a transaction on my behalf

The site would be able to identify your wallet from your signature thus allowing them to index chain for the wallet's UTxO set.

I want to give a site the ability to read my wallet state getUTxO without the ability to generate and request signature for a transaction on my behalf

Id argue that CIP-30 almost allows this behaviour, a user could always refuse a signTx action. The only difference is that the site is allowed to request it as much as they like, but I dont really see this being much of an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants