- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 31 Mar 2014 22:14:16 -0400
- To: Web Payments <public-webpayments@w3.org>
The minutes for "Session 5: Front End: Wallets - Initiating Payment and
Digital Receipts" from the Web Payments Workshop are now available.
Thanks to Charles McCathie Nevile for scribing!
https://web-payments.org/minutes/2014-03-25-s5/
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).
----------------------------------------------------------------
Web Payments Workshop - Session 5 Minutes for 2014-03-25
Agenda:
http://www.w3.org/2013/10/payments/agenda.html
Topics:
1. Front End: Wallets - Initiating Payment and Digital Receipts
2. Creating a Level Playing Field - W3C
3. Money for the Underbanked - Mahindra Comviva
4. Mobile Wallets - Gemalto
5. Privacy Issues Related to Payments - Lyra
6. Wallets - Deutsche Telekom
7. Mobile Wallets - GSMA
8. General Discussion around Payment Initiation and Digital
Receipts
Chair:
Daniel Appelquist
Scribe:
Charles McCathie Nevile
Present:
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
Prakash Hariramani: Good news is things are growing in online
payment.
... bad news, the experience is a mess. Repeated repetition of
terrible steps to go through.
... m-commerce rates are < 1% - imagine what it could be
without such friction.
... we've got different stakeholders here and tried to cover
the world. 2.5 billion are underbanked...
... We're focusing on b2c payment.
... will consider this a success if we can narrow our focus on
what needs to be standardised.
Topic: Creating a Level Playing Field - W3C
Slides for Dave Ragget's talk:
http://www.w3.org/2013/10/payments/front-end.pdf
Dave Raggett: The goal here is to create a level playing field
for providers through standards.
... I want to be able to get a digital receipt from a
part-payment for a group meal like last night.
Dave Raggett: We have web app to browser transition, and then
browser to wallet conversation, and wallets talking to individual
providers, as possible points of standardisation.
... and we can have multiple wallets, like in the real world.
... standards should be minimal, enabling competition
... information needed (slide 5)
... amount, currency, jurisdiction, acceptable settlement
solutions, etc.
... in current UX we have to repeatedly add too much info.
Could be done by the wallet
... Maybe you need DRM for virtual goods?
... What about value-added services - what is compelling enough
to get people to switch. Loyalty coupons (seemed very US-centric
idea), where does escrow fit?
[Slide 6]
Dave Raggett: Wallet can keep receipts etc. Where does the
receipt get held?
Charles McCathie Nevile: That was my question about receipts
helping EME yesterday.
Manu Sporny: Oh, I had it the other way around, I thought you
were saying that EME would help digital receipts... not that
digital receipts could help EME. Totally agree w/ you wrt.
digital receipts helping EME not create such closed solutions.
Dave Raggett: It's about improving the experience. Less data
entry. This just depends on the risk model for provider/customer
- the merchant just wants the money
[Slide 7]
USE CASE: The wallet as an expert system - decide the best mode
of operation for the purchase, make wallet providers compete on
that metric.
Dave Raggett: Trusted customers can have expert wallets as user
agents. Shouldn't offer solutions that won't match the acceptable
mechanisms fora transaction.
... wallets need to provide information, options for payment
(use debit, or pay with coupons, ...)
... and of course transparency in eventual cost.
[Slide 8]
Dave Raggett: Standardisation needs to be unbiased, we need to
be held to that. Effective competition is critical for
improvement, so we need hooks in browsers for multiple wallets to
be used / dropped.
... these could be in the cloud, or not...
... And should be movable between my devices.
... What about offline payments? That's a complexity we should
bear in mind for the future.
[Slide 9]
Bryan Sullivan: Offline payments is a current capability, not
only something for the future
Dave Raggett: Sysapps is working on APIs for trusted
applications, allowing web apps to create device side part of
wallet is a possibility.
... need to move away from username/password as the base of
authentication.
USE CASE: Identity solution must not rely on passwords for
primary functionality.
Dave Raggett: What happens when I give someone else my device?
... privacy friendly "Know Your Customer"?
Bryan Sullivan: Identity of all parties is essential for trust -
Know Your Provider (KYP)
... related - NFC, and upcoming bluetooth work at W3C
[Slide 10]
Dave Raggett: Loyalty schemes as value-adding services for a
wallet. coupons, vouchers, etc - how does this fit. Maybe a
question for the future.
... Merchants want repeat customers, want to know how users
arrived.
Bryan Sullivan: I use a Safeway app that provides me discounts on
things that I typically buy, and alerts me when they're on sale,
and uses barcodes so that I can "like" products right in the
store - all key parts of the new retail experience.
Cyril Vignet: Careful of loyality coupons : the business model is
that the customer value them but don't uses them ;-)
Topic: Money for the Underbanked - Mahindra Comviva
Slides for Vidya's talk:
http://www.w3.org/2013/10/payments/slides/session5_comviva.pdf
Vidya Chandy: Money for the un/derbanked
... who is familiar with mobile money? [almost everyone raises
their hand]
[Slide 2, recaps yesterday points]
Vidya Chandy: 2.5B underbanked, big opportunity
... growing industry increasingly competitive. dominated by
telcos.
Bryan Sullivan: Just like the payment experience - make the
couponing experience transparent/effortless and usage will
increase and churn will decrease
... very lightly regulated, no interoperability.
[Slide 4 - stats]
Vidya Chandy: 1.2B users in 9 months. 2.5B un/derbanked people
online in 3 years
[Slide 5 - africa research]
Vidya Chandy: Huge growth in everything - 100's of % CAGR
... Kenya 5th fastest towards cashless society because of
M-Pesa
Bryan Sullivan: What's the Y axis?
Someone shouts from the audience: It's just a marketing slide!
(laughter)
Vidya Chandy: It's a calculated metric to show adoption
velocity.
Vidya Chandy: Shows M-pesa changes the way a country deals with
cash, which is a surprise
... Money systems don't interoperate, no public API. That will
change soon to have an ecosystem building around it. There is
already a mini-industry offering integration, bridging, etc.
... Strong growth trajectory, time to leverage the synergy with
standardisation.
... otherwise experience will be siloed.
... Where will mobile money fit in a layered appraoch?
[Slide - Standardisation Considerations]
Vidya Chandy: Different from cards, this is a stored value
system on a phone not card.
... mobile number is account nuber, but portability signals a
coming need to change that.
... low tech literacy means UX needs to be simple, smooth.
... 2-factor auth is inherent in mobile money.
Chaals wonders why 2-factor is inherent in mobile money.
Vidya Chandy: Category of goods that can be purchased could be
limited by account type.
... consumer demographics include multiple languages, multiple
currencies, low literacy, ...
...P2P transfer is big in mobile money, that's where the
traction has been.
... what is relevant for merchants is proximity not online
payment.
... Mobile payments are done on mobiles, not cards, and that's
what's different about it.
Topic: Mobile Wallets - Gemalto
Philippe Cabos: Who uses a mobile wallet daily?
Only a few people raise their hands.
Philippe Cabos: That's why I am here. Think this is really key
to help adoption of payment technology. Will focus mostly on UX.
... key aspect is that the wallets should be multi-scheme
multi-technology from the start.
... acccept MNO billing, alternates, ...
... Why is user expecting so much? There is a lack of control
for the end user on what payment to use, clear reward for doing
so, and feeling secure about the payment
... Giving my data to multiple websites doesn't feel secure, I
want a wallet to keep them in.
... I don't know the balances on my cards, want to see them (or
info about the differences in different cards at merchants) at
purchase time.
... I don't have a central point to store receipts.
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.
Philippe Cabos: Payment process can be very painful. To secure
it with 2-factor can bring problems e.g. trying to use CAPTCHA on
mobiles.
... login is painful across multiple sites. Wallet can help
here.
... Today there are lots of loyalty cards, but don't see a
reward. Wallet could show you that
USE CASE: Show added/stored value from things you already do
(discounts on gas purchases associated with a grocery store you
shop at regularly).
Philippe Cabos: Blockers to having this lovely wallet?
... need more implementations to be availble, more ways to
deploy wallets.
... ability to port wallet to various platforms is key.
USE CASE: Wallet is synced with loyalty coupons and digital
receipts as they are collected. Data is synced to cloud or local
wallet seamlessly.
Manu Sporny: How about this: You should be able to store your
digital receipts wherever you want - whether it be in a wallet
or in the cloud.
Philippe Cabos: W3C can help abstract and standardise these
interfaces to reduce the cost of deployment.
... Unfortunately, wallet issuers are too eager for user data,
so seems like a privacy threat.
... end user should be able to choose what info to share with
whom. Think this will be key.
... of course need to standardise interations with merchant
website - coupons, sharing shipping addresses, etc
... smartphone is a good way to allow users to select payments.
... Need to make sure wallets are widespread and available,
believe W3C is the right place to make sure there will be an open
garden type of wallet
Bryan Sullivan: I agree, a wallet issuer should not have access
to my data just because they provided the wallet
USE CASE: Wallet data should be separate from wallet provider,
data should be owned by the customer.
Topic: Privacy Issues Related to Payments - Lyra
Gregory Estrade: What do we need to standardise on front end for
wallets to integrate?
... What merchant wants isn't always what customer wants.
... Purchase: There is a cart. Some providers require the cart
contents to be passed to the payment provider.
... There are some advantages - if customer goes to another
website, will be pleased to see the cart is still the same.
... Provides valable information for fraud detection, digital
receipts.
... But drawbacks too - consistency has to be achieveed. And
raises privacy concerns - does the customer want all purchase
information detail given to the bank?
... Then billing and shipping info. Most annoying part of the
process.
... But while cart is temporary, these are related to identity
(which is its own can of worms)
... When it all goes well, everyone wants to skip this and let
the wallet do it.
... But if something goes wrong with the purchase, some privacy
concerns are raised. Merchant acquires information about a
non-customer, device fingerprinting them, etc.
... like in the physical world. Merchant wants the customerto
open the wallet, customer doesn't.
Charles McCathie Nevile: What the merchant really wants is for
the customer to start buying. and then buy some more.
Gregory Estrade: There isn't a process to figure out which
system is the best. Payment schemes have deals with merchants,
customers have different goals.
... for instance a merchant might have a reason (or more) to
try and sign you up to a new wallet
... At payment there are mostly security concerns. Merchants
shouldn't collect credit card details, but part of these are
meaningful.
... E.g. issuer may determine where the merchant wants to
process the transaction.
Prakash Hariramani: Merchants should just get a token, not real
credentials?
Gregory Estrade: Partially, but there are parts of the
information the merchant should get too.
... e.g. in PCIDSS you mask middle of the number. But on modern
POS terminals masking is first 12 digits. Merchant loses
important information on what kind of card it is.
... 3D secure, etc can be involved. This is a real pain point.
UX is bad, website is mobile-first and often -only, terrible on
desktop.
... SMS auth when you purchase from your phone is no good if
your phone gets stolen.
... But birthday security in a facebooked world is even worse.
... We could stepwise propose better integration for most
common auth schemes.
Charles McCathie Nevile: This sounds like password management in
browsers, which is years old.
Gregory Estrade: We could alternatively enrich the
authentication process with branding from the merchant website.
... Then there is receipts. There are many receipts.
Merchant-supplied, something from a payment provider. If customer
uses coupons and loyalty cards, the amount of money will be
dispatched around the world with tex and handling fees from
different places coming into play. Standardising this seems
difficult.
... Merchant receipts are a sales facilitator. Lots of the
receipt is used to offer coupons, advertising, etc.
Cyril Vignet: Standard for receipts should be "cumulative" i.e.
each actor could add its won information for the receipt during
the payment life cycle
... problem is payment-gateway receipts.
... They should be digitally signed, merchant receipts will be
useable for warranty.
Charles McCathie Nevile: Cyril, so who "owns" the receipt
content?
Cyril Vignet: Warranty or tax issues as well
Topic: Wallets - Deutsche Telekom
Slides from Jörg Heuer's talk:
http://www.w3.org/2013/10/payments/slides/session5_dt.pdf
Jörg Heuer: This touches everything - identity, privacy, and
mobile.
[Slide - development history]
Jörg Heuer: Not talking about a product, just what we think a
wallet might look like.
... started in NFC, infocard. Found that compelling in the
context of payments.
... so we created a wallet - same virtual card can be used on
payment terminal or web shop.
USE CASE: Customer can receive digital receipts (receipt POSTed
to user's digital receipt storage vs. an emailed receipt).
Jörg Heuer: Want a framework independent of implementation, so
the card is an abstraction, where people can make payments with
whatever instruments they have.
... so far only used in trials. Aspiration to cover tickets and
identity as well as payments seems feasible
... expect any account online becomes a virtual customer card.
[Slide - wallet vision "so abstract it can't be wrong"]
Jörg Heuer: Providing security and communication needed for
transaction. The actual transaction happens outside the actual
wallet, but there are times when it appears. it's mine on my
system that I can secure.
Joseph Potvin: Wallet architecture needs to be open to any type
of implementation technology
Jörg Heuer: This is an agreement between me and a payment
provider.
... maybe I can use NFC, hardware-secured ID management, OAuth,
... or not ...
... I just need to be told what level of security I am ignoring
at the moment.
... When I join airline program, I get a number on paper - this
is free to issue. If I get more miles, I may get a card with NFC
access to lounge, etc.
Jörg Heuer: The ecosystem needs to be arrange differently from
what people think.
[Slide - future wallet definition]
Jörg Heuer: This is user-centric (everyone says that...)
... we give the card to the user. Maybe that never holds any
more data.
... can make things more transparent to the end-user.
... wallet provider is important role.
... better if it isn't a payment provider too.
... Operator might be OK for that - or not. Service providers
need to be differentiated.
[Last slide]
Jörg Heuer: We already have lots of APIs. Our wallet is
implemented in HTML5. Could be cloud-based or belong on client
device.
... You could have several wallets doing partial
synchronisation
... we can have wallet responding to auth requests. It can be
done, but lack of standards makes it a mess.
... and then we want all the things people already said - start
transactions, etc.
Cyril Vignet: I suggest to include along with cards the 3 other
main payment mechanisms known: credit transfer, direct debit,
crypto currency
Natasha Rooney: Jorg covered a lot of the technical detail of
where we are going.
... a long time ago we were working on projects, eg with NFC.
That has started to change, providing trusted security modules
around SIMs and wallet has become important to us.
... we want a simple approach from customer viewpoint (with
business things wrapped around it)
... Idea is use a wallet to pay, and it has security.
... Spec is for operator-led wallets held on the device.
Sometimes may not need secure elements all the time.
Charles McCathie Nevile: I love the fact that people can steal
everything if they take it in $20s...
Topic: Mobile Wallets - GSMA
Natasha Rooney: CAPTCHA is painful, wallets will simplify life
by having your details on your device
... Lot of work going on around Identity. Generally there is a
lot of movement towards identity providers/managers. Who do
customers choose - my main one now is Google. I made that choice
(and people gasp) based on what I get...
... It's up to you - what country is your data held in, what do
you get, do you trust the company, ...
... not much uptake for identity by interpretive dance yet. But
we want to do it in the most secure way we can.
... The process of buying candy at your local grocery store
shouldn't involve 2-factor authentication.
... There is a heavy business aspect around wallets. Who holds
the data and what are they getting by doing it?
... and can we hold you money for a while too?
... We still have to deal with these issues. Which leads to
merchants. They are losing valuable data to wallets, paymetn
providers, etc. Merchants have to weigh up the cost benefit
... Don't believe it is our choice.
... There has been a lot of talk about choosing your payment
provider on your device. Something that wants to get paid giving
you a button to click and pay it, backed by whatever you have
chosen to use, this leads back to tokenisation.
... Final point - lose your phone is a real issue. We'd like
to see more activity in the cloud - but not sure which cloud.
Topic: General Discussion around Payment Initiation and Digital Receipts
Prakash Hariramani: Talked of consumers, merchants,
wallet/payment provider
... does everyone agree with Dave's characterisation of the
three points for standardisation?
Joseph Potvin: "Connect the dots" mobile lock/unlock is an real
application of finger-based interpretive dance... so perhaps
interpretive dance isn't so far off.
Olivier Maas: Reacting to wallet interface. Philippe showed few
people use them today, retail wallets more success than bank
wallets but that will lead to us having lots of them. Wonder if
we will talk about them in 5 years.
... surprised nobody has mentioned trend to personal data
stores, to me describe use cases which fit with the seamless UX
better than wallets which are repeated one-shot transaction
interfaces
... my point: don't restrict the interface to wallets.
... they are just a 'new' way to do payments today.
Sergio Aquero: "Wallet" presupposes an architecture
Sergio Aquero: it's one way of handling the payment request
Dave Raggett: Agree - wallet is a personal assistant, not a
container for payment cards. There will be assistants, e.g. help
manage expenses, tell you not to buy more ice cream. Think those
value-added services are key
Jörg Heuer: Should be cautious about putting too much into the
wallet. But one power of the notion of a mobile wallet is as an
authorisation agent.
... but it needs to be somehow cloud-capable, synchronised, ...
... what do we call it? I don't know.
Prakash Hariramani: Does anyone think P2P payment belongs in the
primitive set?
Chaals, you wanted to mention that the merchant wants user data
too.
Charles McCathie Nevile: Jorg, Yes.
Bryan, you wanted to ask why portability is a concern for use of
mobile # as account key.
Bryan Sullivan: You commented on portability as a problem for
using mobile number as account identifier.
Vidya Chandy: Mobile money uses the number as an account
identifier. When the number gets ported to another telephony
provider, the money account may stay with the original money
operator, which can become a problem.
Bryan Sullivan: Not sure if it does, but...
Bryan Sullivan: Re: the last question are use cases equivalent to
primitives ? "P2P", "B2C" are use cases, not primitives
Bryan Sullivan: A primitive is e.g. "make a payment request",
"get a receipt", etc
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".
Manu Sporny: Wallet is best word we have, but isn't really
ideal. So we will get misunderstanding from that. As we've just
experienced, everyone thinks that a wallet does something subtly
different, and this is going to be a problem moving forward. The
wallet skeumorphism is probably not appropriate in this context.
... Growing concern about where the contents of the wallet are
stored. People have more than one device, so they have to sync.
... Wallets are not the only things that get synched these
days, anyone that uses LastPass can attest to how great it is to
have all of your data synched across all of the devices and
browsers you use.
... maybe W3C should think about synching in general. We
probably want this stuff on the web not on the device
USE CASE: Sync wallet data, password data, and credential data to
the cloud - use the same mechanism for all three.
Mountie Lee: Mobile is now the megatrend but wasn't always, and
we're also talking about internet of things, wearable devices,
vehicles as clients.
... wallet is targeting for human interaction based on mobiles
and brings a risk of adding a layer of activity, with W3C trying
to take the role of banks and payment service providers. And this
is too complex.
... User and user agent is the centre, and standards need to
concentrate on the connections between the devices.
USE CASE: Wallet portability to move to a new wallet service
provider at will.
Stéphane Boyera: There are different views of the wallet. Could
be a very light element supporting payment. If we can gather
payment systems, that's great. If it's another layer that we
need, I think we will fail - getting everyone to delegate
everything to a wallet will be a challenge.
... how can a mobile provider be a wallet provider, when you
change operator all the time - from phone to wifi to roaming to
...
Jörg Heuer: I'm here to reduce complexity. Today all platforms
need different implmentations. standardise this through a layer
of abstraction - it's feasible and would help to have a good
identity abstraction layer. We don't have it yet.
... Who looks at certificate stores?
Bryan Sullivan: Stephane, the ISP/MNO can be the wallet provider
just like anyone else. ISPs/MNOs are not limited to serving users
over specific networks - they can be cloud-based service
providers just like anyone else. The IdM key that is used is also
not necessarily tied to specific networks.
... If we can brand strong authentication (Walmart security
anyone) you could sell it.
Stéphane Boyera: Is it a technical issue? I think that isn't the
problem, it is about getting agreement to delegate the work.
Ori Eisen: What is "strong authentication"?
Jörg Heuer: We're missing the motivation to accept the extra
complexity of security, while for big players it is cheaper to
just use risk-management. We're pushing toward monopolistic
tendencies because the large players don't need anything new.
... what we do today is nonsense for security, but it works for
the existing market. I hope the neutral position at W3C can
enable us to make something usable and attractive enough to get
adopted
Melvin Carvalho:
http://en.wikipedia.org/wiki/Strong_authentication
Ori Eisen: My point is that "strong authnetication" is a relative
term, compared to what are we trying to authenticate
Natasha Rooney: How can we make this implementable? Everyone
agrees that mobile number is a bad identifier.
... If you have a contract there are a lot of ways to be
identified. Liked the idea if you're paying to use the name of
the event not the person.
... GSMA standardising a wallet isn't about forcing everyone to
use it, it is making a business product for operators, so the
goals are different.
... If there is a hook in the wallet to say "now please pay"
and the standards are agnostic to the wallet chosen, that is
interesting.
Emil Johansson: I think that a definition of "strong
authnetication" is needed.
Bryan Sullivan: Not sure I agree that mobile number is a bad
identifier. It's just an ID like all others, and in fact one that
everyone understands and uses every day;
... comes back to the customer choosing what to do.
Martin Hepp: IMO, security in payment cannot be built into the
standards. instead, it will be a highly adaptive component that
permits or declines a transaction based on 100+ signals.
... this is achievable in the short term - which isn't always
the case with a complex set of stakeholders.
... It isn't the be-all answer.
Erik Anderson: Mobile wallets aren't that useful, which explains
some low usage. Concerned about device storing wallet, being the
2-factor auth vector and synching to the cloud. It becomes a
single point of massive failure.
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.
Cyril Vignet: When you go to a merchant, we almost know what
they are. If you go to a certificate chain it gives no
information. The policy is a nightmare.
... I don't know what is going on as a user. Is a problem of
trust to explain this better -what the certification means?
... signed by someone *I* trust, not a chain of trusted trusted
trusters?
... maybe this is part of an extension.
Manu Sporny: +1 To mhepp wrt. security must be modular.
Jörg Heuer: This transparency needs to be used with care. Users
need to put a name to the responsibility. If they trust a brand,
they don't question it.
Martin Hepp: The standards should support interoperability at the
data (and maybe process) level, but not standardize the
implementation and internal processes of components.
... they allow for trust to be distributed. It needs to be
transparent, but a lot of real trust comes from trusting on
particular brands. We can use that to help get acceptance, or
misunderstand it and build stuff that fails
Daniel Appelquist: I'm worried about the notion of standardising
a wallet. feels like the wrong level of abstraction.
... some twitter comment said startups should be the
innovators. Feels like an attempt to create an app, not
underlying technologies.
Bryan Sullivan: Dave, standardizing interface primitives and data
formats for browser interface with a wallet is not the same as
standardizing the wallet - so we are not standardizing the wallet
really - implementations are free to innovate / differentiate
... maybe better takeaway for W3C is to look at use cases in
the context of existing work - look at synch in the context of
storage work, ... what are the primitives for multiple wallets?
Dave Raggett: Idea is to create a space for innovation. Maybe we
don't need to standardise sync. What are the *minimal* set of
standards that meet the primary goals - innovation, merchants'
and users' needs met
Jörg Heuer: Wallet should be seen as a Concept helping us to
guide standardization in various fields ! (security, identity,
identity selectors, transaction framing)...
Ricardo Varela: There may be a bit of confusion about what is "a
wallet" in this context... because for example for
requestAutocomplete spec it already says you store cc and
credentials in either "the user agent or other element" (in
chrome's implementation in google wallet) so that already defines
that there IS a wallet
Gregory Estrade: We are focusing on ID and security, losing
sight of what functions and features a wallet can add to
payments.
Erik Anderson: Certificate chains are important. I know firewall
units and corporate policies at corporations that inject its own
certificate of authority into your browsers so they can
"man-in-the-middle" decrypt SSL traffic. Corporations do this so
they can read your email, prevent file sharing/uploads, but they
shouldn't be connected in between the user and what they are
purchasing.
USE CASE: Prevent corporate man-in-the-middle attacks that are
commonly used in corporate environments.
Prakash Hariramani: Need to define wallet, by use of a token....
Joseph Potvin: I thought that authentication through
interpretive dance is what a written signature involves. Or the
dot-connecting to unlock my phone.
... drawing a symbol on a tablet can provide an authentication
mechanism.
Martin Hepp: +1 To Ricardo
Bryan Sullivan: Ricardo, I personally dont like
requestAutocomplete - it's a crutch to help us deal with with a
last-gen interaction method (web forms) and is a continual source
of privacy concern for me (where is all that info backed up? is
it secure? what if someone gets one of my devices that is synced
with it?)
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.
Bryan Sullivan: Applying WCAG to this, there are people who are
visual, and people who have e.g. dyslexia and huge problems with
authentication.
Natasha Rooney: Identity and how we authenticate will be
something we choose- retina, password, use a signature?
Ricardo Varela: Whether we like the API or not what I mean is
that we need a vocabulary that defines "wallet" because different
people have different interpretations and I think user agents are
already aiming to behave like at least my interpretation of a
wallet, whether directly or via things like requestAutocomplete
... accessibiltiy comment is important. and this has impact on
the web of things. Was at a dev conf in London and people were
talking about accessibility, and there were people who still
couldn't see that the web might not always be entirely visual.
Chaals, you wanted to ask about shared devies
Charles McCathie Nevile: What do we do with the family tablet
that is shared by 4 members in a family? Who's account is used to
pay?
Prakash Hariramani: Don't want to bleed into identity session,
but I'd love to look at identity questions about how we look at
risk in authentication.
Charles McCathie Nevile: I think people share devices, we should
look at those as a use case. [scribe assist by Manu Sporny]
Bryan Sullivan: Phobeo, I agree we need discussions based upon
actual behaviors/features and functions, and less focus on terms
at the start - the terms will define themselves through the
discussion process
USE CASE: Payment systems running on shared devices must be able
to determine the payer.
Prakash Hariramani: Shared devices can lead to "friendly fraud".
For physical goods the main vector is account takeovers. You need
something other than username/password.
Jörg Heuer: Adding biometry or behavioural auth, these can be
solved.
... you can do air writing as a secure instrument. But tests
showed germans didn't like it.
Joseph Potvin: Principles of the WCAG standard should apply to
authentication methods (therefore offer various kinds of
authentication)
Dave Birch: We mustn't jumble biometrics for authentication
(good) with identification (bad)
... corrupt officials have been selling bogus national id cards
- these things are of limited reliability
Evgeny Vinogradov: Dave Ragget says there is a problem about
where we keep receipts. We need to differentiate notification
from real receipts for eg warranty. Using phone number as
identifier - in some countries you need to show ID to have a SIM,
and the number is linked to a real person, and then may be
useful. Gregory talks about UI problems for security systems -
this can be easily solved with a standard by building an API.
There is one edit field and one button, not too hard.
... How deep should the standard go into communication channels
- totally transport-agnostic, or more detail on
NFC/bluetooth/whatever?
Erik Anderson: In Indonesia the phone number is locked to a
particular SIM card. If the SIM card expires for over xxx time
period the SIM must be replaced and the user gets a new phone
number
Jörg Heuer: We framed this with total payment-agnostic. Could do
it with EMV, think it works with paypal online, shouldn't matter.
Ori Eisen: As someone with experience in India, I am shocked
that ID cards got sold wrongly! :) (laughter)
Ori Eisen: Where there is value there will be fraud. Take a case
where people are trying to pay 30p for sweets or 300k for a
house. standards for communicating what is being paid, who is
authenticating, the wallet that is being used? What are we trying
to standardise, many things could be affected.
Erik Anderson: +1 To "Where there is value, there will be fraud"
Prakash Hariramani: Didn't see Dave say standardise wallet, but
interface between wallet and browser, and between wallet and
payment provider.
Dave Raggett: Right.
Melvin Carvalho: +1 "Where ever there is value there will be
fraud" or "A certain percentage of fraud is accepted as
unavoidable" -- Satoshi Nakamoto
Martin Hepp: To make ground we should separate the work that
needs to be done as implementation, and the things that we should
standardize. If we standardize protocols, the decision to decide
if something is fraudulent will be probabilistic. So what should
we standardise? Means for interoperability of data. Conceptual
structures for stages of initiating, archiving, etc, steps that
can be document. Not IMHO processes that determine whether a
payment is fraudulent.
... standards are slow, bad guys are fast.
Prakash Hariramani: Focus on parts that are missing. Don't try
to build a giant end to end standard - no need and too much work
to get it done.
Daniel Appelquist: +1 On not trying to build end-to-end solution
Wendy Seltzer: An interesting question overall: how do we
standardize frameworks for risk-based decisions on security?
Martin Hepp: Chaals, I said that bugfixes to security issues in
standards will likely come much slower than apple's bugfix for
the #gotofail vulnerability ;-)
Martin Hepp: Thus, we should not standardize processes with a
binary outcome of "1 - transaction valid" vs. "0 - transaction
declined". The actual decision will be based on tens of signals
from the client (e.g. id, geo-location, history), transaction
(volume, type of goods), merchant, etc.
Martin Hepp: Instead, we should focus on standardizing data
interchange, so that components can exchange the respective
signals.
Melvin Carvalho: Mhepp: +1
End of session 5.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/
Received on Tuesday, 1 April 2014 02:14:54 UTC