Web Payments Interest Group Teleconference -- 03 Feb 2015

<trackbot> Date: 03 February 2015

<wseltzer> Meeting: Web Payments Interest Group F2F, Day 2

<wseltzer> Day 1 minutes

Welcome

<wseltzer> Erik: Today's main topics will be payment agent and to start on roadmap

<wseltzer> ... idea of discussing payment agent is to give us a lens for viewing the use cases

<wseltzer> ... not yet an actual architecture

<wseltzer> ... it's up to you to tell us when we're wrong

<wseltzer> scribenick: wseltzer

David: [recap of yesterday]
... We reviewed some outside resources -- not all
... reviewed use cases. Necessary but challenging
... Today, we want to talk about straw architecture
... speaking as a WG member, I've never thought we'd replace X9 or ISO 20022
... but think about way technologies fit together with the Open Web Platform
... other W3C values, universal accessibility
... We're the steering committee

<scribe> Agenda: https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Day_2_.28Tuesday_-_Start_9:00_Local_Time.29

David: We'll see Joerg's demo, then talk about user payment agent
... Afternoon, we'll look to use cases+architecture => roadmap

<AndersR> Related to payment agent. W3C WebCrypto.Next went belly-up yesterday

David: IG publication of FPWD will help show the rest of the world what we're starting
... Roadmap give us a starting point

<Zakim> m4nu, you wanted to recommend we look at payment phases from the agenda yesterday

m4nu: Can we talk about phases of payment process?

Joerg: I planned to run through the wiki page briefly
... first, a quick demo
... then go into phase model, to connect with use cases

David: Time-boxed discussion of payment phases

Payment Phases

https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Afternoon_1

m4nu: breaking down into the steps that any software needs to complete for a transaction
... group could add/remove decide we don't want to deal with some
... 1. Offer of sale
... 2. payment initiation. e.g. customer on-site finds something they want to buy. invoice-generation
... 3. jurisdictional and regulatory controls. fuzzy area
... pre-purchase, e.g. regulatory reporting for authorization

4. proof of funds

scribe: Delivery of Proof-of-Hold / Proof-of-Funds/ Proof-of-Purchase / Digital Receipt
... this is out of the hands of the customer and merchant
... 5. payment clearing
... 6. refunds/reversals

david: that's not really a step, but an aspect

m4nu: what does the group do for each of these stages?
... maybe nothing, maybe something

jheuer: Important aspects of the process. Not all are steps, but some are framing.
... offer of sale may be a thicket. for Payments, we might want to start with payment initiation.
... shopping experience may be out of scope, unnecessary for "payments" work
... so I'd start with payment initiation, take out jurisdication, possibly talk about credentials, then delivery of digital receipt
... not sure we need to go deeply into processing now / as w3c

CyrilV: we may need more detail
... describe the actors participating in these steps
... notifications

<steph> +1 to detail the payment processes

CyrilV: for me, it's a 3D description, but after we describe the process, we can apply it to many kinds of payment

Chaals: take offer of sale off the critical path

<evanschwartz> +1

<mario_de_armas> +1 remove offer of sale from the critical path

<evanschwartz> +2 actually

dezell: we probably need a subsuming activity, "web commerce," but offer is probably not part of "web payments"
... appears in the use cases
... second, this seems to be missing the value-add

evert: I'm mapping this onto the diagram

<Zakim> stefb, you wanted to ask for a dedicate slot on push-based payment

steph: should we have a deeper discussion of push-based payments?

dezell: I'll put that on the parking lot list

Laurent_: +1 to start with payment initiation
... re 3 or 4-corner model, focus on the delivery of proof of payment
... so here, we should be careful to support both models
... so focus on payment initiation, delivery of proof

<Zakim> evert, you wanted to say VAS is not yet covered

evert: +1 to add step on value-added services

<Zakim> NickTR, you wanted to ask if q+ establishing the id/credentials of the parties is a precursor or part of this process

NickTR: establishing the id/credentials of the parties is a precursor or part of this process?

jheuer: payment agent I'm going to show offers one posibility, but doesn't require specific position of the identification

NickTR: proofs may differ depending on identification
... "from check-out to check-in"

m4nu: put it in payment initiation

<dezell> ack mario*

[wseltzer says credentialing should include possibility of un-identified use]

mario_de_armas: you might provide credentials one time, then not have to repeat

<Ian> [IJ considers that "one time credential provision" is an optimization of "provide credentials before payment"]

mario_de_armas: instead of talking about txn flowing across consumer to network to merchant, talk about the data that's flowing

<jheuer> Proposal: layer the steps: One for the whole transaction, and an optional recurring presentment and processing of individual process steps and credentials

mario_de_armas: think about the data flows more than the particular parties

padler: list reminds me of a slide from the FOCAFET deck

<Joseph_Lubin> Joseph_Lubin is Joseph Lubin

padler: once we get the list, we'll need to prioritize
... what requirements will we have on the recipient of the payment? Payment receipt?

<dezell> dezell: "throw" and "catch" have a rich semantic here.

padler: think about on-ramp

<Zakim> padler, you wanted to suggest that this reminds me of FOCAFET materials

