Web Payments Interest Group Face-to-Face Meeting
17 Jun 2015

Lessons learned from ISO 12812 standardization experience

-> Presentation by Mark Tiggas

mark: Work started on 12812 in Nov 2010
... "It was a cold winter day when we started work. The Mississippi River was frozen"
... Our biggest challenge --and likely yours-- will be to keep scope to a manageable size.
... our focus was mobile...when we first conceived of this work there was no iPhone.
... the first Wells Fargo mobile banking offering was in 1998...but there was not enough acceptance at the time so we got out of the business.
... smart phones have made all the difference
... what was "in" and "out" continued to be part of the discussion (and continues to be so)
... the UK's current position is "it's just another computer"

[slide 5]

scribe: our scope included opening accounts, transferring funds (payments), locating ATMs, paying at point of purchase, bill payment, value store
... We organized the work in multi parts...that was a mistake
... Part 1 is general framework
... 2 is security and data protection...probably one of the most mature parts, and also most contentious
... questions about topics like when is a signature required (e.g., not for low-value transactions in favor of speed)

Part 3: financial application lifecycle management

Part 4: mobile p2p

Part 5: mobile payments to business

scribe: note that merchants are absolved from need to know...their banks need to know.
... and so the difference between 4 and 5 is mostly about whether there are financial institutions in the background

slide: where are we now.
... we are at draft standard....ballot end date in July

mark: There will be some "no" votes
... I think that different parts will fare differently (e.g., part 1 is not controversial)
... in some cases, some experts may not be able to convince their (national) communities

[Mark walks through some possible outcomes to the ballot]

mark: ISO standard v Technical Specification (which is reviewed more frequently)
... a technical specification does not have SHOULD or MUST statements

[slide: unexpected challenges]

mark: cooperation/competition roadblocks surprised me.
... e.g., problematic to take requirements from smart card forum but didn't have an IPR regime for doing so
... One challenge that W3C may not have....there are many payments in the ISO space...one of the expectations in the ISO world is to honor and refer to previous ISO standards
... e.g., there are terms defined for cards standards like "proximity payment"
... we had to invent terms that are close to other terms
... e.g., proximate is not proximity payments or contactless payments

[slide 12]

scribe: political sensitivity to EMV
... similarly SEP/ISO 20022 terminology dominated the early drafts
... everybody wanted to make sure their prior investments were preserved

