- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sun, 29 Nov 2015 18:04:26 +0100
- To: Web Payments IG <public-webpayments-ig@w3.org>
There is a quite popular payment scenario which is not yet considered for standardization which is when a merchant holds credit-card data (or similar) to directly pull money from their customers' accounts. Think Amazon, Apple, PayPal, etc. This (IMO) appears to be approximately the same kind of relation you have with electricity companies and mobile operators. This obviously works but doesn't scale terribly well due to security issues related to storing sensitive credentials in many places. Expired cards add complexities to the plot as well. If each such party rather had a passive "certificate" for each customer allowing them to withdraw money on the customer's behalf, theft of account data would be useless (customer login is still vulnerable to attacks but schemes like FIDO will make this much harder). How would such a certificate be architected? Maybe something along the lines of SCAI (https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI#Representation_of_a_SCAI_line) where an outer payment-provider signature wraps a merchant authorization request could be useful? To authorize a payment operation, the merchant would counter-sign an envelope containing the certificate + payment request. Although not exactly the above, the following link shows a three-level "Russian-doll"/SCAI message in JSON notation: http://xmlns.webpki.org/webpay/v1/webpay-card-payment-messages.html#p11 There's more to this but now it begins to reach TL;DR Anders
Received on Sunday, 29 November 2015 17:04:57 UTC