Erik: these steps don't match the industry standard
... lots of these things are already documented; let's use their words
... industry has many diagrams; let's normalize

dezell: do you have a specific pointer?

Erik: I can provide those

<Ian> [+1 to sending us diagrams ]

Erik: we're only 5% aligned

<Laurent_> +1 for sharing diagrams

steph: which diagram are we talking about ? we don't need the same steps as e.g. interbank transfers

Erik: business processes don't change too much with tech

[on screen: ISO 8583- Business Processes]

Erik: We should augment the diagrams, not replace them

CyrilV: 8583 is not industry standard

dezell: these are the kinds of business processes

<padler> +1 to Stephans suggestion that we need to come up with an additional layer that interacts with Payment layer...

CyrilV: 20022 is another standard. maybe we need a part that's link to the Web

<steph> SCT: credit transfer? sdd: direct debit ?

CyrilV: the card system is not the only system

dezell: fair enough.
... let's try to sidestep the noise between US and European banking system terminology

Erik: payment initiation is not a step, it's a series of steps.

<Ian> +1 to concrete proposal

Chaals: Concrete proposals for change are helpful

jheuer: instead of alignment, embrace
... you need to support legacy, but not adopt their processes

padler: as we discussed at first meeting, need to choose the scheme at the beginning of hte payment
... we need to layer on top of whichever scheme used

<Zakim> dsr, you wanted to note that Manu’s framing omits coupons etc. as a step before payment initiation, but one that involves the payment agent/wallet

dsr: framing omits coupons etc. as a step before payment initiation, but one that involves the payment agent/wallet

evanschwartz: 2 most important things: choosing scheme/mechanism
... second, using the web to improve clearing and settlement. I'd like to talk about a task force.

jean-yves: payment initiation has important step, consent to payment

<CyrilV> 8Q?

jean-yves: EU regulation will apply to requesting consent, giving consent for payment
... VAS is on the side of purchasing, not payment
... are we confusing two kinds of payments?
... existing industry standards
... ISO 20022 is compulsory for EU payment service providers
... check if world-wide web compliant
... Delivery of information, whether before or after payments
... shouldn't we have some info functions?
... can come at different places in the transaction
... legal requirements need to be a parameter

jheuer: ... support a new tf on processing
... I'd propose layering: 1st describing the transaction, usually by the merchant
... inside, a loop of iterating steps
... which could include different kinds of transactions, e.g. loyalty cards
... thinking from experience with proximity cards

Ryladog: regulatory steps, including logging, reporting, auditing
... ensuring user control before commitment step, thinking about WCAG2

<m4nu> USE CASE: Logging and auditing for the purposes of jurisdictional controls.

<Zakim> evert, you wanted to say that 8583 and friends define interface messages between actors to fulfill the payment steps we identify

dezell: please write a use case

evert: if we get to a minimal model, we'll get steps between actors, that will need to be mapped to several standards

<chuckles> [user confirmation sounds like a (possible?) step - in support of "user knows what they are payiing when they make the payment"]

<chuckles> USE CASE: Logging transactions for users who want to know where their money meant [like cheque book reconciliation]

evert: should we ask payment processors to support a number of APIs that support use cases?

<dezell> david: +1 to the idea of identifying actor(s) in each step.

<chuckles> [+1]

<Ian> (This corresponds to my comment from yesterday that I would like to have all the roles + verbs + data exchanged clearly written down)

CyrilV: Identify actors

[break: return at 10:50]

<dsr> scribenick: dsr

we resume after the morning break.

David notes that this demo is to introduce ideas, but nothing is baked, so please keep that in mind.

Payment Agent

Demo by Joerg Heuer

<CyrilV> http://www.iso20022.org/payments_messages.page# for dowloading xsd and PDF of explanation of messages delivered by ISO 20022

The demo involves a smart phone and a tablet. Joerg sets the scene. Some years back at Deutsche Telekom, his team started to explore what could be done with NFC, SIMs and the metaphor of cards for payments.

The smart phone displays a list of cards, discount coupons, loyalty cards.

Joerg notes that the demo in implemented in HTML5, and is inspired by the infocard idiom.

Picking a card is easy for users to understand and better for consent that alternatives like opting in and out.

A web page includes a graphic for a discount coupon based upon a JSON object.

Tapping on the coupon transfers it to your wallet.

Later when buying some products in a store, when you decide to buy, the wallet asks if you want to use the coupon you got previously.

The next step is to tap the phone to the point of sales terminal (represented by the tablet).

The user experience is very important to get right.

Chaals: the basic thing is that the merchant is talking to your phone, whether this is via NFC or HTTP doesn’t really matter.

Joerg: when we heard about NFC based payments, we were surprised that no one had yet included support for coupons and loyalty cards. When we created the demo, we got very good reactions.

Ian: how did you get the wallet on your phone?

Joerg: one answer is that I installed the app from an app store/operator etc. If you have the payment solution on the SIM, this necessitates the involvement of the operator.

Nick: can you provide a reference to the GSMA recommendation?

Joerg: yes

Chaals: if I have a wallet on my phone, I could conceivably do some steps to add my card to my phone. The phone can talk to the merchant to see which payment solutions the merchant accepts and then ask the user to select between them.

