Web Payments Community Group Telecon

Minutes for 2013-12-04

  1. Web Payments at the African Union
  2. Federal Reserve Call for Papers
  3. ISSUE-9: Choice of Price Index
  4. March 2014 Web Payments Workshop Call For Participation
  5. Web Identity
Action Items
  1. Manu to post slides for African Union presentation.
  2. Manu to create skeleton Web Price Indexing specification.
Manu Sporny
Dave Longley
Dave Longley, Manu Sporny, David I. Lehn, Pindar Wong, Joseph Potvin, Brent Shambaugh
Audio Log
Dave Longley is scribing.
Manu Sporny: any changes to the agenda?
David I. Lehn: we should discuss the fed call for papers
Manu Sporny: right, we'll add that to the agenda after the Web Payments at the African Union discussion.

Topic: Web Payments at the African Union

Manu Sporny: we can do that as the item before web payments workshop since it's time sensitive
Pindar Wong: Manu presented in Bali at the Internet Governance Forum 2013. In about 19 hours african union 50th anniversary celebration will kick off. It relates to ICT week and web payments group will be speaking in about 19 hours, linking some of the great work andd tech and policy they've done with mobile payments, we'd like to invite them to join the work of this group, most importantly from the policy level. A big shout out to Mozilla for giving me a Firefox OS phone to show to the AU at the meeting. Myself and Manu will be on that call, hopefully the outreach and dialog will be good.
Manu Sporny: the dates for the workshop will be march 24th-25th, we can tell them the date and the location (Paris).
Pindar Wong: A lot of very important people will be there for this planning meeting. If you look down the list all the names are preceded by "His Eminance/Her Eminance", great follow up from the IGF, hope it will lead to more participation in this group on policy, we'll be opening our fifth IP trading platform in about 9 hours from now as well.
Pindar Wong: here's a link to the African Union their Information Technology and Communication Strategy (ICT) slide deck: https://payswarm.com/slides/2013/au-ict-strategy/
Manu Sporny: here's a link to the African Union and Web Payments slide deck: https://payswarm.com/slides/2013/au-webpayments/
Manu Sporny: thanks pindar!
ACTION: Manu to post slides for African Union presentation.
Manu Sporny: we need to discuss the fed reserve call for papers next

Topic: Federal Reserve Call for Papers

Manu Sporny: as dave lehn pointed out on the mailing list, fed has put out a call for papers, due in 9 days, we haven't done much work on them, we need to get this done and in there, i'm going to take an action to write a position paper based on some of the stuff we've been writing for mozilla and some other stuff, it will be a recap, and we'll point the fed at the web payments work and ask for their input and participation
Manu Sporny: i expect it to be 2-4 pages fairly high-level, important to get on their radar and get a contact from them
Manu Sporny: Dave Lehn sent this out to remind us about the Fed paper submission: http://lists.w3.org/Archives/Public/public-webpayments/2013Dec/0001.html
Joseph Potvin: currently, i'm looking at the wiki right now, the sections haven't been fleshed out yet
Manu Sporny: yeah, really our response is only supposed to answer some of those questions, and with all the travel, etc. we haven't had time to work on it
Manu Sporny: it's mainly a prompt for responses, we'll go ahead and say what we've been working on, summarizing all the work, price indexing, payments protocol, ripple, bitcoin, etc. and say there's a group working on all the things you've identified as issues and we'd like the fed to take part in that work and follow up with them later on in the yera
Joseph Potvin: i'll arrange to commit some time over the ... what's our deadline?
David I. Lehn: next friday
Manu Sporny: i'm hoping to have something to send by upcoming monday
Manu Sporny: hopefully you can add your thoughts to it after that and then i'll send it in
Joseph Potvin: ok

Topic: ISSUE-9: Choice of Price Index

