Wallet ICRC prioritization suggestion

[dostro]

Given what we've learned going through the standardization process so far and the pressing ecosystem need for wallet standards, I propose we re-focus efforts on these 5 dapp requests to signers:

Get accounts

• Useful for: Quickly connecting to dapps and retrieving public data about principals/accounts
• Current ICRC: Combination of ICRC-27 and ICRC-31
• Notes: Dapps can read principals + sub accounts from an Account response, so it's unclear to me why we should separate the two since signers that don't support sub accounts can still respond appropriately. Also I don't believe it's the signer's responsibility to tell dapps which assets it supports. Worst case scenario, the dapp could always call execute transaction (aka canister call) to help users transfer assets to signers that support them.

Sign message

• Useful for: Proving ownership of principal/account
• Current ICRC: ICRC-32 but with message
• Notes: For similar reasons as get accounts, I believe this ICRC should be extended to support Accounts and optional message parameter for user readability.

Execute transaction (aka call canister)

• Useful for: Executing authenticated function calls to any ICP smart contract canister
• Current ICRC: ICRC-49
• Notes: None.

Get session delegation

• Useful for: Siloed dapps that make many authenticated calls and don't care to incorporate user data across ecosystem
• Current ICRC: ICRC-57
• Notes: None.

Get global delegation

• Useful for: Dapps that make many authenticated calls within its own service and wants to incorporate user data across ecosystem
• Current ICRC: ICRC-34
• Notes: None.

Overall, it's not immediately clear to me why the base ICRC-25 standard should exist. It seems to overcomplicate the actions above without an obvious benefit in my mind. I could, of course, be wrong here.

cc @frederikrothenberger @sea-snake

[frederikrothenberger]

Overall, it's not immediately clear to me why the base ICRC-25 standard should exist.

All of these methods listed are specific use-cases. But we do need a framework to place them in.

One spec that deals with the use-case independent questions of:

• What features are offered by the signer?
• How are initial connection / permissions dealt with?
• Provide other common definitions / functionality used by all extensions (e.g. error codes, transport requirements, session handling)?

Which is exactly what ICRC-25 does. I don't think we should abandon this very extensible and clear structure now and leave these points undefined.