W3C Payments Workshop, day 2

Session 4 — Enhancing the Customer and Merchant Experience

Dave_Birch: kickoff on consumer and merchant experience with focus on the frontend
... people have asked why look at this? things work OK
... but they dont really work for consumers and merchants, basically
... how many paid for the dinner last night with cash (a few respond)
... the paypal payment method did not work, got locked out after three tries due to some suspicion
... puzzling as my paypal app knows who and where I am.
... the app could figure this out, and just do it since its only 30 euros. we would be moving to the right experience
... I use Hailo in london (taxi service). the app shows you the license # and picture of the driver. you tell them where you're going, you get there, and walk off. payment is automatic. there is no payment experience.
... no one looks forward to payment, they look forward to buying stuff. payment needs to be transparent, out of the loop
... all sorts of clever stuff will enable this experience. where is dave, is this activity normal, don't bother him.
... we should make the experience vanish, set the bar high.
... its not good to make it easy for me to type in a card . that's a hack.
... cards as the central metaphor for payment is anachronistic. we dont want to make cards work better on the web. its 1949 tech, and too dangerous now.
... knowing that use of cards is risky, and that eventually you will be attacked, please imagine further forward.
... starting with a merchant perspective now
... Gray Taylor (NACS - @grayotaylor)

Gray_Taylor: represent PCATS & NACS, attached to convenience stores in the US, involved in system data exchange
... payments is 30% of our effort. mobile commerce will increase that, so we are focused on this work today
... where are we? the system is broken. in the 70s there was no need for data visibility, data was static, magstripe based
... a lot of people are being hacked. 1.6B cards, 1.5B have been reissued.
... this is about a 10$B problem in the US, just the cost of fraud to banks

<m4nu> Gray: Fraud cost is 6 basis points... that's just due to fraud.

Gray_Taylor: another problem is segmentation of the customer to the merchant. knowing your customer is important.
... e.g. walmart needs to know who is buying what, and they don't want to get that data from mastercard
... due to data security, we are moving to EMV
... we are last getting on this tech, and it's not a good feeling.
... what can we do? we wish that mobile was ready, because we feel like a real late comer to an old tech
... major oil companies have no plans to implement EMV, due to poor ROI
... incrementalism in the card business creates heartburn. todays system is based upon the account, more important than the person.
... the system is moving toward the person, who can select the card. card companies don't like that, banks are ambivalent
... W3C's job is to boil this ocean. this is a critical subset of global commerce, and shouldn't be a walled garden for the web
... tech has the ability to overturn monopolies
... US Payments SOI 2016 slide

<korz> @bryan i like the focus on the person, not card. good step

Gray_Taylor: debit is the single largest thing going forward, driven by the banking crisis in 2008
... people are living in their means more now
... 2006-7 we hit equilibrium with paper on the way out
... cstore profile vs card fees graph shows fees pulling away from pretax profit

<erik_anderson> Was that a use case? 2 fat guys arguing over a ham sandwich?

Gray_Taylor: the fees are passed onto consumers, 1$B of subsidization
... the only higher cost is labor

<m4nu> Gray: If you pay cash, you pay over $400 a year to subsidize the card industry.

