Transaction approval for proxying calls to other canisters

[dostro]

Problem: Developers may want to call other canisters as the authenticated user, but don't have a way of doing that when using an identity provider that generates new principals for each domain.

Requirements:

• Developers should request approval to call methods in other canisters
• Identity provider should protect users from malicious calls (i.e. pretend like it's asking DSCVR for username information when in reality it asks to transfer all your assets to a predefined wallet address)

Thoughts on a solution: @frederikrothenberger suggested a potential solution where, similar to .well-known for alternative origins, developers set up something like .well-known/proxy to expose metadata on trusted endpoints and their descriptions (with support for internationalization).

[marydwyer]

10 Jan 2023 Meeting Notes:

Potential Solutions

• Make the description templated
• Developers write comments in idl files
• .well-known json file - https://jsonforms.io/, candid ui, etc.
• call a specific canister method on the target

Risks/Concerns

• Could there be a timeout in devs requesting approvals to call methods? (could be an argument for the templated static file solution)
• What information can we take in and present in a trusted environment? (could be an argument against canister call)

Strengths of static file

• Allows for more experimentation
• The description of the call is more reliable and understandable

[frederikrothenberger]

Given the importance of this topic and the multiple different approaches being taken right now, I have taken the time to create #16. Hopefully it prompts a lively discussion on how to implement the user-facing consent flow and helps us agree on a common specification that works for all IDPs.

[frederikrothenberger]

@dostro: I'm closing this issue because I think it is sufficiently addressed with ICRC-21 and ICRC-25. Please let me know if you disagree.