Strawman of a CAIP-25 split into required/optional with session properties attached and verbose response

[bumblefudge]

As per yesterday's RPC meeting, this is a straw man of a more verbose CAIP-25 request dividing its params between required and optional arrays, the latter of which includes session properties.

This allows a simplified negotation-by-subset of optional authorizations, and a way for providers to override, ignore, or impose their own constraints to the session metadata. This may offer enough flexibility for everything requested in #141, at the expense of some complexity around corner cases. It also outsources to #170 the definition of valid properties and their valid values. Note that there is currently no versioning for #170 objects.

We should decide where "accounts" go as per #144 -- I took the liberty of throwing them into the namespace/chain objects, and allowing all-but-one of them to be empty arrays, but this was simply for the sake of having a straw man to debate. Opinions, corner-cases, UX nightmares, and new requirements welcome!

Signed-off-by: bumblefudge jcaballero@centre.io

[bumblefudge]

On a 1:1 call with a CASA member discussing this PR, they mentioned some semantic tweaks:

1.) renaming required and optional to something more semantically clear vis-a-vis their contents, i.e. scopes_required/scopes_requested or namespaces_required/namespaces_optional.

2.) moving sessionProperties out to a top-level param (sister of required and optional) rather than inside of optional so that each namespace object would just contain namespace properties, i.e.

...
    },
    "optional":{
      "eip155:42161": {
        "methods": ["eth_sendTransaction", "eth_signTransaction", "get_balance", "personal_sign"],
        "events": ["accountsChanged", "chainChanged"]
      },
    },
    "sessionProperties": {
      "expiry": "2022-12-24T17:07:31+00:00",
      "auto-refresh": "true"        
    }
  },

(they would still be defined as optional in the normative text of the spec, and responder could override or drop any of them, they just wouldn't sit inside the optional namespaces object)

[pedrouid]

I would put this in the response instead of the request

IMO it should always be the responder that defines it and/or calculates it

Alternatively there should be an upper bond for the expiry (eg. 30 days)

[bumblefudge]

Hehe, scroll down, in my example the responder picked a 7-day expiry and overrode the request :D

"expiry": "2022-11-31T17:07:31+00:00"

[bumblefudge]

Self-merging after editorial clean-up as agreed on today's call