search

ChainAgnostic / CAIPs

Chain Agnostic Improvement Proposals
https://chainagnostic.org
Creative Commons Zero v1.0 Universal
503 stars 146 forks source link

CAIP-25: Should there be a notion of sessions, and should they expire? #141

Open rekmarks opened 2 years ago

rekmarks commented 2 years ago

Ref: #138

Problem

CAIP-25 currently does not mention anything about the length of time for which a handshake persists, or what we may call "sessions". Should CAIP-25 specify some notion of "sessions" and whether/how they expire?

It's worth noting that, per @ganchoradkov and @bkrem, WalletConnectV2 expires CAIP-25 handshakes after 7 days by default.

kdenhartog commented 2 years ago

+1 we've found that time based permissioning can be extremely helpful for our browser permissions and I'd think this would be really useful for the wallet as well. The current options for time to reset/re-ask for consent are:

Screen Shot 2022-09-29 at 4 28 26 PM

depatchedmode commented 1 year ago

@kdenhartog Do you happen to know how many people end up using any of time based expiry for permissions?

kdenhartog commented 1 year ago

I don't believe we gather any data on this. Here's the list of P3A data we gather for telemetry if the user opts in for this: https://github.com/brave/brave-browser/wiki/P3A

bumblefudge commented 1 year ago

In the interest of moving 25 to Review, we might delegate/punt this to the #170 CAIP and wait for interested parties to harmonize session management there, if everyone is happy with the assumptions codified in the more topical/external #171. To discuss at next RPC call.

bumblefudge commented 1 year ago

At last RPC call, we got #171 to a good place and left some notes on how to continue iterating #170. Leaving this issue open for tracking if 25 gets merged before 170 does.

bumblefudge commented 1 year ago

merging further updates to CAIP-25 today, but still no progress on CAIP-170, so removing the CAIP-170 constraint for now. Leaving this issue open in case session design makes quick progress, but most likely the session object's properties will remain undefined in 25 and be constrained by an optional extensions later down the road, if at all.

kdenhartog commented 1 year ago

leaving this as an optional extension point will likely impact interoperability. It is possible to achieve, but the downside here is that on the DApp side logic has to fail gracefully here in a much more complex way. Especially if we plan to support things like multi-transaction flows or multi userOps (for AA style wallets) because in these case the content length may be larger than what would fit within a single request.

I suspect we could look to what HTTP has done over it's various revisions to find what the right pattern would be here if we don't want to constrain this to 170 right now.