Merge pull request #327 from adonesky1/ad/refine-scopes-type-naming

Refine 'scopes' naming conventions

CAIPs/caip-217.md

@@ -49,10 +49,8 @@ uppercase in this document are to be interpreted as described in [RFC
 The syntax of a `scopeObject` is as follows:
 
 ```jsonc
-
-
 [scopeString]: {
-   *scopes: [(chainId)+],
+   *references: [(reference)+],
    methods: [(method_name)+],
    notifications: [(notification_name)+],
    *accounts: [(account_id)+]
@@ -64,10 +62,10 @@ The syntax of a `scopeObject` is as follows:
 Where:
 
 - {`scopeString`} (conditional) = EITHER a namespace identifier string registered in the CASA [namespaces][] registry to authorize multiple chains with identical properties OR a single, valid [CAIP-2][] identifier, i.e., a specific `chain_id` within a namespace.
-- `scopes` (conditional), formerly `chains` = An array of 0 or more [CAIP-2][] `chainId`s. For each entry in `scopes`, all the other properties of the `scopeObject` apply, but in some cases, such as when members of `accounts` are specific to 1 or more chains in `scopes`, they may be ignored or filtered where inapplicable; namespace-specific rules for organizing or interpreting properties in multi-scope MAY be specified in a [namespace-specific profile][namespaces] of this specification.
+- `references` (conditional), formerly `chains` = An array of 0 or more references - a resolution to a specific blockchain for the `namespace` specified as the `scopeString`. For each entry in `references`, all the other properties of the `scopeObject` apply, but in some cases, such as when members of `accounts` are specific to 1 or more chains in `references`, they may be ignored or filtered where inapplicable; namespace-specific rules for organizing or interpreting properties in multi-scope MAY be specified in a [namespace-specific profile][namespaces] of this specification.
   - This property MUST NOT be present if the object is already scoped to a single `chainId` by the `scopeString` value above.
-  - This property MUST NOT be present if the scope is an entire [namespace][namespaces] in which no `chainId`s are defined or no [CAIP-2] profile has been published.
-  - This property SHOULD be present if the scope is an entire [namespace][namespaces] in which `chainId`s are defined. An empty `scopes` array MUST NOT be interpreted as authorizing an entire namespace in which a finite list of [CAIP-2] value could be set, but rather, as applying equal to zero members of that finite list until 1 or more of them are added to `scopes`.
+  - This property MUST NOT be present if the scope is an entire [namespace][namespaces] in which no `references` are defined or no [CAIP-2] profile has been published.
+  - This property SHOULD be present if the scope is an entire [namespace][namespaces] in which `chainId`s are defined. An empty `references` array MUST NOT be interpreted as authorizing an entire namespace in which a finite list of [CAIP-2] values could be set, but rather, as applying equally to zero members of that finite list until 1 or more of them are added to `references`.
 - `methods` = An array of 0 or more JSON-RPC methods that an application can call on the agent and/or an agent can call on an application.
 - `notifications` = An array of 0 or more JSON-RPC notifications that an application send to or expect from the agent.
 - `accounts` (optional) = An array of 0 or more [CAIP-10][] identifiers, each valid within the scope of authorization.

CAIPs/caip-25.md

@@ -69,8 +69,8 @@ Each `scopeObject` in either parent object MUST be keyed uniquely within its par
 (i.e., additional properties of an authorization target in `requiredScopes` may be requested in a separate `scopeObject` with the same key in the `optionalScopes` array).
 
 Each `scopeObject` in these parent `...Scopes` objects can be keyed to a specific [CAIP-2][] network identifier, or to an entire [CAIP-104][] namespace.
-`scopeObjects` keyed to an entire [CAIP-104][] namespace SHOULD contain a non-empty `scopes` array to be actionable, making them functionally equivalent to a series of identical `scopeObjects`, each keyed to one of the members of `scopes` expressed as a [CAIP-2][] scope.
-An empty or absent `scopes` array SHOULD NOT be interpreted as a namespace-wide authorization (i.e. authorization for ANY network therein), but rather as a null authorization of 0 specified `chainId`s within that namespace.
+`scopeObjects` keyed to an entire [CAIP-104][] namespace SHOULD contain a non-empty `references` array to be actionable, making them functionally equivalent to a series of identical `scopeObjects`, each keyed to one of the members of `references` expressed as a [CAIP-2][] scope.
+An empty or absent `references` array SHOULD NOT be interpreted as a namespace-wide authorization (i.e. authorization for ANY network therein), but rather as a null authorization of 0 specified `references`s within that namespace.
 (See [CAIP-217][] for more details on the structure of the typed objects included in these `...Scopes` objects.)
 
 The distinction between `requiredScopes` and `optionalScopes` is ultimately semantic, since a wallet may still choose to establish a connection authorizing a subset of requested networks or requested capabilities from each; the primary function of the distinction is to offer callers a mechanism for signaling which scopes they consider primary and which they consider secondary to their request, in order to better inform the authorization logic of the respondent.
@@ -96,7 +96,7 @@ Example:
   "params": {
     "requiredScopes": {
       "eip155": {
-        "scopes": ["eip155:1", "eip155:137"],
+        "references": ["1", "137"],
         "methods": ["eth_sendTransaction", "eth_signTransaction", "eth_sign", "get_balance", "personal_sign"],
         "notifications": ["accountsChanged", "chainChanged"]
       },
@@ -187,7 +187,7 @@ An example of a successful response follows:
     "sessionId": "0xdeadbeef",
     "sessionScopes": {
       "eip155": {
-        "scopes": ["eip155:1", "eip155:137"],
+        "references": ["1", "137"],
         "methods": ["eth_sendTransaction", "eth_signTransaction", "get_balance", "eth_sign", "personal_sign"]
         "notifications": ["accountsChanged", "chainChanged"],
         "accounts": ["eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb", "eip155:137:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb"]
@@ -294,9 +294,6 @@ Regardless of caller trust level, the following error responses can reduce frict
 - When provider does not recognize one or more requested notification(s)
   - code = 5202
   - message = "Unknown notification(s) requested"
-- When a badly-formed request includes a `chainId` mismatched to scope
-  - code = 5203
-  - message = "Scope/chain mismatch"
 - When a badly-formed request defines one `chainId` two ways
   - code = 5204
   - message = "ChainId defined in two different scopes"