From a6fb781558b59e21d29ac22d07e05bcc28616696 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Tue, 16 Jul 2024 20:28:23 +0200 Subject: [PATCH] clarity edit from adonesky1 Co-authored-by: Alex Donesky --- CAIPs/caip-25.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CAIPs/caip-25.md b/CAIPs/caip-25.md index eab0be35..b41e7d01 100644 --- a/CAIPs/caip-25.md +++ b/CAIPs/caip-25.md @@ -41,7 +41,7 @@ Each `scopeObject` in these arrays can be keyed to a specific [CAIP-2][] network 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. (See [CAIP-217][] for more details on the structure of the typed objects included in these arrays.) -The distinction between `requiredScopes` and `optionalScopes` is ultimately semantic, since a wallet can still choose to establish a connection authorizing a subset of requested networks or requested capabilities on each; the primary function of the distinction is to offer callers a signaling mechanism for primary and secondary requests, to better inform the logic of the respondent. +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. If a connection is being rejected, whether on the basis of end-user input or on the basis of evaluating `requiredScopes` against available capabilities, the respondent SHOULD choose its response based on trust: e.g., one or more specific failure states MAY be sent (see [#### failure states](#failure-states) below) for trusted counterparties, but an `undefined` response (or no response, depending on implementation) MAY also be sent to prevent incentivizing unwanted requests and to minimize the surface for fingerprinting of public web traffic (See Privacy Considerations below).