- From: <msporny@digitalbazaar.com>
- Date: Thu, 17 Apr 2014 00:55:29 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes
for this week's Web Payments telecon are now available:
https://web-payments.org/minutes/2014-04-16/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2014-04-16
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0116.html
Topics:
1. Organizing In-the-Field Use Cases
2. Organizing Web Payments Workshop Use Cases
3. Use Cases Organizers/Volunteers
4. Use Cases Output Document
Action Items:
1. Manu to create a page for broad categories for use cases and
transfer mailing list use cases to that wiki page.
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, David I. Lehn, Brent Shambaugh
Audio:
https://web-payments.org/minutes/2014-04-16/audio.ogg
Dave Longley is scribing.
Manu Sporny: Today, we'll be trying to organize the use cases
into something we can feed into the upcoming web payments
interest group, then figure out how workshop input fits in, then
get volunteers for use case work. The goal is a consistent,
updated use cases document for the upcoming Web Payments IG work.
David I. Lehn: Nope
Topic: Organizing In-the-Field Use Cases
Manu Sporny:
https://www.w3.org/community/webpayments/wiki/WebPaymentsUseCases
Manu Sporny: Brent has done a great job getting all these use
cases documented on the wiki. There's a lot of data there, brent
has started summarizing some of the information there at the top,
what we're trying to here is take this list and demonstrate that
these are the use cases taht are already supported by many
players out there and then we want to find the most common use
cases in the area, then we're taking use cases from the workshop
which are more forward looking future use case sthat would be
part of new standards on the web
Manu Sporny: Brent can you talk about the current use cases
you've documented?
Brent Shambaugh: Yeah, starting at the top, just going to go
over the major themes/areas.
Brent Shambaugh: There's a highlights section at the beginning
Brent Shambaugh: And it splits things into APIs, developers,
technologies that allow for a prepaid card, cryptocurrencies,
things that are based on the bitcoin technologies, some of them
seem to be very similar with the functionality, there's also tech
like prepaid card you may get in a store that you then can use
online,
Brent Shambaugh: Apps that makes your smartphone become lots of
different credit cards, originally developed stripe technology
for these credit cards
Brent Shambaugh: Take this and put it in a phone, lots of
fitting legacy technologies into more technical framework, then
there are several techs that rely on card readers, they may have
an API, or have a card reader you attach to your phone like
square so you can accept payment like that
Brent Shambaugh: Then you also have things where you get some
kind of number you can pay with, e-cash for example, techs that
use NFC, techs that use bluetooth low energy, and using a QR-code
to pay with mobiles, like starbuck's
Brent Shambaugh: Starbucks is kind of a leader in the mobile
payments QR/bar code payments and there's certain cases where
you'll be able to pay for your items before you go to the store
so you don't have to wait in line, some form of cash, some techs
allow you to pay within a mobile app, and then there are several
techs that emulate your card. Subscription seems to be a common
use case as well.
Manu Sporny: Go back to techs associated with your credit card
image, how do those work?
Brent Shambaugh: You may take a picture of your credit card but
it's in your app so you can use it as your credit card in a way
Brent Shambaugh: So for example, you can take pictures of the
cards and store them, then pay using those cards.
Brent Shambaugh: That's something to look at again
Brent Shambaugh: Subscription payments, set up, it continues to
charge the card on a scheduled basis, there's stuff to do
refunds, different options for that depending what your API is
Brent Shambaugh: There is also automatic application of
discounts, and APIs to list products for sale on a site.
Manu Sporny: By list products you mean you can use the API and
submit something to a store and your product will be listed on
the store?
Brent Shambaugh: It might be as simple as listing the item on a
website, let me get an example...
Brent Shambaugh:
https://www.2checkout.com/documentation/libraries/node/api/products/update
Brent Shambaugh: That's an example of listing products via an
API.
Brent Shambaugh: So conditional payments using some
pre-determined agreement.
Manu Sporny: So, in the future, if you could elaborate a bit
more on the list products conditional payments and coupons and
the rest of them in the list, it's hard to understand what the
functionality provides, you can guess you can register a product
with the store, but exactly ... what does the API look like and
elaborate a bit, maybe a sentence or two... what it looks like is
that these broad categories that you have up top with the ... a
lot of these that you put each payment provider under could be
reworded as use cases, the categories can be, for example,
disputes within the API could be expanded to "a mechanism is
provided to the customer to allow them to click a link to dispute
a transaction after the transaction has occurred and that link is
provided in the digital receipt at the time of sale"
Manu Sporny: That's something we could work with, assuming
that's how balanced, paypal, stripe, work... just reword it so
that it matches what they do in the most generic way
Manu Sporny: Make sense?
Brent Shambaugh: Yes
Manu Sporny: You've categorized each of these into generic techs
and we could go further and make a generic use case, for example,
for techs that let you save cards in the app, we could change
that to "save a physical credit card into the application and
then use that credit card information to make a payment online"
Manu Sporny: That could be a use case
Manu Sporny: The next step here might be to iterate through the
broad categories at the top to transform these high level
categories into a 2-4 sentence use case
Brent Shambaugh: That could be helpful
Manu Sporny: That's what we'll be using as input to the web
payments interest/business group, they need to know that that use
case is already supported by X, Y, Z payment processor, we don't
have that now and if we don't then the work we're doing isn't
clearly influenced by real world data
Brent Shambaugh: There's also this that Natasha has updated:
https://github.com/w3c-webmob/payments-use-cases
Manu Sporny: Do you feel like these categorizations are complete
or does more need to be done?
Brent Shambaugh: More needs to be done, there's a lot of data
here.
Brent Shambaugh: There might be some more to look at, definitely
Manu Sporny: I'm trying to figure out a way that we can easily
divide and conquer on this work, when we were working in the
microformats community many years ago, we built an app that would
let you type out features and then for each product/website you'd
go through and say whether or not the feature was supported, at
the end you had a big database you could run stats on, but that's
a project in and of itself
Manu Sporny: What i'm saying is that at some point we're going
to have to list all of these features in a way that allows to
easily analyze the data, right now it's a big huge website,
that's not a bad thing, that's just the first iteration which we
need, but now we need each feature into a use case or set of use
cases to figure out which features are most common
Manu Sporny: For example, being able to go to a website and
click a pay button to pay the merchant is the biggest feature
that all the apps provide, but the important thing for that use
case is that you're directed to another website, it doesn't
happen in the merchant website
Manu Sporny: From an operational/coding standpoint, that's
important to note even if it is an implementation detail
Manu Sporny: I think it would certainly help if you just took
the broad categories at the top and created use cases out of
them, and saying braintree, paypal, stripe, etc. all support this
use case is very useful, then we have to make another pass
through and determine whether or not there are missing use cases
that are fairly/broadly supported by other payments players
Manu Sporny: Does that make sense, Brent?
Brent Shambaugh: Yes
Manu Sporny: Anything else on the high level use cases?
Manu Sporny: We'll be chatting with Andrew Mackie in 10 hours
about this. He usually can't join these calls because he's on
australian time which is the middle of the night for him right
now. He's going to try and help a bit with these as well, so we
should be on for that tonight
Manu Sporny: Specifically with the web payments use cases, the
ones that exist out there today, any concerns/questions before we
move on?
No concerns, group realizes that more work needs to be done and
more categorizing and elaboration on each use case is needed.
Topic: Organizing Web Payments Workshop Use Cases
Manu Sporny: The use cases that came out of the Web Payments
Workshop are here:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0043.html
Manu Sporny: While the web payments workshop was going on, we
had a person that was specifically allocated to be a use case
scribe, their primary duty at the workshop was to capture use
cases, to listen to people and capture the use case that the
person seemed to be trying to express. When we went and cleaned
up all the workshop minutes we extracted these use cases and sent
and email to the mailing list on each one of these use cases
Manu Sporny: So i'll go down the email with those use cases to
give people an idea of what's in scope and what's out of scope.
Manu Sporny: Going back to the main outcomes of the workshop,
there was a fairly big desire to work on identity, payment
initiation, and digital receipt
Manu Sporny: So that means things like coin and loop, while very
interesting, the idea that you'd put all your credit cards on a
device and be able to switch It's neat but doesn't have all that
much to do with web payments, other than being able to express
using a card who your payment provider is, a lot of the hardware
based stuff seems to be out of scope, the hardware based stuff
seems to supprot the payments process, when we're talk ing
specifically about web protocol-level stuff. While 2-factor auth
is very important for security purposes and 2-factor will play
into the payments stuff, this group probably won't be working on
it other than liaising with these groups to ensure you can do
2-factor on a payment if you need to.
Manu Sporny: We have to take these use cases and say there are a
number of sites that support some kind of hardware-based payment
today, but that is more than likely not what the web payments
group will be working on
Manu Sporny: I'm going to go down the list and try and say if
they are in scope for this first payment iteration document
Manu Sporny: Each topic is listed before the use case to give
some context about the use case
Manu Sporny: So, for example - Topic: Alternative Currencies -
Ven and HubCulture
Manu Sporny: That would have something like this: Use Case: Bots
that execute financial operations on behalf of users.
Manu Sporny: This is about algorithmic trading/purchasing
Manu Sporny: We're laying the ground work for that to happen,
but the APIs for how to interface with or manage these bots are
far out of scope for the first iteration
Manu Sporny: Use Case: Personal vault can host
information/assets and issue ids
Manu Sporny: This is useful for various things (e.g. payments)
Manu Sporny: That's in scope, the idea of a digital wallet was
something that people were very interested in, and having a
personal vault for your identity would be important
Manu Sporny: That's an example that's certainly in scope for the
first iteration based on output from the workshop
Manu Sporny: Use Case: Managed access to personal
identity/attributes as economically valueable things.
Manu Sporny: This was about being able to store valuable assets
(including credentials) in a payment system
Manu Sporny: That's also in scope
Manu Sporny: Hopefully that outlines how we'll determine what's
in scope/what isn't
Manu Sporny: Any questions?
Brent Shambaugh: The bots, when you're using linked data, isn't
that kind of part of the use case? Linked Data?
Manu Sporny: We're building a foundation for the bot case w/
Linked Data, but saying we'll write a specification that details
how you do automated (bot-based) purchasing is out of scope
Manu Sporny: We're getting into a space where bots could buy and
sell for us on our behalf, but i don't think we'll be creating a
spec to standardize that in the next 2-3 years because there's no
groundwork there. We're building the groundwork.
Brent Shambaugh: Could you be using linked data so you could
keep track of all your transactions on your different sites, so
you could find out exactly how much tax you need to pay this year
Manu Sporny: Yes, a bot could keep track of your buying/selling
and because there's all that linked data that says there's sales
that happened on ebay and where it was sold, which state
sold/bought, etc. then it could file your taxes for you
Manu Sporny: But we're not going to write a spec for that yet
Manu Sporny: So what we need to do is put these use cases into
buckets: "identity", "initiation of payment", and "digital
receipt"
Manu Sporny: Those seem to be the buckets where there was rough
consensus, if use cases don't fit into the buckets then they are
either unknown or out of scope for the first iteration
Manu Sporny: There might be a fourth category "unknown" where we
don't know how this stuff will fit into what we want to do, and
we put those use cases into that and the web payments
interest/business group can figure out where those fit
Brent Shambaugh: I'm looking at the list, URI scheme for
payments?
Manu Sporny: Yes, yandex was saying it would be nice if there
was a URL to say who you were paying, etc., just a payment link,
which we actually wrote a spec for a while ago, and we already
did the work on that and found out that you need to actually work
on the protocol not just the link
Manu Sporny: There are a lot of these use cases, there were a
ton and we don't have the time to go through it on the call and
other people will need to put them into those three buckets so we
can talk about them in more detail
Manu Sporny: Anything else on this particular agenda item?
Brent Shambaugh: Who will work on this? just start working on it
and put things into buckets and other people will jump in and
discuss?
Manu Sporny: Yeah, if you can start that it would be great, i
was going to jump in and work on it, if you can get it started
and put it on a separate wiki that would be helpful
Manu Sporny: To store digital identity credentials online,
hubculture, ven supports that
Manu Sporny: Since you have a lot of this in your head already
it would help if you started this ... create a wiki page and then
start categorizing into the 3 categories ... there are actually
5: "identity", "payment initiation", "digital receipts", "we
don't know where this goes, but it's in scope", and "this is out
of scope for the next 3 years, etc"
Manu Sporny: I could try just setting up that page today, i'll
do that
ACTION: Manu to create a page for broad categories for use cases
and transfer mailing list use cases to that wiki page.
Manu Sporny: I'll create the broad categories and start
classifying a couple of them and then you can classify the rest,
would that work for you, brent?
Brent Shambaugh: Sure
Topic: Use Cases Organizers/Volunteers
Manu Sporny: I will help out where i can here at a high level,
Andrew Mackie and Brent may also help, once we have them in
pretty good shape we could .... we've got a use cases document
that we've had for a very long time, it was one of the first docs
we worked on
Brent Shambaugh: Would that be a template?
Manu Sporny: https://web-payments.org/specs/source/use-cases/
Brent Shambaugh: So it's more readable?
Manu Sporny: I put the link to the use cases doc in IRC, we want
to list what the use case is and then list what the requirements
are to achieve that use case
Manu Sporny: And the reason these use cases and requirements are
so important is because we use that to determine if the tech
we've created applies to 80% of the use cases then we're in good
shape, if it's 20% then we've got a problem and we need to cut
use cases down or reconsider what the spec is capable of doing
Manu Sporny: For right now, brent, andrew, and myself will try
to look at the use cases and boil them down, i think maybe we
could pull in natasha from time to time to look at the use cases,
but right now it looks like we need to make a first pass over it
and make it a manageable set of use cases there are too many
right now
Manu Sporny: When people look at all of those use cases they
have a hard time figuring out which ones we're working on and
which we will push off to another time, so we need a much smaller
list for those 3 buckets
Manu Sporny: I would imagine that we'd go through 3-4 iterations
here, first was what you did brent, surveying what's out in the
field and getting input from web payments workshop, second
iteration is categorizing into those 5 buckets, and then we can
try and combine use cases to be more succinct in what we're
trying to achieve
Brent Shambaugh: https://github.com/w3c-webmob/payments-use-cases
--- how to relate this ?
Manu Sporny: We may even want to rate (during the 4th iteration)
them as the level of desire for the feature, is it highly desired
or would people not mind it not being in the first iteration,
etc.
Brent Shambaugh: This was updated quite recently after the
workshop (link in IRC) natasha and others were working on this
Brent Shambaugh: They have their own kind of use cases going on
Manu Sporny: Yeah, we'll want to integrate that as well
Brent Shambaugh: I wasn't sure where that was coming from, from
the workshop or what
Brent Shambaugh: Maybe what i was producing was a little
confusing and Natasha wanted to clean it up a bit
Manu Sporny: That's a pretty good document -- what natasha has
Manu Sporny: We're probably going to want to pull all of these
in as well
Manu Sporny: They may or may not have better categories
Manu Sporny: They've marked mobile-specific ones
Manu Sporny: We're going to want to pull these in as well, just
at least to make sure that we've got it clearly ... so we've got
these use cases listed somewhere
Manu Sporny: This is not an easy task to pull all this
information in and put it together
Manu Sporny: Ok, the final thing that we have here is the use
cases output document
Topic: Use Cases Output Document
Manu Sporny: What we're shooting for is a use cases document ...
and it may be that we're talking about three different use cases
docs, identity, payment initiation, digital receipt, but we'll
have them all in one document with 3 sections, then we'll put
each use case in those sections and then we'll have a section at
the very end for future use cases and that ... if we can give
that to the Web Payments IG then they can determine whether or
not ... they can focus on that and then whittle that list down to
what they think is achievable in the first iteration of the
technology
Manu Sporny: Anything else about what our output should be as
far as use cases are concerned?
Manu Sporny: We've got about maybe a month to get this stuff
together, it's not a lot of time, if it's half-formed we can
still hand it off to the IG, but it's important that we have
something for them to start with rather than them just having all
this raw data
Brent Shambaugh: I want to make sure we don't throw anything out
Manu Sporny: There's going to be an aspect of that where we
throw out a use case that should have been in there, but someone
will hopefully mention that and we'll get it back in, we don't
want to delete the data ... use cases would just fall into the
future list (things to achieve after 3-4 years) and people can
scan that list and help decide if we need to move them back into
more immediate use cases to cover
Manu Sporny: Anything else for the call today?
Manu Sporny: Virginie and Wendy couldn't make it to discuss
OWASP, we'll shift that to another telecon
Received on Thursday, 17 April 2014 04:55:52 UTC