- Front End: Wallets - Initiating Payment and Digital Receipts
- Creating a Level Playing Field - W3C
- Money for the Underbanked - Mahindra Comviva
- Mobile Wallets - Gemalto
- Privacy Issues Related to Payments - Lyra
- Wallets - Deutsche Telekom
- Mobile Wallets - GSMA
- General Discussion around Payment Initiation and Digital Receipts
- Daniel Appelquist
- Charles McCathie Nevile
- Daniel Appelquist, Charles McCathie Nevile, Prakash Hariramani, Dave Raggett, Manu Sporny, Bryan Sullivan, Cyril Vignet, Vidya Chandy, Philippe Cabos, Gregory Estrade, Jörg Heuer, Joseph Potvin, Natasha Rooney, Olivier Maas, Mountie Lee, Stéphane Boyera, Ori Eisen, Emil Johansson, Martin Hepp, Erik Anderson, Ricardo Varela, Dave Birch, Evgeny Vinogradov, Wendy Seltzer, and 81 others for a total of 103+ people
Charles McCathie Nevile is scribing.
Note: These are minutes for an official W3C Workshop event that have been cleaned up and reformatted by the Web Payments Community Group. The Web Payments Community Group and the W3C are two different organizations, and it is the W3C that managed this event. These minutes may be handed over to the W3C to become the official minutes for the event, but that has not happened yet (and may not happen at all). Readers should understand that there is a difference between officially sanctioned W3C work, and the work done by the Web Payments Community Group (which is not officially sanctioned by W3C's membership).
Topic: Front End: Wallets - Initiating Payment and Digital Receipts
Topic: Creating a Level Playing Field - W3C
USE CASE: The wallet as an expert system - decide the best mode of operation for the purchase, make wallet providers compete on that metric.
USE CASE: Identity solution must not rely on passwords for primary functionality.
Topic: Money for the Underbanked - Mahindra Comviva
[Slide 2, recaps yesterday points]
[Slide 4 - stats]
[Slide 5 - africa research]
Someone shouts from the audience: It's just a marketing slide! (laughter)
[Slide - Standardisation Considerations]
Chaals wonders why 2-factor is inherent in mobile money.
Topic: Mobile Wallets - Gemalto
Only a few people raise their hands.
USE CASE: Enable people to transfer tokens of value between their wallets (digital cash equivalent).
USE CASE: Realtime checks on account balances in wallets to help decide how to pay.
USE CASE: Show added/stored value from things you already do (discounts on gas purchases associated with a grocery store you shop at regularly).
USE CASE: Wallet is synced with loyalty coupons and digital receipts as they are collected. Data is synced to cloud or local wallet seamlessly.
USE CASE: Wallet data should be separate from wallet provider, data should be owned by the customer.
Topic: Privacy Issues Related to Payments - Lyra
Topic: Wallets - Deutsche Telekom
[Slide - development history]
USE CASE: Customer can receive digital receipts (receipt POSTed to user's digital receipt storage vs. an emailed receipt).
[Slide - wallet vision "so abstract it can't be wrong"]
[Slide - future wallet definition]
Topic: Mobile Wallets - GSMA
Topic: General Discussion around Payment Initiation and Digital Receipts
Sergio Aquero: "Wallet" presupposes an architecture
Sergio Aquero: it's one way of handling the payment request
Chaals, you wanted to mention that the merchant wants user data too.
Bryan, you wanted to ask why portability is a concern for use of mobile # as account key.
Manu wanted to raise the point that if we store wallet information on device, that we're inevitably going to need to sync it to the "cloud".
USE CASE: Sync wallet data, password data, and credential data to the cloud - use the same mechanism for all three.
USE CASE: Wallet portability to move to a new wallet service provider at will.
USE CASE: Where is the wallet, how is it protected, is it stored on the same device as your 2-factor authentication device? Security side-effects of mobile-as-wallet are not straightforward.
USE CASE: Prevent corporate man-in-the-middle attacks that are commonly used in corporate environments.
USE CASE: Reject the form auto-fill anti-pattern (RequestAutoComplete) and move to one that doesn't result in security risks if data is stolen at the merchant.
Chaals, you wanted to ask about shared devies
USE CASE: Payment systems running on shared devices must be able to determine the payer.
End of session 5.