Mobile App Integration

[frederikrothenberger]

(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)

Problem: Mobile Apps, for example Distrikt, are hard to integrate with II. Because II only accept and response to browser window. The integration flow will become as following:

1. Mobile app needs to load up a browser window page to redirect the authentication payload.
2. The middle page should be the same url to web version login page of the DApp to make sure the principal ID is the same to both end.
3. Payload are session publickey , “frontend url” and anchor number.
4. After II response with a delegation message, this middle page will have to rebuild the delegation chain and get it back to mobile native side to recover the correct delegation identity.

This flow is not very good for mobile DApps, and we need to find a way to remove the middle page and call II’s canister function directly or allow II’s frontend to receive payload from other client software besides of Browser.

[frederikrothenberger]

Hi @neeboo

Thanks for raising this issue. We also think, that we should streamline the authentication flow. Not only for better interoperability with mobile apps, but also just for the UX improvements.

We have made a recent change to redirect handling in the service worker: https://forum.dfinity.org/t/changes-regarding-redirect-handling-by-the-service-worker/15047 This has previously been a blocker for Plan A. We are now looking into the details of allowing a redirect based authentication protocol.

Could you explain the plans B and C in more detail. For me it is currently unclear, what exactly you mean.

[neeboo]

Thanks for moving this topic to Github @frederikrothenberger .

I think we need II accepts parameters in different ways. Windows.message only lives inside a browser window, which will limit the usage. Other non-browser clients want to connect with II, will have to embed a browser( a compatible one). For example, what if my ubuntu iTerm want to connect with II's canister?

Right now, we are only consider agent<>canister authentication, but what if we comes to cansiter<>canister authentication, like in the future, user might control canister as his/her account/wallet to interact with other canister. Then we might have an authentication flow like client <JWT/DID> canister <key:id> identityProvider , which will enable a much safer and better way to interaction. More like an open-internet service.

[frederikrothenberger]

Hi @neeboo

Thanks for the feedback!

I think we need II accepts parameters in different ways.

Yes, this is something we plan on doing ever since we fixed the security issue with redirects.

However, it is also an Internet Identity specific restrictions. Other IDPs such as the ME application or NFID could already make use of redirects.

Right now, we are only consider agent<>canister authentication, but what if we comes to cansiter<>canister authentication, like in the future, user might control canister as his/her account/wallet to interact with other canister.

This is explicitly being picked up by the interoperability discussion in #5 and #6 (requirement R9). Please bring in your point there too, if you feel that we are missing some aspect of inter-canister communication in the current set of requirements.