Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)

>  I don't think we would extend the current way we handle shipping.

This is concerning to me. Building features into the Web Platform that we know are short-term point solutions (like a special API for collecting shipping address) creates technical debt in the Web Platform.

If we want a more standard way of handling assertions like shipping address, which I assert is not special wrt. other types of credentials collected during the payment flow, then we should understand what the mechanism looks like before we standardize on an ersatz version of it.

> I'm not sure what that would look like right now, as I don't have a good mental model for how to think about those. 

Others, namely many of the participants in the VCTF, have been looking at this problem for a while now do have a more developed mental model of how this stuff should work. We haven't been able to discuss it in the WPWG yet because the discussion keeps being corralled into the VCTF work, but there are a set of proposals that have been discussed/worked on for multiple years now (Credential Management API from Google being one of them) as well as working code that demonstrates an alternative.

... but going back to Adrian's request:

"I'd like to establish if this is a firm requirement for the API before we define the way it is done."

I'd assert that gathering the shipping address isn't a firm requirement for the web payments browser API in Phase I for at least the following reasons:

1. We have a disagreement on the best way to do it, and at least two other groups working on this problem (WebAppSec and VCTF).
2. For shipping address, we have requestAutocomplete already, why aren't we depending on that?
3. At the very worst, we can always add it in Phase II.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/39#issuecomment-165336579