Summarized Feedback for ICRC-25

[frederikrothenberger]

Quick summary of the feedback received across different channels:

General

• [x] Add a sequence diagram / flow chart to visualize all the interactions
  • Sequence diagrams by @sea-snake: https://gist.github.com/sea-snake/99486dd25a58db48f525c4527dfdd839
• [x] Write a document with motivating use-cases / supported scenarios?
• [x] Explain transport / channel requirements
• [x] Explain trust model
  • Especially explain the interaction relying party <-> wallet interactions need more explanation.
• [x] Extend explanation of challenge-response-mechanism, link to interface spec for the supported signatures schemes
• [x] Clarify that response.identities[n].ledger refers to ICRC-1 ledgers.
  • Do we need support for multiple ledgers with many different subaccounts?
• [ ] Suggestion to switch from JSON-RPC messages to Candid
• [x] Introduce message to disconnect / switch identity?
• [ ] Introduce Icrc25SupportedStandards field on the permission request response to list possible future extensions?

Message Format

• [ ] Rename request.appMetadata.icon to request.appMetadata.iconUrl
• [ ] Rename response.appMetadata to response.walletMetadata
• [ ] Move response.signatures into response.identities[n].signatures
• [ ] Binary format: hex vs base64

Various smaller things handled in comments to the PR.

If anything is missing, please add a comment and I'll add it to the list.

[sea-snake]

Introduce message to disconnect / switch identity?

A way to indicate the intended identity to make the canister_call with seems missing currently.

Explain transport / channel requirements

Clearifying how a data channel could be considered "authenticated" is something missing indeed.

[frederikrothenberger]

Introduce message to disconnect / switch identity?

A way to indicate the intended identity to make the canister_call with seems missing currently.

You can specify sender when requesting a canister call.

[sea-snake]

Introduce message to disconnect / switch identity?

A way to indicate the intended identity to make the canister_call with seems missing currently.

You can specify sender when requesting a canister call.

Ohh that makes a lot of sense now, I always looked at that as the data required to make the canister call, but indeed the wallet could also use that to check if the right account with access to that identity is currently signed in.

[frederikrothenberger]

Summary of decisions made regarding ICRC-25 in last working group session (September 5):

General

• Process: Fix only minor issues in the current PR #32 and then merge, continue with smaller PRs.
• Split out more non-essential parts:
  • ledger metadata (because it is not core to the protocol, other metadata might also be useful)
  • App metadata: verification depends on channel / transport. Should be specified in these standards.
• Explore whether the messages should be defined in candid and a separate standard should govern how to map the types into JSON

Details

• Do not add Icrc25SupportedStandards but rather request scopes optimistically and a dapp then needs to make do with what is returned.
• Split error types to be per message rather than global.

[sea-snake]

@frederikrothenberger Here's a first draft of the ICRC-26 spec for the JSON value syntax of Candid types: https://github.com/dfinity/ICRC/issues/30

Wasn't sure where to put the spec since it's broader topic than the ICRC-25 spec, so made it a gist for now.

[sea-snake]

First draft of a ledger extension spec can be found here: https://github.com/dfinity/wg-identity-authentication/pull/47

[frederikrothenberger]

Closed, because all feedback has either been addressed or is outdated due to other changes in the standards.