W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > March 2015

[payment agent] Minutes for 2015-03-27

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 27 Mar 2015 11:43:18 -0400
Message-ID: <55157A96.8010700@digitalbazaar.com>
To: Web Payments IG <public-webpayments-ig@w3.org>
Minutes for today's Payment Agent Task Force call are here:


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

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
<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

<padler> Here is the current version of the document..
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
... 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
... 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.

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
... 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

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
<trackbot> Created ACTION-84 - Propose an alternative document
flow/section break up for payment agent document. [on Manu Sporny - due
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
... 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 ?
<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

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
... 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
Received on Friday, 27 March 2015 15:43:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:33 UTC