Manu Sporny is scribing.
Joseph Potvin: On the discussion on github, I think Dave and I worked out a scenario on how this could be implemented, from a big picture point of view, by providing a choice of indexes, it creates an open market for producers of indexes. Most wont, some will.
Joseph Potvin: Classes of vendors who are similarly impacted by certain forces in the market will tend toward one or another index. So trust models can be created around certain index providers. It's a different scenario from autonomous providers like Bitcoin. It's a different sort of financial instrument - the price index.
Joseph Potvin: From a legal point of view, in terms of language and the way it's implemented, it's significant that the indexes are provided as alternative exchange rates, a whole bunch of different laws come in. if it's just algorithmic pricing, that's just in contract law and things are simpler. There is a deep principle that buyers and sellers can negotiate prices in that way, we should refer to...
...it in that manner.
Dave Longley: I think we're on the same page on the goals, I think the discussion was around how the technology would work. I think we sort of came to an agreement that we can break this thing up into its respective parts. Make sure payment providers don't have to implement things they don't need to implement. We should only make the people that need this feature implement it.
Dave Longley: So the core ecommerce protocol would deal w/ listings. Listings could include price index information, but customer sites wouldn't have to do that. Sites can provide this feature, not the core protocol.
Dave Longley: I think we more or less came to a good conclusion on how we could do this. We need to have a spec for how price indexing should work, but not require payment processors to implement it.
Dave Longley: We could have payment processors support other things - like currency conversion. It allows them to provide value-add services.
Joseph Potvin: First, on the documentation side. Where should we document this?
Dave Longley: We have a number of different specs. We have Web Identity specs, we have Web COmmerce specs, HTTP Signatures. What we're looking at is another spec on how you do price indexing.
Dave Longley: We can talk about how a listing is generated if you want to use price indexing. What the spec would say is: If you take these inputs from a vendor, you can generate this final price listing output. We could also define the protocol for communicating w/ the price indexing services.
Joseph Potvin: Who will initiate writing the spec?
Dave Longley: I think we should present this to the group as another spec and be clear how this could be another thing that could fall under the charter.
Joseph Potvin: What are the things to do between now and March.
Dave Longley: We need to spec out what an API for a price indexing service would look like. What the inputs and outputs are.
Dave Longley: We need to describe the purpose of this. How people could implement their own or how payment processors could implement this as a service.
Dave Longley: If you are a vendor and you want to use price indexing, you would do XYZ.
Manu Sporny: Here are the actual steps: 1) Create a skeleton spec for Joseph and his team to fill out on payswarm.com, 2) Flesh out the spec to explain the basic protocol (vendor contacts price index, uses that information to generate listing, JSON-LD messages sent back and forth, etc.), 3) Publish a paper for the Web Payments workshop on price indexing, 4) pick the price indexing stuff up as a working group item.
Manu Sporny: I still do have concerns that Dave Longley and Joseph are slightly out of alignment. We have to tread a fine line here. Price indexing is important, and it's completely foreign to Web Developers. If we put it in the core protocol, we run the risk of the entire thing not being implemented because it's too complicated. If we don't put it in the core protocol, we run the risk of price indexing not being implemented at all because it's an optional feature. I think there is another option that hasn't been discussed, and that's to include the price index and a price variability amount. So, if the price varies too much, then the payment processors will mark the listing as invalid. The upside to this is that it doesn't complicate the core protocol too much, but still allows listings to be invalidated if the price index shows that the price has been too volatile (such as in the Bitcoin case).
Joseph Potvin: Having vendors choose their price index - many people are not expecting to have the right to choose. There is going to be a fear of freedom. There will be FUD. It's not my intention to not to try to impose the use of this, but I do want to make sure that we don't block it out. So, as long as that choice is there, there can be a slow multiyear realization that it puts a lot more power into peoples hands.
Joseph Potvin: They can still trust third parties.
Dave Longley: My concern is hitting every price point for every currency that would be available over a 5 minute period.
Dave Longley: for every vendor [scribe assist by Dave Longley]
Joseph Potvin: How this would play out is hard to know at the moment. That is, what direction things will go is going to be hard to determine. The speculator intent, like volatility, the goods and services industry hates volatility. So indexes that offer good price stability don't have to be updated on an hourly/daily basis. So, where the predominant market demand for these indices will go, we'll have to see.
Manu Sporny: I don't buy the whole scalability problem. We have tons of services on the Web that are hit more frequently than a price indexing service would be hit. We can design these things so that payment processors don't bear the brunt of the processing here. For example, the difference w/ the proposal I'm making is that the price information can be evaluated and cached by the vendor, payment processors are completely out of the loop until the time of purchase. Then, at the time of purchase, the payment processor just needs to check w/ the price index once per refresh cycle, we can depend on HTTP Cache headers for most of this. Very few indexes are going to fluctuate as wildly as Bitcoin is, and even in that case, a 10 minute window between Bitcoin price refreshes wouldn't be a terrible concession. As a result, the payment processors and the payment price index servers don't really have to do that much extra work. Now the question is, what happens when the price deviates from the price index by more than 5%? Reject the listing and notify the vendor? Or allow the payment processor to modify the price? I don't have a strong opinion either way, but the first one would be easier to implement.
Dave Longley: We'll have to be careful w/ that. Version 1 might just be to reject it by sending it back to the vendor. This is important, because this is going to happen w/ other things.
Joseph Potvin: So we could give the option of 1) reject, or 2) revise the listing.
Dave Longley: These are minor changes, so I'm fine w/ what Manu's proposed because it seems like it scales and doesn't put undue burden on payment processors.
Dave Longley: Once we get a skeleton up there, I can spend a little time about how we communicate w/ a price indexing service.
Joseph Potvin: To be clear, what my colleagues are doing here - we're going to lead documentation and lead source code generation. I'm also collaborating w/ 5+ price index providers, so there will be work from those areas.
Manu Sporny: Yes, very important to get others into this group. External parties that want to implement the spec are important.
Joseph Potvin: I need to convince them that it's good to make this information semi-public
Manu Sporny: Index providers don't really have to make this open data. The price indexing server is more or less an oracle - you ask it a question, it gives you an answer.
Dave Longley: There might be something we can figure out where we can express more information about the index. Getting an implementation done will go a long way to showing people how this works.
Joseph Potvin: What specs should I look at to get an idea of what needs to be written?
Manu Sporny: These are the specs that you can look at as an example: https://github.com/web-payments/payswarm.com/tree/master/specs/source
ACTION: Manu to create skeleton Web Price Indexing specification.