Gray_Taylor: re cost/liter, 2/3 of margin is gross profit
... much is cost of unauthenticated card use
... focusing on business and consumer in the payments ecosystem
... (totally lost on this slide - not sure what's being said...!)
... customers get steered to where discounts are offered
... re method of payment, they are changing, polluting the card handling environment
... we have to enable these methods but not have them affect the card vendor environment

scribe: we are turning a battleship here. PCI has helped re a finite set of things to look at

(anyone know what PCI is?)

<mountie> Payment Card Industry

<mountie> DSS Data Security Standard

<schuki> bryan: standards council, security I think

scribe: it's a huge science project to become compliant. our #1 threat vector (dispenser skimming) was excluded from PCI

<wseltzer> PCI

scribe: defending PCI, it provided a clearinghouse to mitigate risk
... when it comes to trust, banks are #1, the crisis dipped that, but they are still #1 going forward
... payments in flux - the perfect storm
... for profit without competition is bad

scribe: bank brick and mortar infratstructure is a cost holding them back
... it will be difficult to get the profit margin from the banks

<phobeo> bryan: for ref pci dss docs are at https://www.pcisecuritystandards.org/security_standards/

scribe: a consumer focus will be required, mobile and online banking will be changed by focus on the consumer

<m4nu> Gray: We need to re-think how we do digital identities and security.

scribe: mobilization will rise, mobile wallets are will become the mobile briefcase. digital identities and megabit encrypted PINs are where we need to get to

Dave_Birch: digital ID problem is underlying many of these problems

Gray_Taylor: with trust credentials, we can take ACH from Zimbabwe and be reasonably assured for it

<m4nu> Gray: With the appropriate trust credentials floating around, I could bank w/ different people and decrease fraud.

<AxelNennker> ACH=?

Gray_Taylor: re tokenization, there are about 6 standsards

<AxelNennker> thanks m4nu

Gray_Taylor: we need to kill standards as readily as we create standards - look at what's out there to leverage it, that will ease globalization
... Digital Identity
... counterfit IDs are easily obtained. transaction auth is similar to the boarding process
... all of the financial system is depending upon authentication of the individual

<m4nu> Gray: Digital identity will preserve our freedom online, not take it away.

Gray_Taylor: this is something that will preserve freedom

<m4nu> Gray: There is still no way to digitally sign any contract, how dumb is that?

Gray_Taylor: guiding access, medical records, etc...

<erik_anderson> +1 passport is one of the weakest areas in need of security enhancements and digital ID's

<m4nu> Gray: I believe in standards - that's the way forward.

Gray_Taylor: i believe in standards, you need to come up with building blocks. any safe system has not reached volume yet
... we need plausible deniability of risk
... what are the best practices systems should be following? consumers are just kicking the tires, and hacks can take wind out of the sales
... uniform datasets; at the end of the day, moving money is not rocket science; datasets need to be flexible and amended per the payment type
... re digital receipt standards, look to fiscal receipt standards

<m4nu> Gray: Important to bring more data into the digital receipts, look to people that need fiscal reporting in their receipts.

Gray_Taylor: "out of the box" use cases; data security is about minimizing value and maximizibng effort; hacking ROI needs to be low
... we need to look to how we can keep credentials in a small ecosystem and use tokens outside it

<m4nu> Gray: We should keep credentials in a small ecosystem, use tokens/intermediaries.

Robin_Berjon: I work for W3C, editing HTML
... acronym blizzard ... things are sinking in; from the perspective of the web platform, these thoughts are about how we can work together for payments on the web
... it would be easy to standardize what is done today; APIs would be easy. but they would not be innovation conducive
... a better approach is an "intents" based approach; like HTTP, when you ask for something you don't know what will result, you just get something back
... we can reproduce a similar system for payments, avoiding the "nascar" problem, i.e. that user have to choose among a lot of logos for providers e.g. socnet "share" buttons; this hurts the small players
... "intents" on the android platform indicates something the user wants to do; the user is allowed to pick among services that are available to them
... we can include payment in the intents architecture as an "intent to pay"

(I think I said the same thing yesterday, and it was in the discussion of web intents earlier)

scribe: intents can provide a very simple flow for the web platform, that is orthogonal to the underlying payment system

Dave_Birch: we didn't test the notion of being able to pay without any understanding of the underlying payment system; to decouple it sounds great but it is real;

Robin_Berjon: domain experts need to help us with the mapping to the payment level
... we need to avoid locking ourselves into what payment is today, and move to decoupling at the design level

<m4nu> Use Case: Decouple payments as much as possible. Base on an intent-to-pay mechanism

Cyril_Vignet: I work for BPCE, a bank in France; I have worked in the payment systems for 25 years
... focusing on one point from the paper, the SEPAmail project
... we have clients, merchants, cardholders, etc; B2B, B2C... there is a lot of savings that could be made, Euro billions, to be saved
... the idea of SEPAmail was to define not only a protocol but how actors interact
... slide 2 Trusted Third Party Processors
... TTPP Trusted Third Party Processors
... ABC Inc talks to TTPPs in a trapezoid arch to Alice
... SEPAmail is based upon web standards, ISO 20022 or xlm data formats

<TomPic> Intend is nice but might be preventing the user to discover new services, no ?

<dsr> SEPAmail uses web/internet standards to encapsulate ISO20022 or xlm data format for payments via trusted third party processors.

Cyril_Vignet: the protocol is mandatory between the TTPPs, optional between the endpoints and TTPP
... what we want to avoid; one party must be connected to the TTPP of the other party (thus the trapezoid arch)
... each client can choose their TTPP
... we also want to avoid subject-specific protocols, and use encapsulation for that
... we also want to avoid ACH or CSM; these are not very well regulated; ACH is quite expensive; much less than manual but still expensive
... it was important not to have a central monitoring point, enabling freedom to do what you want
... experience with SEPAmail; based upon ISI 20022, with different layers for bill presentment, direct debit e-mandates, IBAN control, data along payments
... (discussing EPC...not sure what the points being made are)
... (what is IBAN?)
... we will launch this in 2014 a network for TTPPs

<marie> [crédit mutuel, crédit agricole, société générale, BPCE, BNP Paribas banks in France}

Cyril_Vignet: design is in progress, "families for TTPP than may not be PSP" (someone explain if possible...)
... SEPAmail is an "overal arch that solves (part) of the auth problem"
... example of the "SAPPHIRE family", implemented this three years ago. it's very simple from the banks' view; self-care for the user
... the corresponding private keys is in the mobile, in the secure element or NFC card
... if the payment is low, you may not need very high security
... with this generic approach we have demonstrated ability to support more things beyond payment
... SEPAmail is CC-SA Paternity licensed

<phobeo> link is wrong in the slide, should be http://documentation.sepamail.eu/

Joseph_Potvin: here I am as an economist, 15 years in the IT domain
... re the UI for digital payments
... leave it up if you clicked on conversion options in paypal's screen
... amounts were quoted in local and Euros; this illustrates and underlying assumption, that there is only one exchange rate option; this example though showed other options e.g. between paypal and mastercard/visa, the diff being whether you know the rate at the time of the transaction
... I chose the credit card, due to fewer intermidiaries, rather than use paypal then intermediaries
... re philosophy of money; the tokenization of human obligations; a means of accounting them
... if we did UML for the payment process, three use cases for money
... unit of account; medium of exchange (communications); value aspect (descriptors or standard of deferred payment, stored value - I call it a value benchmark)
... doing the use case and relationship diagrams in UML; who are the stick figures?; who gets to choose the value benchmark etc?
... we are used to those choices; but not for this example (the exchange rate options showed earlier)
... in this paypal example, who got to choose the value benchmark? there were two parties in the transaction, did either get to choose?
... happy that paypal provided this choice, but whose role is it?
... example of a taxi and porter to the check-in. if the porter opens the bags and takes something "it's my business model to take something" - it's not the intermediary's role to determine aspects of price, rather to define service fees
... conversion rate is not a service fee, it's a component of the money
... there is a lot more to this example choice than is apparent
... in the WWW, we need a way to code these things
... thinking about this in the UML terms, where do the lines go and what roles do the actors have, this is a direct line to the theory of money

Neil_Mason-Jones: I represent Trans-Africa Solutions, a South Africa startup; bringing the emerging market / unbanked perspective
... the market is very difficult to authenticate
... we are trying to meet them in the way they want to transact; mostly cash

<phobeo> small highlight over Josephs comments: many payment providers, including paypal, do not call this a conversion but mention it specifically as "cross border and currency conversion fees", as there are both variable and fixed costs associated with the networks they use to move money

Neil_Mason-Jones: in SA we have a huge divide in economic capability

<phobeo> so yes, they are fees and you accept them as so on the payment terms and conditions

Neil_Mason-Jones: re the unbanked, in SA as much as 80%, scenarios such as this occur; in the living in city center, traveling back to home is very expensive
... outside the city center, you can spend a lot just going to buy a ticket
... we find that there is a resistance to putting cash anywhere, in wallets or savings
... we are trying to bridge the last mile, using the mobile devices, libraries or cafes to access the product, gain a token and make a payment in a physical location
... tokens can be barcodes, QR codes, etc
... this is slightly different use case; between request and receipt, it can take days
... its easy to expect all to be online; that the offline are not that large a subset; that may be but we need other options and fluidity to support them
... also there's a large opportunity for tech to help; but in Africa charges are obscene re the service bring provided; people thus distrust the banks; in the UK it is very different, the cost factors are so low
... tech talked about in this meeting e.g. crypto currencies can have large impact in emerging economies
... though banks etc resist on every possible level, we need tech competition to bring about change

Dave_Birch: summing up; Gray established the merchant needs
... Robin suggested a web framework for this
... Cyril suggested a standard way to move around the data
... Joseph pointed out that we have collapsed unit of accounts, building upon other work
... Neil made the point that the medium of exchange needs to be extended into cash

<chaals> usecase: allowing for a settlement that is based on a cash transfer

Dave_Birch: e.e. walmart has a capability to buy online and pay in cash
... to the floor

Stephane_W3C: you make a good point re the notion of decoupling payment systems with intent of payment
... this is a critical point; we need layer separation;
... having an easy way for merchants to support multiple systems and a method for user to select...

Dave_Birch: between the phone and a payment terminal, there is a lot of chance for complex options to take place; standards may need to address the complext negotiations that will occur

Cyril: part of standards is to define the value chain of payments

Gray: taking into account foreign exchange, what I care about in the end is what I will get charged for
... quoting the final ticket price will let the user choose

Michel: there's no breakout that makes it possible to know what cut was taken by whom;
... re transparency and seamlessness, they don't correlate; the more choices are offered, the more complex the UX

Gray: customers will never read those screens

Eric(Bloomberg): what about POS terminals, how to integrate what we come up with here

Gray: fees added happen in the back office, not the POS. pricing queues at the POS are philosohically great, but impossible
... if we can present the final ticket across multiple vendors and give choice that would be great
... our POS challenge is painting the screen as the user is using it; we have to keep it simple for the user
... moving the POS screen down to the phone, you can see exactly what's going on

<erik_anderson> usecase: Move the point of sales terminal off to the users mobile ?

Michel: need for customer choice may be based upon size of the transaction

Cyril: is is possible to automate options at the POS, for POS with web-based presentation

Dave: existing systems do limit us, so we mustn't limit our standards efforts to the existing card system, but look to more options, with the understanding that one implementation of the standard may ultimately be card-based

Michel: should a standard be explicit about roles? would it be acceptable for intermediaries to propose components of price?
... in multiple currency transactions, the intermediary does define components of price

<Zakim> m4nu, you wanted to ask about entry points for change being merchants (MCX, could we deploy web payments in fuel industry?)

Manu: it's good to think past cards; who will be the early adopters? probably not the banks unless fees are preserved
... convincing consumers may also be difficult

Dave: successful wallets are from retailers

Manu: exactly; retailers will push this into the market; W3C will need to figure out how to work with them

Dave: we do need to build those bridges

<Ori_Eisen> What is the problem we are trying to solve?

Michel: if the banks are changing, they will change with the game also if the economics are right

Dave: banks also have an interest in driving down costs

Gray: the limus test for retailers will be can they get banks to change from the interbank model
... retailers want online and POS to work the same

<m4nu> ACTION: Manu to reach out to MCX to try and get them involved in the W3C work on payments. [recorded in http://www.w3.org/2014/03/25-w3cpayment-minutes.html#action01]

Dave: retailers will incentivize customers to opt for MCX

(what is MCX?)

<dezell> Merchant Customer Exchange

Ernesto: re the point about negotiation on the payment process, users may need to choose manually since you can't always know what balances are on the different payment methods
... availability of options will also depend upon location

Dave: what I am saying is there can be a wider set of possibilities

<virginie> note MCX : http://www.mcx.com/

Ernesto: range of payment service providers can be loaded into the wallet in the short term, but balances may not be known
... user behavior/preferences can also drive automated choices

Dave: policies can be set and downloaded from many sources and executed at the POS

Tobie: this is typically where user agents compete

Ricardo: API integrations in browsers will likely cause Visa/MC to cooperate; so we shouldn't expect them to resist this. The standards won't say anything about fees so that will change on its own
... is we assume that we have to tell intermediaries what they have to do we are already making some assumptions

Joseph: what I was saying was that the role that intermediaries are taking needs to be visible in the standard

Ricardo: there you are already supposing there will be intermediaries, and how many there are is unclear

Emil: question re SEPAmail; trust is important, what will be the consumer protections?

Cyril: consumer protection will be provided by the TTPP; the payload will define terms etc; the payment request will have all the data, the idea is to have all the info at the customer side so they can make decisions

Dave: under the current systems, these aspects are all bundled. A system like SEPAmail will allow unbundling of those elements, which can then become part of a negotiation.
... Specialist Intermediaries may arise who can provide that role; Visa/MC may actually fulfill that role

Alexander(EC): we have draft legislation that payer should have the final word on which payment service should be used

(end of session)

<Zakim> chaals, you wanted to say now this is right

<schuki> chaals: are you scribing?!

<chaals> scribe: Chaals

<schuki> thanks

Front End: Wallets - Initiating Payment and Digital Receipts

Prakash: good news is things are growing in online payment.

<m4nu> scribenick: chaals

… bad news, the experience is a mess. Repeated repetition of terrible steps to go through.

… m-commerce rates < 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.

DSR: Creating a level playing field for providers.

-> http://www.w3.org/2013/10/payments/front-end.pdf Dave's slides

… I want to be able to get a digital receipt from a part-payment for a group meal.

[repeats Jeff Jaffe's slide of where we might standardise...]

<m4nu> That was actually Dave's initial slide - not Jeff's

DSR: We have web app -> browser transition, and then browser -> wallet conversation, and wallets talking to individual providers, as possible points of standardisation.

… and we can have multiple wallets, like int he 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]

DSR: Wallet can keep receipts etc. Where does the receipt get held?

[chaals: that was my question about receipts helping eme yesterday]

DSR: 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]

<bryan> usecase: wallet as an expert system

DSR: 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]

