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.

[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 #.

[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.

[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.

[adonesky1]

Diagram of session lifecycle for a session initiated without a sessionId:

Diagram of session lifecycle for a session initiated with a sessionId:

[hmalik88]

This is looking good, had a thought that could probably benefit from some more language in the spec: How would a wallet migrate from an existing dapp's session that has no sessionId to one that does if the wallet infrastructure now supports sessionId? Should the wallet communicate this to the dapp or would it just revoke all existing sessions across all dapps? I think we should also be explicit in stating that if a wallet doesn't return a sessionId it is implicitly stating that it runs under a single-session model.

[adonesky1]

This is looking good, had a thought that could probably benefit from some more language in the spec: How would a wallet migrate from an existing dapp's session that has no sessionId to one that does if the wallet infrastructure now supports sessionId? Should the wallet communicate this to the dapp or would it just revoke all existing sessions across all dapps? I think we should also be explicit in stating that if a wallet doesn't return a sessionId it is implicitly stating that it runs under a single-session model.

added some language to specify a migration path here: https://github.com/ChainAgnostic/CAIPs/pull/285/commits/71b77444c778d0f5a98885d14529c26ff8d9de22

Thanks for the feedback @hmalik88

[bumblefudge]

leaving some notes for today's discussion here: https://hackmd.io/VLhYsoFhTmCaGQJg1DXv6w