Web Payments IG - Payment Agent Task Force Telecon -- 19 Dec 2014

Agenda Bashing

<scribe> scribenick: manu

Joerg: Anything we should add?

manu: We may want to lightly touch on Github.

pat_adler: There was a GitHub security vulnerability, may want to update your clients.
... Also, there was talk about the Glossary, may want to cover that.

Joerg: Yes, open on changing wording/terms, sounds good.

jean-yves: I want to say that I got in touch with Bank of International Settlements - the group in charge of payments glossary - glossary issued in 2003 by them - asked them if there is a new edition on the way...

<pat_adler> +1 on the BIS glossary…

<pat_adler> this is a great resource!

jean-yves: They said they'll issue a new one next year, I asked them if we could get an official version.
... There is a strong link between glossary and payment agent.
... according to the 'payment agent', 'third party provider', 'payment service provider', regulations are not the same, functionality is not the same.
... There is a very useful tool inside of BIS, I'll try to get it for the group.

jheuer: Sounds good, always good to start w/ something well thought through like that.
... We need to make sure we're not just focusing on one view on payments.

<pat_adler> here is the link to the existing payments glossary… http://www.bis.org/cpmi/publ/d00b.pdf

ack

<Zakim> manu, you wanted to talk about BIS glossary.

<jean-yves> +1

manu: I like the BIS glossary, very bank centric, but we should reuse it.

jheuer: Yes, we need to have discussions on glossary - we didn't have any pre-established discussion on glossary. We need to move into an operational mode.

<jheuer> +1 to glossary following use cases and payment agent

<pat_adler> +1

evert: Sorry to have missed the last few meetings, but about glossary - open to suggestions - whether we would need moderated discussion, or work on use cases / payment agent and have that influence glossary?

manu: I'd like us to focus on use cases and payment agent - have that influence the glossary.

evert: Ok, so maybe I should do continuous editorial work on glossary, working with use cases and payment agent and that influencing glossary.

pat_adler: Yes, glossary depends on payment scheme and specific use cases - glossary that we have - normative terms we need to anchor - in bridge glossary - something we use at a high level - allows us to plug in other glossaries from other schemes... rules/requirements tied to payment scheme - terms are tied to specific payment scheme.

jheuer: Evert perhaps you read through text in use cases from payment agent / use cases from time to time, and make suggestions on what should be added/settled in the glossary.

evert: Seems feasible, let's figure out if it's practical.

manu: Yes, we should ping Evert every time we need a term and we don't know what we should be using.

jheuer: Anything we should add to the Agenda?

manu: As long as we focus on Pat's diagrams, we should definitely focus on that today.

jheuer: Yep, already on the Agenda.

Payment Agent Diagrams

jheuer: great work pat...

manu: +1, really great work Pat.

pat_adler: Just building on top of everyone elses work.

jheuer: That's what we should be doing in this group.

https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#Attempt_at_harmonizing_versions_1_and_2_above

pat_adler: What would we label a "device capabilities" box?
... If you're on a browser - the device is the laptop you're on.
... Trying to stay fairly agnostic to device... "local communication devices"? Can we use that?

jheuer: That's tricky - wallet application, if you run it in the browser, it can make use of NFC / SE through device APIs available... but if it's server-hosted, a set of secure elements, plastic credit card, sits in a high-security data center, and you get access through a server in the cloud.
... Device capabilities of client device are important here.

pat_adler: I'm updating this as we're talking - changing this to "local interfaces", if you follow it down - you go to the application layer, to browser layer, you get to remote host/hardware layer.
... Or you could use one that's accessing localstorage - you could implement it differently. Use case - payment via bluetooth from device-to-device, that would work. Or you could use local interfaces - laptop/handset - to get to remote wallet.

jheuer: That's a big question in the picture - very helpful to have remote version of architecture available... but don't want to imply that there always has to be one. Standalone quality of on-device wallet is important. It's very important to have cloud there as well as local. Don't know if it should all be in one picture, or a different picture.
... Maybe not dig deeper into client? Payment Agent on both optional sides are the same.

pat_adler: So, you're suggesting we have one top level picture, talking about local wallet, and something showing localhost implementation of wallet, then something about a remote wallet - then have another diagram about combo wallet.
... So, the intent w/ the picture is not that all of this is mandatory, but there are various options. You can have local wallet, local wallet storage only, multiple remote wallets, etc.

manu: +1, sounds good

pat_adler: I'll try to think about it a bit more, maybe break the picture up - then make it modular and put everything back together.

manu: Yes, like the approach - good for the narrative - modular approach, put stuff together to provide richer use cases.

pat_adler: Should we point out existing W3C specs?

jheuer: I can do that.

pat_adler: Yes, put the specs in italics to let people know that specs exist for some of this stuff already.

jheuer: We need to discuss - voice needs microphone, so rather have microphone instead of voice.
... voice is strange - you can have a scratch card which is not voice, but used to authenticate.

manu: Isn't voice just another type of biometric?

jheuer: Might be good to point microphone out?
... I don't think we'll be able to cover all this w/ buzzwords - anything that helps us authentication better, we need to be open to. We don't need to define that, just for illustration.

pat_adler: There's a little bit of an overlap - biometrics via microphone (voice pattern analysis), you can do that via camera - iris scans. Maybe the goal for biometric is really to talk about fingerprint readers. Specific capability of device itself. Maybe we should just call that fingerprint scanner.

jheuer: Couldn't we use a different type of font - whole area of different mechanisms.

<Zakim> evert, you wanted to use customer verification method (CVM) as in EMV

<jean-yves> +1 for "authentication" as a general pattern, covering sub functionality as biometrics, ...

evert: Should we bind these terms together - customer verification methods.
... That's what we tend to do in the card industry.

