RE: [payment agent] Minutes for 2015-03-27

Manu, thank you for the minutes taken and distributed.



As we touched it during our call, we are confronted with a decision on, what I would call ‘the scope’ of our work.



In below picture (I hope you all can see and read it – should be a plain picture in .png) I tried to illustrate the world as I see it.



[cid:image001.png@01D06AEF.576D8E30]



I will – if time permits so – in our IG call try to address the different viewpoints I perceived and under which architectural work has taken place so far. My question will basically be: Can we tackle the topics in the red solid line and the red dashed line at once or should we look at both separately? Or is the picture plain wrong? (always an option – just tell me right away and safe time for everybody.) The notion of what a ‘Payment Agent’/ ‘User Payment Agent’ is, will determine our work for the next weeks, I’d suppose. Any guidance from the IG team should be discussed in the TF team on Friday.



Talking to you soon,



Jörg



-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com]
Sent: Freitag, 27. März 2015 16:43
To: Web Payments IG
Subject: [payment agent] Minutes for 2015-03-27



Minutes for today's Payment Agent Task Force call are here:



http://www.w3.org/2015/03/27-wpay-minutes.html




Full log below for archival purposes:

------------------------------------------------

Web Payments IG Payment Agent Task Force

27 Mar 2015



Present: Joerg, Istvan, Manu, Pat, DavidEzell, DaveRaggett,

         Hassan, Pascal

Chair: Joerg, Pat

Scribe: manu

Contents



Topics

1. Agenda Bashing

2. Timelines for Payment Agent FPWD

3. Payment Agent Document Structure



Summary of Action Items



[NEW] ACTION: Manu to propose an alternative document flow/section break up for payment agent document.



Agenda Bashing



Pat goes over the agenda...



Pat: We had a lot of discussion on diagrams, those haven't been updated yet.

... Payment Agents that we're calling wallets - there is a list of functions/features - additional things - payment agent more abstract - incorporate those with big picture view.



jheuer: One question for David - does it make sense to discuss your topic today - we'll have a talk about it later?



DavidE: I'd like to hear what you have in your head and how to get that down onto paper.



<padler> manu: no framework yet to put the discussion topics into the document… <jheuer> +1 to first review the doc structure

manu: I'd like us to focus on document structure / framework.



<padler> manu: we need to focus on how the document should be structured… this will help to allow people provide input to the document

dezell: There are a number of not fully formed thoughts in this area - this is an exercise - don't know if it'll work... might precipitate some discussion.



<padler> Here is the current version of the document..

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html


dezell: Joerg has a number of things in his head - this is what is driving him - it would be good to get those out into the group,



<padler> manu: would like to see actions taken to translate list into tech specs..

dsr: We can't run before we can walk - we need to understand at some broader level what we're trying to achieve.

... I think you're right, but it may be too early.



dezell: I think the list you're talking about was an aside that we want everyone to look at. It's more of a bottom-up approach - manu is suggesting a top-down approach, it assumes alignment with the use cases document.

... I think that's a good suggestion - if the use cases - the chunks of functionality that are re-used in various places, if we created a thought map into the components of the architecture, we'd either discover that it fits nicely, or it rocks our world. In which case, we'd have to look at reviewing them again..

... Is such a mapping possible to the proposed bits in our architecture.



padler: There have been a number of conversations since the call last week. We've tried to work with everyone on the editorial schedule - what's the structure of what we're going to produce? We need a good way for the sections to be represented in the Payment Agent conceptual architecture... the use cases document and micro-use cases - what's in the payment agent architecture - ties to discussion w/ joerg - in the large picture, for payment agent.

... It's hard to represent specific use cases - those are very concrete, specific to one place that payment agent may be deployed. The back and forth has been around use cases - but payment agent itself is more abstract than that. We were going back and forth - do we start w/ abstract view of payment agent and walk into specific linkages to use cases.

... So, what is a payment agent and what does it do vs. specific use case tie-ins, then work more abstract.

... There are pros and cons to both ways, but not always a one to one correlation between use cases and payment agent architecture. Not one to one tie for a particular sequence.

... There might be approaches that are easier for merchants to understand - specific ways the payment agent is built for merchants...

if you're a wallet provider, how does the payment agent concept applies to what Joerg sent out earlier.

... We need a big picture thing, but we need smaller more focused concrete use cases.



jheuer: Would you say that it would be possible within a few hours to take up to 3 of the use cases and run them through your diagrams? See whether they're useful? Or should there be work done on architecture?



<dezell> +1 to continuing the "validating the architecture against the use cases" excercise.