DSR: 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 teh 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> offline payments is a current capability, not only something for the future

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

… What happens when I give someone else my device?

… privacy friendly "Know Your Customer"?

<bryan> identity of all parties is essential for trust - Know Your Provider (KYP)

… related - NFC, and upcoming bluetooth work at W3C

[slide 10]

DSR: 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> 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> careful of loyality coupons : the business model is that the customer value them but don't uses them ;-)

Vidya: money for the un/derbanked

… who is familiar with mobile money? [almost everyone]

[slide 2, recaps yesterday points]

Vidya: 2.5B underbanked, big opportunity

… growing industry increasingly competitive. dominated by telcos.

<bryan> 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: 1.2B users in 9 months. 2.5B un/derbanked people online in 3 years

[slide 5 - africa research]

Vidya: Huge growth in everything - 100's of % CAGR

… Kenya 5th fastest towards cashless society because of mpesa

q: what's the axis?

comment: It's just marketing pictures

Vidya: Shows mpesa 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: 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]

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

Philippe: Who uses a mobile wallet daily?

[few]

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

usecase: go to london and spend schuki's friend's money on coffee

<bryan> usecase: realtime checks on account balances in wallets to help decide how to pay

… 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

usecase: showing added value from things you already do

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

<bryan> usecase: wallet is synced with loyalty coupons and digital receipts as they are collected

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

… W3C can help abstract and standardise these interfaces to reduce the cost of deployment.

<bryan> cloud or device would be included in the previous usecase

… 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> I agree, a wallet issuer should not have access to my data just because they provided the wallet

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

[chaals: Merchant wants customer to start buyijg. and then buy more]

Gregory: There is 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 2€) 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: Merchants should just get a token, not real credentials?

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

[chaals: this sounds like password management in browsers, which is years old]

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

Jorg: Identity, privacy and mobile

<Cyril> waranty or tax issues

[Cyril: so who "owns" the receipt content?]

Jorg: Not talking about a product, just what we think a wallet might look like

[slide development history]

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

<m4nu> Use Case: (from Ernesto) User can receive digital receipts (receipt POSTed to user's digital receipt storage vs. an emailed receipt)

… want a framework independent of implemnetation, 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"]

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

<jpotvin> wallet architecture needs to be open to any type of implementation technology

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

[chaals already has that card…]

Jorg: The ecosystem needs to be arrange differently from what people think.

[slide - future wallet definition]

Jorg: 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]

Jorg: 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> I suggest to include along with cards the 3 other main payment mecanisms konwn : credit transfer, direct debit, crypto currency

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

[chaals loves that people can steal everything if they take it in 20s...]

… 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 a 30p sweet 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.

<jpotvin> interpretive dance --- bees do that

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

Prakash: talked of consumers, merchants, wallet/payment provider

… does everyone agree with Dave's characterisation of the three points for standardisation?

<jpotvin> "connect the dots" mobile lock/unlock is an real application of finger-based interpretive dance

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

<jpotvin> q

<Sergio_Aquero> "Wallet" presupposes an architecture

<Sergio_Aquero> it's one way of handling the payment request

DSR: 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

Jorg: 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 we call it I don't know.

Prakash: Does anyone think P2P payment belongs in the primitive set?

<Zakim> chaals, you wanted to say the merchant wants user data too

Chaals, Jorg: Yes

<Zakim> bryan, you wanted to ask why portability is a concern for use of mobile # as account key

Bryan: You commented on prtoability as a problem for using mobile number as account identifier.

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

<Zakim> m4nu, you 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"

Bryan: Not sure if it does, but…

Manu: Wallet is best word we have, but isn't really ideal. So we will get misunderstanding from that.

<bryan> ? re the last question are use cases equivalent to primitives ? "P2P", "B2C" are use cases, not primitives

… Growing concern about where the contents of the wallet are stored. People have more than one device, so they have to synch.

<bryan> a primitive is e.g. "make a payment request", "get a receipt", etc

… Wallets are not the only things that get synched these days

… maybe W3C should think about synching in general. We probably want this stuff on the web not on the device

Mountie: mobile is now the megatrend but wasn't always, and we're also talking about internet of things, wearable devices, vehicles as clients.

<bryan> usecase: wallet portability to new wallet service provider

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

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

<Zakim> steph, you wanted to ask how can an operator be a wallet provider

… how can a mobile provider be a wallet provider, when you change operator all the time - from phone to wifi to roaming to ...

Jorg: 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> steph, 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.

Steph: 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"?

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

<melvster> http://en.wikipedia.org/wiki/Strong_authentication

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

<Emil> I think that a definition of "strong authnetication" is needed.

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

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

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

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

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

<m4nu> +1 to mhepp wrt. security must be modular.

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

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

DKA: 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> 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 teh context of storage work, … what are the primitives for multiple wallets?

DSR: Idea is to create a space for innovation. Maybe we don't need to standardise synch. What are the *minimal* set of standards that meet the primary goals - innovation, merchants' and users' needs met

