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

[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/.

[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.

[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.

[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.

[nickjshearer]

It fits the dictionary definition of a credential, so I don't quite see why you think it's overreaching.

Because that definition of 'credential' is so vague as to encompass everything. If you say a credential is a "set of claims about an entity" then it follows that any property of an object is inherently a credential. For example, take a Java interface. An object can claim to implement an interface, which would by your definition make the interface a credential of the object. It's credentials all the way down.

This proposal seems to be built around the assumption that a shipping address is always a credential, but I don't think that assumption has been proven. Because of that, the proposal seems premature.

[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.

[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.

[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

[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.

[msporny]

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.

The United States Post Office, UPS, and FedEx are interested in issuing digitally signed shipping address credentials to people and organizations. Doing so, and enabling people to use those instead of something they type into an online form would reduce tens of millions of dollars in wasted effort re-routing misrouted packages.

Note that the definition of "credential" in the Credential CG's glossary uses 'such as' before the examples. A credential can be any set of claims about an entity. Saying that "Person X can receive packages at Address Y" makes Address Y a credential of Person X (at least, that's how the Credential CG has decided to model things - and it works pretty well across a variety of market verticals).

Surely nobody would propose a latitude/longitude coordinate be a "credential"?

They would. For example, a lat/long credential issued to a person via a mobile phone provider with a timeout of 3 hours would enable that person to consume region-locked content on a particular website without tight coupling between the mobile phone provider network and the content provider.

Calling it a credential seems like some serious overreaching.

It fits the dictionary definition of a credential, so I don't quite see why you think it's overreaching.

Do you mean that calling a shipping address credential a credential as it is defined in the Credential Management API is overreaching? If so, I agree, but that's only because the Credential Management API has a very narrow definition of credential at the moment (what they really mean are 'a small subset of credentials that can only be used to login'). That said, we've had the discussion w/ @mikewest about extensibility in the CM API and the answer we got back wasn't "the CM API isn't extensible enough to support the types of credentials that the Credential CG is working on".

[webpayments]

On Jan 26, 2016, at 4:36 , Manu Sporny [email protected] wrote:

A credential can be any set of claims about an entity.

Surely a set of claims about an entity are simply properties? A credential would be a claim or property that both needs to be, and can be, verified.

Dave Singer

[email protected]

[adrianhopebailie]

• This proposal was tabled on the WG call on 21 January but was not resolved.
• @adrianhopebailie has an action to summarize the arguments for and against the proposal on the group wiki.
• The discussion from this thread has been transcribed back to the original thread at #39 where it can continue to be debated by the group.
• Any member of the group that feels a modified version of this proposal, or a counter-proposal, will be accepted by the group should tabled this new proposal for the agenda of an upcoming meeting.

UNRESOLVED