How to connect two dApps as having the same user?

Developers Motoko
1

I want one dApp to grant users some kind of permission and another dApp ask the first one, whether a user has the permission.

The problem is that users have different principals on different dApps. So, how the first dApp identifies that the user info delivered by the second one is of a certain user of the first dApp?

I suspect that I need to sign a message by one canister to another canister? I think, I could invent this auth scheme by myself, but I better use a well-known Motoko workflow. Please, explain how to do this.

3 Likes
2

A response to a forum thread that led to a similar question:

  1. You could ask the user to input the principal. This would “reveal” the identity of the user.

  2. As an alternative, you could not use Internet Identity as an authentication. You could require the user to authenticate with the same wallet (ex. Plug).

3

On another note, why would you need two different applications?

4
  • Inputting principal is insecure: The user could intrude entering principal of another user and getting his/her permissions.
  • Only II.
5

I want to create a “central” app that verifies an II user anti-Sybil status and distributes it to multiple other apps to be used by them.

6

You could try using ICRC-35 for this. There is a reference implementation which works fine.

ICRC-35 is an autorization agnostic webapp integration framework based on postMessage API. Basically, it works the same way Log in with II function works - a user would open a separate browser window with another dApp, do some stuff there, and then pass some information back to the opener window.

You could enable your “core” dApp to receive ICRC-35 requests from other dApps and respond back with user’s anti-Sybil status. In general this would be a complete alternative to “entering principal by hand”, but without “by hand” part - you would just pass the principal from one browser window to another.

I don’t know much detail about your app, but I could help you integrating ICRC-35 into it.

1 Like
7

I don’t understand how ICRC-35 can help to “coordinate” (check that they are of the same user) two different principals: the principal of the calling app and of the called app. Please, help.

8

Since the whole interaction happens within the same browser, there is no way to intervene into that protocol. This means, that the user is safe to pass their own principal from a dApp to the “core” dApp, somehow attest this principal in the “core” dApp (by signing it or something - I don’t know your inner workings) and then pass it back alongside the certificate of attestation and anti-Sybil proof.

It would make it simpler if you could explain how you currently prove that a particular user of your dApp proofs their personhood to other dApps. To this protocol you would just add a principal delegation protocol and it should be sufficient.

ICRC-35 is only used to safely pass data between browser windows.

9

I just didn’t implement it yet “currently”.

10

Then I think you should do that :slight_smile:
I’m not sure, but it seems like an important part of the value your dApp could propose.

11

Can it be done without opening a window? I want the apps to exchange data automatically (without user interaction): The client app requests whether for the current principal it has the permission and the “core” app answers.

Maybe, I should open a window for communication, and then this window should pass the messages and then immediately do self-close by window.close()? Is it a good idea?

12

With ICRC-35, can’t a user obtain fake permission in “core” app by using a modified browser?

If yes, then the user of the “client” app would be able to use other user’s permission from “core” app in “client” app.

13

Yes, you can do that. But the user would have to authorize within the “core” app, right?

How would that work? I can’t do much without knowing the internals of your app.
But if I would implement something like that, the Gitcoin passport would be signed by some trusted entity. This signature is unforgeble and it refers the user’s principal ID from the “core” dApp as an owner of the passport.

Then, in you “core” app you would allow users to delegate their passport to some other principal ID, by signing some message referring the passport’s hash and another principal ID.

Then, this delegation can be used in other dApps to verify 2 things:

  1. Some principal ID X has a passport with some fields. This passport is legit and is signed by the CA.
  2. This principal ID X has delegated their passport to principal ID Y. This delegation is signed by the X.
14

I’m not quite sure if this helps, but if both apps are developed by yourself, you could consider using the alternative frontend origin feature from II. These docs are a bit out of date last time I checked. Recent updates to this feature.

1 Like