Should CAIP-27 explicitly be limited to methods pre-authorized by a CAIP-25 call/session object? i.e. should "method not previously authorized" be an error response?
arguments pro: security, simplicity
arguments con: anyone got a use-case?
idempotent 25 --> update session object (WC has internal session update methods as well)
WC: already checked internally (WC won't call 27 on a non-25-authZd method anyways, error thrown before this even gets sent)
seems unanimous to just say... YES
Do some methods require an account, and thus a separate error message? Or is that best left outside of the scope of 27, for caip 25 and/or the node itself to provide?
Chain-specific methods that assume one (default) account?
Jakub: wallet can validate this before accepting/signing/sending the 27 call; Juan: But defining error msgs? Jakub: seems unsolveable at this layer
Juan: Maybe a caveat to 25 sets "default" account if there are more than 1?
[x] @bumblefudge will open issue summarizing corner-case request
More discussion regarding CAIP-25?
idempotency: normative or non-normative text defining expected behavior?
H: Something non-normative phrased as an assumption sounds better
Pedro requested implementer feedback/reports
implementation timelines?
H: MM Snaps v1 won't use all this; targetting launch of a multichain provider Q2/Q3
Jakub: already roadmapped tentatively - Kotlin SDK team might start any day now
Dan Finlay: Service discovery function <> UX "one-click" mechanism
DF: Need for caveats: i.e. "give me an acct with more than X DAI in it"
2023-01-18
PRs to refine/move to close
Ongoing issues/topics
Should CAIP-27 explicitly be limited to methods pre-authorized by a CAIP-25 call/session object? i.e. should "method not previously authorized" be an error response?Do some methods require an account, and thus a separate error message? Or is that best left outside of the scope of 27, for caip 25 and/or the node itself to provide?idempotency: normative or non-normative text defining expected behavior?Other business
Next Steps