<Jorg> Wallet should be seen as a Concept helping us to guide standardization in various fields ! (security, identity, identity selectors, transaction framing)...

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

<virginie> note speaker is gergory estrade

Gregory: 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 shouldnt be connected in between the user and what they are purchasing.

Prakash: Need to define wallet, by use of a token….

Joseph: I thought that authentication through interpretive dance is what a written signature involves. Or the dot-connecting to unlock my phone.

<mhepp> +1 to phobeo

… drawing a symbol on a tablet can provide an authentication mechanism.

<bryan> phobeo, 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?)

… Applying WCAG to this, there are people who are visual, and people who have e.g. dyslexia and huge problems with authentication.

Natasha: Identity and how we authenticate will be something we choose- retina, password, use a signature?

<phobeo> 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 noit always be entirely visual.

<Zakim> chaals, you wanted to ask about shared devies

usecase: payment systems running on shared devices.

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

<m4nu> Chaals: I think people share devices, we should look at those as a use case.

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

<Ori-Eisen> bravo for the last comment about RBA!

<m4nu> Use Case: How do wallets work with shared devices?

Prakash: Shared devices can lead to "friendly fraud". For physical goods the main vector is account takeovers. You need something other than username/password.

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

<jpotvin> Principles of the WCAG standard should apply to authentication methods (therefore offer various kinds of authentication)

DaveBirch: Mustn't jumble biometrics for authentication (good) with identification (bad)

… corrput officials have been selling bogus national id cards - these things are of limited reliability

Evgeny: DSR says there is a problem where to keep receipts. 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

<schuki> close q

Jorg: We framed this with total payment-agnostic. Could do it with EMV, think it works with paypal online, shouldn't matter.

Ori: Shocked that ID cards got sold wrongly.

<schuki> q close

<erik_anderson> +1 "Where ever there is value there will be fraud"

… Err. 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 uesd? What are we trying to standardise, many things could be affected.

Prakash: Didn't see Dave say standardise wallet, but interface between wallet and browser, and between wallet and payment provider.

DSR: Right.

<melvster> +1 "Where ever there is value there will be fraud" or "A certain percentage of fraud is accepted as unavoidable" -- Satoshi Nakamoto

mhepp: To make ground we should seperate the work that needs to be done as implementation, and the things that we should stnadardise. If we standardise 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 fraudule[CUT]

… standards are slow, bad guys are fast.

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

mhepp: @@

<dka> +1 on not trying to build end-to-end

<wseltzer> [an interesting question overall: how do we standardize frameworks for risk-based decisions on security?]

<mhepp> @chaals: I said that bugfixes to security issues in standards will likely come much slower than apple's bugfix for the #gotofail vulnerability ;-)

s/@@/bugfixes to security issues in standards will likely come much slower than apple's bugfix for the irc://irc.w3.org:6665/#gotofail vulnerability/

[lunch]

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

<mhepp> instead, we should focus on standardizing data interchange, so that components can exchange the respective signals.

<melvster> mhepp: +1

<schuki> scribe: schuki

Identity, Security, and Privacy

virginie: there have been many sessions which have mentioned security
... identity and privacy
... our panelists are going to talk about these stuff
... hannes will be talking about IETF, gmandyam from qualcomm, tim from microsoft talking about product choices in microsoft, greg will share deployments solutions related to security, stefan from ripple, and harry from w3c perspective
... hannes to the stage

hannes: i work in the ietf and was asked to talk about identity management
... a few years ago there was a patent where linked in was asking for user/pw of email account
... this created many privacy / secuirty problems
... many companies worked on solving this

<mountie> what OATH stand for?

hannes: many of us have noted the building block approach and use of these
... the original protocol for this was OAuth

<wseltzer> [OAuth is an authorization protocol, not an abbreviation]

hannes: there are many companies using this today, some are in the room, also many smaller companies using this

slide [2]

hannes: this is how we defined identity, could be ansything from user/pw to a rick set of attributes
... not just auth context, usually much more than that
... so how does OAuth work? It all starts with the user ('resource owner')
... he stores resources somewhere
... he/she wants to give access to this shared resoucre
... an auth server has control of access to this
... it grants this access
... and this uses tokens, it captures the consent you have given and gives the client access
... here is a typicaly diaglogue

slide [3]

slide [4]

hannes: so the resource owner is the end user
... and this user wants to buy something on a website, the client will then play the role of a merchant
... the merchant then gets the access to withdraw the money from the users bank account
... this is not an abstract concept. You can find descriptions of what these companies have tried to do

slide [5]

hannes: i was told visa japan uses this mechanism

slide [6]

hannes: those are proprietary extensions on top of those protocols
... but i think we made a good contribution to lower the password sharing of the old patterns
... and helps users reduce the usage of pws
... but we did notice challenges,
... the industry likes to be an 'identity provider'
... but not many want to be a reliant party
... some hardware reliance for security for example
... the mechanism we have come up with is a decentralised approach
... even still many companies decided to go with a small number of identity providers
... so it;s still hard to find a fully open approach to identity providers

<bryan> re high interest to be IdP, relying party = identity consumer; most companies want to be the producer instead, and not dependent upon external companies for their user IDs

hannes: we also noted some companies who use oauth also use it because they want to be interoperable with other companies
... this can create lock-in
... we cannot force people with what they do in thier business decisions, but it is unfortunate
... e.g. facebook only allow you to login with them

slide [7]

<bshambaugh> If I may ask, what is identity?

<bshambaugh> sorry..

<bshambaugh> for interrupting

hannes: whitelisting, there are some business agreements which make it difficult to give everyone full open access
... there is some groups like Open Identity Exchange which work on this
... the education industry is also good here
... in terms of security, some companies ignore our recommendations
... or shortcut it, and optimise it in another way
... with regards to privacy: consent management helped with privacy

<Ori_Eisen> Facebook will not allow others to authenticate for them, as they can not control the quality of the process

<marie> group

<Ori_Eisen> this is a fundamental issue, that can not be solved with technology

hannes: the reliant party asks for so much data
... they can ask for the purpose of the application
... e.g. angry birds asks for location
... FCC may need to kick in to stop this happening, but we are limited in what we can do here

<bryan> dependence upon reliability of the IdP is one reason for reluctance to be a relying party

hannes: how much data you have to share depends on so many aspects

slide [8]

hannes: here i have included a link to the openID Connect protocol
... thank-you

virginie: 5 min qs

Zakim: open q

Jorg: have you considered who owns the identity data or who owns it
... and who takes responsibility for it
... the stuff we're talking about here may be too technical, but these issues are real

hannes: sim based auth may be the way you want to do it, or a smart card
... we didn't standardise on this, it can be outsourced

<m4nu> use case: Use OpenID Connect to bootstrap a payments process.

hannes: also, how do you separate the identity and the person?

<bryan> as noted by Hannes, OAuth can be a basis for payment APIs such as the OMA Payment API: http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20130924-A/OMA-TS-REST_NetAPI_Payment-V1_0-20130924-A.pdf

hannes: also te auth server and resource are separate components implemented by different implementers
... this makes a lot of sense

adrian: what is a payment protocol and how can it fit?

hannes: the payment mechanisms on top of identity infrastructure already had the hooks to give the consent in the web and mobile app space
... all they did was create additional data structures
... it might be a good starting point as what can be done with these mechanisms
... e.g. how you provide access from one payment system to a merchant

<bryan> as noted by Hannes, OAuth can be a basis for payment APIs such as the OMA Payment API: http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20130924-A/OMA-TS-REST_NetAPI_Payment-V1_0-20130924-A.pdf

m4nu: we looked at openid connect and working on identity credentials spec

<bryan> Sorry for the repaste... bad client

