What is the mechanism that the user consents to having an address that is known by the payment handler to the site where they're paying? (I'm a little concerned here because there are some types of payments for which no address is required and the user might not expect an address to be revealed.) Is the consent UI specific to each payment handler (which would be a little worrying from my perspective), or is there browser UI involved in that consent, or is it up to the browser which way to go?

Do you think it's worth worrying about consent in the other direction -- the possibility that some payment handlers don't really need the address, but this would push them to ask for or require it? I think this is probably less concerning than the first point.

A few other notes/questions (though I'm more concerned about my previous comment than this one):

I'm a little curious about how the proposed PaymentDelegation enum differs from the PaymentOptions dictionary; the former has shippingAddress whereas the latter has billingAddress and shipping (with request at the front). How do these correspond? (And PaymentHandlerResponse is in turn slightly different, with the added shippingOption.)

This bit of the explainer:

Payment handlers which support shipping delegation should be able to fire shipping[address|option]change events to let the merchant know that the user has selected a different shipping address/option. The browser will then get the updated request details from merchant and forward it to the payment handler after redacting displayItems.

seems a little confusing to me. I would have expected the second sentence to describe how the browser moves the information from the payment handler to the merchant, not from the merchant to the payment handler. If this is the correct direction, it might help to clarify exactly what's going on here.

The proposed supported_delegations member in Web App Manifest seems like it should probably have a name that makes it clear it's related to payments, since manifests are more general than just payments. (Also, I think PayerName there should probably be lowercased as payerName to match the enum PaymentDelegation above.)

What is the mechanism that the user consents to having an address that is known by the payment handler to the site where they're paying? (I'm a little concerned here because there are some types of payments for which no address is required and the user might not expect an address to be revealed.) Is the consent UI specific to each payment handler (which would be a little worrying from my perspective), or is there browser UI involved in that consent, or is it up to the browser which way to go?

What is in browser's control is to a)Exclude payment handlers that cannot provide merchant requested information from list of available payment instruments b)Tell the user selected payment handler whether or not merchant's website has asked for the shipping address and/or payer's contact information c)Share payment handler provided shipping address and/or payer's contact information with merchant's website only if the merchant has asked for it (i.e. even if the payment handler decides to overshare the browser should block it). It's up to payment handlers to a) Share shipping address and/or payer's contact information with the browser only when the browser has asked for it (on behalf of merchant's website) b) Get users consent about the data that they are sharing with merchant's website. Please note that this is not any different from the case where merchant's websites use ExamplePay's custom JS library to enable checkout with ExamplePay

Do you think it's worth worrying about consent in the other direction -- the possibility that some payment handlers don't really need the address, but this would push them to ask for or require it? I think this is probably less concerning than the first point.

Whether or not shipping address is required, is specified in the payment request created by merchant's website and has nothing to do with payment handlers. The browser tells the payment handlers whether or not shipping address is requested by the merchant, so the payment handlers won't have any incentives to overshare the address when the merchant's website has not asked for it. If your concern is about more payment handlers providing shipping address so that they can process transactions which require it; The payment/wallet apps are doing this today via their own custom JS libraries, in fact supporting this feature in payment handlers API is something that they have asked for to be able to adopt the API.

