Technical Working Group: Identity & Wallet Standards

internet-identity
82

The recording of the 26 November 2024 WG meeting is now available.

Summary of the WG meeting:

  • Discussed moving ICRC-95 to WG approved status, see the post above.
  • The first draft of ICRC-94 has been merged.
  • PrimeVault, the first wallet to implement ICRC-94, has been presented. Watch the recording and read more here about PrimeVault.
  • The first draft of ICRC-X has been presented, please add your feedback and comments on the PR.
  • ICRC-34 & ICRC-28: An open discussion around security considerations in relation to UX in dapps was held between @bjoern, WG members and community members. Watch the recording to learn more.
1 Like
83

Agenda for WG meeting 2024-12-10T16:00:00Z:

  • ICRC-95: Derivation Origin, moving to approved status.
  • ICRC-X: Batch canisters call, further discuss draft of a standard to make multiple canister calls in a single JSON-RPC call.
  • Review and merge the changes in the readme overhaul.

Any topic missing or want to bring up a new topic? Post a message in this thread or send me a DM.

84

New zoom link: Launch Meeting - Zoom

85

The recording of the 10 December 2024 WG meeting is now available.

Summary of the WG meeting:

  • Agreed to move ICRC-95 to WG approved status.
  • Reviewed and merged the changes in the readme overhaul.
  • ICRC-X: Batch canisters call, further discussed:
    • Agreed on the issue that a signer cannot continue or stop a sequence of calls based on the success/error response of a canister. This is due to the signer not being aware what response value means “success” or “error”.
    • On the other hand, the relying party is aware of the response structure and what a “succes” or “error” response looks like.
    • But the signer cannot communicate with the relying party directly to ask it if each individual call is either “success” or “error”.
    • If ICRC-49 is used, the relying party and signer communicate back and and forth for each individual call.
    • But with a batch call - meant for e.g. mobile use cases where the above isn’t feasible - the relying party and signer only communicate only once with one another.
    • So if we can’t ask the relying party if a response should be interpreted as “success” or “error”, the idea came up in the WG meeting to have the relying party hand over this responsibility to a canister.
    • This would be a canister controlled by the relying party - inspired by ICRC-21 - that takes one or multiple canister call responses and returns either “success” or “error”.
86

As discussed in the last working group meeting, the upcoming meeting has been moved a day earlier due to the holidays: 2024-12-23T16:00:00Z

The schedule for this upcoming working group meeting will be posted here in the coming week.

87

Agenda for WG meeting 2024-12-23T16:00:00Z:

  • ICRC-94: Browser Extension Discovery and Transport, go over standard once more and collect feedback.
  • ICRC-X: Batch canisters call, further discuss draft of a standard to make multiple canister calls in a single JSON-RPC call.

Any topic missing or want to bring up a new topic? Post a message in this thread or send me a DM.