Joerg: we haven’t done this just yet, but yes, that is the general idea.

Joerg demo’s the use of a coupon which appears on the tablet (the point of sales terminal). The phone shows a list of transactions, green for success.

In this case that payment has been made and the coupon redeemed.

Joerg: we would like to maintain a log, where this is legally permitted.

Once you have the history, users want to see a what a given card has been used for.

Joerg switches to a online purchase use case. He starts by loading a web page on the smart phone, and selects the option to log in with his wallet.

Allowing the app to know about the wallet has privacy implications and would require the user’s consent.

The login may involve picking a card to act as a credential, and in principle, may involve a PIN or finger print scan etc.

Joerg: when you get the wallet for the first time, you would usually be asked for a user name and password as a means to get a club card for the online store.

Android handles the asynchronous notification of the “delivery” of the club card.

Manu: I have a question about data formats and protocols used to handle the process.

… What’s sent over NFC, what’s sent over the Web, what APIs, data formats and protocols we need to standardize?

Joerg: if this approach is adopted, DT would help with that work.

… I hope we can find a home for this sort of approach, and we’re talking with Mozilla ...

Manu: is the exchange over NFC the same as over the Web?

Joerg: absolutely not. We want to use the existing standards for each context.

<Zakim> m4nu, you wanted to ask about the messages and protocols being used.

Joerg: if there was one way to do things around the world, that would be great, but we need to allow for the differences.

Chaals: what you have is a fancy password manager that actually interacts.

Joerg: we have an abstraction for secure storage.

Chaals: in theory I could put in a card for my facebook account, right?

Joerg: yes.

<dezell> ?

You could be an issuer for the cards that you control.

… It has broad scope from things requiring low security to things that require really high security.

Joerg describes a scenario with a PC. The app creates and displays a QRCode on the PC screen which you can scan with the phone to invoke the wallet on the phone.

The phone can then authenticate you to the website for the app on the PC.

<Erik> NOTE: Very important. Cross device and on device use cases for payments

Joerg: this could support card present transactions using the card in the phone.

… We are agnostic as to the communication technology e.g. NFC or Bluetooth.

YY: FInancial institutions may want to create their own UX skin.

Joerg: yes indeed.

<Ryladog> USE CASE: customised (e.g. branded) UI for payment instrument found in the "wallet"

Laurent: is it really necessary to tie authentication to the web site to the payment experience?

<Ryladog> Additional info for USE CASE: Financial providers or merchants could provide their own skin for the PA

… some concerns over privacy and what info is made available to the merchant.

Joerg: this is all about UX that enables people to easily understand what is happening at each step.

I think this approach is a good fit for what W3C could standardise.

Consider what I have done as a strawman for consideration (points to the figure in his presentation at TPAC2014).

This involves a modular set of plugins for different cards.

The wallet is controlled by the user, and the cards by the issuers.

The approach works when the device is offline.

<sboyera> :nick steph

… Some features however, may require the device to be online.

Stephane: I like the diagram, but I am missing how to fit it into the payment transaction and the role of the browser, e.g. when does the browser invoke the wallet.

<wseltzer> Pat's diagram

Pat describes his diagram illustrating the wallet interfaces. We’ve separated out the application layer from the server layer

At the top of the picture there are a number of components such as display, touch, fingerprint scanner, …

Pat explains how the wallet could be split across a local app on the phone and components on the server. This allows for offline operation with subsequent synchronization.

Some key examples of plugins include a POS (point of sales) plugin.

Joerg: we’re not yet through with the design, and this group could help to refine it.

(more details at https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force)

Pat: please don’t hesitate to provide us with feedback!

David: the reference UI shouldn’t be part of the wallet core.

… this is starting to look like a web centric solution as opposed to a hardware centric approach.

<Zakim> dezell, you wanted to ask about UI separate from agent

Laurent: Can W3C specifiy on device APIs? (as a W3C newbie)

… for data formats, I expect that to be yes

David: this is touching on a hot debate. Does it necessitate the involvement of browser vendors or not?

<Ian> [W3C WGs have dropped Web Intents -> http://www.w3.org/TR/web-intents/ ]

… should this be part of HTML6 and how do we convince the browser makers?

<NickTR> i want to be in the meeting next door

Joerg: today we need to rely on specific browsers.

Laurent: can you enable native apps to invoke the wallet?

<AndersR> https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/0000.html

Pat: certain capabilities can only be accessed from the local device

Joerg: this could defined by other orgs than W3C, e.g. GSMA

… we’re working with Firefox OS which provides a means to access NFC from JavaScript. On Android, we need glue code to bridge the gap from the web run-time to the native NFC capabilities.

I just want to standarise the minimum, the rest should be left for innovation by platform providers.

<Zakim> NickTR, you wanted to ask if payer and payee both have payment agent?

<Ryladog> Should we add 'inner-agent APIs' to glossary?

NickL does the payer and payee both have access to the wallet?

… right now the payment agent looks like it is controlled by the payer and not the payee

Stephane: how do you install a wallet in your web browser, and how does the merchant invoke it?

What do you see this group working on? The interface between the wallet core and the payment solutions for sure.

<Zakim> sboyera, you wanted to reask the same question no news on install/invoke

Joerg: we want to update this payment agent wiki page, please join the payment agent task force to help us do that.
... right now we’ve used different approaches for invoking the wallet on different platforms, but yes a common approach is desirable.

<Zakim> m4nu, you wanted to mention standardization around data formats, protocols, User Agent APIs, and REST APIs.

Manu: I think there are 4 things the payment agent is doing. data formats for receipts and payment request, the protocols involved, browser APIs (e.g. that the buy button invokes), and finally, the REST API definitions.

David: I agree with Manu. I want to focus on the web server as an abstraction for the payment agent that can be accessed from the browser using existing standards.

(modulo the use of CORS)

<Zakim> dezell, you wanted to say one more thing about devices.

<Vinay_Gupta_E> +q

<m4nu> +1000 to Evan, we need to have Payment Agents online at all times (we need to support that as one mode of operation)

Evan: One of the use cases we need to discuss are pull payments and subscriptions. This is needed for services that need to get money from me, so there needs to be a way for services to discover the end point (the URI for the server).

<sboyera> +1000 to evan, we should not consider user-agent interaction

Evan: we need some agent representing me that is always online. We should not standardise too much.

… we need to make it easy to adopt new solutions without waiting for new standards to be developed.

The interface that needs to be standardised in the one that other people need to access.

Chaals: I would like to disagree with Manu. W3C prefers to focus on data formats and not on protocols. We need to allow for flexibility in the underlying transport, e.g. NFC, Bluetooth, monkeys …

<jheuer> No problem with Evans concept - but not to replace the current notion of a UPA unless we found a new name for it and, thus, 'user payment agent' might be free to be used in a new way

We *do* need to standardise the APIs and the data formats

… We should focus on the use cases that helps us figure out what the requirements are for these from real world examples.

We will find the need to support offline payments (lots of colourful details elided)

<padler> this is where the micro-web might help... two users running a wallet can do an NFC to NFC push payment W/O being connected to the larger web...

<Ian> [Back to point from yesterday: design goals are important or solution constraints like "must work offline"]

<padler> ex. for stored value credit pushes...

<CyrilV> who grasp all, lose

Chaals: the payment transaction can be commited to offline, and finalized when the devices next go online. This is important in the real world where you can’t rely on being online all of the time every where you are.

<padler> msg/ CyrilV In the US we say "A bird in the hand is worth two in the bush" :o)

Chaals: we don’t want to constrain the implementation any more than strictly necessary

David: in summary, I am excited about modularization and payment protocols, and the important point that all of this needs to scale.

<chaals> [my random prompts for me: probably data format, APIs are part of the work we have. W3C doen't do a lot of protocol, and tends to think data formats can be protocal-independent… Use cases that explain why the API needs to work on browser or in cloud or… minimum constraints on interaction with the agent such as accessibility but live at a separate level… offline has to work - always online is too constrained for reality]

<wseltzer> scribenick: evert

<scribe> scribenick: evert

dezell: most of today further dedicated to the payment agent, and next steps for roadmap

… before we do the roadmap, let everybody express 2-3 items as a short term outcome

… things for next 3 months

… JY will give information of regulatory items to be considered

… tomorrow pick up one use case for detailed analysis

Manu: suggests to take 4 use cases (not too deep)

David: to be decided tomorrow

Erik: Try to explain what a “wallet” is. Shows presentation.

… BIP 32 wallet, wallet is a tree of identifiers

… elliptical curve cryptography, computer generates random number as a key.

… Derive further keys for different acounts from the master key

… derive keys for ID/login, sending payments, receiving payments

… brand new key for every transaction

… when a single key is compromised, the other keys are not harmed

… chain of identifiers. The masterkey must be protected “at all costs”

… key storage on a secure device, which may communicatie via NFC

… can also be installed on a secure element.

… the master key enables the key chain to work

<jheuer> q*

… digital signatures, identification etc to be signed with keys from the chain, not the root key

… wallet is nothing but a tree of identifiers

… Shows a hardware based wallet, protected by biometrics

<padler> All... I just added an updated zoom in on the concept Erik is discussing related to the last wallet concept here -> https://www.w3.org/Payments/IG/wiki/File:WalletDetail.jpg

… What is a financial identifier?

… This concept can be used with any credential, encryption requirement etc

Ryladog: privacy : this would be personal financial information related

Erik: Trace back is not possible

… technology is part of FIDO alliance

<m4nu> +1 to key derivation

Jheuer: interesting view. Important to look into the impact of ‘device binding’

… if a credential requires a certain device to be authenticated

<m4nu> +1 to supporting newer crypto mechanisms such as Elliptic Curve and others.

… than the credential is bound to the device, cannot be used otherwise

David: you can use this to protect a chain of coupons for validity

Jheuer: finds the use of the term “wallet” confusing.

… wallet is a term where people have a definition for already, pre-empted

<padler> we need a code name for the wallet... maybe project "Costanza"?? :)

… the user payment agent is the connection between the network and the user

… be clear when to use the term “wallet” and “user payment agent”

… to use “wallet” for this key-chain? (sighs)

erik: this stuff is in the industry, exists already

… used for identifiers - for which the purpose still must be defined

<Laurent_> +1 on not relying on one source

<Zakim> dezell, you wanted to clarify wallet vs. payment management application

dezell: “payment management application” - is an extremely thin wallet, a credentializing system.

… isolate things on different levels

… does the bracelet constitute 2 factor authentication using biometrics?

Erik: can be 2-factor, or quasi 3-factor

dezell: will it also create a cryptogram, check signed input?

erik: you can use it to sign transactions etc

… private key will be kept on the secure device

<Vinay_Gupta_E> +q

ryladog: see the identifier-thing in the “PMA” payment management application

… this component in the credential box

… what is the effect on ledgers?

pat: explains the effects so fast that I can’t cope : )

<Zakim> m4nu, you wanted to support Elliptic Curve and Derived Keys in general.

manu: +1 to use cryptographic tools - should be looked into

… digital signatures add tremendous value

erik: technology is to be NIST standardized

Vinay: curious about the interface, how do you know what it is you are signing?

Erik: similar to a case with walmart with NFC collisions

… Evert can show a ‘what you see is what you sign device’ used by Rabobank

… enforce a one step user confirmation

Vinay: payment agent relying on the hardware token

Laurent: concept seems somewhat disconnected with the web payment. Use cases must be taken further to evaluate

<Ian> +1 that we should focus on the requirements than the solutions

… bit too soon to decide on the type of crypto required right now

… leave it to the working groups

<Joseph_Lubin> Joseph_Lubin is Joseph Lubin

… would love to use smartcards, but not yet clear at this point in time

<evanschwartz> +1 too soon to decide on particular crypto schemes now

pat: jurisdiction may define requirements for crypto

<Ian> scribenick: Ian

<m4nu> evert: As an example of what Rabobank uses for consenting with transactions (holds up device)

<scribe> scribenick: m4nu

evert: We have these crypto calculators - we forgot five digit code required to activate the device. So we moved to cards - standard EMV technology.
... In the latest iteration, it contains a camera - it communicates a color QR code that has a signed message from payment processor which is the bank, saying what you are going to consent to.
... Nobody can sit inbetween your transactions - it's a nice evolution, it's not free - we issue 5 million of these devices. It's worth it because of all the man-in-the-middle attacks get a bit too much for us.
... So, for web payments, electronic transactions, this is where we're headed.

<evert> Laurent: the term wallet for the secure device seems to be a bit specific

joseph: I think it's important ... that you can take a seed and a master device and generate subtrees. You can be locked into a separate hardware wallet if you need it to - lock in isn't a big concern.

<padler> +1

<evert> Joseph: you can move to any type of hardware device. That will not make it a wallet, as people from bitcoin suggest

<evert> … centralization: this is a user defined way of storing tokens of identification which may be used for authentication etc. Excellent for a decentralised approach

<evert> pat: identitiy use cases as a way to get adoption. interoperability is an issue

<evert> erik: wallet as an identification factor?

<evert> joerg: wallet is an intermediary

<evert> dezell: presented as an example, not as the single way to do things

<evert> cyril: the user interface should be protected

<evert> … the wallet can be the combination of the card and the card reader as in Evert’s example device

<evert> … the wallet is not only the credentials

<evert> dezell: how much time do we need today to finish the UPA discussion?

<evert> joerg: we might need to split up in smaller groups to progress faster

<evert> … go through wiki contents

<evert> … to feed back in the roadmap document(in the end)

<evert> Ian: suggests to look into changes rather than getting on with demonstrations

<evert> joerg: inventorize required changes and applying these later offline

<evert> … most important will be the retrospect of the phases

<evert> … bridges we need to build between the use cases

<evert> … UPA, PMA - how do you come to the right name in w3C?

<evert> Ian: people write proposals, put in wiki, and vote

<evert> joerg opens the user payment agent wiki page

<evert> … a “storage area” for all what is discussed, not yet a good readable version

<evert> … created a new page

<Ian> Payment Agent Task Force wiki

<evert> … took a few of the inputs to create a new structure for the page

<evert> … high level overview, scope / key concepts / features

<evert> … lay-out still to be reviewed

<evert> … high level overview to explain the overall topic (based of Pat’s figures)

<evert> … editing / contribution can be done on the wiki

<evert> Ian: discusses diagrams on the flipchart (which I can’t get in the irc :)

<evert> Ian: sees a “bunch of stacks” but these do not tell a story

<padler_> for q+

<wseltzer> https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<evert> … must be able to walk through it

<evert> Joerg: diagrams from the old page must be drawn new, terminology has changed

<evert> … high level overview seems ok

<evert> … Scope of the User Payment Agent

<evert> … specific things to standardize (interfaces, protocols, api’s)

<evert> … we need to be really clear what picture we use

<evert> …need to have the boxes to discuss the interfaces between them

<evert> Pat: after doing the roadmap discussion, we can prio work, what details must be defined

<evert> … start with a very simple interface, with just one interface

<evert> … expand on that later

<evert> Joerg: use cases tell the story of the architecture - and vice versa

<evert> … not easy because we have to touch on the use cases again

<Vinay_Gupta_E> +q

<evert> … concerned about the clarity of the user view as we get to deep in just a collection of functionalities

<evert> … describe a meta date structure in a tangible way for the user, so it can be shaped by implementers

<evert> Vinay: gets to sketch something on the flipchart

<evert> … 3 fundamental models

<evert> … XML / EDI mesh on lowest level

<evert> … on the other end: JSON structures with signatures which is processed.

<evert> … simplest thing which could possibly work

<evert> … somewhere in the middle, a series of messages back and forwards, negotiating steps between actors

<evert> … it might help to name scenarios of these types

<evert> … to identify nomenclatures of different architectures

<jheuer> New UPA - wiki: https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<evert> … other point: crypto currency, VAS can be linked on the (top) model after “payment consent”

<evert> joerg: some problem when provisioning security elements for creditcards

<evert> … drove to get to a meta data structure to get to a different user experience

<evert> … could add a greyed out card which gets active after all steps are completed

<evert> … inform the user with a “token” of the fact, e.g. that the requested card is under way

<evert> … decouple user experience with the way how it is processed in the back end

<evert> Vinay: informed consent and fulfillment as different categories?

<evert> dezell: can we agree upon groups of api’s and data structures with these api’s

<evert> … use cases are abstractions (as one definition) of real life scenarios

<evert> … modeling these is the work we have not yet done

<evert> … if we put the actor and subject names consistently

<evert> … ooand done right, verbs and objects, to agree on

<evert> … distinct connection between the modeling suggested, use cases and protocols/api

<evert> Vinay: feels we are slipping down the architecture

<evert> dezell: that is why you need to do the use cases first

<evert> … a little ahead of the game with this discussion

<dezell> https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<Ian> scribenick: evanschwartz

<Ryladog> tt

David: discuss the high notes on what is relevant from a regulatory point of view, then we'll do the 2 short term points everyone would like to see, then begin to revisit use cases
... also supposed to begin outline of roadmap

Jean-Yves (JY): What are Payment Services?

JY: Regulation matters because in most countries payment services are regulated, depending on service or role requirements are triggered automatically
... need to keep in mind key rules and try to draw guidelines to integrate into roadmap
... people understand the word payment but it's more complicated from a legal perspective, "payment" in everyday life is different from the commercial/banking sense
... In most jurisdictions e-payments are "payment services"
... Should we call our IG the Web Payment Services IG? Open question
... Merchants and Payment services: depending on implementation (legal and technical), many use cases could be outside regulatory requirement fields
... in EU merchant is not providing "payment services" when invoicing and being paid, as long as it's for themselves
... now in EU market places must comply with PSD2
... a merchant is not offering "credit" when it allows payment facilities to the debtor, easy terms of payment could be improvement for merchants and customers
... prepaid instruments are not "payment services" if they're for one or a small number of merchants
... Payment service providers: acting as financial institutions, should be cautious not to confuse them with banks or payment processors
... in some countries banks are the only ones allowed to make payment services
... payment processor is techincal agent, subcontractor of payment service provider or bank
... in some jurisdictions payment processors can do whatever they want within AML and consumer protection laws
... Banks / Non banks - in EU bank is credit institutions, means taking deposits and making loans, money belongs to the bank
... other payment institutions are PSPs so they can transfer funds, accept or issue payment instruments, but they just "transit" through them, they never belong to the PSP
... some use cases we are discussing include regulated functionality, supervisory authorities are trying to make regulation more effective around the world, AML is a global priority
... some current trends include keeping records of sensitive payment data require PCI-DSS compliance, in EU under PSD and PSD2 some functionality will be strictly limited to regularly authorized PSPs only, including some functions we have described in use cases
... PSD2 will mainly apply to authentication, access to payment instruments, begging consent to payments, access to settlement systems, issuing e-money or prepaid accounts for general purposes, acquiring payment orders on such instruments, transfering and debiting payment accounts
... in EU if you comply with requlations you'll have access to all settlement systems
... regulatory jurisdictions determine what kind of services should be regulated, who can provide services, what are the services/roles/functions are outside regulated activities

<Zakim> Ryladog, you wanted to keep 'user' in the name of the payment agent/tool/app so that the primary reason in my eyes

<evanschwartz_> Pat: when a transaction starts it creates a definition about what details need to be captured, you know what jurisdiction the payer or merchant are in

<evanschwartz_> scribenick evanschwartz_

<evanschwartz_> Pat: regulation today is after the fact, smart contracts could be built in so that regulators could authorize payments before they flow, small banks get requests for paper records and regulators are swamped under loads of paper

<floris> * legal clearing services require interpretable transaction data and information on relevant jurisdictions in the transaction

<evanschwartz_> Vinay: in south-south trade there are huge identity requirements for payments, especially because of absense of payment instruments and micropayments

<evanschwartz_> Pat: could be informed of reg requirements when you initiate the payment

<evanschwartz_> Cyril: there's regulation and also payment schemes, including the contractual frameworks between banks and schemes like MasterCard, contracts are different with Visa, direct debit, parties need to know beforehand which scheme they're going to use to determine what data is needed

<evanschwartz_> Cyril: it is the job of banks and PSPs and scheme managers to define good rules to coordinate with regulators

<evanschwartz_> Cyril: web payments should organize schemes so that you don't need bilateral relationships to send payments between countries, cryptocurrencies could even be considered schemes

<evanschwartz_> David: ISO 12812 working on Mobile Financial Services, this will start appearing in legislation near you, defining "mobile financial service provider", that should be no different than web PSPs so we should tell them that

<evanschwartz_> David: they talk about secure element, calling it "trusted execution environment"

<evanschwartz_> Tim: actually "secure element" + "trusted execution environment" = "secure environment"

<evanschwartz_> David: also includes consumer protections. We should figure out why ISO would want to create a new financial service provider and push our comments in their direction

<Zakim> dezell, you wanted to mention ISO12812

<evanschwartz_> Katie: some laws have connection to whether there's a physical business, people want distinction to go away

<Zakim> chaals, you wanted to ask for clarification on how only PSPs being able to do payments, means there is nothing for us to do… and to ask if the differences are generally more or

<evanschwartz_> Chaals: If only PSPs can do payments and there's nothing for us to do, it seems like that's not the case, PSPs might appreciate us or people could become PSPs

<evanschwartz_> Chaals: if PSPs in the EU want to work with unregulated PSPs elsewhere then they might be interested in working with us, we might want to get EU regulators in the room. Also do you have a sense of whether the regulations are compatible?

<payt> +1 :D welcome to the team evan!

<evanschwartz_> JY: at this moment when everyone is seeking new common language to operate it's a good opportunity, one of the major risks is to just stick to one scheme even if it's ISO

<evanschwartz_> @manu, i'll make sure to take worse notes next time

<chaals1> [We should be looking for e.g. EU regulators to paticipate in the discussions *anyway* - but that's a discussion for tomorrow]

<evanschwartz_> JY: someone will end up driving new regulations and standards but that's where the W3C can help standards to be worldwide

<evanschwartz_> JY: my hint is that there are a few key points we have to be really aware of, especially AML, because that has strict requirements in every country, the other point will be around authentication

<chaals1> [AML - anti money laundering]

<evanschwartz_> Laurent: propose that we sidestep the problem in the short term by leaving this in the extensibility part of the spec, identify the things that are heavily regulated like authentication and leave that in the part that is scheme specific, focus on interoperability of the merchant talking to a fleet of user payment agents, delegate responsibilty to complying with regulations to user payment agent, from experience we could spend years on regulatory [CUT]

<evanschwartz_> Laurent: it's a nightmare by design, US proposes something and EU thinks it's crap

<chaals1> USE CASE: Susan lives in South Africa, but her mother in Norway passed away and left her the family home. She wants to sell it and bring the money to South Africa, and finds a buyer in Canada…

<payt> we could call it the "Paradigm Agent" LOL

<Zakim> m4nu, you wanted to ask where we put the "regulatory overview" table?

<evanschwartz_> Manu: where are we going to capture the document laying out the regulatory mapping exercise? roadmap or use cases?

<evanschwartz_> Chaals: Sounds like we make a document, and use that to generate requirements which we add to the work we're doing right now

<evanschwartz_> Erik: need to capture what the regulated points are going to be, going back to bitcoin world the discussion with FinCen was with multi-signature, pushed Ethereuem to come on board to use smart contracts, want to use multi-sig to bring regulators into the loop, want automated reported on the payment service provider's side

<evanschwartz_> Erik: when it comes to consumer protection, it's going to hit us like a runaway truck because we're going to be privy to consumer data

<evanschwartz_> Vinay: huge overlap with identity issues, most regulatory issues come down to knowing the customer

<payt> it's not so much that the regulation needs to be implemented off the bat... just that there needs to be a "plugin" to Laurents suggestion that there should be a way to "plug-in" regulation notifications / processes once the key data about the transaction is identified (ex. location, tx value, etc)...

<payt> it is a big space, however, there are a relatvely low amount of data elements that are required across the different regulatory "schemes"...

<evanschwartz_> Jeorg: also try to talk to privacy people, lots of them in the EU, a lot of this would be a huge step forward for user control, might be easier to change a few regulations

<NickTR> The regulatory issues are, for me, business rules applied to data elements as a function of the identity of the actors (where identity includes attributes of location/appropriate regulator)

<chaals1> scribe: chaals

short term outcomes...

DEzell: Want to see published last call for use cases doc, analysed as discussed by Vinay, making Ian happy, and categorised so we can work out our requirements.

Ian: Want to see the stories driving this work clearly articulated. Some nice diagrams and consistency in teminology, so people can understand what we are doing just by looking.

Laurent: To get into the trenches especially what happens when you click "buy" on the browser.

… how do we get a WG working on that ASAP

Mario: Want to see the data formats for use cases, to identify consistency and exceptions.

Joseph: Lots of diverse tech. around the table. Want to see listing of the technologies and what they do. (and don't). And a set of the use cases that everyone can handle.

Floris:

… iprovements in the knowledge model. There are good ideas, but inconsistencies.

… will ask my people to help.

ss/iprov/improv

Evan: Opportunity is to unify the value networks of the world.

… want to see some exploration of what it would take to make that happen and what W3C's role could be.

<sboyera> emvco

PS: Want to see the use cases documented, to what extent they are relevant to EMVCo…

… if that's positive, how can the two groups work together?

Vinay: What's the simplest thing that could work? Would be nice to have a good grasp of that.

<mario_de_armas_> +1 to simplest thing that could possibly work

… The first milestones should be the simplest thing, and then a notion of the sequencing in the roadmap.

… There might be less work than we are afraid of.

<CyrilV> i'd love to see detailed flows with actors associated with responsabilities, in order to be sure to comply with legacy schemes (card, v.me wallet, SDD, SCT, SEPAmail)

<Ian> +1 as well to starting simple use case (to be decided by consensus)

Cyril: [as noted by Cyril - thanks!]

Steph: Divide and conquer. Identify the sets of independent blocks so we don't mix the discussions together and get lost. Push payment, Pull payment, Identity, …

… so we can move on each independently

<evanschwartz_> +1 on dividing and conquering but I'd argue that the split is probably between payment and clearing/settlement

Pat: Building on that… further refined version of big picture architecture to identify what we can usefully build and work on in parallel.

… Don't want us to get bitten by missing out a key piece because we didn't understand overall needs.

Eddy: Flesh out use cases, see how they might apply to Visa, see what is in scope for the group

<dsr> Dave’s short term priorities:

<dsr> Published use cases and high level requirements

<dsr> White paper setting out vision, assumptions, priorities, and relationship to other groups as a means for reaching out to stakeholders globally

<dsr> More proof of concept demos

<mario_de_armas_> to evan: I think that the break down should be 1) authorization, 2) clearing & 3) settling

<Ryladog> SHORT TERM: Clear Use Cases document. NEAR TERM OBJECTIVES:....mine are really long term.... Provide users with an easy/intuitive secure interface (and framework) to empower them to control and determine with whom and with which payment vehicles/instrument they wish to use to participate in commerce/acquisition for all aspects of their lives. Can cover management of funds, funds for daily needs (food, utilities, supplies for home appliances), for medical an[CUT]

<Ian> scribenick: Ian

<scribe> scribenick: chaos

<m4nu> chaals: I want to see a bunch of stuff - I want use cases document well advanced.

<m4nu> chaals: I want to see some legal framework analysis taking shape

<m4nu> chaals: I want to see an explanation of how the payment process works.

<m4nu> chaals: If we get that far, we've done a reasonable job.

<m4nu> chaals: I also want a pony.

<chaals> scribe: chaals

Istvan: Want a unified standardised payment solution allowing anyone to be able to plugin. SOmething tangible delivered. Some predictions on the roadmap.

i/chaals: if we get/chaals: a pro-tem statement of what we think success looks like (i.e. scope of work)

Bernard: Expecting the group to have a growing number of participants and clear message. That leads to lots of new members… Seriously now: Make sure you bring the right people to this table.

Jean-Yves: Understand how W3C can solve the complexities we are facing. Dream that we choose some use cases and start implementing some solutions with a common vocabulary, consistency checked with other standards in industry, to deliver a first proof of concept.

Manu: Publish FPWDs of use cases, roadmap, payment agent document.

… these will let us explain our work effectively to the people we want to bring into the work.

<NickTR> I want to see good definitions of the actors and their interactions at a sufficiently generic level onto which we can then map the multiplicity of "real world" examples

<mario_de_armas_> +1 we need a d ocument that we can shop around

Nick: definitions of the actors and their interactions, at a level where we can map all our use cases into that. That picture is what we need to explain ourselves.

<evert> Limited, basic set of use cases and interactions between well defined actors (roles) for API design and data models,

<evert> Good separation of “kernel payment functionality” and “purchase related functionality” not being the payment itself

Evert: Limited set of base use cases. Interactions between the actors explained. Spearation of core payment and purchase-related payments.

Joerg: More people actively participating. Well-aligned big picture explanation, pattern description. Identifying the standardisation items.

… For long term, make the digital world a bit more transparent and secure, and W3C should digitise the rest of the world.

Wendy: See us headed toward sending work to an existing WG, or chartering a new one. That would indicate that we had got the foundations in place.

… Privacy pervasive through use cases and discussion.

<Erik> Erik Anderson and my views of the next 3 months.

<Erik> - Realistic expectations. SWIFT was built in the 70’s and we cant change the world in 3 months.

<Erik> - Published initial working draft of use cases that are implementable (not theoretical voodoo and targeting what we can standardize and what we cant)

<Erik> - Published Road Map for the 1st and 2nd phase and breakdown of building blocks in the roadmap

<Erik> - Play well with others (ISO, Glossary, Reuse of existing standards)

<Erik> - Identify the road blocks

<Erik> - Identify the regulatory points

<Erik> - As a chair I view my role as bad cop, good cop, and a bulldozer to help remove road blocks

<Erik> - When we all go home to our day jobs please continue this efforts forward

- DRAFT -

Web Payments Interest Group Teleconference
03 Feb 2015

Attendees

Contents

Welcome

Payment Phases

Payment Agent

Demo by Joerg Heuer

short term outcomes...

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments Interest Group Teleconference 03 Feb 2015

Attendees

Contents

Welcome

Payment Phases

Payment Agent

Demo by Joerg Heuer

short term outcomes...

Summary of Action Items

Scribe.perl diagnostic output

Web Payments Interest Group Teleconference
03 Feb 2015