Lifecycle Methods and Event Alternative to sessionsId

[adonesky1]

This proposal introduces new "lifecycle" methods for managing permissions within an existing CAIP-25 session, allowing for addition, revocation, and retrieval of permissions. These methods provide an alternative to session management via sessionIds, allowing sessionIds to be optional for CAIP-25.

[vandan]

I agree that we need a way to distinguish between the initial and subsequent permission requests as they may have different implications to the way permission requests are presented to end-users.

Specifying that subsequent calls to provider_authorize will be treated as additive (similar to how provider_augment would work) seems like an elegant way to handle this. Otherwise we might have ambiguity about what happens when provider_authorize is called multiple times.

I initially thought we might need wildcards in the provider_revoke call, but with provider_getSession available it should be trivial to create application-side utilities to do things like "revoke all" permissions (aka logout).

[hmalik88]

I would prefer the various methods to be spun out in their own respective CAIPs, you can mark the CAIPs based off of the PR #.

[hmalik88]

I'm assuming you're referring to user-initiated permission revocation in the extension? If so, what happens if the dapp is not connected to the wallet when the permission is revoked? Can the dapp just not rely on provider_getSession?

[adonesky1]

I'm assuming you're referring to user-initiated permission revocation in the extension? If so, what happens if the dapp is not connected to the wallet when the permission is revoked?

🤔 I guess you mean if the connection is severed somehow? I suppose in that case the dapp would use provider_getSession but I think this event is useful for most cases where a dapp can immediately reflect a change to the state of its permissions

[bumblefudge]

severed, or just timed out. i think the fundamental assumption that both app and wallet persist the config (if not the "session" in browser-memory or RPC-connection sense) is the first thing we need to be aligned on, before getting to other stuff? in hassan's example, the wallet would let the user revoke a permission and... persist that message/event until there's an active RPC connection, right?

all this sounds fine to me, but should be explicit in the spec since it obligates the provider (or the wallet+plus+provider) to persist until next connection. conversely, if this event is ONLY fired within an active session and dropped otherwise, specify that and separately define the behavior if user tells wallet to revoke without (or without knowing about the absence of) a live connection

[adonesky1]

Does the following additional sentence assuage your concerns?

"If a connection between the wallet and the caller/dapp is severed and the possiblity of missed events arises, the caller/dapp should immediately call wallet_getSession to retrieve the current session scopes."

[adonesky1]

I would prefer the various methods to be spun out in their own respective CAIPs, you can mark the CAIPs based off of the PR #.

Happy to do this. Wanted to present these as a package to lay out the full sweep of scenarios they are serving in place of sessionIds.

[bumblefudge]

...on the assumption that dapp should only persist one "session" (config) at a time for any given wallet, thus new sessionId overwrites/replaces the revoked session, that by not being persisted is as good as dead.

(no change here, just filling in the assumptions/thought behind status quo in case it's cryptic)

[bumblefudge]

Love it, looking forward to discussing Wednesday on the community call

[adonesky1]

I'm starting to wonder - forgive me if someone already suggested this - whether wallet_updateSession (previously called provider_augment in this PR) could be used for both adding and revoking permissions, rather than having a separate wallet_revokeSession method to partially or fully revoke. Why not just have one method that could do both additions and revocations simultaneously.

I suppose you could then argue why not just let it all fall back to provider_authorize (which may be renamed to wallet_createSession) and just create a new "session" with modified scopes (added and/or revoked) each time.

I think that could work too. Whether its a new session or just an updated existing session becomes pure semantics when you don't include a sessionId and the new wallet_createSession must be called with the full scopes that should be authorized after the call (not just the delta).

After reflecting on it I think its cleaner to either:

1. Just fall back to provider_authorize/wallet_createSession for adding/revoking to an existing session
   or
2. Just use wallet_createSession for an session initiation and wallet_updateSession for any changes (additions or revocations) to an existing session.

WDYT?
@bumblefudge @pedrouid @shanejonas @vandan @hmalik88 @300

[bumblefudge]

1. Just fall back to provider_authorize/wallet_createSession for adding/revoking to an existing session
   or
2. Just use wallet_createSession for an session initiation and wallet_updateSession for any changes (additions or revocations) to an existing session.

But isn't option (1) just... status quo? CAIP-25 as written means the dapp sends update/escalate/partial-remove proposals by sending the entire state it would like to see, with the current sessionId written on the envelope, or if it sends an envelope with no sessionId, that's interpreted by the wallet as wiping the slate and proposing a totally new session.

As I understood it, the whole reason for adding more RPC methods was that either party could send deltas without a sessionId and have the other side accept/reject the delta. This gives a sessionId-free wallet a way to interact with a sessionId-relying dapp, while still allowing the dapp to send a blank sessionId when it wants to renew. Makes it easy for both sides to interact meaningfully.

[bumblefudge]

Looking mergeable, once we renumber all the docs? I opened tracking issues to ensure people find THIS thread when looking up THOSE documents:

The only thing that seems like it might change as this gets implemented is error codes and Considersations sections, but all that should be easy enough to update with separate PRs down the road.

@hmalik88 have you taken a stroll through here?

[hmalik88]

LGTM 🎉

[Rahul-cyber26]

#358