-
Notifications
You must be signed in to change notification settings - Fork 321
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
Comments
@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.) |
This feels like wallets asking users which CIP-30 extensions to enable for a given dApp? |
Perhaps but could also be taken a step further and higher to even the "core" CIP-30 functionality such that:
etc :) |
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.
The site would be able to identify your wallet from your signature thus allowing them to index chain for the wallet's UTxO set.
Id argue that CIP-30 almost allows this behaviour, a user could always refuse a |
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.
The text was updated successfully, but these errors were encountered: