PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls

[adrianhopebailie]

Proposed by @msporny
Attempts to resolve #39

PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls because there may be work starting shortly in the Verifiable Claims work and the Credential Management API that would almost immediately deprecate the mechanism. The Web Payments Browser API may support it via a key/value pair in the payment request data or options object passed to the API if the Verifiable Claims / Credential Management API fails.

[ianbjacobs]

If we consider the WPWG's time frame, we had our first charter draft in June and launched the WG four months later. A conservative estimate of when an attributes WG might be launched is six months from now. Then it would require another 18 months minimum to get a Recommendation.

While I would like to see the attributes task force identify a problem where there is community consensus that W3C can add value through standards, I am concerned about a dependency of this work on that early work.

[msporny]

We do not have to create a dependency. We just need to not include gathering shipping address information. Full stop.

The downside here is that merchants will have to gather shipping address information in the way they do today (solved problem, albeit not in the best way possible). The upside is that we don't build something into the Web platform that will almost certainly be cruft if the Verifiable Claims work is a success.

[msporny]

Also note that this work of getting a credential is already being done in the Web Applications Security Working Group via the Recommendation-track Credential Management API.

Mike West from Google is working on it, and it's confusing to me why someone else from Google (other than it's a large company and there is no communication happening between these two spec editors) is proposing something specific and separate from that API that does effectively the same thing.

[zkoch]

Mike West from Google is working on it, and it's confusing to me why someone else from Google (other than it's a large company and there is no communication happening between these two spec editors) is proposing something specific and separate from that API that does effectively the same thing.

I have confirmed with Mike West that this is not currently what is being proposed. They have built what is, in effect, a "sign in" API.

[mikewest]

There is certainly "getting a credential" work being done in WebAppSec. It isn't clear to me that "shipping information" is such a credential. It's certainly not part of the proposal at https://w3c.github.io/webappsec-credential-management/.

[msporny]

Hey @mikewest,

We've had a very lengthy set of conversations with you in WebAppSec over the past year about "more than just login credentials" use cases:

w3c/webappsec-credential-management#8
w3c/webappsec-credential-management#7
w3c/webappsec-credential-management#4

As a result of those conversations, there were changes made to the CM API spec, namely the Extension Points portion of the spec:

https://w3c.github.io/webappsec-credential-management/#implementation-extension

It's documented in the CM API that these sorts of credentials are of interest and Credentials CG, Web Payments IG, and Verifiable Claims Task Force are exploring the space and expect to use the Credentials Management API to implement these features:

https://w3c.github.io/webappsec-credential-management/#future-work

We (Digital Bazaar) even went to the trouble to align the Credential CG API w/ the Credential Management API because we thought there was agreement that the CM API could do this in the future. I realize that you're not currently chartered to do more than just login credentials. That's not the point.

The point is that there exists an API at W3C that is Recommendation track that /could/ gather shipping address information, and the Credentials CG and VCTF work intends to extend that API to do just that. However, the requestPayment API proposal intends to create its own API to gather shipping address information instead of extending the CM API (which could be done).

The question is, why isn't the requestPayment API not just extending the CM API? Why is it effectively re-inventing a very specific subset of the CM API?

[msporny]

@zkoch wrote:

I have confirmed with Mike West that this is not currently what is being proposed. They have built what is, in effect, a "sign in" API.

There was a very active discussion a number of months ago where we asked that the CM API be renamed to something like "Login API" (because it wasn't doing generic 'Credentials'). There was push-back on that because there was an assertion that the CM API could be extended beyond just Login credentials (even though that's what they're currently chartered to do). The CM API has extension points to get other types of credentials that we have vetted over the past year to ensure that you could do things like getting shipping address credentials:

https://w3c.github.io/webappsec-credential-management/#implementation-extension

My point here is: there exists an API that we could do shipping address credentials through other than the paymentRequest API. So, why are we re-inventing the wheel in WPWG instead of re-using the CM API?

If @mikewest is asserting that the CM API is just for login credentials, then we should request that that API be renamed to something like the "Login Credential API" or the "Login Management API".

If @mikewest is asserting that the CM API does have extension points and it's up to other groups to use those as they see fit, then we should request that the paymentRequest API extend the CM API instead of re-inventing the wheel.

[mikewest]

Hi, @msporny. I do indeed remember our conversations. :)

The credential types actually defined in the WebAppSec document do, in fact, boil down to "sign-in" stuff. https://w3c.github.io/webappsec-credential-management/ defines those types in terms of a number of extension points that folks like yourself can use in a number of ways to implement a number of things. The FIDO submission, for instance, is starting to explore areas beyond the boundaries of the spec we're working on in WebAppSec, and I do expect to see more of those kinds of concrete proposals in the future.

My point here is simply that WebAppSec's work in this area is fairly narrowly scoped by our charter to "assist[ing] users in managing the complexities of secure passwords" (which might not be "the" point, but is certainly "a" point). If this group agrees that the best way to make shipping addresses available is via the navigator.credentials API, I'd suggest putting together a concrete proposal, and pitching it to developers and implementers. I'd certainly be interested in reading through it.

[dlongley]

For reference, here's some of the code that the Credentials CG has been working on that was refactored to extend the Credential Management API: https://github.com/digitalbazaar/credentials-polyfill

[bifurcation]

The FIDO submission, for instance, is starting to explore areas beyond the boundaries of the spec we're working on in WebAppSec, and I do expect to see more of those kinds of concrete proposals in the future.

Nonetheless, these proposals are still dealing with authentication, so they're still very distinct from what the CG has been talking about.

If this group agrees that the best way to make shipping addresses available is via the navigator.credentials API, I'd suggest putting together a concrete proposal, and pitching it to developers and implementers. I'd certainly be interested in reading through it.

As would I. But to be clear, I would very strongly oppose the addition of such work to the WebAppSec charter.

[dlongley]

@bifurcation,

Nonetheless, these proposals are still dealing with authentication, so they're still very distinct from what the CG has been talking about.

I agree that the CG is doing something different from the Web Authentication group. The CG work is about verifiable claims/attributes. This is a layer above the FIDO/Web Authentication work because it has to do with what is out of scope for that group (e.g. multi-origin credentials/federated identity/etc.), but that doesn't mean it has no relation to authentication, e.g. did entity A really make claim B about entity C?

The two groups are doing different things at different layers, but both see the Credential Management API as a potential fit (and the CG has built a demo that shows that fit).

As would I. But to be clear, I would very strongly oppose the addition of such work to the WebAppSec charter.

I think we should wait off and let the CG/VCTF do their work which will hopefully result in an appropriately chartered WG that would work on any extension that is relevant to that work.

[nickjshearer]

To be honest, I am very confused by the notion being put forward that a shipping address is a "credential" in the first place. In the Credential CG group's own glossary a credential is defined as:

A set of claims that refer to a qualification, achievement, personal quality, aspect of an identity such as a name, government ID, preferred payment processor, home address, or university degree typically used to indicate suitability.

A shipping address is none of these things. It may be a home address, but it equally may be an address a friend gave me and I have no proof that it is or isn't real.

Surely nobody would propose a latitude/longitude coordinate be a "credential"? So why is a shipping address any different? Like a pair of coordinates it represents a physical location. Calling it a credential seems like some serious overreaching.