A few other notes/questions (though I'm more concerned about my previous comment than this one):

I'm a little curious about how the proposed PaymentDelegation enum differs from the PaymentOptions dictionary; the former has shippingAddress whereas the latter has billingAddress and shipping (with request at the front). How do these correspond? (And PaymentHandlerResponse is in turn slightly different, with the added shippingOption.)

PaymentOptions dictionary is used by merchants to request the additional information they need for the checkout; That's why the dictionary members are all booleans and start with "request". The proposed PaymentDelegation enum specifies the set of possible delegations. Payment handlers can support any subset of it via calling enableDelegations during their installation (please check the payment handler registration example for more details). We are not reusing PaymentOptions because "request" does not make sense during payment handler installation when no payment request has created yet. "billingAddress" is not a member of PaymentDelegation enum yet, but it can be added in the future if there is demand for it. PaymentHandlerResponse is the dictionary that payment handlers use for sending their response to the browser; That's why its members are optional strings as well as shippingAddress (with type AddressInit) (e.g. response.payerName received from ExamplePay will be "John Smith" if request.paymentOptions.requestPayerName is true and ExamplePay has called paymentManager.enableDelegations(['payerName']) during installation .

This bit of the explainer:

Payment handlers which support shipping delegation should be able to fire shipping[address|option]change events to let the merchant know that the user has selected a different shipping address/option. The browser will then get the updated request details from merchant and forward it to the payment handler after redacting displayItems.

seems a little confusing to me. I would have expected the second sentence to describe how the browser moves the information from the payment handler to the merchant, not from the merchant to the payment handler. If this is the correct direction, it might help to clarify exactly what's going on here.

Without this change when the user selected a different shipping address on browser's payment sheet, the browser would notify the merchant's website by sending shippingaddresschange , and the merchant could in turn notify the browser about updated payment details by calling updateWith . This is for handling the cases like when shipping cost depends on the shipping address, or express shipping option is not available for the country of the shipping address, etc. Now with this change since the payment handler is responsible for providing shipping address, it should be able to notify the browser about changes in user selected shipping address/option. changeShippingAddress() and changeShippingOption() methods added to the PaymentRequestEvent make this possible. The proposed changes to PaymentRequestDetailsUpdate let the browser forward the updated payment details from the merchant to the payment handler. I updated the shipping-addressoption-change-events of the explainer to explicitly mention changeShipping[Address\Option]() methods in the text rather than just inside the code block of changes to PaymentRequestEvent.

The proposed supported_delegations member in Web App Manifest seems like it should probably have a name that makes it clear it's related to payments, since manifests are more general than just payments. (Also, I think PayerName there should probably be lowercased as payerName to match the enum PaymentDelegation above.)

I updated the JIT installation section of the explainer with your recommendations.

Payment handlers can support any subset of it via calling enableDelegations during their installation (please check the payment handler registration example for more details).

What happens if the payment handler after an update would like to enable further delegations?

Payment handlers can support any subset of it via calling enableDelegations during their installation (please check the payment handler registration example for more details).

What happens if the payment handler after an update would like to enable further delegations?

If the payment handler is already registered, getRegistration('app.js') would work:

function updateSupportedDelegations() {
  navigator.serviceWorker.getRegistration('payment_handler.js').then(registration => {
    if (!registration.paymentManager) {
      console.log(
          'No payment handler capability in this browser. Is chrome://flags/#service-worker-payment-apps enabled?');
      return;
    }
    registration.paymentManager
        .enableDelegations(['shippingAddress', 'PayerName'])
        .then(() => {
          console.log('Enabled delegations');
        })
  })
}

It's up to payment handlers to ... b) Get users consent about the data that they are sharing with merchant's website.

It seems like some browsers might want a step where the browser ensures that the user has consented to this, because they might not trust the payment handlers to adequately get user consent here. (Whether to do this might also be a function of what we observe in the ecosystem of payment handlers as it develops.) Given the shape of the API, would it be possible for a browser to do this if it wanted?

It's up to payment handlers to ... b) Get users consent about the data that they are sharing with merchant's website.

It seems like some browsers might want a step where the browser ensures that the user has consented to this, because they might not trust the payment handlers to adequately get user consent here. (Whether to do this might also be a function of what we observe in the ecosystem of payment handlers as it develops.) Given the shape of the API, would it be possible for a browser to do this if it wanted?

Yes, browsers can explain the data which would get shared with merchant's site and get user's consent in their native UI where the user selects a payment app to proceed with.

Sorry for the delay in finishing going through the replies here:

In reply to https://github.com/w3ctag/design-reviews/issues/425#issuecomment-559330717 I'm a little bit skeptical about the lack of incentives to overshare data given the markets for user data that exist today. That said, given the replies up through https://github.com/w3ctag/design-reviews/issues/425#issuecomment-572269163 I think I'm no longer as concerned about this point.

In reply to https://github.com/w3ctag/design-reviews/issues/425#issuecomment-559352691 I'm aware that one of them has all of the values prefixed with request, but I was concerned that billingAddress and shipping in one of them didn't match shippingAddress in the other, and was wondering why the items in them didn't align more closely.

That (my going through your replies) was the remaining thing keeping this issue open, so I'm going to close this issue now as the TAG discussed earlier.

Thanks for submitting this review request to the TAG and for being responsive to our feedback (definitely more responsive than we were to your replies -- sorry about that!).