m4nu: seems like credential solution could work on storing credentials in some kind of cloud based identity
... and then have the ability to send the credentials in a very specific way
... for a payment you show up to a merchant and share your payment provider info
... it seems like we're heading to a system which manages all of this
... have you seen anyone at IETF talk about the transmission of digitally verifiable credentials?1
... oh, and requestAutoComplete does the same, shares certain details

<bryan> What Hannes is referring to re OpenID Connect use in payments is I think more specifically the use of OAuth (as a fundamental part of OpenID Connect) as a framework for defining the scope of a payment, as in the OMA Payment API I mentioned before.

hannes: well, the access token that we have here between the client and protected resource is the credential
... what some of the industry players are working on are a higher security version of this
... currently uses TLS
... we are working on using a key or async credential
... in order for it to be sucessfully deployed it requires existance of standards that harry et al have been working on at W3c
... with todays browers this is tough, to store stuff in localstorage
... so we have to work on something which is more secure
... so we are hoping W3C crypto work is getting there
... we are getting closer to deploying this secure version

mountie: we have seen openid, these kind of mechanisms touching for identity, do we think multiple provider (payment, identity, FX etc) we have this idea of expansion
... will there be a gateway?

<bryan> OpenID Connect is also being used in the GSMA Mobile Connect API program http://gsmamobileeconomy.com/gsmamc/ as another example of how secure/trusted identity can be seamlessly integrated into mobile services, based upon OpenID.

hannes: we didn't look much at multiple sources, but people have explored this
... telecomms people have looked at attribute provider (e.g. street address info as well as subscriber data)
... provider has the ability to verify against this data

<m4nu> Identity Credentials spec: https://web-payments.org/specs/source/identity-credentials/

hannes: idea was that there will be some sort of broker which would make it available to the user

<m4nu> A Proposal for Credential-based Login: http://manu.sporny.org/2014/credential-based-login/

mountie: with the payment provider we don't exchange info cross site, just with provider only
... so address is given to delivery provider only

<m4nu> (that is related to the comment about OpenID Connect, storage of credentials online, etc. above)

mountie: possible?

hannes: nothing we have done so far

virginie: let's welcome tim from microsoft to the stage

slide [1]

tim: i work on the commerce team at microsoft

slide [2]

tim: our thoughts around identity
... as a result of living in multiple countries i have many bank accounts
... I also have many social network accounts
... i tend to separate with who i interact with
... I also have an address and I went to school and am recognised against these
... these are all things used to find me
... so we decided at microsoft that we didn't want to launch a new commerce identity
... we didn't want you to give more info over
... so you take something that identifies you with a commerce identity

slide [3]

scribe: this identity identifies you next to these identities
... whatever you created it links to your financial data
... it realted you to rights, you may have purchases an xbox game
... or whatever,
... you have a right to the game, but you may not have paid for it
... you mum might have bought it for you

tim: we also model things against your 'friends'
... this could help you give access to some friends so they can access things you have license for
... we model both buyers and sellers
... so from a commerece perpective we see what is bought and sold
... we have all the info on your purchase history
... we give a score for this
... we want these commerce accounts to be stored offline and online
... we want you to get a statement at the end of the month as to what you bought
... finally we give you the ability to enter multiple payment options and rules
... there are simple rules (50/50 between two credit cards)
... rules can be complicated
... the commerce identity is separate from your google/yahoo/hotmail
... we are trying to find out how users can get a commerce account for those who don't have an online profile
... say if user first goes to a store
... so can we use credit card or passport as in ID?

slide 4]

tim: there are a lot of identity providers here
... we use the oauth protocol to integrate these
... we use different views
... so if you login with your corporate account you get a different view
... modelling trust between commerce accounts: so you don't give credit card to merchant
... also limiting spending limits for family members
... what we have done is only for microsoft products
... we want to extend this
... this is a opportunity for partnerships
... we want to bridge physical and digital worlds
... also fraud
... fraud is very siloed
... there is some interesting things to research here

slide [5]

<m4nu> use case: Associate fraud information with identities.

security, we want to establish a secure protocol

tim: we may look at some money transfer scenarios

<m4nu> use case: Don't share any theft-worthy data with merchants.

tim: we are looking at new flows here
... we would like the same API to work across situations
... we have some issues with security across banks and providers
... ACH is good but hard, we want to work with this
... I'd like to see more encryption in this whole pipeline
... we'd like to increase interoperability, discover where in the stack these solutions can help

<Ori_Eisen> you cant easily change the 8583 protocol as millions of legacy systems will need to be changed

tim: thank-you

<Zakim> wseltzer, you wanted to ask what about customers who don't want a *single* commerce identity but multiple personalities? and to discuss strong privacy guarantees, if you do link

virginie: just one question from wendy, then wait till the end of all the speakers

wseltzer: thanks for sharing tim, what privacy considerations could you offer to user who doesn't want a single identity? Or who only wants to make payment but not to anything else

tim: good q. Today we allow user to create commerce account and not link org to that identity, and then you can create another account
... then we wouldn't know the accounts were linked

virginie: next is stefan from ripple

stefan: i will talk about identity from decentralised networks POV

slide [1]

and how distribute networks can help the issues speakers have bought up

slide [2]

stefan: definition of terms

slide [3]

<m4nu> Use Case: Place identity in a decentralized network

stefan: authentication (identifier could be name, or anything), attestation
... (providing better solutions for trust)
... as a payments WG we would not presume to be more knowledgable on identiy, but look at some of the unique challenges for identity and payment
... and how these distributed networks can help here
... or be impacted

slide [4]

stefan: you have many identities (work, home, gamer id)

slide [5]

stefan: with your identity you can have claims and orgs requesting claims

slide [6]

stefan: openid connect is pretty good, agnostic to provider
... cryptographically secure
... offers granularity
... supports discovery

slide [7]

stefan: why would you care if google are your provider?
... they are a target, so you might care
... also there is a lot of lockin for some providers
... it's hard to capture this point, but ppl do think there should be a different way

slide [8]

stefan: openid is another option
... in ripple, we take a pw, we blind it, we take the unblinded value as a key
... have full benefits of identity provider and 2 factor auth

slide [9]

the other problem is switching providers

stefan: a global identifier could help here
... so Alice can sign things that act on her behalf
... this is independant of any company
... so how do i pay Alice?
... we have a mapping from Alice to global pay identifier
... and from there you map to different ways you can pay Alice
... e.g. bank account, or bitcoin wallet

<Ori_Eisen> How do you know for sure it is Alice who provided the crednetials?

stefan: this is an early version of what a web payments group could come up with

slide [10]

<m4nu> Use Case: Update identity information in a decentralized network (replace payment providers, etc.)

stefan: so where is this info stored?
... we want claims to not be stored in any particular place
... so we can store these pieces of information decentrally
... thank-you

virginie: gmandyam is our next speaker

<chaals> [Agree with ernesto, relying on reputation provides a barrier to entry...]

gmandyam: thank-you to the organisers
... i run web standards in qualcomm
... within QuIC
... we have been doing more in the mobile payments given the hardware that has come into play

slide [2]

gmandyam: some history, lots of work in premium sms
... this is still growing!
... not going to die soon
... any soltuon will have to look into how premium sms fits into the open web
... it's not a great solution, bad rev shares, need to eat the bad debt, etc.

slide [3]

gmandyam: header enrichment, this is actually a very workable and used method
... msisdn is injected into the header in the operator proxy
... user never knows payment doens't take place
... but it's not as secure
... once your outside the network then the operator doesn't know what you're doing
... standards could help by setting guidelines

slide [4]

we are seeing more use of contextual data (geo location etc)