padler: We had five examples of diagrams - specific use cases - core/common things... figure out required capabilities of payment agent

- had to be in all five of those use cases.

... If you're a payment agent that's being deployed in context of user - there might be a set of required capabilities that you're required to implement.

... There are capabilities that need to be added - not just payment related things, but other services that may be required on that host.

... That's the way the document in its current form is structure - working from more abstract in to use cases - broad introduction - forget diagrams for a second, look at the outline. High-level description of what a payment agent does - section 3 in context, it'll explain why it was broken down that way - four and five - required and optional capabilities, respectively.

... There are a couple of places we can put it - we could have a section for mobile handset providers... in context of a smart phone - is it a secure element, is it some kind of a cloud encryption mechanism, etc.



<padler>

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html


jheuer: Could you send the URL to the document you're talking about Pat?



padler: Ok, it's above.



jheuer: The new picture that Pat put together - really creates a big picture from the view of the payment expert.

... I wouldn't have included some of those - not visible to user - so may have not included that, but that big view makes sense - you need to see where the work we're doing fits in.

... I'm happy to have big picture that makes all payment people happy - then see what part of it is user-facing.

... I like to see user side of it for browser for credentials and claims

- wallet - payment agent is abstract for it... what the term means has changed.

... We need to find a concrete form for a payment agent - before we can go into the use cases - that makes me a bit unsure - don't know if we can map the use cases properly w/o doing that step. Coming from big picture, boiling down to abstraction level, how do we map to use cases?

... If we need to map use cases, we should do it very soon. We should use the use cases as a guiding light for us. The use cases are the most advanced and best aligned w/ what we have so far.

... We need to boil down the big picture to something that meets the use cases.



dezell: That all makes sense to me - with my agile hat on - we're kind of stuck here - almost too complicated - concrete set of steps that we can get in the next few weeks - don't see any problem with what's been done... all looks pretty good. We need to bring these things together.

... We need to make progress.



<dsr> [with hundreds of use cases in Manu’s backlog, it is indeed like a log jam]

jheuer: We can still be goal driven...



<Zakim> manu, you wanted to propose a way forward.

