Web Payments Community Group Telecon

Minutes for 2014-04-16

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

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.