Re: [payment agent] A proposal to structure architecture, agents and use cases

Hi Jörg,

Thanks for sending your thoughts along – I think you bring up some very interesting points that are definitely worth some discussion/attention from the group.  I'll add some thoughts to your email to hopefully jump start some of the discussion…

If I could try to summarize, I think what you are calling out (and rightly so!) is that identity (and trust by extension) are concepts which are applicable BOTH inside and outside of the payments process.  So if Identity and Trust are "bundled" into a Payment Agent construct then they are more difficult to use elsewhere.  In that regard, the original term/concept of a Wallet was better, in that it could support interactions which were only Identity Based, or Payments Based, or BOTH.  From the particular point of view (and terminology) of a user (person), the term Wallet is pretty easy to understand as well, which is good.  The part where things get a little bit harder, is that Identity (and trust mechanisms) are also needed by the Payees, and the devices and agents used by both Payers and Payees, which is I think the point that Tim was trying to raise in his post that you included.  It is hard because from the point of the view of the Payee, the name/term "Wallet" might not resonate with Payees such as merchants who might think of the same functionality being provided by "POS Terminal" - even though it could be argued that the POS Terminal has the same functional needs (identification and Payment).

One of the key motivations for the symmetric view of what is currently being called "Payment Agent" is that at the abstract level both Payer and Payee must both have a set of standards for 1) trusting each other, and 2) moving value as well as several other things.  There are still many cases where these both provide value independently and from both the Payer and the Payee sides.  For example, there is potentially a lot of value in a payee being able to identify a past customer, even if that customer is not currently making a payment and in a way that does not over-share private data about the customer.   Also, what I think is something important in the link from Tim that you shared is that Trust is brokered (or at least could/should be) in a number of different ways.  So I might establish trust via a direct experience between 2 users/devices, or in cases where I can't establish that trust myself (or my device can't) I can choose to rely on frameworks for helping to broker trust.  What I am getting at here is that if we are intending to promote a unifying set of standards, they should allow for adaptation or "plug-ability" with regard to both the trust models and the payment schemes that can be leveraged.

So in short, I would tend to agree that de-coupling Identity and Payment within the architecture is a 'good' thing.  The question of course that this raises (and it is a good one) is what do we call the parts and the whole so that they can be referenced abstractly across a number of contexts while still being able to link to concrete domain terminology such as Wallet or POS terminal on either side of the interaction.  Perhaps this is something as simple as saying a Payment Agent as defined, must implement a standard set of Identity and Credential protocols/standards (which may be defined by an Identity and Credentials group). In that way the architecture document becomes more of a "Conceptual Architecture for Payments on the Web" which highlights those 2 concepts (at a minimum) versus an architecture of just the payment agent which may be too narrow or too bundled based on the questions raised in your email.

Finally, I did update the current editor draft outline, which I think could be adapted pretty easily to what is discussed above if the group feels this is a good approach.  I temporarily removed all of the diagrams so as to focus the discussion on the document structure approach, and I think that this thread will help to shape that discussion quite a bit.  The latest github copy is here:  https://github.com/w3c/webpayments-ig/blob/master/latest/payment-agent/index.html

Thanks again for the great input!  Looking forward to hearing others thoughts as well here!

Pat


From: "Joerg.Heuer@telekom.de<mailto:Joerg.Heuer@telekom.de>" <Joerg.Heuer@telekom.de<mailto:Joerg.Heuer@telekom.de>>
Date: Thursday, April 2, 2015 6:19 PM
To: "public-webpayments-ig@w3.org<mailto:public-webpayments-ig@w3.org>" <public-webpayments-ig@w3.org<mailto:public-webpayments-ig@w3.org>>
Subject: RE: [payment agent] A proposal to structure architecture, agents and use cases
Resent-From: <public-webpayments-ig@w3.org<mailto:public-webpayments-ig@w3.org>>
Resent-Date: Thursday, April 2, 2015 6:21 PM

Hello everybody,

As I can’t be with you tomorrow, I promised to contribute my thoughts on the architecture work and make a proposal for the document structure. As I can’t seem to read the document on github properly, I have to interpret the code, but it’s not too hard.

My general view according to the figure below is:

·         The original user payment agent represented by the left hand blue box, was associated to the ‘user agent’ and was meant to give control over payment instruments to the user (and in my eyes, with an outlook to covering identity, keys, and similar functionalities in the future – see my list of ‘wallet services’ per my Mail on Mar 27, http://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0139.html (but the embedded list looks awkward in the archive, sorry))

·         The discussion of the last weeks has seemingly unraveled a host of payment process-related topics which might be as important as the user payment agent, but seem more in a ‘requirements phase’ (all inside the dashed line primarily)

·         The overall architecture involves all the components below (at least) and should probably follow the comprehensive architecture figures Pat created

Given these different scopes I propose to separate the two aspects – at latest in the new working group structure we are asked to provide. For the current tasks I propose to focus on the overlap (part of the blue box with the yellow boxes inside), in which IMHO exactly the aspects should be covered which we have focused in the use cases:
1. Negotiation of Payment Terms
2. Negotiation of Payment Instruments
3. Payment Processing
4. Delivery of Product/Receipt and Refunds
This should be most helpful to the overall delivery. Other aspects should be left for later.

I am unsure what to do with the term ‘payment agent’. A symmetrical ‘payment agent’ which seems to be attractive for the payment process world is cut differently than a ‘user payment agent’ we started with. Such ‘payment agent’, as I understand it, wouldn’t have to have a UI (could still be a subset of the ‘user payment agent’) and would focus on payment processes only. Complementing this, a ‘user transaction agent’ would be what I had in mind to facilitate payments on the user’s side, but should also cover also other convergent use cases as described.

Timothy Holborn pointed us to W3C’s design issues a few days ago. I found Tim Berners-Lee’s requirements on trust-modelling most remarkable. (http://www.w3.org/DesignIssues/Security-ModelTrust.html) and I felt pretty certain that a ‘user transaction agent’ would be able to address almost all of these requirements in a promising way. So why not give it a start in the Web Payments IG and work our way towards a payment architecture and a ‘user transaction agent’ (or call it a ‘digital wallet’ or ‘convergent wallet’ or whatever…)

I hope my words have been clear enough to explain the figure and consider my proposal even though I (once more) can’t attend the call tomorrow. I will be in the calls starting next week again, but am looking forwards to comments on the list and in mails.

Happy Eastern to all who care,

                Jörg

From: Heuer, Jörg
Sent: Montag, 30. März 2015 13:49
To: msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>; public-webpayments-ig@w3.org<mailto:public-webpayments-ig@w3.org>
Subject: 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@01D06D99.4C208D50]



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/




This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information.  If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.