Merge pull request #360 from ffmcgee725/chore/update-caip25

Modify CAIP-25 spec to account for additive vs atomic wallet_createSession requests

Author: bumblefudge

CAIPs/caip-25.md

@@ -46,10 +46,12 @@ Note that wallets NOT returning `sessionId`s MUST implement additional methods a
     * [`wallet_sessionChanged`][CAIP-311] to notify caller of updated session authorizations.
 
 After a session is established between wallet and caller, subsequent `wallet_createSession` calls can be used to update the properties and authorization scopes of the session.
-- When a `sessionId` is returned in the initial `wallet_createSession` response, subsequent `wallet_createSession` calls either: 
+- When a `sessionId` is returned in the initial `wallet_createSession` response, subsequent `wallet_createSession` calls either:
   - include a previously used `sessionId` on the root of the request meaning this request is intended to modify that session, or
   - do not include a `sessionId`, in which case a new session is created - the respondent generates a new `sessionId` and sends it with the success response - and the previous session dangles in parallel (until its expiration, if applicable), though maintaining concurrent sessions is discouraged (see Security Considerations).
-- When the wallet does not provide a `sessionId` in its initial response, subsequent `wallet_createSession` calls overwrite the previous singular session between caller and wallet.
+- When the wallet does not provide a `sessionId` in its initial response, subsequent `wallet_createSession` calls target the previous singular session between caller and wallet. 
+ - Wallets MAY interpret the intent of subsequent scope requests as adding to or overwriting of existing permissions
+ - Users MAY choose to grant a subset, superset, or entirely different set of permissions
 
 When a user wishes to update the authorizations of an active session from within the wallet, the wallet should notify the caller of the changes with a [`wallet_sessionChanged`][CAIP-311] notification.
 
@@ -119,7 +121,7 @@ Example:
     },
     "scopedProperties": {
       "eip155:42161": {
-        "extension_foo": "bar"    
+        "extension_foo": "bar"
       }
     },
     "sessionProperties": {
@@ -210,7 +212,7 @@ An example of a successful response follows:
       "cosmos": {
         ...
       }
-    },      
+    },
     "scopedProperties": {
       "eip155:42161": {
         "walletExtensionConfig": {
@@ -296,7 +298,7 @@ Regardless of caller trust level, the following error responses can reduce frict
   - message = "Unknown notification(s) requested"
 - When a badly-formed request defines one `chainId` two ways
   - code = 5204
-  - message = "ChainId defined in two different scopes"  
+  - message = "ChainId defined in two different scopes"
 - Invalid scopedProperties Object
   - code = 5300
   - message = "Invalid scopedProperties requested"