See also: IRC log
<scribe> scribe: manu
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.
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.
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
<padler> -padler
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/but I want it to translate to spec text.// Succeeded: s/look at them/look at reviewing them again./ Succeeded: s/manu: What's/padler: What's/ Succeeded: s/meeting into/manu: meeting into/ Succeeded: i/re: socializing - if we need some/Topic: Payment Agent Document Structure Succeeded: i/re: socializing - if we need some/Topic: Payment Agent Document Structure Found Scribe: manu Inferring ScribeNick: manu Default Present: Joerg, Istvan, manu, padler, dezell, Dsr, hassan, Pascal Present: Joerg Istvan Manu Pat DavidEzell DaveRaggett Hassan Pascal Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0138.html Got date from IRC log name: 27 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/27-wpay-minutes.html People with action items: manu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]