jheuer: We learned that we should best make available technical capabilities, and then let issuers decide how to use it. The microphone isn't a capability for customer verification, but it does become one if you're doing analysis... might be part of OS, for example.
... In order to not get wrapped up w/ different layers, there are so many fancy things that can happen, in future there could be more - for example, using gyro for making a signature in the air. Want to be open for these options/opportunities.

evert: Essence of mechanism I'm trying to refer to - a method to send certificate from one party to another - maybe that's a use case. Maybe we should have verification in there.

jheuer: What should we do w/ the diagram?

evert: Maybe have a customer verification method in there.

pat_adler: When we first had that in V2 of the picture - idea was that the top level pattern, we should name that use case in that picture - starting from payer - coming down through parts of the system. customer verification is part of a use case, not a capability of the phone.
... How all these bits are put together are a part of the use case.

manu: Yes, agree with Pat - this diagram is the parts of the system - use cases is how you put everything together.

dezell: There are abstractions embedded in this diagram that are not easy to see yet. Great start to the diagram, got us talking about this.
... Our recommendations for user agent - if we keep in mind that what we want to address - when I use my browser, how does my browser figure out what it can do wrt. payments? It's going to do it largely through the designing of these interfaces. By defining abstractions, the people designing the agents we tell folks how to implement these things. We don't want to bind all this functionality to one vendor. That's why we're here.
... So, those abstractions are the next thing here - Pat, don't think there's anything technical missing here - it's a metamorphosis.

pat_adler: I think key is - key abstractions of the wallet - what we need is a couple of sequence diagrams - what happens when you hit "pay" in the browser... what happens to different pieces in the browser? Maybe that's the next picture we need - is there a higher-level of steps that happen as a part of the payment process?

<jheuer> adding abstract processes and 'patterns' would be useful

pat_adler: Payee authentication, payee funding, select destination, etc... you tie the pictures together - process picture + logical flow picture tells people what can be used.

jheuer: Agreed.

jean-yves: I'm sharing David's viewpoint - we have everything in the design in front of us, besides that, there are a few things we're looking for that are not easy to see from this overview. I wanted to stress, via Evert's suggestion - can we merge authentication w/ customer verification methods?
... functionally, it's about the same, but if we consider EMV is a top thing, customer verification method is strongly linked w/ specific payment instrument. If card is the payment instrument, you trigger a customer verification method.
... There is another way to play the functionality - start from authentication, the customer will prove that they are who they say they are... for example, 3D Secure checks whether someone is who they say they are.
... Maybe we could have new views according to the point of view we choose (payer, merchant, etc.)
... Like the same approach we might use for use cases? We may want to think differently if we're a merchant, customer, bank, payment instrument issuer, etc. Maybe thinking about it that way will help us figure out how to organize this?

jheuer: Maybe a 3D-ish picture... you need 3 of them to kind of discuss this - customer, merchant, bank, payment instrument provider, etc.

<pat_adler> +1 on abstraction..

<pat_adler> key example is the nymi band/heart rate monitor over BLE…

<Zakim> manu, you wanted to talk about longevity of this document.

manu: We should keep the abstractions high-level
... Let's not focus on Voice, BLE, NFC, etc. We should be focusing on "biometrics", and "local communication"

pat_adler: Yes, Nymi band creates public/private keypair - communication comes over "proximity communication channel"
... You have input mechanisms (display, touch, audio inputs), then you have local proximity communication (NFC, BLE, ZigBee, etc.)

jheuer: I think that sounds like the right way to go...

pat_adler: Yes, I'll make some changes, and send something out to the list.

jheuer: Let's chat about application layer - could be a long discussion.

pat_adler: Is there a good logical picture on how user agent is reflected - is payment agent part of UA, or next to UA?

manu: Looking at Payment Agent API layer - connections going from UA->app is normal for W3C, other stuff is new to W3C - connections coming from apps to UA are new.

<Zakim> manu, you wanted to mention something about application layer.

pat_adler: Is there already a diagram that shows what the UA looks like?

jheuer: I think W3C looks at what's "inside" a UA, not what's outside.
... Someone who implements applications - browser is nothing but another app on the OS
... Is there really a browser layer? We should discuss - developers said that "this is not reality" - this isn't for a developer.

pat_adler: Where from a W3C perspective would we place the logical construct.

jheuer: We're running out of time for the call today - let's move this discussion to the mailing list. If Pat can send out a new figure, we can have the discussion on the mailing list. Looking forward to that discussion.
... We're already decided that the figure needs to be redone a bit - thanks to Pat for redoing it. Process steps and patterns came up - who can volunteer to do that?

dezell

dezell: +1 for what Joerg said - WebIDL is a way to extend browser, we should think in those terms.
... WebIDL is our friend.

manu: I still owe a time-based approach to explain this stuff to the group.

jheuer: Let's work on doing this independently, then try to merge later.

manu: +1, sounds great.

jheuer: Hopefully we can put these pictures together and decide how to merge them.

Next Telecon?

jheuer: What about 9th of January 2015?

pat_adler: Sounds good to me.

<Istvan> +1 9 Jan is fine

manu: +1 9th of Jan works for me.

<jean-yves> +1

jheuer: Try to think about glossary as well.

<dezell> please fill in the WBS!!!

- DRAFT -

Web Payments IG - Payment Agent Task Force Telecon
19 Dec 2014

Attendees

Contents

Agenda Bashing

Payment Agent Diagrams

Next Telecon?

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments IG - Payment Agent Task Force Telecon 19 Dec 2014

Attendees

Contents

Agenda Bashing

Payment Agent Diagrams

Next Telecon?

Summary of Action Items

Scribe.perl diagnostic output

Web Payments IG - Payment Agent Task Force Telecon
19 Dec 2014