search

dfinity / wg-identity-authentication

Repository of the Identity and Wallet Standards Working Group
https://wiki.internetcomputer.org/wiki/Identity_%26_Authentication
Apache License 2.0
28 stars 9 forks source link

Global delegation Identity and cross-device authentication #2

Open frederikrothenberger opened 1 year ago

frederikrothenberger commented 1 year ago

(This issue was created on behalf of Neeboo based on the following forum thread: https://forum.dfinity.org/t/internet-identity-roadmap-update-september-2022/15306/2)

This two problem are related.

First, global delegation identity, is more important than we think for users. Delegation Identities provided by II, initially design for a secure way to access domain-tied canister, to prevent the delegation leak and protect users’ privacy. However, users today are too familiar with global ID for example ethereum’s wallet, they find it very easy to use to login as many integrated website. These IDs are portable, easier to understand that seems every DApps display the same thing, and more importantly. Users can use them to receive and send assets(coins/nfts) across the DApp. On IC, users find it difficult to understand and getting confused when they mint a nft from DApp A, and they have to manually input the principal/accountId of DApp B (market place maybe) to be able to list it to the market.

We have been told that the II team is working hard to find a solution with “pemission/capabilities” model of delegation. Which is great, however, we still need to find a way to generate such global ID for users to understand and use.

delegation_identity

Secondly, AstroX is experimenting with such global delegation. We need to be careful that the delegation targets(canister IDs) have to be passed into the canister signature. And every time when there is a new actor with new targets used by frontend, these targets are also needed to added to the signature. If not, the global delegation can access to all the DApps and putting users in dangerous situation. We have seen Plug wallet is using the same mechanism to prevent this situation happens, since they are also another solution of global IDs. Although we can keep this secure by signing every targeted canister, but It will also increase the cost of interaction of Users. For example, entrepot has over 190 NFTs listed right now, and more will be added to the market, users need to sign all of them. Now think of if some day oc.app is integrating with such global ID, since every user control his/her own canister, if you invite a friend to your chatting channel, another canister need to sign. Which will cause such delegation not applicable to IC DApps.

cross_device_delegations

For our problem, is that we cannot use cross-device login. For example, Alice has a mobile app holding her identity, meanwhile she wants to login to a computer in the public Cafe. Now she won’t have to add the computer as a device to her II, but to control a temporarily session identity using her mobile app, just like scanning a QR code. Now if only when the delegation is global, the signing process is needed when new target canisters are added. Which will cause so much trouble in this device-to-device situation. We do really want to support this scenario, but to overcome this problem, we need advanced solution of global delegation capabilities or we just have to use other protocol like WebSocket or other methods.

frederikrothenberger commented 1 year ago

Hi @neeboo Thanks for raising this issue. Do I understand correctly, that you would like to have an easier way to limit interactions while keeping a stable principal?

What do you think of the following scheme:

  1. When logging into a dapp, a delegation is created that has a limited set of permissions for the corresponding canister (similar to targets but finer grained).
  2. When the dapp requires permissions to another canister it will initiate an interaction with the IDP to get consent from the user. If accepted, the dapp gets a new delegation with the added permissions to the third party canister.
  3. On subsequent visits, when logging in to the dapp, it is issued a delegation with all the permissions to third party canisters that were previously granted included automatically.

If I understand correctly, this should address both problems, right? There is exactly one user interaction for each authentication flow and an additional interaction each time the permissions get expanded. So in your cross-device scenario, the user can log in and access the dapp and authorize all previously requested cross-canister interactions with just a single interaction. Only when the permissions get changed, another interaction is necessary.

What do you think?