Web Payments Telecon Minutes for 2012-08-07

Thanks to Dave Longley for scribing! The minutes for today's telecon are
now available here:


Full text of the discussion follows for archival purposes at the W3C.
Audio of the meeting is available as well (link provided below).

Web Payments Community Group Telecon Minutes for 2012-08-07

   1. Decentralized Web app stores
   2. Client-side Asset/Listing publishing process
   Manu Sporny
   Dave Longley
   Dave Longley, Manu Sporny, David I. Lehn

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
Manu Sporny: Melvin raised this as a point of interest -
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

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

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
   ...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
Manu Sporny:

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

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:

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:

Manu Sporny:  we take the asset hash and include that in the
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
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
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
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
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
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
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:

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:

Manu Sporny:  the payee comment just displays some test
Manu Sporny:  the payee rule places limitations on additional
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,
Manu Sporny:  the license hash works the same way as the asset
Manu Sporny:  to ensure that you're linking to the license you
   think you are
Manu Sporny:

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
Manu Sporny:  right, if any of the hashes dont' match, a purchase
   process will be aborted
Manu Sporny:

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]

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?

Received on Tuesday, 7 August 2012 19:45:19 UTC