RPC Authorization Meeting 9 Nov

[bumblefudge]

PRs

• Olaf's PR on 25 and 27
  • un-abandon 27! ( [X] Juan will do it)
  • quick regexp to limit string length and charset
  • session token versus session OBJECT (logging, etc)
    • 25: capabilities negotiation would complement 171: session/state
    • pedro: idempotency? successive 25s --> update contents of 171 WITHOUT CHANGING TOKEN
      *[X] juan will openPR#184
    • pedro: rename token --> session (Szimon: or sessionId)
      * [X] see PR#173
  • Ideas for Pre-Draft: Browser-Session Data Model CAIPs#170
    • juan: can CASA even specify a session object in a browser? is a browser standard necessary? a browser profile of a session abstract data model object?
    • pedro: i prefer source to browser or domain... keep abstract and platform agnostic; specify the data model without platform-spec terminology and mental models
    • pedro: session includes authZn event and other events in its state; wallet-initiated events (i.e. upgrading, exposing new caps, etc) should also live somewhere in it
    • hassan: session object <> sessionid ? dereference?
      • Pedro: WC has a session model; my goal for 25 is: dapp needs methods to interact with chains, so requests them from wallet; wallet can also advertise additional methods and/or chains; caip25 needs a session object to write events to for this latter part to be
      • hassan: wallet needs to know what's in the session (expiry, for ex.)
      • pedro: I didn't know MM had expiry yet? persists indefinitely now, non? hassan: yup, we want them somewhere, don't need to be in 25
    • pedro: possible path forward:
      • TTL in session establishment --> session obj with expiry
    • PR 170 (session object) versus 171 (sessionID)
      • pedro: singlechain --> authN'd provider (e.g. signAPI); multichain --> unauthN'd provider relationship (not authN'd until accounts authZd) (e.g. authAPI)
      • pedro: CACAO is authN'd by definition...
  • revive PR 170 - what props make sense?
    • hassan: expiry and stable token/sessioniD is a good start
    • pedro: namespaces, expiry and ID are a subset of signAPI so that works for us; don't want to bias this caip towards WC status quo by including anything else
    • division of labor: dereference relationship between sessionID and sessionObj? decouple? (decouple!)
    • firm up 171 sooner, 170 can stay open and keep iterating
    • pedro: modularity-- people could use one or the other but would need both for state changes...
    • hassan: where idempotency go, tho? 25 assumes each req/resp updates state in a 170 object, right?
  • iteration of 25 for session lifecycle
    • pedro: does 25 request a session? juan: what about a req where no session exists yet?
      • pedro: but who sets expiry, etc? dapp shouldn't define session...
      • hassan: yeah wallet sets all these
      • juan: who sets expiry if session created in 25 exch? Pedro: dapp should maybe request a TTL optionally at most; wallet sets default unless it feels like entertaining that TTL request :D
        • pedro: TTL could be mandatory or, if optional, implicit (default to, say, 7days;)
        • pedro: could also be configurable but with a min value, say 30 days
        • pedro: all these mean new error codes to be defined explicitly in CAIP-25, tho (i.e. TTL too high, TTL too low...)
      • juan: does each new 25 req bump expiry back?
      • szimon: feat req on gh for setting session expiry for testing purposes; CI/CD for example would benefit from manually setting a very short session to test handling of expired sessions
    • TTL <> heartbeats/keep-alive mechanisms...
    • Pedro: how is MM doing it now? Hassan: no maximum, no storage limit (set by); no heartbeat now
    • Juan: Usecase for keeping a conn open forever? Pedro: but heartbeat handles that-- idempotent 25 with same params keep
    • Pedro: state-changes for session as separate CAIP - new very cheap event type (e.g. heartbeat) that JUST extends expiry, no other compute or interaction model...
  • hassan: caveats in 25 req/res?
    • pedro: namespace indexing AND chainId indexing would allow a flatter expression without the extensions model...

{
  "eip155": {
    "chains": ["eip155:1", "eip155:137", "eip155:10"],
    "methods": ["personalSign"],
    "events": [],
    "extensions": [
      {
        "chains": ["eip155:137"],
        "methods": ["eth_getAccounts"]
      }
    ]
  }
}

proposed flatter structure:

{
  "eip155": {
    "chains": ["eip155:1", "eip155:10"],
    "methods": ["personalSign"],
    "events": [],
    ]
  }
 "eip155:137": {
    "methods": ["personalSign", "eth_getAccounts"],
    "events": [],
  }
}

Should there be a new error code for this error case? (:137 requested in two different ways)

{
  "eip155": {
    "chains": ["eip155:1", "eip155:137"],
    "methods": ["personalSign"],
    "events": [],
    ]
  }
 "eip155:137" {
    "methods": ["personalSign", "eth_getAccounts"],
    "events": [],
  }
}

issues

• decision on namespacing? mixed-key flat solution? or keep CAIP 25 simple now that session exist

next steps

• merge sessionIdentifier PR by next