In sec and priv considerations:

 - Merged two related paragraphs.
 - New paragraph on possibility of configs to share less response data.

index.html

@@ -785,13 +785,22 @@ <h2>
         Due to differences in quality of implementation and the end user's
         ability to input data into unconstrained input fields, merchants are
         expected to revalidate all {{BasicCardResponse}} returned by APIs that
-        make use of this specification.
+        make use of this specification. In particular, merchants need to treat
+        the values of any <a>details</a> with the same scrutiny that they would
+        apply to a [[HTML]] <code>input</code> element, by, for example,
+        sanitizing all the members of a {{BasicCardResponse}} before rendering
+        them anywhere.
       </p>
       <p>
-        In particular, merchants need to treat the values of any <a>details</a>
-        with the same scrutiny that they would apply to a [[HTML]]
-        <code>input</code> element, by, for example, sanitizing all the members
-        of a {{BasicCardResponse}} before rendering them anywhere.
+        Payees make multiple uses of the data provided through this
+        specification, including payment authorization and risk assessment.
+        Some users may prefer to share less data than is returned by default
+        through the <a>steps to respond to a payment request</a>. User agents
+        may offer configurations where less data is returned in the response
+        (e.g., by redacting the <code>phone</code> of
+        <code>billingAddress</code>). Such configurations may have an impact on
+        authorization or other aspects of user experience (e.g., subsequent
+        requests for strong authentication).
       </p>
       <p>
         Depending on jurisdiction, users of this specification (implementers,