<scribe> ACTION: Manu to propose an alternative document flow/section break up for payment agent document. [recorded in http://www.w3.org/2015/03/27-wpay-minutes.html#action01]

<trackbot> Created ACTION-84 - Propose an alternative document flow/section break up for payment agent document. [on Manu Sporny - due 2015-04-03].

manu: I'll volunteer to put my thoughts down into a document.



padler: Yeah, we may need to work from both directions... bottom-up and top-down - we need to show concrete and abstract at the right points.

... Rather than coming up with a separate document - is there a way that we can comment on what's in the editor's draft?

... So use that document as a collaborative thing - don't mess w/ diagrams - goal #1 is getting document together. Put pieces together in the document...

... I want to make sure we're all focus on getting everything back into the same place.

... What's good about the group - we have the big picture - focused on use cases - that'll help us in the long term - it'll be good - compressing them into the one document would be good.



Timelines for Payment Agent FPWD



padler: What's required for some of the upcoming meetings?

... Joerg - we want to make sure we have a FPWD by June 1st ... That would be basically - put us in a good position to have the document in place before the face-to-face in New York. Roundtable discussion on where the group is at, get more of the browser vendors involved.

... It's critical that we start making some direct progress on that.

It's important to get those things moving.



<padler> manu: W3c Publishes on Tuesday's and Thursdays <padler> we need to have text in really good shape by May 15th to allow for the document to be reviewed prior to publication..

<padler> manu: typically it is Task force first then IG review <padler> manu: internal reviews on this document should be targeted for last two weeks of May

jheuer: Any vacations that could get in the way of this?



padler: When we do FPWD on June 2nd - what's the process from there?



<pbazin> Could somebody write the link to the document for everyone ?

<padler>

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/payment-agent/index.html


<pbazin> thanks

manu: We would probably ask for external reviews - tell X9 / ISO groups to review the FPWD by July 15th 2015, for example.



Payment Agent Document Structure



padler: re: socializing - if we need some innovation/web crypto - what are those going to be - thinking through the document, how we choose to organize the document may be tied to overview - specific sections, specific areas of the document targeted to specific user communities...

don't have to read through 500 pages that isn't relevant to them. As we think about the document framework - how we proceed - if we can figure out how to prioritize overview section. Eno



ugh weight - recruit specific members - compile how payment agent concept fits in - best done by people that are operating in those areas.



padler: We don't want whole group trying to comment on secure element.

... When I think about the document - let's say a payment system company implementing the payment agent - understand basics of payment agent - then "what do I have to do to be payment agent compliant?"

... When I think of people doing wallets - they may not be interested in PoS terminals and how they tie into merchant back-end systems. They're interested in a different set of scenarios - if they're framed in payment agent/verticals - that might make it easier to make it easier to use the document.

... There is no good way to walk through the document - makes sense from a use cases standpoint - difference from vending machine vs. PoS terminal. There are probably big implementation differences that are important to understand.



dezell: I think what you're touching on is that somehow we're going to have to put these things in various languages that each of these stakeholders understand. I'm not sure that's even possible.

... There may be a less onerous way to approach it ... There are certain APIs that certain verticals want and ones that they don't want.

... This fits my particular use case vs. I don't care about these other use cases. When I say API - I don't mean WebIDL - it's this abstract notion of a restful web service and a WebIDL call - whether you're on the device or off the device. There are some examples of these things in the wild - FirstData's PayEze - initiating a sale.

... We need to identify, in our diagrams, where those APIs are... so people can reason about the content.



padler: Yes, that's where I was going w/ the comment - I think you're right - the rationale for the diagram in section 2 initially - it's organized around breaking the concept of the payment agent up around sending payments, receiving payments, PoS, etc.

... So, for linkages for particular standards - host container itself matters a lot - host containers may be PoS terminal, smartphone, cloud, etc.

... If you're a scenario - Cyril brought this up - I've got a reader, the payment stuff shows up on my device - communication is broken up by API or functional area - payment agent is implemented across different implementations.



dezell: I think that makes sense - concerned about what we're going to do before next meeting.



jheuer: My impression here is that things have gotten more abstract from when I left a few weeks ago - that might be good. We need to drill things down to something that matches the use cases.

... I do have the feeling that we're in a similar situation wrt.

reinventing WWW and web browser - ecommerce has started out w/ web being there - developing the first web browsers, we didn't know what ecommerce would look like.

... Without understanding supply chains, delivery mechanisms, etc. it was still possible to make ecommerce happen. I was hoping we'd do something similar w/ users claims/credentials - user agent analogy - objects in that to be displayed/handled - web page that has virtualized cards/snippets/tickets/etc.

... If we start from totally abstract view - we won't be able to handle it. I don't think we are creating something that's needed... when we did it, we found it very helpful - we had the example of the infocards, for example. That proved to be useful.

... No one talks about virtualized cards - we talk about abstract dependencies - allows for any kind of solution, it's nice - you can do everything via networks, but you have to do it all by yourself. Which approach are we going to take?

... Do we start w/ big picture? Or somewhere else.

... The big picture that we have no is probably a bit too far away from the use cases.



<Zakim> manu, you wanted to propose less onerous way to approach what padler wants.

dezell: Joerg, this is why I wanted you to make that list - it's apparent to me - the structure of the wallet - cards or coupons - those are absolutely going to have to be there. It's not clear that they're first-class citizens of the wallet... or are they?

... We need a shorter list than the one you sent if we're going to think about it that way - we need a model that's manageable.

... The sheer number of things in your list - those need to be abstracted - maybe we haven't abstracted it correctly.

... Maybe we want an overly thoughtful view of a perfect world... and the other is an industrial view of the nuts and bolts.



padler: Let me comment on what david said - I think this is a good thing

- we have both the big picture and some practical things. This weeks priority - standard X or standard Y - we've gotta figure out a way to represent both of those view points.

... A payment agent and why does the abstraction exist - that's what gets us to something where the payment agent can be extended over time.

What's coming next?

... There has to be sections on where payment agent lives in the wild - give industry players examples on how that happens.



<Zakim> manu, you wanted to say I remembered my proposal!

<padler> +1

<padler> manu: meeting into the middle by defining core blocks of functionality (which may or may not be required)…

jheuer: I think we can consolidate - we have inconsistencies wrt.

payment agent / wallet, etc. - if we do that over the week, we'll need more communication - expect myself to be ready to react to mails more - will try to make my contributions, hope others can do the same over the next week.

... wrt. the verticals - agree that we may want vocabulary here - important to understand the tool - like the web browser, serving many different verticals... but they didn't have to know what those verticals are - my list is lengthy, but serves all those different means - I think we can do that and the consolidation should happen over the table of contents perhaps.

... ok, we'll chat over mailing list - we need to align over vocabulary

- by next week, we'll have an idea of how these things will connect to each other.



dezell: Don't forget, I'm publishing agenda for telecon - please send suggestions my way.



<padler> Thanks everyone!!! :D



-- manu



--

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.

blog: High-Stakes Credentials and Web Login http://manu.sporny.org/2014/identity-credentials/