See also: IRC log
forgot the RSS agent, just going to repeat the previous line
<scribe> scribe: nick
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
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]