gmandyam: we did a lot of research on mobile shopping, particularly germany
... in grocery they scan items and present final barcode and then leave the store
... this was ok, but why can't we use indoor location to tell when they left
... bluetooth access points was not great for indoor location tracking
... i reason was couldn't keep up with speeds
... beacons might help here
... user should just be able to walk out.
... and purchase should happen
... HTML5 has given us some helpful APIs here
... it could help with multifactor auth too

<wseltzer> [note: privacy in contextual information]

gmandyam: security is still an issue
... even TLS has security holes
... WebRTC has some issues here with emergency calls, biometric data has issues too
... re trust in browser and TLS
... EME spec is a bit of a blackbox, so we are getting comfortable with more secure models
... thank-you

<erik_anderson_> W3C needs to reference some 3rd party secure hardware

virginie: next speaker is gregory fhe lyra network

<erik_anderson_> Google and Yubico have been working together on the U2F spec (universal 2 factor)

gregory: here we will talk about principles

slide [2]

we have been conerned with centralised systems and data leaks

scribe: or surviellance

gregory: there was some expression to centralise the web

<erik_anderson_> ernesto: http://www.yubico.com/2013/03/future-of-authentication-faq/

<erik_anderson_> ernesto: www.getnymi.com

gregory: there have been platforms that are more decntralised

slide [3]

gregory: there is a lot of innovation in hardware
... but not just hardware, some innovations are listed here

<erik_anderson_> Facebook and Google have been working with Yubico on a hardware solution to remove passwords

gregory: secure elements, nfc, biometrics...
... FIDO, identity credentials

<cyberphone> http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf

gregory: some issues need to be addressed
... ease of use
... related to data aggregation
... currently easy to copy data between devices, this is difficult to trust

<erik_anderson_> m4nu I have been following this industry for a while. I cant kill the evil anonymous until it is nearly impossible to impersonate someone

gregory: so many devices could produce multiple points of failure
... identity and privacy is different, what you are is what other orgs know about you

<erik_anderson_> schuki - Nearly impossible to coordinate a remote attack across multiple devices

gregory: identity is being someone
... trust, trust is a subjective idea
... we talked about cryptography
... you can have trust in something / someone without sharing keys / credentials

slide [4]

gregory: idea is to build your own web of trust
... you can add your id card, it can be part of your web of trust
... you have to do the choice
... also about education
... facebook have done something for 1/2 years re trusted contacts
... not everyone is web savvy
... anyone could fall into the trap
... you should put people who act as an insurance for you in case someone puts something which is wrong for your service

<m4nu> Use Case: Figure out a way to couple identities together to allow one identity to retrieve access to another identity if the 2nd identity loses their 2FA device.

<bryan> usecase: keeping your web of trust in your wallet

gregory: there needs to be a balance of things you need to give to the merchant and not

slide [5]

<erik_anderson_> Manu: most providers allow you to setup multiple 2FA devices for your account incase you loose a device

gregory: secret sharing: idea is to avoid the point of failure

<virginie> note shamir's reference : http://point-at-infinity.org/ssss/

<erik_anderson_> 1 on person, 1 in fire safety box

gregory: you don't store your credentials in one place but in many places

<m4nu> Shamir's secret is considered bad security practice via Bitcoin community - which is why they did multi-sig (in a way that wasn't Shamir's secret)

<erik_anderson_> Shamir's Secret Sharing Scheme is less effective than multiple key signature protocols

<erik_anderson_> +1 Manu!!!

gregory: internet of things: could argue the object owns, rather than other way around
... object can become part of your identity
... thank-you

<bryan> usecase: secure backup storage of wallet info in a friends wallet

virginie: we have discussed open id, protocols, security features, better management of identity

harry: there are a number of things going wrong
... there is a number of things W3C can do, and one of those is web crypto API
... up to a few months ago it was very hard to check digital signatures
... this was because those components which were needed for secure applications were not available in the JS runtime

<chaals> [I still rely on a lot of real life social networks for authentication - e.g. in banking…]

harry: workshop ran some time ago
... we can build technical systems that can build secure systems
... and the great success over the past few years is oauth
... persona came about a few years
... dying now
... but at the same point whilst this was going on the auth stuff was happening

<erik_anderson_> Chaals: Go buy a 3D printer!!!

harry: and now we have the crypto group (lists participants) which are unified on an API

<virginie> note : Web Crypto API https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

harry: so you need to know who has the private key material
... right now the crypto API doesn't allow you to do that
... but now we;re working with some new groups: FIDO alliance et al
... so we can get hardware tokens working for the browser
... we're inspecting key storage stuff in browser, new crypto works by some other groups, working with IETF
... working with all these people to develop crypto API and hardware token
... pretty sure hardware tokens will have a workshop in September 2014 in silicon valley
... so join the crypto group
... and help us take these implementations to the community so we can discuss them all together
... thank-you

virginie: thanks for the good work in the crypto group harry
... next is Louise

louise: identity is married with trust
... trust is essential for online payments
... standards for payments on the internet is linked with security, tracability, privacy and anonymity
... you have to get the right data at the right place at the right time, so you need to be certain for some use that the identifier is linked to what you are concerned with
... since people and orgs are not attached to the internet
... how do you know they are linked on the internet
... how certain you need to be that it is me or my company that is needing the thing is where we come into risk in the internet
... in the virtual world you may want to know you're dealing with me by many levels
... in banking transactions the only thing that matter is i opened the account and i am deposting the money
... but there exists legislation
... will web paymetns come under jurisdiction?
... I predict p2p payments will start to become regulated
... this will of course have impacts
... should you have one or many identities
... most people think you should be allowed to have many identities
... associated with ppl or orgs
... there are terms and conditions assoicated for each
... some people think IPv6 is the answer to the issues with identity
... i think that's a non starter
... korean govt mandated that access to korean sites would only be available to those who had government-verified identities, but this was later ruled to be unconstitutional
... in online commerce you need to be able to provie you've made the transaction
... i like the allipay escrow model
... in many online / international dealing you need a third party

<erik_anderson_> For public record Anonymity is evil!!!

louise: i would say anonymity is not evil, people can hide behind it an do evil things, but it doesn't make anonymity evil

<erik_anderson_> :)

louise: privacy is about only providing data to those you want to provide it

<bryan> privacy is also the right to share what you want to share - seems like the same thing as protecting what you want, but it isnt

louise: advocates of privacy are trying to protect the individual

<chaals> [I wonder if privacy is about providing data, and a sense of what you think it is OK to do with that data]

<bryan> +1 chaals - putting people in control of their data is privacy

louise: de-anonymisation is much more damaging then anonymity
... seems some people didn't want anonymity, they wanted non-tracability
... some people wanted to hide from the authorities
... they didn't want to hide from friends, just not tracable from the state
... many of us achieve this by using the different identities

<m4nu> Loving this talk - really great capture of the subleties of privacy/anonymity/security/traceability.

louise: freedom of speech is far more important than privacy

<erik_anderson_> usecase: separate the idea of privacy and anonymity when it comes to web payments. Privacy for online actions is important. Anonymity when it comes to financial transactions and moving of money is evil

<jpotvin> US freedom to > freedom from; EU freedom from > freedom to

louise: you must address these issues otherwise standards will have no global validity

virginie: i would like to thank the speakers

<chaals> usecase: completely banishing the word "evil"

virginie: we covered the multiple identity issue, user control over their info, protocols and how to make them secure, education
... please ask questions to the speaker in the break

