Closed frederikrothenberger closed 1 year ago
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.
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?
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).
4/4/2023 Working Group Next steps:
Superseded by ICRC-21 and ICRC-25.
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: