W3C

- DRAFT -

SV_MEETING_TITLE

28 Oct 2015

See also: IRC log

Attendees

Present
jiangtao
Regrets
Chair
SV_MEETING_CHAIR
Scribe
nick

Contents


forgot the RSS agent, just going to repeat the previous line

<scribe> scribe: nick

Web payments working group architecture

Andy: we are partner with SK Telecom. We are in charge of development and service operation.
... we named our web payment standard prototype PAYTO
... Payto standard allows the payer to transfer money and simple checkout
... it uses a payto://PayToAddress,Amounts scheme
... the payer has the authority over the payment process
... supports various service models, like delivery service ordering through app
... another service model, donations and gifts. no need to share the payer’s finance information with the service provider
... demo of delivery app and donation app

Ian: so this is using a mobile money account in the back?

Andy: no, carrier billing is the model
... when your delivery comes the delivery person has a device

??: What’s the use of the beacon?

Andy: it’s cash on delivery, the beacon confirms receipt of goods

Adrian: what’s the protocol actual being used here?

Andy: BTLE

??: but the ID of the beacon is tied to the order?

Andy: yes

??: so the reading of beacons is done on the platform or through the browser

Andy: by the app
... payment notification is finalized by SMS
... payto supports both cash on delivery and pay now

<Zakim> AdrianHB, you wanted to look at the flow diagram from the presentation

Andy: all payments work in the web
... the app is just to do the beacon work

