Web Payments Community Group Telecon

Minutes for 2012-08-07

Agenda
http://lists.w3.org/Archives/Public/public-webpayments/2012Aug/0004.html
Topics
  1. Decentralized Web app stores
  2. Client-side Asset/Listing publishing process
Chair
Manu Sporny
Scribe
Dave Longley
Present
Dave Longley, Manu Sporny, David I. Lehn
Audio Log
Dave Longley is scribing.
Manu Sporny: in addition to the agenda, something came up on the mailing list
... he asked if payswarm could support a paid app market concept
Manu Sporny: Melvin raised this as a point of interest - http://lists.w3.org/Archives/Public/public-webpayments/2012Aug/0005.html
Manu Sporny: and perhaps we should talk about how payswarm enables decentralized webapp stores
Manu Sporny: to allow people to pay to get access to webapps but then also pay small amounts to use features within webapps themselves

Topic: Decentralized Web app stores

Dave Longley: I would've figured we had a web app use case [scribe assist by Manu Sporny]
Dave Longley: we are trying to cover that use case, maybe we have something about a web game
Manu Sporny: we should probably add this to the use cases
Dave Longley: +1
Manu Sporny: because we are definitely supporting it
Manu Sporny: melvin was interested in getting something together as a proof of concept within the month or at least within 3 months
Manu Sporny: this is a demo we've been wanting to do for a while, so maybe we can talk with melvin and help it get built
Manu Sporny: we have most of the code done (on the payswarm side) for this demo
Dave Longley: I think what we have in the PHP or JavaScript code is done ... we have everything required for doing a demo for selling recipes... Web Apps are not that much more different. [scribe assist by Manu Sporny]
Dave Longley: We do want something a bit different for the automatic purchase part of it... if the web app store sells a game, and they wanted to do the purchase in the background. [scribe assist by Manu Sporny]
Dave Longley: You could setup a budget for the game at your PaySwarm provider, subsequent purchases (as long as they're below the budget threshold you have), they'd be done in the background. [scribe assist by Manu Sporny]
Dave Longley: I'm pretty sure we have that working in the client code in JavaScript... if we don't, it's easy to add. [scribe assist by Manu Sporny]
Dave Longley: Most of what we would need is the infrastructure for the demo itself... [scribe assist by Manu Sporny]
David I. Lehn: i have a question about the message
David I. Lehn: it's talking about paid apps, does that mean app stores like phone apps or webapsp
Manu Sporny: i think he's talking about webapps not mobile apps
Manu Sporny: but it could work for both, but i don't think that's what he wants
Manu Sporny: we have had three groups approach us and ask how payswarm enables webapp stores
Manu Sporny: the ability to sell an HTML5 webapp off of your website or a centralized webapp store
Manu Sporny: we definitely support that use case
Manu Sporny: we could also support an in-phone store app, but we don't have the code to demonstrate that just yet
David I. Lehn: so the webapp store use case would look like our recipes demo now?
Manu Sporny: i think so, but it could extend further to show how to buy extra lives/equipment/whatever for say, an HTML5 game that you originally bought simple access to
Manu Sporny: so there are two things:
Manu Sporny: access to the webapp and the other is in-app purchases
David I. Lehn: it doesn't sound like it's a stretch to come up with a demo for that
Manu Sporny: i'm wondering if there's some existing demo we could leverage
Manu Sporny: if we could wrap an opensource game and hook it up to the fake money development site
Manu Sporny: to show granting access to the game and also show buying say, extra lives within the game when you die
Manu Sporny: it's the equivalent of an arcade style model
Manu Sporny: so i'm hearing that we can help melvin with this and that it wouldn't be a distraction as it's a demo we've always wanted to do
Dave Longley: i agree
Manu Sporny: so we'll ping melvin and see what kind of help he needs to build this demo
Manu Sporny: we can make the demo open source and host it on a subdomain on payswarm.com (eg: games.payswarm.com) or something like that
Dave Longley: i think it would be faster to spin up a demo in node than PHP
Manu Sporny: ok, we can get our current release out and then try to help melvin out on the demo
Manu Sporny: ok, next topic then

Topic: Client-side Asset/Listing publishing process

Manu Sporny: hitting .well-known for the payswarm config and the webkeys will give you the payswarm and webkeys end points
Dave Longley: Yeah, I think that's what we want to do. [scribe assist by Manu Sporny]
Manu Sporny: so, publishing an asset for sale
Manu Sporny: the link to the source is in IRC ... there's a lot of boilerplate in there
Dave Longley: Yeah, the information in the config file is something that you don't want to keep repeating over and over again. It's in the config file so that they don't have to keep typing it over and over again. [scribe assist by Manu Sporny]
Manu Sporny: publishing an asset for sale is a 3 step process
Manu Sporny: so you first need to create the asset and digitally sign it with your previously generated private key
Dave Longley: When we say things like "You have to digitally sign the asset", we mean that there is a call to the payswarm client... payswarm.sign(). No highly technical details that folks need to get into, they just use the method that's provided. [scribe assist by Manu Sporny]
Manu Sporny: the asset is what you want to sell and the listing indicates the pricing for it, etc.
Dave Longley: People using the API don't need to get into any of the technical details about what's happening with the crypto stuff. [scribe assist by Manu Sporny]
Manu Sporny: the listing also indicates the license that the asset is being sold under
...creating the asset is step 1, creating the listing is step 2
...and step 3 is publishing that asset and listing ...
...which can be done on your own website
Manu Sporny: and that listing is decentralized, it can be distributed from anywhere
Manu Sporny: the asset and listing are identified by a URL
Manu Sporny: and anyone can pass them around as they are digitally-signed, you can get them from anywhere, but they typically just live at their URLs
Manu Sporny: so we create an asset, a listing, and then publish them
Manu Sporny: then a purchasing client can just grab them from the URL and do a purchase.
Manu Sporny: so let's go through the code briefly
Manu Sporny: first a config is read in and then we create an asset
Manu Sporny: the asset is created as JSON-LD, which really is just JSON
Manu Sporny: we say that the asset's type is an asset and a webpage, we use an product ontology to mark it up as a webpage
Manu Sporny: the creator of the asset is just the person who created the asset
Manu Sporny: we give the title for the asset and the URL where the asset content can be found, and the provider of the asset, which is the asset's owner
Manu Sporny: and that's all the basic information for an asset
Manu Sporny: but because we're using JSON-LD you can extend this however you'd like
Manu Sporny: you can put whatever vocabulary terms in there you want and it will be digitally-signed
Manu Sporny: and custom applications can display that extra information or do something with it
Manu Sporny: tracking numbers/other details, whatever they want can be added to the asset
Manu Sporny: and payswarm authorities will keep that information around and include it in digital contracts
Manu Sporny: next the asset is passed off to the signature call
Manu Sporny: and the payswarm client does an RSA signature on the JSON-LD object
Manu Sporny: you give it the object to be signed (the asset) and your private key pem and your public key ID which is a URL to your public key
Manu Sporny: that way anyone can fetch your public key and check the signature on the asset
Manu Sporny: next we hash the asset, and the reason we do that is so that the listing doesn't have to repeat the asset itself
Dave Longley: The asset hash is important because when you want to sell something, you're going to assign a price to it. There is a possibility that your asset will change over time. When you create your listing, you want to be very specific about the asset you're selling. [scribe assist by Manu Sporny]
Dave Longley: You don't want somebody to come along and say that you promised to sell them something for $0.05, and you've changed the asset to be worth much more than that. It protects sellers against people claiming that they promised to sell them something they didn't. It's an assurance against situations where the asset changes. [scribe assist by Manu Sporny]
Manu Sporny: we take the asset hash and include that in the listing
Manu Sporny: which we generate next in step 2
Manu Sporny: the listing has a validity period just like say, SSL certificates have
Manu Sporny: this is so that people can offer something for sale but they aren't bound forever to offer that asset for sale forever
Manu Sporny: so if a merchant wants to change their price every week or day then they'll generate their listing using that validity period (one week/one day)
Manu Sporny: they can use whatever makes sense for them
Manu Sporny: the listing also has an ID which is a URL
Manu Sporny: the type is a ps:Listing (a payswarm Listing) and it's also a good-relations offering
Manu Sporny: we might not keep that around in our example, but it isn't part of the spec, just like with the asset you can add additional markup
Manu Sporny: the listing contains the list of people that should be paid (payees) when an asset is sold
Manu Sporny: payees are associated with financial accounts and indicate some amount of money that should be paid to those accounts
Dave Longley: Payee position is important - you specify a rate and a rate type. rate can be a flat amount - rate type will be flat amount. [scribe assist by Manu Sporny]
Dave Longley: There are also exclusive percentages and inclusive percentages for rate types. [scribe assist by Manu Sporny]
Dave Longley: So, there are cases where you want to use exclusive percentage - sales tax falls into this category. [scribe assist by Manu Sporny]
Dave Longley: inclusive percentages allow vendors to take a cut of the total price... so 2% of $2. [scribe assist by Manu Sporny]
Dave Longley: These calculations are affected by where you put the payee in the list. When we talk about payees, we are talking about people that should get paid... not necessarily how much they will get paid (that amount is calculated) [scribe assist by Manu Sporny]
Dave Longley: When you put your listing up for sale, you don't have to know about which PaySwarm authority is going to process your payment. This is where payee rules come in... you can limit who takes a cut of the sale like this. [scribe assist by Manu Sporny]
Dave Longley: For example, you can limit how much a payswarm authority takes for processing your asset - this is good because it's a really decentralized way of who gets the money, and makes sure that the people running the transactions are very much decoupled from who is getting paid. [scribe assist by Manu Sporny]
Dave Longley: All of this happens before you having to talk to every payswarm authority out there... you just publish the listing, If people want the listing, and the payswarm authority wants to process the listing - you will get paid. [scribe assist by Manu Sporny]
Dave Longley: We're trying to take a decentralized, free-market approach to this. There are no centralized parties controlling this stuff. [scribe assist by Manu Sporny]
Manu Sporny: this also allows people to set up a rogue payswarm authority that says "oh yeah, a person paid for this" to trick software into giving people access that shouldn't have access, however, there is a protection against this built into the system
Manu Sporny: you, as a vendor/merchant, specifically say which authorities you trust
Manu Sporny: and you can use a whitelist for this (only trust authorities A, B, C) or just blacklist those that you think are misbehaving
Manu Sporny: we expect there to be a whitelist
Dave Longley: We have to make sure where we avoid problems in the future where PaySwarm Authorities get shut out... if somebody wants to start a new payswarm authority, if they're legit and acting in good faith, they need to get on that list. [scribe assist by Manu Sporny]
Manu Sporny: and that whitelist could be centralized and well known
Dave Longley: We don't want the case where good PAs are not allowed onto the list. [scribe assist by Manu Sporny]
Manu Sporny: and managed automatically similar to how browsers deal with certificate authorities
Manu Sporny: one way we could deal with payswarm authorities getting shut out could be by having the w3c manage the white list ... such that if you pass a test suite and pass some good "karma" system you'd get onto the whitelist automatically
so payees say who gets paid and payee rules say what restrictions apply to additional payees
Manu Sporny: in this demo we can see that there is just one payee and the destination is the account of the person digitally signing the listing (the vendor/merchant)
Manu Sporny: the rate is the price that was set earlier in the program and the rate type is a flat amount
Manu Sporny: the rate is $0.05 here, so that's what the payee will get on sale
Manu Sporny: the payee comment just displays some test information
Manu Sporny: the payee rule places limitations on additional payees
Manu Sporny: this particular rule says that a payswarm authority can take up to 10% of your sale if they want to for processing it
Manu Sporny: this assumes that payswarm authorities must not run this transaction through and take 12%
Manu Sporny: they must limit themselves to be a valid payswarm authority (and to get onto that whitelist)
Manu Sporny: the payswarm authority must be a trusted party
Manu Sporny: the listing next says what the asset is and then what the license is
Manu Sporny: the license can say all kinds of things (it's text) and say "you can do X things with this asset Y times" or whatever you'd like
Manu Sporny: it can simply say it's a direct ownership change, etc.
Manu Sporny: the license hash works the same way as the asset hash
Manu Sporny: to ensure that you're linking to the license you think you are
Manu Sporny: then the listing is signed, just like the asset was
Dave Longley: In case anybody has a question about what happens when a PaySwarm Authority looks up the license and the hash? [scribe assist by Manu Sporny]
Dave Longley: The PA will report that it's a bad listing if the licenseHash doesn't match the license. [scribe assist by Manu Sporny]
Manu Sporny: right, if any of the hashes dont' match, a purchase process will be aborted
Dave Longley: http://listings.dev.payswarm.com/ exists for demo purposes, and the final step registers the asset/listing combo there. However, you can publish to anywhere on the Web that you have write access to. [scribe assist by Manu Sporny]
Manu Sporny: we support both RDFa and JSON-LD
Dave Longley: We will want to say that at a minimum, you'll want to support RDFa and maybe JSON-LD. Other PAs could support stuff like XML, but they won't be inter-operable. [scribe assist by Manu Sporny]
Manu Sporny: so here we just post the asset and the listing to a URL where they'll be published
Manu Sporny: keep in mind that this is a non-HTTPS site, it's just HTTP
Manu Sporny: and the nice thing about payswarm is that this isn't an issue because the asset and listing are digitally signed
Manu Sporny: so they can't be forged here and still result in a valid purchase
Dave Longley: The way this could be mitigated is that the vendor could just revoke their key... then all listings signed using the key would become invalidated. [scribe assist by Manu Sporny]
Manu Sporny: if a vendor mis-signs an listing with a very low price for say, a long validity period like a year
Dave Longley: Yes, key revocation is the best solution for this. [scribe assist by Manu Sporny]
Manu Sporny: so once you've published your asset/listing to a webpage, that's it
Manu Sporny: and that covers the process for making something available for sale
Manu Sporny: the actual code to do this is pretty minimal (we've got some other stuff in there to make the demo run nicely, etc)
Manu Sporny: you don't need much knowledge to do this either
Dave Longley: Yes, so pretty simple process - generate asset, generate listing, digitally sign them, publish them to the Web... then you're selling via PaySwarm. [scribe assist by Manu Sporny]

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