Changes stemming from privacy review: (#856)

- Corrected bug by removing MUST language from the informative introduction.
- Corrected bug by aligning the definition of requestBillingAddress (under 9. PaymentOptions dictionary) to look like the other definitions (and include "SHOULD").
- Enhanced 19.6 Exposing user information by explaining more both the reason
  for PaymentMethodChangeEvent and the privacy implications. Enhanced the
  explanation by allowing for other ways to minimize data sharing, including
  an emerging idea for providing an "exclude" array (or similar) as payee
  request data that could be used by the payment method definition to
  limit which response elements are returned.

Author: ianbjacobs

index.html

@@ -228,14 +228,6 @@ 
             that results in a <a>dictionarya> or <a data-cite=
             "WEBIDL#idl-object">objecta> or null.
           p>
-          <p>
-            A <a>payment handlera> that defines <a>steps for when a user
-            changes payment methoda> MUST redact the <a>address linea>,
-            <a>organizationa>, <a>phone numbera>, and <a>recipienta> from
-            any <a>PaymentAddressa> included in the
-            <a>PaymentMethodChangeEventa>'s <a data-link-for=
-            "PaymentMethodChangeEvent">methodDetailsa> attribute.
-          p>
         dd>
       dl>
       <p>
@@ -2147,14 +2139,15 @@ 
           <dfn>requestBillingAddressdfn> member
         dt>
         <dd data-link-for="PaymentMethodChangeEvent">
-          A boolean that instructs the <a>user agenta> to get the billing
-          address associated with a <a>payment methoda> (e.g., the billing
-          address associated with a credit card). Typically, the user agent
-          will return the billing address as part of the
-          <a>PaymentMethodChangeEventa>'s <a>methodDetailsa>, albeit
-          possibly with parts of the address redacted for privacy reasons. A
+          A boolean that indicates whether the <a>user agenta> SHOULD collect
+          and return the billing address associated with a <a>payment
+          methoda> (e.g., the billing address associated with a credit card).
+          Typically, the user agent will return the billing address as part of
+          the <a>PaymentMethodChangeEventa>'s <a>methodDetailsa>. A
           merchant can use this information to, for example, calculate tax in
-          certain jurisdictions.
+          certain jurisdictions and update the displayed total. See below for
+          privacy considerations regarding <a href="#user-info">exposing user
+          informationa>.
         dd>
         <dt>
           <dfn>requestPayerNamedfn> member
@@ -5273,21 +5266,13 @@ 
         p>
       section>
       <section>
-        <h2>
+        <h2 id="user-info">
           Exposing user information
         h2>
         <p>
           The <a>user agenta> MUST NOT share information about the user with
           a developer (e.g., the shipping address) without user consent.
         p>
-        <p>
-          One way that the API supports limited information sharing is through
-          the "<var>redactListvar>" associated with the creation of
-          <a>physical addressesa> throughout the API. This feature enables
-          user agents to provide the payee with enough information to compute
-          shipping costs or tax information, while limiting the payee's ability
-          to identify the payer via the address.
-        p>
         <p>
           The <a>user agenta> MUST NOT share the values of the <a data-lt=
           "PaymentDetailsBase.displayItems">displayItemsa> member or
@@ -5296,6 +5281,38 @@ 
           member with a third-party <a>payment handlera> without user
           consent.
         p>
+        <p>
+          The <a>PaymentMethodChangeEventa> enables the payee to update the
+          displayed total based on information specific to a selected
+          <a>payment methoda>. For example, the billing address associated
+          with a selected <a>payment methoda> might affect the tax
+          computation (e.g., VAT), and it is desirable that the user interface
+          accurately display the total before the payer completes the
+          transaction. At the same time, it is desirable to share as little
+          information as possible prior to completion of the payment.
+          Therefore, when a <a>payment methoda> defines the <a>steps for when
+          a user changes payment methoda>, it is important to minimize the
+          data shared via the <a>PaymentMethodChangeEventa>'s
+          <a data-link-for="PaymentMethodChangeEvent">methodDetailsa>
+          attribute. Requirements and approaches for minimizing shared data are
+          likely to vary by <a>payment methoda> and might include:
+        p>
+        <ul>
+          <li>Use of a "<var>redactListvar>" for <a>physical addressesa>.
+          The current specification makes use of a "<var>redactListvar>" to
+          redact the <a>address linea>, <a>organizationa>, <a>phone
+          numbera>, and <a>recipienta> from a <a data-link-for=
+          "PaymentRequest">shippingAddressa>.
+          li>
+          <li>Support for instructions from the payee identifying specific
+          elements to exclude or include from the <a>payment methoda>
+          response data (returned through
+          <a>PaymentResponsea>.<var>detailsvar>). The payee might provide
+          these instructions via <a>PaymentMethodDataa>.<var>datavar>,
+          enabling a <a>payment methoda> definition to evolve without
+          requiring changes to the current API.
+          li>
+        ul>
         <p>
           Where sharing of privacy-sensitive information might not be obvious
           to users (e.g., when <a data-lt=