AdrianHB: can we look back at your presentation and the flow? Where does the URI scheme fit in?
... what’s the format of the address (in payto://PaytoAddress,Amounts)
... the reason I ask is because there’s only one way to pay, without much change I see a synergy between what we want to do in the WG and providing a list of options

??: the payto:// URL seems more like an instruction to pay?

Andy: this is just a prototype from IG discussions

Cyril: so payto can implicitely identify carrier billing?

Ian: if I understand Adrian’s comment it’s that there’s a service ,and you’re using the URL to invoke the service
... and you’re handing them an offer, here’s the offer
... and then the service gets invoked and asks for a payment insturment
... can we generalize

q

Andy: want to show one more thing, payto for P2P

Ian: so the question for you, as well as Zach and others working on other proposals
... what are challenges for the wg? what problems are hard to solve? what challenges exist between local services and cloud services?
... part of the goal of today’s session was to hear from people who may not be at the wg
... where are the biggest hurdles?

zkoch: I think the biggest thing will be to find a way to register payment instruments
... we want to define a standard way to do this but recognize platforms have limitations
... what’s the right way to invoke the installation of particular instruments?
... on desktop in general how should we treat this?
... on mobile you can imagine an intent model, but on the desktop we don’t necessarily have this
... how can we standardize this as long as you have an instrument it’s available?
... when the browser takes a stance and says “yes, we can process a payment” it’s an implicit confirmation the website is trustworthy
... in actuality you can’t really do that
... we’re limited to the current set of web technologies
... when you think about the chain of trust what are the resources we have at our disposal?

Ian: is your vision we can do better?

zkoch: I don’t have any ideas, there are tools we use as browsers
... one big thing is spoofability.
... sometimes we can break out of the DOM and into the browser chrome, but users never notice

jheuer: we should consider the payment instrument chosen might have their own ways of ensuring security

(+1 to jheuer’s point from me)

zkoch: it will probably end up there

<Zakim> MattPisut, you wanted to Ian's question if 'we can do better today' ?

<CyrilV> +1 with the two levels of security

MattPisut: excellent question. to pile on, authentication between the terminal and the payment device
... the device isn’t authentication the terminal
... can we do better today or tomorrow? I’m not so sure we can actually do better
... one concern we have is chain of trust

Ian: one clarification - there will be some things that will be better
... like not sending PII through forms
... I just meant the confidence in the party at the other end

rbarnes: I think Zach is on target. the critical question is what is a payment instrument
... there’s a bunch of instructive prior art that leads to different conceptions and might cover different chunks of use cases
... when I think of what a payment instrument might be it’s some chunk of state that gets put into the browser
... I think one of these constructs will be good enough for what we’re doing here
... the critical step is to find one of these constructs

Ian: sounds like an agenda for the wg is serving this prior art

<Zakim> AdrianHB, you wanted to expand on payment instruments

AdrianHB: something that has been difficult to nail down is the definition of payment instrument
... some people consider a payment instrument to be as simple as a piece of data
... that probably doesn’t work, or that’s not going to be enough
... maybe an instrument is some executable logic given to the browser to deal with the payment
... that thing may have another whole flow of its own for authentication
... the challenge i think we have is there are models in existence where a payment instrument may have multiple credentials, like PayPal (a front for potentially three cards)
... what happens if I visit a merchant’s site and they don’t support PayPal but do take those cards backing PayPal
... do we have a way for payment instruments to expose the credentials they use

<AdrianHB> nick: a point of contention so far has been definitions of various terms

<AdrianHB> ... there is a spectrum of complexity wrt what we call a "payment instrument"

<AdrianHB> ... we need to figure out what those mean

<AdrianHB> ian: is that important to the protocol design or the work of the group

jheuer: we’ve done stuff like that in software, but the only thing I don’t know if it will be compliant with W3C standards
... I hope to see something which is on a higher level of understanding and compliance

Ian: jheuer showed up with a demo at the last IG F2F so he has experience

zkoch: I might be a little biased since I’ve come up with a proposal, but with regard to prior art
... at some point you’re going to leave the comfort of the web and go into proprietary systems on different platforms
... you can imagine a world where I’m on my android device and end up in android pay, a native application

rbarnes: ultimately this payment instrument will be a represented as a web thing

zkoch: not necessarily. one of the goals we have is to bring secure payments into the browser, and to do that you may need to exist the web ecosystem temporarily

rbarnes: it should appear to the web as part of the web, even if the internals are doing something different
... again, I think it’s important to keep in mind the browser might bring some things along but keep a more general frame in mind

zkoch: two other comments, from an instrument perspective it could be complicated or very simple
... as long as you can speak the messaging system I don’t care if you’re a piece of data or a more complicated application
... you [nick] mentioned auto form filling
... we did try this with request autocomplete
... we should look at that and see if there are any learnings

CyrilV: I think there will be some issues on the protocol side for the instrument
... part of closed loop / card based systems, if you see the ISO 20022 there is a payment initiation
... initiation for direct debit, credit transfer, etc are different. part of the protocol would be to have a factorization of those messages, but that implies we must explicitely explain the payment instrument
... this is the form for direct debit, this is the form for credit, etc.

Ian: one of the things that occurs to me is that I think in the HTML working group they did some work polling preferences amongst members, etc
... I wonder if something like this might be useful in this group
... “we need a solution to accommodate a full range of scenarios”, type of thing. you only have to say one time “yes, we also need to take this case into account"
... don’t want to add work but if it helps avoid redundancy it might be useful

rbarnes: you mean use cases?

Ian: less use cases, more design goals and constraints. there must be a way for a wallet to reside in the cloud, for example. not quite a use case, but a requirement / constriant on the protocol

rbarnes: I think it is useful to go through use cases
... what are the logical message flows that we want to support for those things
... what does migrating to this API from now look like?
... but I would really strongly prefer if we didn’t have multiple levels of this API (the static one, the dynamic secure one, etc). we can probably arrive at an abstraction that can scale

Ian: i agree

<Zakim> AdrianHB, you wanted to respond to Cyril

<Ian> (I wanted to say that Richard's comment was the sort of "design goal" I was referring to)

AdrianHB: I think part of the goal we’ve discussed is putting a lot of complexity behind…all the different ways you can pay, the types of data…I see that not being part of the API, and being part of what the instrument does and the PSP does
... if it’s something new, like bitcoin, maybe they return cryptographic receipts rather than something else. It’s determined by the two entities (PSP and instrument)
... to address what zkoch said about instruments. I think even simple instruments will need logic to return a response
... when you register that instrument it may be as simple as five lines of JS that return its data

CyrilV: instruments may have some constraints
... we have constraint in, say, some characters, each payment instrument should give a list of data

(nick on IRC: other constraints might be monetary, e.g, a ceiling)

AdrianHB: my expectation is that level of constraint will be handled by the instrument

CyrilV: the issue there is, for example, some banks may not be allowed to change their constraints or adjust the request. in some cases you could imagine it is better to process the payment

??: In this case, if you have real time payments you need to process the constraints

AdrianHB: so an example might be a separate credit transfer? the payment instrument that’s installed is my bank’s implementation of that standard?

Laurent: most of what Ian said I wanted to say, but to reinforce two points
... on CyrilV’s side the instrument is linked to your account, on rbarnes side the instrument is really your credit card number inside the browser…these are two very different views of instruments
... maybe we need to find common ground on definitions in the wg
... there’s a common set of issues like plumbing between merchants / PSPs / instruments, discovery selection...
... the spec should leave flexbility for comlpex instruments, be extensible

Ian: for the chair, it feels like the sooner you can as a group converge on the sense of boundaries and explicitely say “this is being left” with rationale…keep the scope explicit

AdrianHB: it’s clear in my head

AdrianHB invites us into his head

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/28 06:32:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Zach/zkoch/
Succeeded: s/jeheuer/jheuer/
Found Scribe: nick
Inferring ScribeNick: nick
Present: jiangtao

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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

Got date from IRC log name: 28 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/28-wpay-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]