W3C home > Mailing lists > Public > public-payments-wg@w3.org > January 2016

Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)

From: Manu Sporny <notifications@github.com>
Date: Tue, 26 Jan 2016 21:28:52 -0800
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>
Message-ID: <w3c/webpayments/issues/63/175407854@github.com>
> 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.

Self-issued credentials may or may not be able to be verified. We're splitting hairs at this point, but the Credentials CG has a pretty solid model about how we think about these sorts of things, and it goes something like this:

 * Entities have properties associated with them (no surprise here).
 * Entities can make statements (aka claims/attestations) about properties related to themselves or other entities - we call this data structure a credential.
 * A credential may or may not be able to be verified (it may or may not have a digital signature).
 * Low-stakes credentials are typically unsigned ("I took a rock climbing class last week").
 * High-stakes credentials are typically signed ("I'm a board certified doctor in Florida").

A shipping address can be low-stakes (ship this box of gum to this address), or it can be high-stakes (ship this box of *guns* to this address). Clearly the latter use case could benefit from a verifiable address credential (along with a whole slew of other verifiable credentials).

> This whole 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.

The proposal is built around the assumption that there are other groups working on this problem in a generalized way and the PaymentRequest approach for gathering a shipping address seems to 1) overlap heavily with that work, and/or 2) be a highly specific solution to a more general problem (collection of payment related information - what about billing address, what about loyalty card, what about coupons and discount codes - why aren't we special casing those things as well?).

What do we lose from not putting this "shipping address collection" feature in Phase I (other than some downside from a usability perspective)?

Reply to this email directly or view it on GitHub:
Received on Wednesday, 27 January 2016 05:29:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:13 UTC