Topic: March 2014 Web Payments Workshop Call For Participation

Dave Longley is scribing.
Manu Sporny: This is the preview for the Web Payments workshop call for participation. It's a draft, DO NOT CIRCULATE IT: http://www.w3.org/2013/10/payments/
Manu Sporny: 24-25 March 2014, Paris, France
Manu Sporny: the landing page for the workshop is done, it gives background on what we're trying to achieve, the types of orgs we expect to show up to the workshop in paris, march 24-25 2014
Manu Sporny: Palais Brongniart (La Bourse)
Manu Sporny: it's in the the old Paris trading floor
Manu Sporny: we have probably around 13 program committee members, we want to get 20-25
Manu Sporny: once we have the program committee together, we have chairs in place, we hope to make an announcement soon
Manu Sporny: i told dave raggett we would simplify the goals and scope of the workshop page, right now it's kind of a wall of text
Manu Sporny: getting the rest of the program committee members on board is important, we'll do that in parallel with the announcement
Manu Sporny: we want to get it out early in december because it will take people some to get spun back up next year (and holidays, etc)
Manu Sporny: and it will take some time for us to review it, papers, etc.
Manu Sporny: we can't delay publication of this too much longer than we already have before doing the official call.
Joseph Potvin: i'll get back to you offline with specific thoughts about the agenda

Topic: Web Identity

Manu Sporny: while in HK i put together a quick Web Identity spec because it's something that we've been talking about for a while without having a spec, we do have an implementation or some version of this for payswarm
Manu Sporny: it is it pretty specific, the way we're going to do identities on the web is... you can have multiple identities, a url associated with each one, you or orgs can read/write to that URL (placed into that identity), validation of your citizenship (US/canadian/chinese/whatever) can be digitally-signed and added to your identity so you can have a mechanism for proving your citizenship on the web
Manu Sporny: or other data, this is important for KYC for banking
Manu Sporny: we're hoping this information can be used to very easily do KYC online
Manu Sporny: security is also key, so access control lists are important, creator of the identity is in ultimate control, you give people right/revoke the privilege of others to read/write specific piece of information
Manu Sporny: you could share your citizenship with your bank but only your email address with some other website, etc.
Manu Sporny: you could give access to allow services to get the latest version of your information
Manu Sporny: most of the pieces of information that are important to validate you can associate a digital signature with
Manu Sporny: the gov't can associate DS with your citizenship info
Manu Sporny: only gov't can then make that assertion
Manu Sporny: you can DS your own information so only you can make that assertion
Manu Sporny: prevents forgery
Manu Sporny: so the spec is about how to store/show identity and read/write info
Manu Sporny: one more thing, kingsley and some others who are part of the RWW group that we're trying to collaborate with, and there's another similar initiative called WebID at w3c that has been going on for many years now, what we're proposing is similar but has important differences, we've already done an analysis of WebID and it seems like it's not something we could use very easily
Brent Shambaugh: So you can't use a WebID URI?
Manu Sporny: You can use a WebID URL, but the information at that URL and how you access that URL may not be quite aligned. It is possible to have something that conforms to both the WebID and Web Identity specifications.
Joseph Potvin: what's the criteria for putting something on the mailing list vs. over at github?
Manu Sporny: we like to keep general discussions on the mailing list, specific technical stuff that's nitpicky happens on the github tracker. It's hard to differentiate one from the other sometimes.
Joseph Potvin: can i point to github when writing to the mailing list?
Manu Sporny: yeah that's good, technical details on github, high level design on mailing list

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