Add proxied canister call spec

[frederikrothenberger]

This PR adds a possible specification for proxied canister calls. It is intended to be implemented by IDPs that provide a front-end for end users. The goal is to have a generic specification that works for existing canister calls (given the canister can be extended to incorporate the consent canister interface).

Rendered version of the specification

Possible next steps:

• Discuss with working group
• Security review
• Add concrete end to end example

[frederikrothenberger]

I see how this works on a technical level. I assume the intention is to use it for infrequent actions?

Yes, exactly. I.e. asset transfers and other high value operations, where you would want user consent anyways.

[neeboo]

There is one situation that is needed to consider, the allowedTargetCanisters can be dynamic. When new canisters are pushed to this array. Will the authentication process start again or start from somewhere in the middle?

[frederikrothenberger]

There is one situation that is needed to consider, the allowedTargetCanisters can be dynamic. When new canisters are pushed to this array. Will the authentication process start again or start from somewhere in the middle?

The proxy calling flow needs to be repeated for each a call that is made. This means that for every proxy call, the allowedTargetCanisters would be fetched new. --> Changes to allowedTargetCanisters will affect all proxy call flows that were started after the change was made (which I think is fine from a security perspective).

[marydwyer]

4/4/2023 Working Group Next steps:

• Separate out validate proxy call / consent message component to standardize, and discuss the other elements of the proposal in ongoing discussions
• Goals for consent message standard
• • Contribute to existing conversations on the topic -- Reuse consent message in different contexts

[frederikrothenberger]

Superseded by ICRC-21 and ICRC-25.