- From: David Jackson <david.dj.jackson@oracle.com>
- Date: Tue, 2 Jun 2015 06:37:45 -0700 (PDT)
- To: Anders Rundgren <anders.rundgren.net@gmail.com>, Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Web Payments IG <public-webpayments-ig@w3.org>
I can see some issues with wording in 3.4 and endeavored to clarify with the updated text below. As for 7.2 -- I see the statement about the receipt delivered to the mobile app -- much like an airline ticket to their mobile app. We could very easily add a standardized line-item receipt via signed data / encrypted transaction is that would be helpful. It begs the question -- is the means of deliver for a receipt part of the processing purview of the IG? Glad to help work on that but don't know if we are going more granular on the topic. I see the issue Anders. In the fourth phase of the payment process, the transaction is completed by providing the payer with a receipt and/or the product that was purchased. Delivery of Product. The payer receives goods or services immediately, at a later date, automatically on a recurring basis, etc. depending on the terms of the purchase. A digital proof of payment may be required to access the product. Delivery of Receipt. Depending on the payment scheme(s) chosen, there are various ways and times that a receipt may be delivered (e.g., credit card receipt, digital proof of purchase, encrypted line-item receipt, etc.). These methods are good cases of the use of signed/encrypted receipt in a standardized format for the itemization. The receipt is delivered as proof of purchase which can be used for subsequent activities including returns. Refunds. At time exceptions may occur (e.g., defective product, application of store return policy, etc.). In this case, the payee initiates payment to the payer. The refund may be delivered using a different scheme from the original purchase including a refund to the payer's payment instrument, a refund using a different payment scheme, or store credit. In the case of a credit, the storage of that credit is performed by the payee and could be proven by the payer using the receipt. -- David Jackson | Senior Director Financial Services Mobile: +1.614.560.1237 | VOIP: +1.614.465.6654 Oracle Industry Solutions Group New York City | Columbus Oracle is committed to developing practices and products that help protect the environment -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] Sent: Tuesday, June 02, 2015 9:15 AM To: Adrian Hope-Bailie Cc: Web Payments IG Subject: Re: Encryption and Signatures in use-cases On 2015-06-02 15:00, Adrian Hope-Bailie wrote: > Hi Anders, Hi Adrian, > > Can you point out which use cases you believe need to be updated? Well, the use-cases are not very explicit in how things like authorization is achieved but there are a few concrete examples. 3.4 Delivery of Product/Receipt and Refunds ...encrypted line-item receipt 7.2 Tokenized Payments (ApplePay / Venmo / CyberSource) The mobile app creates an encrypted transaction Both of these examples are BTW somewhat strange, signed data looks like a more useful concept for transactions and receipts. Anders > > Adrian > > On 2 June 2015 at 08:32, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > I believe use-cases dealing with Encryption and Signatures should specify which entities > are anticipated to be signing/encrypting and verifying/decrypting respectively, since this > has major implications on the key management architecture and enrollment. > > Anders > >
Received on Tuesday, 2 June 2015 13:38:12 UTC