<chaals> [I'm not sure that we want to draw the lines on what is privacy and anonymity. But I think standards need to support transparency of understanding what will happen to information (money, correspondence, associations, …)]

Wrap-up of Workshop

<m4nu> scribenick: m4nu

Steph: I'm going to publish slides soon, Dan, go ahead.

Dan: I'm Dan Appelquist, I work for Telefonica, I chaired the program committee and chair the Technical Architecture Group (TAG) at W3C.

<marie> [Hear, hear: all prez slides will be linked from the agenda: http://www.w3.org/2013/10/payments/agenda.html]

Dan: The next hour will be unstructured, be interactive.

<mountie> share the link on the screen

Dan: So, what are the actionable items for W3C?
... What existing efforts are going on in W3C? Could those groups be influenced by this workshop? Think about this stuff.
... So, let's go through this - we've learned some interesting things.
... The Web should be a level playing field - that's a key concept for the Web. That leveling may be threatening to certain parties. We have to keep that in mind.
... There are not two different worlds (physical and web) - there is one world. More and more, this is not about "Web Payments", it's just "payments" and we're doing "commerce".
... There is no distinct mobile web and fixed web.
... An underlying theme - the web includes both the browser and the web of data.
... When we talk about Web Crypto, we are talking about the browser.
... A browser centric web - that's where a lot of the energy is.
... The Web includes data and data formats. When we start talking about receipts, we need to think about that.
... We've talked about payment scenarios - physically transacting via web app, physically transacting via merchant device, user online and app is online, user to user, etc.

<chaals> [+1 to wendy - let's not spend too much of our time agreeing on the exact weasel words we are all happy with, so long as we have done enough to remember the idea *clearly*enough*]

Dan: There has been a lot of talk of the primitives / building blocks - clear technical work that is going on right now, or may need to start.
... The second category is more strategic, prioritization of requirements, perhaps by splitting off a new WG?
... There are different kinds of groups that W3C can create - technical deliverable groups, interest groups (places to generate requirements / prioritize)
... There might be a call for a more strategic interest group.

<bryan> s/ink rel/link rel/

Dan: Work that's already going on - webapps, security, other, etc.
... payto was an interesting proposal.

Chaals: outside the payments CG, there isn't work in this area. There used to be Web Intents work
... There was work on intents, which has gone to sleep.
... The CG might be the place to develop that further?
... For WebApps, our charter is being rewritten right now in a final draft. if there is stuff that should be in there, right now would be a good time to propose it. There will be a F2F in April.

Dan: How do we influence that?

Chaals: You tell us you want to work on something, if we have consensus, we add it.
... We'll work on new pieces of web stuff to support stuff. If it's in scope, we can add it.
... it could be that we tell folks to do it in a different group - WebApps is a big group, lots of important players involved already. Disadvantage is that its a big group, if you don't have people actively working on something, it'll disappear.

<phobeo> I think we should also keep in mind work done in other related areas that got mentioned... eg RFC 2801 (IOTP), paypal express button code (similarities with payto: link schema suggested)..

<dsr> There are several other W3C groups of interest, e.g. System Applications, Web Crypto, NFC, Geolocation, etc.

<phobeo> and keep payment providers involved so they can share whether discussions fit with their current APIs or not

Dan: Request Autocomplete is going on in WebApps, so good example of piece of work that I strongly recommend that people read.

<chaals> What webapps is currently working on and where it is up to

<phobeo> (eg: we have netm in the room and I'm pretty sure any links to pay with credit card but not mobile billing can be raised by them, same with bitcoin processors)

Prakash: This was announced by Google last May - it's something that's a payments template. There is a chromium dev. post, we'll put that in IRC.

<darobin> requestAutoComplete

Olivier: What does PCI say about this?

<phariramani> requestAutoComplete details are here http://www.chromium.org/developers/using-requestautocomplete#id.befidh5t7x8d

Dan: That's exactly the type of feedback that should go into that group.
... WebApps is via a public mailing list, you can give feedback there. W3C groups MUST respond to public feedback.
... Going back up - lots of conversation about digital receiving - payment requests, digital receipts. Rleate to schema.org - JSON-LD format. - description of goods machine/human readable.

<chaals> a draft proposal for the new webapps charter

<dsr> (this is likely to need to be an extensible format rather than a closed one)

Dan: There isn't work going on in here at W3C - payment requests, digital receipts, - this could be a new work item for W3C, possibly for a new WG.
... This is clearly something that's important.

DaveEzell: Should we check outside W3C too? IFCSF has a card vocabulary - card request, card response, we should look at what they've done.

Chaals: Let's talk to the group that is working on digital items - EME work, HTML WG task force - let's see if that group is interested.

Dan: We might want to think more about the Trusted UI stuff - is there work going on on this? There wasn't.

<bryan> I was going to comment that schema.org seems to be less viable a resource for W3C given ongoing difficulties getting them to allow W3C to leverage / align / influence their work

Dan: There is the Secure UI

<marie> http://www.w3.org/2011/webappsec/

Chaals: WebApps Sec might be interested in Trusted UI

<marie> https://www.w3.org/Security/wiki/IG

<marie> strint wsp: https://www.w3.org/2014/strint/

Wendy: Web Security IG, Web Apps Sec WG is doing XSS protection, site protection, Web Security IG, STRINT workshop (W3C and IETF IAB), interest - how do we help users to deal w/ plethora of choices, right context for making security decisions.

Harry: I know for people that don't know about W3C - Interest Groups have high-level strategic role, commuications, roadmaps, kick out requirements.
... Then kick stuff out to Working Groups - they do implementations.
... Anyone can start a grass-roots community group, they work on pre-standards stuff.

Mountie: The requirement for the user environment - none of the working groups were accepted for specs - there is still a ???

Dan shows what the STRINT website looks like, what came out of it.

Joseph: Relationship between IGs and other IGs - can groups be created where they provide input to other IGs?

<dezell> -- International Forecourt Standards Forum Information --

<dezell> Home:

<dezell> - http://www.ifsf.org/

<dezell> Standards:

<dezell> - http://www.ifsf.org/ifsf-standards.aspx

<dezell> Electronic Payment Server overview:

<dezell> - http://ifsf.org/archive.aspx

<dezell> then search for "Part 3-19 IFSF POS to EPS Interface Specification"

Joseph: Should there be a parallel community group - Web Payments CG - could this other group be an interest group?

Chaals: I don't think it makes sense to have parallel groups - we may want an IG instead of the CG.
... The process differences can be different - there is a different IPR policy, different set of rules.
... One of the things that happens when you get into regulation - how do you define competition, open processes are important. I would be happy for the CG to continue - the one thing I would be oncerned about are that big players don't like IPR policies

Jeff: I want to clarify - within the W3C, we have the official process of W3C, and then we have the less formal processes - official process has W3C WGs that work on next generation standards.
... IGs work on use cases / requirements to feed recommendation track.
... Web and TV IG are trying to figure out what we need for entertainment.
... CGs are not an official part of the process, but we make it available so we can capture the innovatin of the Web community, which is far broader than official process. To give you some sizing, our CG group is 3x the size of our WGs.
... We probably need an IG for payments. The Web and TV IG, in addition to feeding WGs, they adopted several CGs that they want to work on prestandardization work.

<chaals> Community Groups home page

<chaals> [the explanation of how they work]

Joseph: Thanks for the guidance - asked by Central Banker publications to see what parts of this events should be interesting to them. Then next step is how they provide input.

<chaals> [Note also that Interest Groups get dedicated W3C resources, Community Groups do not]

Joseph: in the case of bitcoin, China, finland, does not consider Bitcoin not currency - sounds theoretical, but it invokes a whole different set of laws - for reg ulators that's crucially important.
... Where should these issues go?

Jeff: we don't make comments on laws - maybe an IG?

<chaals> W3C Process

<chaals> [see especially chapters 3 and 6]

Dan: This is what I'm trying to get across - there may be an IG to get across these issues. Other answer to your question is things like - what are these other building block elements.
... Out-of-band authentication, NFC APIs, banking community could engage there.

dsr: we're looking for companies to become involved in NFC.

Harry: To build off of what Jeff said - grass roots community groups are good for ideas. if you want something like hardware tokens to work across all browsers you have to send that to a technical WG, you should join W3C.
... IG -> WG is the generally effective way to get technical work done and implemented. Web Crypto is a good example of best way to approach.

Bryan: very briefly - push API has been under work for a a little more than a year. wallet apps - could plumb that right to the browser - watch it.
... All ideas are welcome.

Dan: Fundamental building block APIs.

<dsr> In addition to NFC, other related technologies we are seeking greater involvment, include Bluetooth, e.g. BLE, and access to Secure Elements.

Ricardo: Now that we have payment providers, they need to join this other work - paypal, bitcoin, etc, companies need to get involved.
... What we do might as well align with what people who are working in this already do - things like that. We keep mentioning a trusted UI, it's just a way to verify.
... Chrome-less apps needs to happen, perhaps in WebApps.

DaveEzell: How do you get input from regulatory folks? I'd hate to see us take a big step back from that. We have a number of people have joined us, I want them to be approached to provide a little bit of bandwidth and input. Let's use this opportunity to reach out to them.

<phobeo> s/This structure doesn't work for me/so that those payment providers can let us know easrly if the structures we define don't work for them or anything of the like/

Wendy: Thanks for reminding us of the the importance of regulatory considerations. We welcome that input and encourage participation, e.g. in the Tracking Protection Working Group. We need to incorporate regulatory concerns.

Dan: The role of cryptography, geofencing, NFC APIs, out-of-band seconday auth - all work that's going on.

<erik_anderson> q$ Muuhahaha!

Dan: When you're within a Web environment, are there additional use cases that are payment related?
... or, could you use the existing technology to support geofencing.

Giri: Geolocation WG is circulating a new charter - hardware accelerated geofencing is in the work. It doesn't solve the whole problem yet, geolocation from trusted source - that's what's needed.
... This could be something they could give assistance to...

<marie> sysapps wg: http://www.w3.org/2012/sysapps/

<chaals> [if anyone wants a quick (and idiosyncratic) guide to W3C Process, let me know and your requests may be answered…]

Wonsuk: SysApps create security sensitive APIs, including Secure Element for providing interface to access secure storage information in the spectre of payment. We need to save/access private key and other info for users - that item is helpful wrt. payment. We are interested in your use cases for Secure Element.
... Secure Element - we're gathering use cases, please come there and share opinions on payments

<virginie> note : secure element unofficial draft is here : http://opoto.github.io/secure-element/

Joerg: I want secure element here, so that's my list of technical items.

<wseltzer> [Secure element discussion likely in the WebCrypto vNext workshop]

<bryan> need to add "Know Your Provider" (KYP)

Dan: Her'es the strategic stuff: tokenization, intents, digital ID problem, authentication on mobile, digital signatures on contracts, Kknow your customers, multi-currency transactions, complex negotiation on payment instrument, price benchmarking

<wseltzer> bryan, and that ties into security for the users

<bryan> exactly, trust is a 2-way transaction

Dan: PoS terminals, string authentication, digital identity, ACH, loyalty card use cases, privacy concerns, ticketing/couponing, API between wallet and browser, synchronizing data to the cloud, interface for web app to request payment and what it gets back

<jpotvin> to "multicurrency transactions" please add "deferred transactions", because many of the same issues arise (value of EUR today not equal to USD today; value of EUR today not equal to EUR next week)

<dsr> Re: authentication -- what can W3C to to enable providers to implement the authentication procededures appropriate to their risk models.

Dan: Identity - long term, where are we going here. Moving away from username/password, identity and privacy social graph, web of trust.
... Secure local storage? Should it be sync'd - does WebCrypto work affect that?

<jpotvin> strat issues should include explicit documentation of roles

Dan: What's missing from this?

<chaals> manu: Putting all this stuff into an IG, it might not be the best place. We may want to incuvate in teh CG and move stuff to working groups from there.

<melvster> wseltzer , virginie ... already raised, and an issue has been filed ... so we'll see ... :)

Stan: It's important that you don't limit what a payment should be. We shouldn't setup guard rails - it should be nodal representation - we shouldn't prevent stuff from happening.

Dan: I didn't mean to exclude cryptocurrencies - but it's strategic long-term.

Jeff: I wanted to first embrace manu's concerns about boiling the ocean.
... Digital publishing work is 1 year old - 60 distinct requirements came out for CSS WG alone - looked like boiling the ocean. When we created IG, chair and people went through prioritization activity. Any group has to get something done, so the IG defined 9 task forces, we're trying to get our arms around what we heard. There will be a significant boiling down activity on what we do.

Joseph: A couple of points - I'd agree that defining what a payment is comes from the legal community - there was some discussion on whether such a standard could be equally useful in handling barter. This might be Web-mediated value transactions. I don't think you list explicit documentation of the roles. Multicurrency transactions issues come up w/ subscription-type payment. Over time, relative values change.

<bryan> +1 to "web-mediated value transactions" as the goal - given that we can keep the scope from being too wide

Dan: We have to close, Stephane is staring at me w/ daggers in his eyes.

Goodbye

<erik_anderson> Is there a way to get the full chat logs?

Steph: There is a mailing list for all people on this mailing list - we'll continue it after - we'll send a draft report soon-ish.

<virginie> lets thanks the scribes, great material there :)

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Halo/Hailo/
Succeeded: s/mortal/mortar/
Succeeded: s/@@/BNP Paribas/
Succeeded: s/APPHIRE/SAPPHIRE/
Succeeded: s/Cyril/Michel/
Succeeded: s/Michel/Joseph/
Succeeded: s/POS/modern POS/
Succeeded: s/mobie/mobile/
Succeeded: s/though/thought/
Succeeded: s/to/too/
Succeeded: s/stnadardise/standardise/
WARNING: Bad s/// command: s/@@/bugfixes to security issues in standards will likely come much slower than apple's bugfix for the irc://irc.w3.org:6665/#gotofail vulnerability/
Succeeded: s/outsources/outsourced/
Succeeded: s/structure/structures/
Succeeded: s/identty/identity/
Succeeded: s/created/credit/
Succeeded: s/thios/this/
Succeeded: s/../.../
Succeeded: s/info/place/
Succeeded: s/with/withi/
Succeeded: s/withi/within/
Succeeded: s/lira/lyra/
Succeeded: s/wbe/web/
Succeeded: s/palces/places/
Succeeded: s/info a/info in a/
Succeeded: s/sept/September 2014/
Succeeded: s/marred/married/
Succeeded: s/of//
Succeeded: s/could access all/mandated that access to korean sites would only be available to those who had government-verified/
Succeeded: s/became uncon/was later ruled to be uncon/
FAILED: s/ink rel/link rel/
Succeeded: s/a good example/the generally effective way to get technical work done and implemented. Web Crypto is a good example/
Succeeded: s/number of years/a little more than a year/
Succeeded: s/This structure doesn't work for me/What we do might as well align with what people who are working in this already do/
FAILED: s/This structure doesn't work for me/so that those payment providers can let us know easrly if the structures we define don't work for them or anything of the like/
Succeeded: s/invited expert group - we need to reach out to them./the importance of regulatory considerations. We welcome that input and encourage participation, e.g. in the Tracking Protection Working Group./
Succeeded: s/Do we have/We are interested in your/
Succeeded: s/verginie/virginie/
Found ScribeNick: bryan
Found Scribe: Chaals
Inferring ScribeNick: chaals
Found ScribeNick: chaals
Found Scribe: schuki
Inferring ScribeNick: schuki
Found ScribeNick: m4nu
Scribes: Chaals, schuki
ScribeNicks: bryan, chaals, schuki, m4nu
Present: Wonsuk_Lee Jungkee_Song mhepp Evgeny chaals darobin tobie MauroNunez JeremyKing

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2014/03/25-w3cpayment-minutes.html
People with action items: manu

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)