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

> 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:30:12 UTC