See also: IRC log
<github-bot> [13webpayments-ig] 15ianbjacobs pushed 1 new commit to 06gh-pages: 02https://github.com/w3c/webpayments-ig/commit/ba6ab5c90f243e0a61d86baee2aa02a7e009f4c2
<github-bot> 13webpayments-ig/06gh-pages 14ba6ab5c 15Ian Jacobs: Merge branch 'master' into gh-pages
<scribe> scribe: Ian
<jheuer> *tuoched the wrong button - I am back again
-> https://w3c.github.io/webpayments-ig/latest/capabilities/index.html Capabilities
Manu: I did some markup cleanup last night; should look like other docs
Note: We'll use w3c.github.io as staging for publications henceforth (but still need to confirm with sysreq)
<manu> http://w3c.github.io/webpayments-ig/latest/capabilities/index.html#introduction
<Zakim> Ian, you wanted to discuss a quick high-level comment
<manu> Ian: High level comment so we are most effective over next 6 weeks on this document if this is the focus - two emphases over the next few weeks - build face-to-face agenda, and the other is the capabilities document.
<Ryladog> REMINDER: to please change my affiliation from W3C Invited Expert to Knowbility
<manu> Ian: I see Thu/Fri meeting being a part of that
<manu> Ian: We want to bring all of this stuff into a shared picture of architecture - one way to think about working on this document is - what will help make it useful for that.
<manu> Ian: If that is going to be the technical vision - we may not need to be focusing on phase 3 things, but if we really need the WG's feedback on something, let's make sure to frame things in that way.
<Zakim> padler, you wanted to discuss framing of the document
pat: Thanks to Manu for
editing
... the only comment to Ian's framing on the usage of the
document
... I am hoping to stay away from the word "architecture"
... we are moving away from that and two a set of
capabilities
... the capabilities are to provide context across WGs
... so, for example, an identity WG could see how their work
would fit into the payments work.
... it is not intended to be a detailed architecture
... the document should be broader than that.
<github-bot> [13webpayments-ig] 15msporny pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/1f433881472d7bde48a4d5bbdd828d7ca0cace99
<github-bot> 13webpayments-ig/06master 141f43388 15Manu Sporny: Change Katie's affiliation to Knowability.
<manu> Ian: What make the capabilities not an architecture? If there is a series of things that make payments possible - it feels close to an architecture.
<manu> Ian: It's not that they describe a flow, but they do enable something to happen - don't want to spend a ton of time on this, but raised high-level point so I know how to talk about it.
<Ryladog> I note that this document is using British English (eg Standardised), I think the norm for W3C docs is American English
<manu> Ian: "We'll show the Working Group something - see how their work can be a part of the payments group story" - Some are bound to payments, others are bound to security and we need them to see what we need. Slightly different view of how they fit in - they're not assigned a piece of this stuff, slightly broader set of things. I can live with either.
padler: People are wondering why
the IG would be discussing "architecture"; I think people think
that an architecture is more detailed/technical
... so we are keeping this generally at a broad set of
capabilities.
... some might touch on architecture (e.g., how does loyalty
fit in)
... this is a way for us to provide overall context on
capabilities and how they fit together
<Zakim> manu, you wanted to weigh in
padler: but "architecture" has given people an impression (perhaps too narrow) of our goals for the document
manu: I think I agree with Pat on
what the document's goal is.
... calling something an architecture may tend to make it too
rigid. Although Web architecture is not overly rigid. But my
concern for "payments architecture" it may be perceived as more
rigid than what we intend.
<padler> +1 to Manu's observation...
manu: rather, this document is a
collection of things we need the system to do.
... not a full architectural discussion because it does not say
in detail how the pieces fit together or specific messages that
flow
... rather we can talk about capabilities as "here's what we
think we need, but it's not clear to us yet how it all fits
together."
editorial: "This document describes aset" -> "This document describes a set"
<Zakim> dezell, you wanted to talk about our narrative
[IJ thinks we may need a bit more explanation of the document up front; no proposal yet]
dezell: Pretty much agree with
Manu
... I think the capabilities doc is a useful tool the way we
are developing it.
<Zakim> manu, you wanted to wonder if we can table the broader discussion and think about it for the next week or so.
Ryladog: Want to avoid giving people impression things are set in stone.
Manu: We don't yet have an architecture in mind.
http://www.w3.org/2001/07/19-tag
<Zakim> padler, you wanted to talk about framing current work in the sections of the document
Ian: I wanted to know what we are trying to accomplish so I know how to contribute over the next 6 weeks
<manu> Ian: Ok, I think I have what I need to be able to contribute to the document.
padler: I think the doc also
highlights the work going on in this space
... and thus serves as a map so people don't overlap
<padler> http://www.w3.org/2004/10/27-tag-charter.html
padler: Our goal is in some sense to give people a high-level picture.
<Zakim> manu, you wanted to move discussion back to document
padler: stewardship role of the IG; continuous context
<manu> Ian: We should reflect this understanding in the document - the document needs more framing.
<padler> +1 to updating goals of the document..
<padler> pat can volunteer to take the intro...
Manu: Who wants to write the intro?
<manu> http://w3c.github.io/webpayments-ig/latest/capabilities/index.html#introduction
<scribe> ACTION: Pat to write the intro to the capabilities doc [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action01]
<trackbot> Error finding 'Pat'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.
<scribe> ACTION: paler to write the intro to the capabilities doc [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action02]
<trackbot> Error finding 'paler'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.
<scribe> ACTION: padler to write the intro to the capabilities doc [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action03]
<trackbot> Created ACTION-131 - Write the intro to the capabilities doc [on Patrick Adler - due 2015-08-14].
(IJ notes that we should discuss updating the glossary AFTER the AC review, since we might make changes based on AC review)
<manu> http://w3c.github.io/webpayments-ig/latest/capabilities/index.html#overview-of-capabilities
Manu: It's not clear in 3 what the big lists ("Capabilities") are doing.
padler: I think the front matter
of section 3 needs to say "payments is a big space. so the IG
has attempted to simplify and compartmentalize
capabilities"
... there used to be a simple diagram
... agree that the long Capabilities lists hit people with a
lot (and too soon)
<manu> Ian: This seems like a good exercise to test the thinking - tying the goals back to the use cases - does our model hold - do all these capability blocks go somewhere?
<manu> Ian: Like we discussed before, you can go one way or the other - each capability block says what group it belongs to - for comms it might not be necessary.
[Pat and Manu will take a stab at cleaning this up]
<manu> Ian: I propose we use the definition from the charter and put it in the terminology section and modify the definition based on what's there.
padler: feels to me like we need
to finish the capabilities section first.
... if we are still focusing on digital wallets, then we might
find we need to define them
... more thought needs to go into how to place wallets in the
doc
<manu> Ian: I'm looking at section 4 and not sure I understand its role in the document. I understand 3, here's a small set of groupings that cover everything.
<manu> Ian: Then 5 says - now that you have the groupings, we can go into more detail - I get that.
<manu> Ian: But inbetween, there is this interaction wheel, it doesn't make sense there.
<manu> Ian: The particular diagramming approach may be useful (I don't know yet) as the super clear way to describe flows. I don't think it is conveying anything useful yet between 3 and 5.
<DJackson> +1, this section belongs in an architecture or process flow section
<manu> Ian: One possibility is - we can't do 5 unless we've explicitly said who the parties are - because 5 depends so heavily on it - what their responsibilities are are critical to understanding capabilities.
<manu> Ian: It feels much closer to flow, which we said is not a key part of capabilities, it feels out of place here.
<manu> manu: +1 to Ian.
DJackson: I agree with Ian. Seems like it is about flow or architecture.
<manu> DJackson: I agree, it does seem out of context - it belongs in a section on flow.
<manu> DJackson: If you are defining the entities - they're defined elsewhere in the document.
padler: There are a number of
scenarios where the whole set of interactions happens very
quickly (matter of seconds or minutes)
... and things can be described in a single flow.
... but there are other scenarios where the interactions last
much longer, especially when you introduce commerce
elements
... such as when a user walks into a store and their mobile
device is recognized by the store's system and they receive
offers on the phone
... they may or may not stay in the store and make a
payment....this is part of the "offer" phase.
... but there are other cases with existing offers (e.g.,
coupon I previously got) and I'm leveraging it now when I go
online to use that coupon that I had received.
... so the purpose of these circles was intended to depict that
variety of flows
... multiparty interactions
... I also agree with Ian that doesn't fit in this context.
manu: Three issues:
... 1) seems out of place (thought it didn't seem that way
before)
<padler> +1 to readability...
manu: 2) Images are big and hard
to understand them
... want to be able to take in the picture all at once
<padler> originally it was a bunch of images on one line..
manu: 3) Payments stuff is unique....other specs talk about protocols and you don't usually think of message transactions outside of, say client/server interactions
<padler> Boleto use case is a really good example of this..
manu: 4) Once we start talking
about flow we are getting into architecture.
... so I think we may want to park it elsewhere.
<Zakim> Ian, you wanted to propose an approach
<manu> Ian: I have a counter proposal / extension
<manu> Ian: We have payment phases - these diagrams might usefully augment the use cases document.
<manu> Ian: I could see these interaction wheels in the use cases document.
<manu> Ian: So, that seems to be at the same conceptual level
<manu> Ian: I don't know - maybe we don't talk about financial institutions - feels closer to those descriptions than the ones in the capabilities documents.
<manu> Ian: Maybe we need to pair them more with use cases
<manu> manu: +1 to pairing them w/ use cases.
<dezell> +1 to pairin w use cases
<manu> manu: -1 for volunteering to do that :P
<Zakim> padler, you wanted to suggest that it may be framing of the title too..
[IJ thinks it's too low-level for use cases, but it's closer]
padler: I agree that we need to
change the section. I do think that the way Manu was describing
it, and the discussion around how payments broadly are a series
of sequential, asynchronous interactions.
... would be good to have some examples somewhere in the
document.
(I still think that we don't need those to talk about ***capabilities***)
padler: Payments can be expressed
as a series of interactions among parties
... capabilities should be expressed as interaction between two
parties
... so it will be important to talk about identity between
payer/payee and that will be different from what identity means
between other parties.
IJ: Isn't that already inherent in 5?
padler: We have tried to do that.
<manu> Ian: My proposal - let's remove diagrams for now - when we talk about these things, it's good to be clear about who is doing what.
<manu> Ian: The beginning of section 5 should say a word about the rest of section 5 - series of bullets
<padler> +1 to including in section 5...
<padler> parties of the interaction would be more helpful..
<manu> Ian: Where possible we try to define clearly - when we talk about an interaction, we try to define who the parties to a transaction are. We want to mention what we think is relevant technology. That list is likely to change over time. We also think that you shouldn't infer that the fact that we talk about something in one capability that it must be done in the same way elsewhere.
<manu> Ian: I'd rather do this as a lightweight set of annotations at first.
<manu> Ian: I do think saying, as a bullet point, we describe transactions as clearly identifying the parties - but they are mixing up flow and use cases with the mere fact of identifying parties in the transaction.
<manu> Ian: Chuck them and create an intro.
<Zakim> manu, you wanted to cover rest of editorial work.
manu: Lots to cover still!
... here's my summary
<manu> * 5.1 Security Core
<manu> * Write introduction
<manu> * Write key concepts
<manu> * 5.2 Identity and Credentials
<manu> * Write introduction
<manu> * Write key concepts
<manu> * 5.3 Accounts and Settlement
<manu> * Write entire section
<manu> * 5.4 Payments and Exchange
<manu> * Write introduction
<manu> * Write key concepts
<manu> * 5.5 Commerce
<manu> * Write introductions for offers, discounts, coupons, invoices,
<manu> receipts, loyalty
<manu> * Write key concepts
Manu: In each section we are
missing introductory material and key concepts
... in some cases (e.g., accounts and settlements) it's a big
section and nothing's there yet
(Maybe Adrian would be best person to work on that)
scribe: we need volunteers to divid and conquer
<Zakim> padler, you wanted to ask if the v2 of the capabilities sections were updated..
padler: I need also to review the groups themselves which we updated after the June meeting.
<manu> padler: I need to go back and enhance - coming out of June F2F - we updated capabilities groups, not certain those didn't get back into the document.
Manu: I can do identity.
<scribe> ACTION: dezell to write introduction to "commerce" section [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action04]
<trackbot> Created ACTION-132 - Write introduction to "commerce" section [on David Ezell - due 2015-08-14].
<scribe> ACTION: Manu to write identity/credentials intro to capabilities document [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action05]
<trackbot> Created ACTION-133 - Write identity/credentials intro to capabilities document [on Manu Sporny - due 2015-08-14].
<padler> here's the latest on the groupings... https://www.w3.org/Payments/IG/wiki/UpdatedCapabilityGroups
<scribe> ACTION: Manu to write security core intro to capabilities document [recorded in http://www.w3.org/2015/08/07-wpay-minutes.html#action06]
<trackbot> Created ACTION-134 - Write security core intro to capabilities document [on Manu Sporny - due 2015-08-14].
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: i/It's not clear in 3 what/Topic: Capabilities in Context Succeeded: i/Lots to cover still/Topic: Detail sections Found Scribe: Ian Inferring ScribeNick: Ian Present: Ian Pat Manu jheuer dezell DavidJ Katie Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Aug/0036.html Got date from IRC log name: 07 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/07-wpay-minutes.html People with action items: dezell manu padler paler pat[End of scribe.perl diagnostic output]