[Mark praises DavidE's group management skills :) ]

scribe: payments baggage weighs on standards process
... invested base and their business relationships
... trust relationships
... some of the trust relationships involve some shady elements and after the Dodd-Frank legislation we had to get out of certain payment activities
... also mobile is moving rapidly; harder to standardize

mark: Now matter how you organize your self...it's going to be wrong.
... capabilities organized by chunks is clearly the way to go

<Zakim> manu`, you wanted to ask about splitting time between breakouts and to ask about legal implications for technology providers for NOT following ISO12812

manu: If 12812 passes, how does that impact this group? (e.g., language in our specs, topics we should cover or not cover)
... of the technology implementers potentially implementing 12812, what happens if they ignore 12812....lawsuits? annoyance?
... what teeth does the spec have?

mark: much like the w3c, standards internationally vary by country with regard to their weight.
... I don't see many standards as a good basis for regulation, due to lack of regulators at the table.
... some nations will likely take it more seriously than other....but in the US, for example (like W3C and X9) adoption is voluntary
... in the case of many of our standards in financial services space, they gain their acceptance through outside groups (e.g., consortia of banks) to agree cooperatively to use the same standard.
... the MUSTs and SHALLs in the document are generally around business principles (less so about technology, except in the security space where there is a nod to existing technology)
... it may be hard to determine that one has violated the standard....there are, I note, some statements in the standard around consumer protection (with participation from those stakeholders)
... I would like to say there is more meat in 12812 than there is, but that is the middle path among the different countries

DavidE: Today, in the petrol space there are hundreds of apps ... these are provisioned....any thoughts on consumer protection?
... there are clearly some challenges with permissions many apps are asking for...in part because the granularity is not where it needs to be (e.g., file system access gives access to everything)
... we tried to go down a path of doing some more appropriate, but many nations recognized that they did not have control of that space.
... the more important things around things like consumer rights of dispute, e.g., some form of record of a transaction.
... I think that those are important areas.
... but the platforms have the control over some of these areas.
... In the US, EMV continues to be a big deal....people are looking at alternatives (e.g., to mobile payments)
... do you have insights into opportunities there?

mark: There was a bit of contention, especially early on....mobile devices have added an interesting dynamic to the process...
... one reason US was slow to adopt is that the average lifetime of a point of sale device is 10 years.
... now there is a push for updates (and liability is shifting to those that do not upgrade)
... in various jurisdictions change happened either due to liability shift or regulation

<evert> In Holland we convinced merchants to migrate by demonstrating lower cost of EFT to cash…

mark: ...in the US our fraud losses were relatively lower, and so there was less of an incentive to change
... People change their mobile phones more frequently

nick_s: How does defining a standard help you differentiate your offering?

mark: Wells Fargo (or any other bank) will leverage what it finds useful.
... that decision will be a business decision.

claudia_s: I participate in X9. It's also fair to say that standards can be infrastructure and there's a lot of opportunity to differentiate on top of a standard.
... eg., there are checking services and lots of differentiation in checking services

DanSchutzer: We did a study with the Clearing House (when I was at FSTC)
... around that time, P2P was big on mobile
... there was a consensus based on that
... Clear Exchange came out of that study
... the bottom line is that the cooperation was necessary to get critical mass to achieve your objectives as a company
... you want to grow the market so that customers flock in the direction of the standard

padler: what would motivate Wells Fargo (or another company) to adopt the standard?

mark: one of the reasons that part 6 fell on hard soil is that not people saw a lot of value in a mobile application
... except perhaps for provisioning and deprovisioning
... but the area where there was the most cooperation was around payments since I can't do payments by myself
... I really need to be able to accept a credit card payment from a customer of another bank
... payments has always been one of those areas where people recognize that to transfer money you need cooperation among multiple parties

DavidE: What is people's biggest concern around the standard?

Mark: Disruption of existing infrastructure
... no compelling business need to change to get the same capability with new programming....
... adding cost in the short term is a challenge, and a big reason why there is little uptake of new payment systems

Revisiting Credentails Briefly

<evert> EBA document: http://www.eba.europa.eu/regulation-and-policy/consumer-protection-and-financial-innovation/guidelines-on-the-security-of-internet-payments

<evert> Strong customer authentication is, for the purpose of these guidelines, a procedure based on the use of two or more of the following elements – categorised as knowledge, ownership and inherence: i) something only the user knows, e.g. static password, code, personal identification number; ii) something only the user possesses, e.g. token, smart card, mobile phone; iii) something the user is, e.g. biometric characteristic, such as a fingerprint. In addition, the

<evert> elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s). At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the internet. The strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data.

evert: Every financial institution is a PSP.
... it does not imply a particular technology
... in PSD2 if you do not implement strong authentication as a financial institution, you are liable

<evert> Credentials mean the information — generally confidential — provided by a customer or PSP for the purposes of authentication. Credentials can also mean the possession of a physical tool containing the information (e.g. one-time-password generator, smart card), or something the user memorises or represents (such as biometric characteristics).

Adam: little interest in credentials

Nick: Similar view from Apple....I see financial institutions have a strong interest
... browser vendors have to support globally...but markets will differ globally

<nick_s> (NB: I don’t speak for WebKit, but I expect the position to be similar)

IJ: I am hearing no credentials for v1. But what about v2? What might be different then?

Nick: Need more international payments people in the room

Adam: Also, credential and authentication standards have been used and abandoned because of flaws
... it's a rapidly evolving space...the more tightly we define the more headaches there will be
... these are driven by business requirements...there are standards at the application layer, not built into browser.
... web payments are hard
... mobile payments are hard...there is value we can add

DavidE: I propose for the breakouts..it sounds like flow is really important
... my concrete suggestion is that we do flows in breakout
... and we take use cases and other topics to a separate space

<Magda> +1 on David's proposal

<adamm> +1

Ryadog: We have a long ways to go on credentials before we get there...what we want in terms of browser vendor involvement is enablement.
... we want to enable what's necessary

dbaron: Following up on the credentials topic: part of the browser view is what pieces are being used today and the question is what can we move into payments to improve payments.
... it's at least not clear to me why or how credentials work can be improved by the browser knowing things about it
... maybe that's a useful coffebreak conversation

<Zakim> manu`, you wanted to mention that the ask is not a browser vendor ask - it's a format and protocol ask from W3C.

<adamm> +1 david

manu`: I feel like we are miscommunicating....nobody has said browsers have to build anything into the core of the browser

scribe: my concern is that we table credentials entirely based on this misunderstanding
... there is a set of people in the room for whom this is important; it does not have to flow through the browser / native APIs

vishshastry: From a financial institution perspective, there's a recognition between what a merchant wants (get person through checkout rapidly) and bank need for strong authentication
... seeking this balance has led to complexities in the ecosystem
... it would be great if this group could evolve technology in that area.
... one area would be provisioning of data from a browser or device all the way to a bank
... giving greater confidence in the device where a request for a transaction started
... at a given point of time
... doing something like that might be a better way to manage the credentials issue
... I'm sensitive to the privacy issues
... but there has to be a balance between device as proxy for easing financial transactions

wseltzer: [Wendy introduces herself]
... I get to take back recommendations back to W3C for new work to charter as W3C WGs
... we also know that there are other types of groups like IGs and CGs
... one of my goals for this meeting is to come out hearing specific needs that go into rec track work for charters as well as where else should we keep our ears open for that work in the future
... there can be lots of productive work that happens outside chartered working groups
... that's a plea for thinking about where each of our items is phased...what needs to go into a web-wide standard and has the interest from all the people who would be needed to make such a standard work
... and which pieces are fodder for discussion or can be made a useful standard by a smaller subset of participants
... who can go and create it in a smaller space
... I hear one stream of payment architecture work
... I will speak later about several streams of security and authentication work (from here and outside)
... I hear another stream on credential work
... each stream has a different set of people interested
... breakouts could be a place where different clusters group and help us work through levels of interest and who is interested

erik: Bloomberg has its foot in both doors (both tech and financial services)
... I agree that many times the work does not belong in the browser
... is there a difference between web standard and browser standard?
... I think we should table credentials until we have a better understanding of what the needs are

<Zakim> nicktr, you wanted to say that given how much discussion of credentials we've just had, we should include it as a breakout if only to continue this argument

nick: -1 to breakout on credentials; we just had it

padler: I think that Mark said earlier that there is a big difference between how the credential data is created, and how important it is to pass the data within the ecosystem
... I'd argue for the payment flow discussion ...what information needs to be passed (in US, PSD2, etc.)
... we need clarity on what information is passed so we can do payments...and then we can talk about standards necessary to fulfill those needs
... and stakeholders may differ depending on the device, etc.
... if we standardize on the payments stuff first before understanding how the information is passed will lead to problems
... so maybe let's focus on message passing first

<adamm> adding comments to log:

<adamm> credential flow: issuance, revocation hardware identification: in a client/server connection, it’s hard to trust the client. based on what? hardware ids can be spoofed. even a tpm is a rabbit hole: how much do you trust the tpm chip issuer which is essentially a CA? What happens when someone at pwn2own breaks the chip implementation in everyones device? how do you know the presenter of the credential is the owner?

<nicktr> identity and the flow of payment credentials are fundamentals of payments on the web. if we don't progress these we aren't moving anything forward

Breakouts

At this point we have two breakouts: one on payment flow and the browser, and one on use cases. The minutes below are about the former; we reviewed the findings of the use cases breakout later in the day.

Payment Flow in relation the Browser

<dsr> scribenick: dsr

Pat: let’s start with discussing what people here want to ask?

Nick: I want to understand payment flows and how they differ

Pat recaps how the payment flow discussion evolved withing the IG.

Pat: everyone agrees that we want to narrow the scope. We ended up looking at what information exchange is needed at particular parts of the flow and how we could improve on today’s practices.

Pat presents a payment flow diagram (URL to follow)

He talks through the various entities used in diagram (shown on rhs)

A user on a merchant’s website, putting something into the shopping cart.

The website prepares the information needed to initiate a payment request.

Payers could push payments or respond to a pull request from the merchant for payment.

Ian describes the idea of a minimal set of information needed for a payment request.

Dan: what would be the benefits of standardising this?

Pat: you wouldn’t have to provide your credit card info to the payee

We’re looking at a standard web request

It’s a communication request

Ian: it is supposed to be abstract at this point

Mountie: the IETF has some proposals about the information needed

Pat: it includes information necessary to fulfil the payment to the payer.

<mountie> ECML v1.1 (Electronic Commerce Markup Language) from IETF

Dan: typically the merchant has a back end connected to a payment processor. The merchant wants confirmation that the customer has agreed to make the payment.

<mountie> another example with banking and push payment.

Sam: the diagram as presented could work with both push and pull payments.

Dan: there would be a risk if the merchant discloses their account details

Pat: this too can be tokenised

<mountie> Push Payment with banking service example

Sam: establishing the identity of the actors in a payment transaction is essential and this involves credentials

Dan: the merchant can provide a token that payment service providers can utilise

Ian: The merchant provides information on how it can be paid. The customer chooses how to pay. The customer involves a payement service to pay the merchant. The merchant gets a proof of payment. The merchant provides the customer with a receipt.

Pat provides further details of what happens in the background, and how the approach also supports push payments.

Dan explains how today’s wallet solutions work. The wallets have not taken off as the approach is rather cumbersome.

Vish: the approach presented isn’t how things work today

Pat: we started the diagrams to capture how existing systems work today.

We wanted a standard way to talk about things consistently across models

Vish: maybe push and pull are a little simplistic, but once merchants have settled on an approach, the cost incurred in setting this up creates a barrier to further change

Dan: indeed

Pat: one aspect of web payments is …

Joerg: we wanted to abstract from the details of how payments are processed and to instead think about what information needs to be exchanged

We should not interfere with how processing is actually done, as we want to leave that space free for innovation.

People here are very involved with the details of payment processing, but that is not what we need to deal with this here

The customer needs to understand what choice of payment instrument to use for this transaction.,

Mountie: we should add more context

Pat: we’re trying to step away for specific use cases and to instead identify the information that is minimally needed for a push or pull payment to be completed

Srikanth: how do you ensure that the payment authorisation only applies to this merchant?

Pat: this diagram abstracts away from the additional information relating to the transaction, e.g. terms and conditions on the sale of some goods.

Some flows may have strong requirements in respect to KYC/AML, others may not

Dan: the customer needs to know what he has to pay, and has to provide his confirmation of agreement to pay.

Pat shows another flow diagram

Dan: so you don’t need to cover routing numbers etc.,

Pat: right

Sam: there are existing players with a huge volume of payments, and there are problems with data breaches and liability

Ian: we want to model existing payment frameworks and not to replace them

Pat: to focus on the consumer, why do you have to use so many different payment techniques for all the companies you have to deal with

What can we standardise at a level of abstraction that overlays existing payment solutions?

Ian: the W3C work started with the question: what can we do to simplify the job of a web developer and giving end users maximum freedom for how they choose to pay

we want to lower the cost for developers and to enable an improved end user experience

Ian: I get that autofill of forms is an improvement for the UX, but what are the other pain points?

Dan: users have to authenticate themselves to their payment processor

Today, if users register with a merchant, the merchant can simplify the payment UX

The pain point is that merchants then have to store sensitive info at risk of breaches

Cyril: where is the step for authentication take place?

Pat: how do you the authenticate the device, how do you authenticate that the person with the device is the right person, and so forth

We get into the regular confusion over different ways that different players have used the term wallet.

Pat: we just need entities that fulfill the role of payment agents, we don’t care how they work, just so long as the info passed to the agent is standardised.

Mountie: we could move the wallet to the browser (?)

… talks about vending machines in China …

Pat: there could be a trust agent that facilitates things

Trust agents and payment agents could evolve in parallel

<nicktr> +1 that payment agent need not be the provider of identity - simply the container for payment credentials

Mark: conceptually the abstract flow makes sense, today everything is based on credit/debit cards and the model is heavily loaded on the merchant, you’re also seem to be requiring continuous connectivity.

<nicktr> but some level of ID is a precursor to the negotiation of the payment instruments

Mark: invoice is a very loaded term, and usually represents a commercial agreement, and I recommend you avoid using it for the sense you need

<mountie> token can be used instead of invoice. "requestToken"

Sam: I understand that the IG will set up WGs, including a payments WG. Is the goal of these diagrams to describe the scope of that WG?

Ian: the IG indeed serves to recommend what WGs are needed, We will go into the details this afternoon.

Sam: do we have a diagram that covers what the WG will enable for payment flows?

<mountie> UML Sequence Diagram is better

Pat encourages people to create diagrams covering their specific payment flows

Sam: I would be happy to go through Apple’s basic payment flow, and we like to talk about crypto and how trust is facilitated

… that has been missing from the current discussion in this session

<mountie> trust relationship between contexts can be established via PKI (in some countries) or blockchain network

Ian: I think we all want to do what you want, and need your help

Ian runs through the stakeholders in the IG

Sam: I don’t think the idea of having multiple wallets is a good idea

Ian: this is in part a terminology problem

Pat: we need to standardise the interface that avoids the need to have multiple wallets.

Joerg: I agree very much with Sam’s point

Katie: we have to support what’s there

<mountie> Banking example

Joerg: the flow diagrams were intended to be neutral

I want to make it clear to the end user what information is being passed.

Vish: the use cases makes it appear that you’re trying to boil the ocean, and you want be better off clarifying the pain points that you are aiming to address

Users should be free to choose which browser that they use on any device

Sam: you shouldn’t standardise the means to support multiple wallets.

DavidJ: I strenously disagree with Sam about "only crazy people carry multiple wallets"

Different payment instruments may have different requirements in respect to biometrics and so forth. We need to enable that not close it down

Adam: we should be addressing threat models for the payment flows

Pat: yes, that is valuable.

<Srikanth> Just in time payments and Returns are couple of things which are missing in the payment flows

Adam: ultimately it is very hard to trust devices

An operator cannot always be sure of the owner of a device

Joerg: trust is based upon establishing relationships through certain means

Ian: I will attempt to summarise for the session. I want to thank everyone for their input.

1. what standards that we need - what will simplify life for merchants and likewise for browsers

2. don’t use the word invoice as it is causing confusion to some

3. we need to understand the payment flows and please help us to realise this and to help with threat models

Ian wraps up the session.

Summary of Use Cases Breakout

DaveR asks people from the breakouts to post summaries into the minutes

Credentials are out for V1 of web payment standard. Registration-less purchases are in for V1.

Multifactor authentication should be in scope for V1.

<Ian> Nick: "Electronic confirmation" rather than "receipt"

Receipts are in for V1 for delivery of physical goods, and for ….

<padler> receipt as payment confirmation is similar to the feedback on invoices...

<wseltzer> Use Cases Breakout wiki

Retail industry will depend support for refunds/reversals

<padler> also... sounds like it might be interesting to talk about standard payment message codes... (Payment received, Payment Acknowledged, Payment declined, Payment Authorized, etc... ) it would be good to have a standard vocabulary for these...

DavidE: we will take up the glossary discussion on email

Evert: CRUD means create, read, update, delete

There are some diagrams for the capabilities doc

some comments on formatting the glossary doc

<AdrianHB> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesBreakoutSession

Security Next Steps

Erik Anderson presentation on security and wiki to help prepare this agenda item

<dbaron> ScribeNick: nicktr

<Ian>[Erik introduces guests for the security session Ron Parsons and Ed Schmidt from TecSec]

Erik: directs us to the capabilities doc

Erik: review of capabilities
... Identity, privacy and consumer protection - privacy clearly super important
... must be able to bind web and real-world identities
... Some regulatory env'ts require notification of users where their PID is accessed
... only minimal info should be disclosed
... Payment account providers should ensure that account identifiers should not be sufficient to reach "real world ID"

Ian: Can you help us understand what needs are being highlighted?

Erik: We haven't done a lot of work on this space yet. I'm telling the story from the perspective of the capabilities document
... some access is timelimited
... Role-based access may be required from a regulatory perspective
... Highlights from Fed Reserve Secure Payments Taskforce inaugural meeting
... 1. Controlling security risk and containment
... 2. Reducing fraud
... 3. Data breaches
... 4. Limiting access
... 5. High risk of emerging payment mechanisms
... 6. Privacy
... 7. Fraud alerts
... 8. No mention of digital signatures
... 9. Tokenisation is overused
... Key takeaways
... Counterfeiting of payment instruments is becoming nearly impossible

<Ian> Erik: Key theft a bigger problem than counterfeit

Erik: Theft of ID and credentials are the key enabler
... ID theft is increasing rapidly (25-50% pa)
... Credentials have long lifetime and therefore higher risk
... Current standards secure the network - but each node is also vulnerable
... If you use public networks, you need to secure each node
... So the only solution is E2E security
... Consumers don't use corrective financial protection mechanisms
... Fraudsters move to identity fraud as instrument security improves
... National concerns should align with international standards
... Keep costs low -
... The right security framework will allow internat based commerce to attain low transaction costs
... Framework must cover each components
... Existing standards
... ISO 20022 - no built-in security
... ISO 12812 - PArt 2 has many relevant compnents
... X9.69, .73, 119pt2, 122 all relevant - but 119pt2 only static tokenisation
... All this documentation should be available to all WPIG members via Bloomberg Impossible Mission doc server

Erik. these docs will self-destruct in 10...9...8...

Erik: Diagram (slide #9) - RHS indicates each institution tailors their own risk/cost profile
... Split your id into fragments which allows you to administer your own security/data
... What occurs on LHS is API for secure transactions
... Application developers shouldn't be exposed to crypto
... Financial Institutions do the hard work
... Software and hardware implementations both required
... TecSec are open sourcing CKM
... Provides a working example of how dynamic keys are generated

Ian: Purview of this group is the very topmost sliver
... what do WPIG need to do?

Erik: Yes - on the last slide

<mountie> what does it mean CKM?

Erik: Each key unique for each transaction - so breach horizon is 1 transaction
... Slide 13: Pseudo random ID bound to a specific institution
... Biometrics shouldn't be used directly
... Geolocation allows ID binding to location
... Time-based access also possible
... Token is bound only for a single transaction
... Legal/regulatory: ID is global but permissions local
... Onion model shows security layers on layers
... This stuff was built in the nineties
... what do we do next? Short-term - protect data everywhere. Mid-term: Poretect e-cash letters and improve card authorisation. Long term:
... Standardise security protocols
... Minimise the standards
... Proprietary standards don't work internationally
... Align liability to the party best-suited to prevent fraud
... FIs and merchants must accept consequence of fraud/sec failure - but this is misaligned to those who can fill the gaps
... For internet, put liability on users and merchants (so there is a motivation for users and merchants to select secure solutions)
... The browser has international penetration - very few other solutions do
... All the tools are there and have been around since the 90s
... Fraudsters are after static keys - short-term goal must be to protect the info

<Zakim> manu`, you wanted to be confused about next steps.

Manu: Lot to take in. Can we see 5 bullets to help us focus?
... I don't know what the next steps are?
... Are there suggestions?

<Zakim> Laurent_, you wanted to ask about scope

Laurent: So for me, there is one bullet - what is the scope of the security task force?
... Securing web payments is solving the security squared

<Zakim> dezell, you wanted to ask for clarification about X9.119-2

Laurent: I think we should only focus on securing the interactions between the actors. Question for the group - what is our scope?

Dezell: We can take questions about x9.119-2 offline

Wendy: <look of puzzlement>

Max (Bloomberg guest): Which info is going in and define an encryption scheme

Max: Don't use proprietary tech
... These go obsolete - everything can change
... Don't mandate specific schemes. be agile.

Wendy: We have a web crypto WG which has built an API to give standardised access to crypto from the browser
... We are totally into the mantra "build on standards"

Srikanth: In the long-term we still putting the liability on the merchant
... All the merchants are getting is an acknowledgement - why should merchants be liable

<Ian> [especially in the long-term]

Erik: It's all about aligning incentives

<Zakim> manu`, you wanted to mention a list of security needs that I think should be in scope.

Erik: It takes too much time for people to change

Manu: I want us to focus on message format and digital signature/encryption

Erik: I don't agree that signatures are required and it does not solve non-repudiation

Pat: Sigs and encryption are needed - it's not binary. Compound sigs also needed

Jake?: Digital sigs carry baggage back to CA

Jake: Better to describe them as electronic signatures

Manu: How do we encrypt the message channel - do we need more than SSl?
... authorisation and authentication
... tokenisation

Manu - this will suss out the technologies that we require

Adam: The liabilities are already well-defined. All of PCI is administered through chain of contract

Ron: Tecsec bringing new tech to the table
... Finegrained access, signed, all flexed re risk and cost

Ron: We are offering a connector that allows browser to generate the headers
... http, https, httpv (which avoid MITM attack)
... Take those pieces and make a security connector in the browser

@@@ Connectors that are not in the PCI domain like ACH

aylcwrc: the idea is to make a secure matrix so that everyone can operate and we can all dance like leaves on the wind

Max: developers should not have access to crypto APIs - should be abstracted
... Keep it simple. Minimise the number of keys
... Everyone screws up ("To Err is Human")

Jeff: We wanted to abstract the underlying h/w
... I like Max's idea of taking it to the next level

<AdrianHB> +1 to sticking to payments and not trying to solve security and crypto that is the domain of the payment scheme

<Ryadog> Web Payment API

Jeff: Is on the table with IP commitments?

Ron: Zero dollars/pounds/yen/BTC

Erik: One note: by putting security in an accessible manner including browser - secondary effect on other things (JLaw's photos no longer available)
... This is not just for payments. It is for all of identity.
... Tecsec solution is 150 algorithms. Institutions can pick and choose.

Group breaks for lunch.

<screen> - Define the information to protect

<screen> - Define the message format

<screen> - Define the lifetime of the data

<screen> - Use electronic signature not digital signature

<screen> - Tokenization mechanism

Review Roadmap for Standardization

<dezell> Ian shows the draft roadmap and draft payments architecture wg charter

<dezell> Ian: we want all of you to share your ideas on what should be standardized.

<dezell> Scope is minimum viable payment flow between payer and payee

<dezell> Ian: is this modest enough for scope, or can it be even smaller?

<dezell> Ian: a few other things - descriptions (a la vocabulary), alternate payment schemes, registry/discovery.

<dezell> Ian: ancillary features include RESTful APIs - proof of payment, invoice processing.

<dezell> Ian: we're looking for feedback.

<dezell> Evan: another input, just mailed a proposal for things in/out of scope for this proposed WG.

<dezell> ...: features or limitations of payment instruments are not really in W3C area.

<dezell> ...: some concrete examples: can we make "filling out forms" less annoying?

<dezell> ...: for another group, too many parties need to store information about a payer, and it needs to be solved.

<dezell> Evan: to clarify, many things we talk about are really problems with payment instruments.

<Ian> evan: place for interop is in how people provide data

<dezell> ...: I would argue that the relationship of a user to a payment instrument should not be standardized.

<dezell> Ian: what about the payment initiation with information blob (like invoice) to kick it off?

<dezell> Evan: would include what payment instrument(s) and amount.

<dezell> Evan: authentication, tokenization, active fraud prevention, and proof of purchase - all these are things that should be out of scope.

<Zakim> manu`, you wanted to mention that "vocabulary" doesn't mean "glossary"

<Laurent_> +1 to evan

<dezell> manu: "vocabularies" are machine readable, not glossary.

<dezell> nick_s: receipts are mentioned several times in various places. Are people really wanting to tackle this requirement for track 1? It's quite variable between countries.

<nick_s> +1 for adrian’s recommendation

<dezell> adrian: this predates the breakout on use cases, I would suggest we change "receipt" to "confirmation of payment" that would work better.

<dezell> nick_s: would be OK with that.

<dezell> adrian: output from breakout was "Optional link to receipt."

<dezell> Ian: so there are two things - initial proof of funds, and completion of transaction.

<dezell> Srikanth: we care about advance transactions and the finalization also.

<dezell> ...: the authorization (of funds) might be all we have for several days.

<nick_s> +1 again for adrian. It’s payment scheme specific.

<adamm> +1

<dezell> adrian: we shouldn't be trying to standardize the really large flows, and the individual local rules should be handled separately.

<dezell> dsr: there are concerns like this trying to formulate a global receipt. But people want a standard way to collect receipts.

<dezell> nick_s: we're all very interested in receipt formats. It's great that they could be used interchangeably for different purposes, but not for v1.

<Ian> Ian hearing:

<Ian> * support for confirmation of payment to both payer and payee

<Ian> * receipt format is not for v1

<dezell> adam: so people really just use credit cards and billing records. The receipt structure etc. is not important.

<dezell> important list: *identity of merchant, *amount paid, *date

<dezell> evan: I'll argue that we don't need a payment confirmation to be part of the standard. It's part of the payment instrument integration.

<dezell> Dan: agreed, but with one caveat - I think the items are useful to an end user.

<dezell> evan: I'll disagree, but I don't see the problem that it's solving.

<dezell> adrian: I think we have something simpler in mind - verification of payment.

<dezell> Srikanth: when we have one identification of that transaction, how is the receipt going to look at various points in the transaction?

<dezell> ...: what is the "identification" flow?

<wseltzer> ian: note the transition from merchant-side processing

<dezell> ...: how is the transition from "merchant side" to provider characterized?

<dezell> joerg: there is use in having a symetrical "start transaction" data and "end transaction" data.

<Ian> dipan: you do need ack of protocol completing

<Ian> ...but invoice more broadly is complex, too much here

<dezell> Dipan: I concur with Joerg. Receipts are very complex and I don't know that we have the right players in the room. Actional digital receipts are quite complex with international implications. Not to mention coupons, loyalty point use, one receipt, multiple receipts, etc.

<nick_s> +1 dipan

<dezell> ...: retailers and POS integrators are the people needed for this discussion.

<Ian> dipan: provide a hook!

<dezell> Claudia: are we closing on the definition we had this morning with a proof of purchase.

<dezell> ...: I'm not sure I agree that it's done by the payment scheme.

<dezell> adam: with added complexity comes added risk. For every new data element, there should be a rationale for each.

<dezell> ...: I have many receipts that I don't really need - they add clutter.

<dezell> ...: it might be good to have a receipt format.

<dezell> ...: but it's a whole lot of rabbit holes.

<Dipan_> +1 for Adams Law

<dezell> zach: it seems that payment doesn't originate with the merchant, even though that is the main way it is done today.

<wseltzer> zkoch: make sure architecture supports current processes

<dezell> pat: I think the architecture >does< support it, but new group members should look and way in.

<dezell> manu: we made it clear that both merchant and customer initiated payments are in scope.

<dezell> ...:(via use cases)

<dezell> pat: goals of the architecture are to support both.

confirmation of transaction message must cover payer and payee initiated payments

<dezell> pat: what is the "minimum viable receipt?"

in fact, all of the messages/components need to work for both initiation sources

<dezell> Note: charter must cover both merchant an payer initiated payments.

<dezell> Srikanth: we need to clarify the "receipt" vs. "payment confirmation" terminology.

<dezell> ...: regardless of which, there will be multiple players involved in any transaction.

<dezell> ...: and there may be varying security constraints.

<dezell> evan: my objection with payment confirmation. Personally, I'd love a cryptographically signed receipt from the payment instrument.

<Ian> IJ to srikanth: please write down the detailed intervention of various parties in the payment flow you described

<dezell> ...: I'm concerned that this kind of change is far reaching from somebody to have to conform to. We'd have to get VISA, MC, and everybody to provide a cryptographically signed receipt.

<adamm> +1

<wseltzer> evan: I personally would love to have cryptographically signed reciepts from credit cards, but I don't have Visa's public key

<dezell> adam: post/redirect/get pattern is an appropriate place for a yes/no response in the context of application logic, that doesn't require a complex response.

<dezell> ...: but defining any kind of response limits the usefulness.

<dezell> ...: where does the confirmation happen?

<dezell> ========

<dezell> jeff: I have a comment not related to receipts.

<dezell> (next)

<Zakim> wseltzer, you wanted to ask "shall we talk authentication?"

<dezell> wendy: Technology and society domain is where we might start this work.

<dezell> ...: we also have interest in next steps in secure authentication.

<mountie> +1 for payment confirmation. receipt need the purchased product and payment result. too complex.

<Ian> scribenick: Ian

wseltzer: Two groups in discussion
... first is FIDO-based
... we are discussing collaboration with FIDO where they could bring specs to w3c (as input) and work through our usual process.
... that's for multi-factor authentication and device enrollment
... and device capbilities.
... the other group in discussion is hardware based security: secure elements, TEE, smart cards, SIM cards
... where we want to leverage those capabilities for the Web, through defined APIs
... and make sure those fit within the web security model
... what capabilities can we build an abstraction layer for that would benefit the web
... discussions from Global Platform, Gemalto and others involved in smart cards
... both of these group charters are at the "preview" stage....only earliest phases of development
... we want to hear input, requirements, and statements of interest in the work
... to ensure that we are scoping it properly, especially for those requirements from the Web Payments IG
... what is needed? how do they compose?

<adamm> adding to my prev comment: for a web service, the payment acknowledgement would be in the http response to the rest call. the message could similarly be true/false or complex.

cyril: do we need secure element work via the browser? It's not the same thing browser v. hardware

cyrl: We have payment service providers connected to the merchant that are doing pull/push payments
... if the PSP is connecting tot he merchant, there's no issue between pull/push
... even if we think on the merchant side there is only pull, that's not the case, on the merchant side there can be both as well

wseltzer: On the role of secure element...we are looking at that as a services question - what services does the web want from hardware?

<mountie> with push payment, we can invite more payment participants.

wseltzer: if one desired service is "secure storage" what does the API look like? Are there limits on use? Is it origin-bound?
... so hearing the use cases (and what the desired services look like) help us scope a charter and work to build it to meet the web need.
... Meanwhile, web crypto WG finishing webcrypto API
... the webappsec WG is doing CORS, CSP, and other elements of support for web application security
... the TAG is also interested in security, as is the Web Security Interest Group (which looks at more broadly scoped questions)

jheuer: We should distinguish the "use" and "provisioning" stages
... e.g., we have implementation of a ticketing system....they can provide tickets via NFC
... the tickets sit in the secure element
... I can imagine communications channels to provision (or pre-provision) the hardware
... eg., to verify a ticket on the web
... I think good to distinguish provisioning and how you "use" the information that is stored.

wseltzer: We'd like groups to be moving by the fall.

manu: We don't have anything in the critical path for V1 re: authentication
... or do we?

padler: I think that a question is, for the message flows, that we will need a way to share info about the entities involved in V1 in a payment.
... but we may not need to standardize the collection point for that information in V1
... so priority is minimum amount information to be exchanged

padler: but I am struggling how we will make a payment without credential/authentication information
... the challenge is understanding that the message has come from a verified source.
... I think we need "hooks" even if we don't standardize everything in v1

manu: Are you saying we need to find a way that the merchant has signed a message?

padler: more what is the basic structure of the payment message, so we know where to find information.
... we don't want to lock ourselves in a single auth. scheme or crypto method
... especially given global scope
... I am less concerned about the details in the message, but more that the message construct allows us to plug in.

<wseltzer> to clarify, we're talking about end-user authentication

padler: we want to allow for evolution....we need v1 to have a notion of authenticaiton

adam: unless it were a wrapper (e.g., like a digital signature)

wseltzer: the authentication you are talking about is different from the authentication we are talking about...FIDO work is end-user client authentication
... and you are talking about authentication of entities sending messages in the transaction
... and there we can draw on existing standards for messaging and authentication
... if there are components missing from those existing things, we need to figure out what to do (and not reinvent CAs)

jeff: I don't know whether the payments community needs FIDO-style multi-factor auth in V1. But I want the payments community to pay attention to the work. Don't want the payments community to come around later and say "we need it but not this way"

<mountie> messages (invoice?) can be verified by recipient in various ways. do not need to standardize it I think.

jeff: I hope that the payments community will look at this work as it is being planned

Laurent_: I want to add my voice to Pat's...we want a placeholder for what a payment scheme would have to define on top of our work
... e.g., maybe we can add this to the document ... an example of what a payment scheme extension would look like to do a web payment

Erik: Hard to add security on later....

adamm: I agree. The placeholder is there. It's external to the message. If we want to design a standard, then I think a good approach is what we were doing - minimum standard necessary to design a baseline transaction and the rest is layers around it.
... as the message traverses the system, you don't have to predesign the layers of the software that unpack the data
... you want an extensible system so you can, e.g., get rid of a flawed authentication system....shed the external component and leave the internal parts untouched

dezell: I think the WG can work out the layering
... we can feed them the use cases
... but we should stay simple...and not tell them "how" to do it

<wseltzer> Ian: we'll summarize later

<wseltzer> ... wrt Evan't proposal: increase usability by making it less necessary to enter data (?)

Dan: I thought I heard these top-level things

- proof of purchase

- individual authenticated (either way)

- transaction authorize

scribe: and not a whole lot more
... some elementary message sets that can be accommodate and extended

<wseltzer> adam: define the simplest possible message formats and protocols

<Zakim> AdrianHB, you wanted to clarify a point in the scope

<padler> +1 to identifying users of apis... this was the intent of the pie diagram... namely in that it could illustrate who is sending, who is receiving.. and the specific type of interaction..

dbaron: (not in v1) but a site could send info to browser on how to handle payments, rather than the browser having customized knowledge

<dbaron> One comment in reply to jeff: we've had charters that have had optional deliverables in them.

<adamm> +1 jeff

<jeff> +1 to dbaron's point (in response to my earlier point) to include certain charter items as optional items

<mountie> think SSL negotiation.

<evan_schwartz> +1 to Nick's point, minus the payment confirmation

<Zakim> manu`, you wanted to say that there is a flow that has been implemented that supports registration.

manu: On registration
... one of the things we were concerned about when we talked about registration was vendor-lockin
... we want customers to be able to switch providers, we want people to be able to use instruments across devices and in multiple locations
... having a mechanism where your payment provider can associate themselves with you so that in any context you don't have to constantly sync devices together to make sure all payment instruments are available
... we don't want to create a system where you are locked into using payment instruments on a single device
... there are technical implementations of this that we could look at to see how this registration and sharing works
... so before we take things off the table in the names of complexity or clarity, we should look at work that's been done as part of deciding what to take up in v1

dans: Thought experiment...look at point of sale terminals historically....lots of merchants have processing systems...but thanks to standards, I can swipe a card and key information gets into diverse merchant systems

<nicktr> +1 to dan's comments. Note that part of that very basic "walk up to a terminal" experience includes the discovery of payment instruments in the selection of the AID (application ID)

<adamm> +1 evan

<nick_s> +1, note that some payment instruments that are stored locally can’t be synced easily, and they should be accounted for

<padler> synching is VERY important when the data concerned is a representation of value...

<padler> not just information (like passwords)..

<adamm> PCI DSS

<Zakim> dezell, you wanted to +1 dbaron characterization of a wp

<padler> +1 to specifying who the consumers of the APIS are and how the api's will help them..

<evan_schwartz> +1 to Adam's point that this is still an evolving space and it'll probably look a lot different in 5 years

Ryadog: Sharing/synching is a pain point

<Zakim> AdrianHB, you wanted to propose some changes to the scope (https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG/ScopeProposal)

<Zakim> jeff, you wanted to respond to evan about useful standards work for payments

<Srikanth> +1 Erik, We should still suggest a minimum required security for the payment instruments to be exchanged from the initiation to rest

<AdrianHB> For anyone looking for something to do this evening there is a free concert in Central Park by the NYC Philharmonic: http://nyphil.org/concerts-tickets/1415/concerts-in-the-parks-june-17

Do our use case changes affect our charter scope?

<Karen> Scribenick: Karen

Ian: proposal for how to run session is to look at use cases

…and make real adjustments to charter scope to see if we are on the same page there

…Do people have other recommendations to establish where we are?

…high level read of the room

…on the screens, left side is use cases

…right side is the original list

…Things marked originally at risk

…Will focus on what the break-out group did

…go through what they thought should be in first

…then begin to attack it

…Registration lists payments was considered in by the breakout

…no account is required to make a payment for some types of payments

…multifactor, payer initiated

…of at risks on right side, here is what we said

…Adding back payee and payer initiated

…consensus we should cover merchant initiated in the charter

…Delivery of physical goods

Manu: Idea that you can buy

…in version one, in previous list we said virtual only because it's easier to deal with

…physical goods is about buying a tangible item

IJ; Is addition of that use case changing the charter?

Adrian: purpose of use case is to consider that in the flow the merchant may want to get additional information from the payer

…like get the delivery details

IJ: not that it's bikes, but that some additional information may be needed such as shipping address

@: will that be covered?

Joerg: Should we name it more generically

Adrian: we could call it out more explicitly

IJ: just enough to do what is needed

weinig: when constructing…you can set address…one way to think of it

IJ: In payment flow we have negotiation of terms

…hearing that this happens in the negotiation of terms

…things critical for completing transaction

Jeff: Katie suggestions delivery details

IJ: Delivery details or something like that

Adrian: use cases in scope

…ordering physical goods, the requirement is addresses

IJ: electronic receipts

…acknowledgement of payment is what we were talking about

…confirmation is in for B1

Jeff: first level

IJ: subscription

…doing a one-time payment is easier than subscription

Adrian: two in there
... subscription and common refunds, stretch goals for V1

…a lot of demand

IJ: those are considered optional
... anyone who iews not stretch goals

nick_s: We consider subscription to be similar to brick and mortar physical details

Evan: with subscriptions, that sounds great; a request for payment, but more complicated

…merchant needs a way to request that

…but aren't refunds on the level of the payment instrument

…do we need APIs

Kate: Also the merchant and financial institution

Adrian: Was there a request for retailer

…difficult to get adoption if cannot match refunds to purchases

…if we ignore there will be a challenge

IJ: is that enough to satisfy the merchant requirement

S: [missed]

…at same time, subscriptions

…I think if we don't complete by then

scribe: that would be a challlenge

…subscriptions is a big industry

…no different from payer initiated transactions

Chris: a lot of pieces of refunds

…parts of that need to be tied to the purchase

…peel back the onion

Joerg: my question about refunds

…if we voted the receipt out of V1 and we need the approval of merchants for the refund, how does that work

Adam: in the design, first one was

…with confirmation

…not sure we are ready to decide if that is necessary

…don't think we understand enough to decide to pre-determine yet

…maybe for V1

…but for overall design of subscriptions, suggest we move to V2

…look at simple as possible, we have not designed it yet

…and look at more complex payment…feels like putting cart before the horse

<Zakim> padler, you wanted to discuss transaction context..

Pat: Comment on

….going back to February F2F

…they described economic transactions as a series of context…return of goods

…as part of those mechanisms, greater transaction context

…how to pass the receipt; how to reflect that

…not needed day one but need books for them moving forward

Magda: Agree with that

…several of hese things are termed in

…better to have in

…list critical path

<padler> +100!!! :D

…multifactor, including biometrics, subs and common refunds

Manu: updated list is on the right

…is on V1, including the stretch goals

Mountie: want to identify user

…not so common

<Zakim> dsr, you wanted to keep commercial transaction and payment transaction weakly coupled

Dave: Adding to what Adam said, I like clean separation, architectural layer

…we talked about commercial layers

…and payment transactions

…need a minimal coupling

…refunds, disputes, taxation

…I understand we need different stakeholders

…how do we keep the minimum coupling to do the work

Zack: i talked yesterday about our learnings

…request auto complete

…what we did

…we did not pass back credit card numbers to the merchants

…we passed back proxy cards

…We learned that was a big blocker for impemetnations

…biggest reason for lack of adoption was subscriptions

…auto complete

…want to throw it out there

<nick_s> +1 subscriptions

<Srikanth> +1

<padler> For those that were not at the Utrecht meeting, here is the link to the FOCAFET information referencing Economic transactions...

David Ezell: Any relationship to V1 and 2017

IJ: We should determine deliverable dates once we know fully what is in the charter.

IJ:…and figured out our activities

…and divvied up among charters, we will have the time

…but longer it will take if one group does one spec

…if we break it out, like security groups in parallel

…proposal is to charter group for two years

…i did hear the sentiment

…here is V1, very tight and agile, and low hanging fruit, but it will take to 2017

…I don't think those two should be planned

Jeff: David asked a good question about schedule

…maybe not the case we can figure it out in a large group

…to get to any schedule, we have to learn how many people are willing to put time into things

…there is real work to be done

…If there is a dedicated team, we can do stuff in a year

…but it could take longer if people cannot dedicate as much time

…we have 42 orgs in this IG

…find out about resources across this community

IJ: I would like to go through this list

…and see, yes, if that is what we would like and try to map them to the charter

Ryadog: not revote on what we have voted on?

IJ: Not everyone knew what these things meant

…is this what they are doing?

…do people know what these short keywords mean?

…Any thoughts on right screen; is that what we are doing for V1

Katie: Minus credentials

IJ: Seeing no questions, can we see a show of hands of support for V1

[Ian counts hands]

ij: 27

…are there objections to this group to V1

…no objections

…now we can map to the charter

<Magda> *mentally cheering *

IJ: exercise is to figure out where things go

[Scope section]

IJ: Web site is meant to say discovery is meant to happen in browser; do same instrument

…Registration-less is … not sure that impacts the draft charter

Manu: It does, we minimize it to mean you should be able to buy something without creating an account on a web site

…may have to fill out some information, but not have an account

IJ: Not including that question

Katie: it includes this

IJ: draft charter doesn't take this into account either way

…by including registration lists, we are not implying any change to charter

[missed]

Katie: Are we trying to determine which use cases fit under one of those four bullet points?

IJ: Adrian's tweak for what fits into a Working Group

…the things we would like to be in is the charter prime

…taking into account comments from the group

…not changing anything

…in the charter

…finding out what changes to charter are needed

Katie; Stick a number?

IJ: Not sure it maps directly

…one-time payment

…Ubiquitous schemes I believe is taking into account existing and future schemes

…not all-inclusive

…not clear in draft charter

Manu: Schemes that are widely deployed

IJ: Like some systems like cards

…so we have to include merchant initiated schemes

…and these are subsets of that

…Discovery; I have lost where we were

…on the mood of the room on registration of payment instruments and discovery

[reads from document]

Adrian: Can we distinguish between discovery and registration

…we want to mandate if you are confirmant to spec, you allow any scheme to be registered; that was my understanding, but not standardize that process

…that is pre-payment

…Discovery is some form of negotiation of a common scheme

…to describe the payment schemes available

Manu: Discovery has to do with you having multiple digital wallets on different services

Adrian: That is payer selection

Manu: But it is labeled discovery in the document

Adrian: why is that discovery

IJ: My understanding is that the user shows up

…installs the BOA thing, and I can have it

Adrian: my understanding of workflow differs…selection by the user

IJ: that's good

…asynchronously I show up and it's known to the system; in browser

…then when I go to pay a few days later, the browser can discover and invoke it later

…then I select from among

…register, invoke/discovery and then choose

Adiran: Discovery is some scary stuff

…vs payee making the selections

IJ: browser helps in finding the intersection and invokes…

Manu: not what the use case says

Adam: Should operate in a way that it's user choices; no automated discovery from merchant

Joerg: You are talking about refinement; register every schema; whether done by browser or operating system

Jeff: we are trying to match undefined words on right with undefined woods on left

…one of the exercises that needs to be done

…not sure if we can do all the details with all of us together

…but we need to get clear definitions of each step and the use cases and define what the terms mean

…we can surface issues, but not sure we can resolve

Manu: we should understand use case work and flow

…we have done that

…no time to rehash it now

…then for specifically for the discovery use case, to clarify we should use the text in the use case first

…versus trying to derive what it means

Jeff: for 6.2.2, what is the verb? What do you do?

Manu: assumption is that when provided multiple options, and choose from among them

IJ: that process is described higher up in the document

…Looking at these, I sense it's largely covered

…some have to do with terminology, some around clarify

…multifactor covered in a different WG charter

…subscription is a stretch goal

Adiran: We will need to change something in scope to handle that; second bullet says pay and payer on one-time purchase

IJ: Virtual goods and physical goods is about delivery

Nick: not sure

IJ: this broader context of ecommerce vs narrower focus on payments

…this charter seems narrowly focused on payments bits

…in charter should we give more context to help people understand where we are coming from

…the bigger sense of receipts and invoice

Pat: Goes back to something

…Evan said on break

…what we can do now is thinking about the broader economic transaction to specify placeholders in V1

…they have to be there so as pieces emerge, we don't have to completely rewrite the transaction message

…if we can define some of this, we can let go of details

IJ: Can you as architecture guru, capture somewhere, like capabilities doc, or elsewhere

…and to what extent there are regulatory hooks

…so we can add into charter as needed

Pat: yes, I will

…and for group's benefit, if we can get a consistent skeleton for message, we can use whether it's an international transaction; makes it easier for hardware vendors to standardize

IJ: Pat needs help

…to write up a skeletal structure

Adrian: That is WG work

Laurent: Where do you propose to do that?

ij: …Adam said how to layer architecture; great if you would write out the layers you have in mind

…charter says it does

<scribe> ACTION: Adam to write up architectural synthesis of what he is thinking [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action01]

<trackbot> Created ACTION-110 - Write up an architectural layer synthesis of components of the web payments stack. [on Adam Muntner - due 2015-06-24].

IJ: I don't see anything else requiring substantive changes

Magda: might...

IJ: Some identifier common between payment request and confirmation to satisfy the refund thing

…just need to know this is the same things as that

Laurent: rephrase as refund request

IJ: either an annotation or referring to refund request

Magda: I defer to the retailers

Adrian: Sufficient there to...

…we have examples of what is in the payment requests

…can I put in transaction type?

…that is how it is done in @ today

…purchase type or it's refunds

…when you do a card transaction today

…when you get your payment request document

…in that payment request I want it for this transaction type

IJ: Retailers are nodding for transaction type

@: for acceptance schemes

…might not initiate refund, as long as there is an acknowledgement

…of payments, but could be more clear on the structure of the message

Cyril: Payment report is @ 14

…description of everything

…full XML description of payment instruments

IJ: Vocabulary or data fields

Cyril: everything used in ISO22

IJ: Can you write references into irc?

Cyril: yes

IJ: sounds like next action is to modify the charter

…Adrian, can you continue to make the edits

Adrian: I added in discovery of instruments that can be used as intermediary step

…updated dated in payment request

…that's it

IJ: there is a wiki with the original charter with concrete deliverables

…don't know how these changes affect the concrete deliverables below

…do they affect?

Adrian: I think they do

<scribe> ACTION: Adrian to create revised WG charter [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action02]

<trackbot> Created ACTION-111 - Create revised wg charter [on Adrian Hope-Bailie - due 2015-06-24].

IJ: Jeff said we should say how this is going to benefit different audiences

…would we get buy-in from people in this room because it improves interoperability of payments

<CyrilV> here is the url to the pain 013 (payment request) and pain 014 (payment report) http://www.iso20022.org/full_catalogue.page

….I see some nodding

DavidEz: creating a payment request sounds like half job

IJ: these bullets constitute a flow

…there are other bullets to be done

David: Ok

IJ: One thing I would be happy to work with people as part of the Comm TF is to get a clearer articulation of what we are trying to do

…what are you doing; how is this new; what is it going to look like

…Is there anyone who is keen on the expression on the broader audiences

…Help me with a one-pager to explain how to make things eaier

…Manu, Arie, Claudia

Jeff: Anyone with a past comm role?

Erik: and anyone who is good at it?

<scribe> ACTION: Ian to work with Arie, Claudia, Manu, Srikanth and Zack on communications [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action03]

<trackbot> Created ACTION-112 - Work with arie, claudia, manu, srikanth and zack on communications [on Ian Jacobs - due 2015-06-24].

Jeff: that is a great selection of names

…with representation from all the bases…browsers, banks, merchants, etc.

IJ: if someone with visual skills, would be good to have a chart or visualization diagram
... maybe Pat could spearhead that

…anyone who could do the visual flow descriptions

…that would be a nice set of materials to give to the membership to support

scribe: David, Laurent, Adrian, Srikanth

Srikanth: clarify contribution...

…I will do what is working today and how we want it to work

IJ: Does someone want to take the lead?

…Yaso will take lead

Pat: We are going to have people reflect that part of payment system

…that feels like next step

…first to understand the flows and then do others for marketing audience

…maybe a higher level for others

IJ: for AC?

Pat: depends upon the audience

IJ: My thought is it is more flow oriented to help people understand the charter

Pat: for WG to consume

<scribe> ACTION: Yaso to organize a flow diagram conversation to produce what is supported by the charter [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action04]

<trackbot> Created ACTION-113 - Organize a flow diagram conversation to produce what is supported by the charter [on Yaso Córdova - due 2015-06-24].

IJ: Thank you

…Sounds like a nice foundation for where we are and what is next

…Dinner is at Fusha (sp?)

…6:30pm

Presentation on Apple Pay

<Magda> https://developer.apple.com/videos/wwdc/2015/?id=702

Nick: demo of payment flow

…last week is first time we talked publicly about Apple Pay which is in the presentation

…we have seen many apps with Apple Pay, more high value transactions, greater growth of transactions using inApp

…can see that in the deck

…talking about payment flow

…Apple Pay works with a secure element [scribe missed something here]

…See in web context, how this would work

…if you did not have PayPal, you can divert the checkout

…If Apple Pay is available

…you can display it

…ask if touch ID is valid

…some stuff happens here

…secure element and touch ID

…are encryptographically paired in factory

…we can still guarantee that it's not been tampered with

Katie: live finger print?

Nick: yes

…So the secure element creates a cryptogram

…we support a full EMV format and code 3DS

…because you send it over 3DS rails

…difference between Apple Pay and others is we have a slightly different method for running it

…two options

…this gets encrypted and goes down to our servers

…We don't trust the transport

…so you have to create a merchant identifier

…and a certificate you give to us and we re-encrypt it

…only merchant can do it

…encrypted by secure element

…this bubbles back up through iOS and delivered to merchant

…most support Apple Pay

…people make payments and it runs through the normal rails

…that's kind of it

…the flow I described just now maps somewhat to what we have been talking about at this meeting.

…We have a payment request

…describes payment you want to make

…confirmation, we return a confirmation to merchant with this cryptogram

…we sign the payment, you go off to process it

Katie: what do you feel in this chain is where you have the highest level of vulnerability?

Nick: very good question

…we would probably say in this chain it is where you send the cryptogram back to our servers to be signed

…not a huge amount of vulnerability

…it prevents merchants from taking a token and charging it

…the underlying data has already been encrypted

…But you might have realized you are sending to iOS before you encrypt

…We sign and encrypt with a secure element

…We are never sending ....

<Magda> For Further reading and learning: https://developer.apple.com/apple-pay/

Katie: encrypt and re-encrypt

…I think the process is one of the more secure out there

IJ: When we are coming up with charter, what are the implicit security requirements in our notes

…encrypt this in our requirements, so these things have to be tamper proof

…that suggest technologies or protocols

Katie: and a viability of where the secure element

Nick: We are not proposing this flow for web; it's for Apple Pay
... ApplePay owns the stack from application through OS

IJ: If we want to create a secure flow, I am hearing you need confirmations and so on

Nick: A token anonymizes the payment information

…I don't want to put Google on the spot

…Android pay is similar

scribe: one of big differences is that Android provides a pure token system

…if it was intercepted over the transport, there is no embedded information

…We encrypt with token ID

…ultimately, looking at security and advice we would give

…it's not enough to trust the transport, you are encrypting your own data

Sam: Hard to do this in a web context

…one thing we are able to do

…because we established relationships with merchants, we can get merchant public keys ahead of time

…at no point do we have to trust that channels are not compromised

Sam: Good question, that does not exist

…similar ideas are certificate authorities

Nick: Android pay, based on documentation

…you can integrate directly with payment processors

…Stripe and @

…you can ask Google to send you a stripe token

…kind of a solution to that

…our flow relies on merchant having registered with us ahead of time

…that may not be ideal for the web

…merchant may not want to do that

…we do it for control

…allow additional security and revoke identifiers and bad actors in the system if someone is harvesting tokens

…This is independent of the standard

Adiran: how similar this flow is for what we envision for the Web

…if we replace iOS layer with the web context

…looks similar to what we are proposing

…that check-out is what we call a payment request

…Only thing I would say is this is merchant authorized

…flow to Apple Service, if instrument specific; maybe send a proof of merchant payment

Nick: reason it goes to merchant is that Apple mainly deals with credit and debit cards

…there is something similar to what you are talking about

…payment gateways

<Ian> Nick: Stripe, Braintree, first data, authorize.net

…that offer device side SDKs

…merchant often never gets any of this data

…get to step where we generate cryptogram…payment gateway sends back to device

…merchant never sees any payment information; an implementation detail of this system

…coudl go straight to the user

…I think it's similar

…device does its thing

…discovery is a big difference

…we have API

…allows us to query types

…to discount

…on web side, having a discovery scheme, you want merchants to offer up front what they are prepared to offer

…a few differences

…go off and make a pyament

…there will be some schemes

…replace the secure element with PayPal

…then there is no token coming back to the merchant

Adrian: maybe they don't need that

Nick: nothing to prevent browser from adopting this

…additional protection in apps environment

Adrian: it feels a lot like the existing implementations

…informative references for what API should look like

…Apple Pay, Android Pay may not be that much different; perhaps a proxy to the Apple API

<Ian> scribenick: Ian

<Karen> How we handle contact and shipping information?

Nick: when merchant provides payment request
... they can also ask for information they need (e.g., shipping address, email, phone)
... the merchant does not at this point know shipping cost (depends on destination)
... we don't release the full shipping address
... we display it on a sheet but don't release until touch id
... what we actually provide apps before the touch id
... is we obfuscate the shipping address
... we provide just the zip code and city
... this allows merchants to estimate shipping
... they tell us that's not enough in the US especially for tax
... in the UK it's a single tax rate...but in the US the tax rate can vary by zip code
... another interesting difference with android pay is that we always make you touch id
... android pay has more of a consent-based model where you can delegate after the first time

<Zakim> Ian, you wanted to ask whether we need to have public keys to secure our payment data?

<Karen> IJ: we have 5-6 people in queue

<Karen> IJ: I was curious about this public key registration thing

<jeff> Ian: Is the added security you would get; make it a great feature for the web?

<jeff> ... "if you have public key - we'll do a better job encrypting"

<jeff> Nick: Merchants would say it is more painful than card number

<jeff> ... Target has implemented

<jeff> ... I don't think it is too hard

<jeff> ... But a centralized key for the web is not great.

<jeff> Sam: This was a decision made by one company

<jeff> ... but TLS and HTTPS are secure channels

<jeff> ... people should be happy with that

<jeff> ... let's not denigrate TLS

<jeff> Ian: I was not suggesting centralization

<jeff> ... A user might want to use 1:1 with merchant's public key

<jeff> ... if supported by browser

<jeff> ... merchant is happy

<jeff> Sam: You could pass along public key with payment request

<jeff> Srikanth: 2 factor with RSA is an option

<jeff> ... can instrument consumers

<jeff> ... get entire payload sent to server

<jeff> ... I don't think it was painful to support ApplePay

<jeff> ... payment networks helped

<jeff> ... pain points: tax changes, reauthorization, returns

<jeff> ... unclear - can we store and reuse cryptogram

<jeff> Nick: Cryptogram depends on brand

<jeff> ... "tokens disappearing" is an EMVCo issue

<jeff> Cyril: ApplePay is mainly a wallet for users

<jeff> ... then you add relationship with public key, contractural with merchant

<jeff> ... three corner model

<jeff> ... to put it on the web it will be hard because Apple Server could be split - Merchant payment service provide and user payment service provider

<jeff> ... But it is harder if these are two separate devices then incorporated into AppleServer

<jeff> Nick: We don't propose this for the web

<jeff> Cyril: The merchant only has token (not card number)

<jeff> ... so token is inside the secure element

<jeff> ... prefed?

<jeff> Nick: We have a security white paper (IOS security)

<jeff> ... IOS cannot query secure element for that information

<jeff> ... even if device is compromised.

<jeff> Cyril: Where are the flows that get the token inside the secure element?

<jeff> Nick: Magda will post link to video

<jeff> Erik: Use PKCS-11; chained together keys

<jeff> ... use a key to encode merchant's private key

<jeff> ... vulnerability only gets to outer key

<jeff> Nick: Somewhat. Merchant key is entirely separate.

<jeff> Erik: To rekey the system.

<jeff> Adam: Mozpay is totally different. Only for virtual products.

<jeff> ... similar approach w/o hardware element

<jeff> ... sign JWT (JSON Web Tokens)