Web Payments Workshop - Session 5

Minutes for 2014-03-25

  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
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.

This page contains minutes for an official W3C workshop event that have been cleaned up and reformatted by the Web Payments Community Group. The W3C and the Web Payments Community Group are two separate organizations. Readers should understand that while the workshop was an official W3C event, the operation of the Web Payments Community Group is not officially sanctioned by W3C's membership. More information on joining W3C (membership fees) and/or the Web Payments Community Group (free) can be found on the respective websites.

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

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

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

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
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.