---
# System prepended metadata

title: Notes for session C1 at WalletUncon 2023

---

# Notes for session C1 at WalletUncon 2023

Title of talk: How to ask for permission?
Convener(s) of talk: [depatchedmode](https://twitter.com/depatchedmode), [Agost Biro](https://www.agostbiro.net/#contact)
Scribe(s) of talk:
Links to any presentation matter:

Tips:
- if you use github or gitlab handles instead of names, that allows scribes and conveners to be easily findable/taggable in threads when these notes get published to the CASA github org)
- preface remarks with name/handle and org if you WANT to be credited for contributions or ideas. 
- feel free to call multiple people "anon" if you don't catch their names or they do not give them
- most scribes love an assist!

## Notes

- We need advanced permission systems if we are serious about self-custody
- The problem: satisficing
- Optimizing vs Satisficing
    - *Optimizing:* user makes a conscisious decision by careful consideration of the problem
    - *Satisficing:* user takes the shortest path to achieve their goal
        - To *satisfy* your immediate needs, you *sacrifice* your informed consent.
        - Users are more likely to do this under time pressure, and the more information is presentd in a popup/confirmation.
        - This session is about how we discourage satisficing user behavior.
- Solutions



| Solution | Web2 | Web3 |
| -------- | -------- | -------- |
| Reduce prompts     | Automatic grants, Trusted UIs     | Intents, Implicit grants, Trusted UIs?     |
| Delay permission requests     | Contextual prompts     | Contextual prompts?     | 
| Isolate apps | Site-specific authentication | Special-purpose keys |



- **Reduce the number permission prompts**
    - Web2:
        - *Automatic grants* 
            - For low impact, reversible actions 
            - E.g. set wallpaper
        - *Trusted UIs*
            - Operating system helps the user to carry out task securely
            - Part of the natural usage flow of the user
            - E.g. photo picker in iOS
    - Web3:
        - *Intents*
            - Web3-native solution to bundle multiple transactions into one permission prompt
        - *Implicit grants*
            - Follows the principle of trusted UIs: "permission" is granted by the user carrying out a desired action
            - E.g. instead of granting a token approval to a USDC payments app, transfer the tokens to an app-specific address.
        - *Trusted UIs*
            - Much more difficult in Web3 than in Web2, because
                - duplicate prompts between dapps and wallets
                - fragmentation of the ecosystem: different wallets and dapps have to coordinate instead of a closed ecosystem enforcing policy

- **Delay permission requests until user is in flow that facilitates optimizing behavior**
    - Web 2:
        - *Contextual runtime prompts*
            - Instead of asking for permissions at install time, ask for one specific permission when the user carries out an action the relevant action
            - E.g. prompt the user for location access when they want to see their location on a map
    - Web 3:
        - *Contextual runtime prompts*
            - E.g. imagine a decentralized social network that has a permission system for accounts. When the user connects their account to a third-party app, it only asks for posting permission when the user actually performs an action that creates a post
            - Difficult, because the third-party app might not be able to prompt the wallet/authentication app when the user tries to carry out the relevant action
- **Isolate app interactions**
    - Web2:
        - *Site-specific authentication*
            - Site-specific credentials to prevent compromise of a single malicious website from compromising other websites
            - Automate the idenfication of websites to prevent users from exposing their credentials to malicious websites
            - E.g. password managers, passkeys
    - Web3:
        - Special-purpose keys
            - Prevent malicious dapps from stealing tokens
            - Allow automatic transaction approval
            - *App keys*
                - Web3 apps on mobile often create their own externally owned accounts (EOA) or smart contract wallets (SCW) to automate signature approval
                - E.g. Farcaster
                - Challenges:
                    - App needs to take care of key recovery
                    - For usage of the key beyond the app, the app has to add wallet-like functionality
            - *Session keys*
                - SCW creates a scoped ephemeral key
                - Challenges:
                    - How SCWs identify dapps (smart contract address) and how user identify dapps (domain name) is misaligned
                    - SCW needs to interpret transaction parameters signed with session key
            - *Dapp keys*
                - Wallet creates EOA for a dapp (bound by domain name)
                - Challenges:
                    - Needs balance to pay for gas
                        - Solved by [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) (AUTHCALL)
                    - Many dapps expect one EOA/user
- Discussion
    - *ENS domain binding* idea
    - Binding trusted UIs to smart contracts
        - Challenge: composability
    - EIP-6963
    - Drag-and-drop permissions

- Sources
    - https://www.usenix.org/conference/hotsec12/workshop-program/presentation/felt
    - https://www.paradigm.xyz/2023/06/intents

- Follow up discussion: https://github.com/ChainAgnostic/secure-design/discussions

## Links

- [description](https://example.com)
- Emily Starks Talks about secure UI design in browsers - https://emilymstark.com/speaking.html
- 