- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 23 Sep 2011 14:54:06 -0400
- To: Web Payments <public-webpayments@w3.org>
The minutes for yesterday's call are now available here, thanks to Mike Johnson for scribing: http://payswarm.com/minutes/2011-09-23/ Full text of the discussion follows, as well as a link to the complete audio transcript: Web Payments Community Group Telecon Minutes for 2011-09-23 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2011Sep/0004.html Chair: Manu Sporny Scribe: Mike Johnson, Manu Sporny Present: Manu Sporny, Patrick Strateman, Amir Taaki, Mike Johnson, Jeff Sayre, David I. Lehn Topic: Introduction Manu Sporny is scribing. Patrick Strateman: Hi, I'm Patrick Strateman - I'm here on behalf of Bitcoin Consultancy Manu Sporny: Amir Taaki said that bitcoin folks are interested in a URI scheme? Patrick Strateman: Bitcoin address is pretty simple right now, a way of opening the payment window in the bitcoin client. Patrick Strateman: Regular bitcoin addresses are a hash of a public key - want to make it simpler. Amir Taaki: Our request is here: http://privatepaste.com/648ddfd486 permalink to Amir's request: http://lists.w3.org/Archives/Public/public-webpayments/2011Sep/0004.html Manu Sporny: We are looking at bitcoin integration into PaySwarm, so we'd be happy to help author that spec or provide guidance. Glad to see interest from Bitcoin folks in W3C Web Payments / PaySwarm work. Manu Sporny: Any updates/changes to agenda? No changes requested. Topic: PaySwarm Use Cases Review (continued) Manu Sporny: We had reviewed quite a number of use cases last time: http://payswarm.com/minutes/2011-09-16/ Manu Sporny: Let's continue reviewing and accepting use cases - next up is content and payment metadata Topic: Content and Payment Metadata http://payswarm.com/specs/payswarm-use-cases#content-and-payment-metadata Manu Sporny: We are trying to automate the purchase process by the browser. The basic requirement is the ability to express assets for sale via a Web page as well as listings that describe how the asset should be sold (licenses, payment amounts, etc.) Manu Sporny: The end-goal is to have the purchase process both decentralized and integrated tightly with the Web browser. So, we need some sort of meta-data in HTML mechanism to do this. The current spec depends on using RDFa 1.1 to accomplish the expression of metadata in the page. Jeff Sayre: +1 Manu Sporny: +1 to support this Mike Johnson: +1 Patrick Strateman: +1 - Sounds good Manu Sporny: Okay, Content and Payment metadata is accepted as a use case. Topic: Price Negotiation Mike Johnson is scribing. Manu Sporny: http://payswarm.com/specs/payswarm-use-cases#price-negotiation Manu Sporny: Price negotiation allows dynamic pricing and can help enforce good market pricing. Was used in the original Bitmunk product. Manu Sporny: Example of price negotiation. Seller offers data for sale at a rate of 10 cents/GB. Buyer asks for 8 cents/GB versus 10 cents/GB. Seller can decide if they want to accept the lower figure based on if they have any spare bandwidth that is not being used. Manu Sporny: Lots of work on the client-side to implement. Client would be very complex. We want to add support in future, push off for now. Suggest that we add to PaySwarm 2.0 use cases. Mike Johnson: Agree. Move to PaySwarm 2.0 spec. Jeff Sayre: Priceline example. They will want negotiation, so it's an important use case - but agree that it's not for now. Manu Sporny: Okay, this use case is deferred to PaySwarm 2.0 use cases. Topic: Multicast License Acquisition Manu Sporny: http://payswarm.com/specs/payswarm-use-cases#multicast-license-acquisition Manu Sporny: Multicast license acquisition. This use case allows people to buy a license independently of the data. It effectively splits license acquisition from content acquisition. Manu Sporny: You must be able to buy a license to something from one location, but get the content from another location. Manu Sporny: Data stream example - I buy access to a movie from the movie studio, but have a local content distribution network provide the data stream for me because it's faster. Manu Sporny: Third point, enabling this via multicast, is unclear. The technology is not well defined yet for IPv6 multicast / MBONE content. Or how this works with Content-Centric Networking. Manu Sporny: I suggest we drop the last bullet point. Push multicast data aquisition off from PaySwarm 1.0 Patrick Strateman: Agrees splitting license from content is a good idea. Patrick Strateman: Multicast may be too specific at this point. Manu agrees. Jeff Sayre: Makes sense. CDN (content delivery networks) could use this mechanism. MicroCDNs would find benefit in this. Manu Sporny: Multicast means technical multicasting. But this is too specific - we may not want to say anything about what protocols are used to deliver the content. Manu Sporny: We keep going back to Netflix as an example. Someone could purchase access to content from Sony Pictures, but choose their download source as Netflix. Mike Johnson: I was going to agree - we did build this into bitmunk - the idea of splitting license from content doesn't happen w/ physical goods, but it is possible with digital goods. [scribe assist by Manu Sporny] Mike Johnson: Buying a license from Best Buy and downloading from Netflix could be an option. [scribe assist by Manu Sporny] General agreement to accept first two "Requirements" bullet points for this use case, but reject the third one. The use case should be rewritten to make a bit more sense w/o the third requirement bullet point. Topic: Licensing Access to Extra Content Manu Sporny: http://payswarm.com/specs/payswarm-use-cases#licensing-access-to-extra-content Manu Sporny: This use case covers the need for a verifiable digital receipt of sale. A digital receipt allows one to access value-added content from other sites. Manu Sporny: Purchasing content via PaySwarm gives you digital receipt today, so we support this use case now. Manu Sporny: Indie band example - you buy their digital album and have the digital receipt for that. You provide the digital receipt to the band's website a year later and get access to their latest tour videos and backstage videos. Merely providing the receipt gives you exclusive access to value-added content. Manu Sporny: The other important bit about the receipt is that it can be verified by a third party - which means that digital signatures are a requirement. Mike Johnson: This is important for consumer protection - proof of sale today is almost entirely dependent on the seller website... this goes a step further - there is a way to prove that the receipt of sale is valid without having to go back to the seller. [scribe assist by Manu Sporny] Jeff Sayre: I agree, this is important. Patrick Strateman: Digital signatures from merchants for consumer sales is very important. Manu Sporny: Ok, then this use case is accepted. [scribe assist by Manu Sporny] Topic: Batching Micropayments Manu Sporny: http://payswarm.com/specs/payswarm-use-cases#batching-micropayments Manu Sporny: This example explores a photography album that somebody puts together and sells. They want some amount to go to them and the rest to go to charities. Payments are split among the creator and charities that the creator has specified - could be 10, could be 100 different charities. Manu Sporny: Other example, multiple artists working together on same content. Online comic artists creating a single book. Manu Sporny: There could be 20-40 people participating - product put out as complete book. Manu Sporny: Royalty splits are automatically handled. Micropayments (royalties) are split to each author. Manu Sporny: Requirments of this use case are to specify arbitrary payment accounts. It could be a large number of payment accounts. No limits (10,000 people should be possible). Jeff Sayre: Integral to my Smartup - PubPie. I want to treat customers as 1st order payees. Jeff Sayre: I don't like the current Google split payment mechanism. A strong feature of PaySwarm is the ability to list multiple people. Jeff Sayre: Great from a collaborator and service provider standpoint. It removes extra accounting - all payments are direct. Jeff Sayre: Collaborators recognized as primaries, paid directly, not through a middle man - that's good. Patrick Strateman: Micropayments are good - Bitcoin's minimum is 6.5 cents. Manu Sporny: PaySwarm's minimum is 1/100,000 of a cent. Manu Sporny: You obviously don't want to do USD/Bitcoin transactions that are that small - but it becomes important for currencies with large value units - such as gold or platinum. We think that precision is good enough for all currencies in the world today. Manu Sporny: Credit cards have a minimum transaction amount that is much larger. PayPal is much larger. Manu Sporny: Going back to Jeff's example - PaySwarm treats everyone as first class citizen when it comes to payment. Batching micropayments use case is accepted. Topic: Customized Application Stores Manu Sporny: http://payswarm.com/specs/payswarm-use-cases#customized-application-stores Manu Sporny: Example came about because of App stores (Google, Apple, Verizon, Microsoft, etc) Manu Sporny: Wait, I'm wrong - that's not this use case. This use case is actually about embedding a digital contract in a binary data stream - watermarking or DRM. Manu Sporny: Buying software will personalize purchases and assign those to you directly. Manu Sporny: This requirement came from the music industry use cases a few years ago. Watermarking purchases (music files), receipt embedded in file. Important to prevent people from uploading the content to a P2P network. Manu Sporny: This use case was originally vital for Bitmunk... not sure if it is vital for PaySwarm. Manu Sporny: I would prefer to keep it out for now. Manu Sporny: Jeff, do you have a use case for watermarking books? Jeff Sayre: My company is opposed to DRM watermarking. Jeff Sayre: Let's not support DRM or watermarking initially. Jeff Sayre: DRM does not protect or increase sales - studies have shown that. Manu Sporny: Reason we had watermarks was so buyer could prove purchase. Manu Sporny: Ties to digital receipt examples earlier - we embed the digital receipt in the file so the person can prove ownership by just providing the file. However, it is very complex to implement. Manu Sporny: Difficult to keep the watermarking binary up to date, it has to be a closed-source module or it won't work, keeping all of the clients in sync is very difficult as well. Jeff Sayre: Physical objects are often not regisitered that way - there is no ownership with the item. Some small examples of registered items. Example of books in personal library. Mike Johnson: The whole watermarking thing was done to try to appease the music industry 6-7 years ago - not a feature we need because the buyer still has access to the digital receipt via the PaySwarm Authority. [scribe assist by Manu Sporny] Mike Johnson: It's complex to implement and we don't need it right now. [scribe assist by Manu Sporny] Manu Sporny: Jeff's example of physical goods not having a digital receipt of ownership is a good example. In the future people might buy a blueprint of an item to manufature. Manu Sporny: 3d printers will happen. People will be able to manufacture at home or locally. Manu Sporny: Schematics might be modified to add a watermark onto the object when it is printed. Manu Sporny: Example of printing out a knife with physically watermarked ownership information used in a crime. It's a use case that's a bit out there - but one that has philosophical implications. Should physical objects have owners? Jeff Sayre: You can't practically rewatermark a physical object. Manu Sporny: In the digital file case, when you resell, the software strips the old watermark and generates a new one. Manu Sporny: RFIDs could be used as programmable watermarks. Although, that is more of a digital watermark example. That way, you could have printed objects have temporary ownership - such as "This frisbee belongs to Jeff Sayre". Watermarking use case is out. We probably won't save use case as nobody really likes it. Topic: Steven Rowat Use Cases Review Manu Sporny: http://lists.w3.org/Archives/Public/www-tag/2009Sep/0055.html Manu Sporny: Most of Steven's use cases have to do with how the license metadata is expressed in the asset or the listing. Usage of RDFa addresses most of these use cases - we can tweak what a license allows by changing a few RDFa statements. Should PaySwarm support these use cases too? Manu Sporny: Most of these use cases seem to be immediately supportable with minor changes to the way the current specification works. We won't have time to go through all of these use cases today, but let's look at the first one. Topic: Limiting Commercial Redistribution Manu Sporny: An independent medical researcher in the USA who produces a pdf report about side-effects of a new prescription drug. Manu Sporny: First example has no resale limitation, however the license that it's available under is a simple Creative Commons attribution, no-derivatives license... maybe just a no-derivatives license? Manu Sporny: This barely says anything about payments, but we can read into it a bit. Manu Sporny: PaySwarm would allow us to do non-downstream sales if we specify that limitation in the listing. Manu Sporny: Jeff, does this use case seem useful to PubPie? Jeff Sayre: Yes. It's up to collaborative teams, but PubPie will allow a lot of flexibility and variety - this use case fits. Manu Sporny: We already have a vocabulary in the works for specifying digital contacts here - http://purl.org/payswarm Manu Sporny: and we already have a limitation where you can state that you do not want to allow any additional payees... Manu Sporny: http://payswarm.com/vocabs/payswarm#NoAdditionalPayees Jeff Sayre: That's not the same as being external data provider. Manu Sporny: That's true, but maybe we can build off of this: Manu Sporny: http://payswarm.com/vocabs/commerce#limitation Manu Sporny: This use case would be if people don't want external data providers - we'd have to add something like ps:NoRedistribution. Jeff Sayre: We also want to allow sales through other networks (Amazon, iTunes) Manu Sporny: Commerce vocabulary allows specifying limitations. Manu Sporny: People could redistribute but not add extra payees, but that doesn't quite address this use case. Manu Sporny: We could add a limitation to only allow download of content from one data provider to support this use case. Mike Johnson: This is a left-over from pre-digital sales era - it's an old mentality - "I need to control my data". [scribe assist by Manu Sporny] Mike Johnson: but it's still important for us to provide this functionality - some people want to drive people to their site - these are all things that are important - we need to be able to limit who the data provider is. [scribe assist by Manu Sporny] Manu Sporny: We're out of time for this call. Let's have another call next week to go through rest of Steven's use cases. Manu Sporny: One thing that is not on the list is alternative currencies (Bitcoin) - we need a use case for that. Patrick Strateman: Very pro alternative currencies. Patrick Strateman: There is a caveat in Bitcoin in that there is a delay in the Bitcoin payment process - funds aren't available immediately. Manu Sporny: PaySwarm has concept of escrow, where we may not push the contract through without verification of payment. Manu Sporny: It is possible to add to spec, but either way we want to support alternative currencies. Manu Sporny: We may not go as far as supporting automatic currency exhange, as that is complex, but adding support for one may allow us to support all currencies. Manu Sporny: Supporting currency accounts may allow us to sidestep exchanges. If you have an account with a certain amount of money in it - great - it works. Jeff Sayre: I agree with the need for alternative currency support. More currencies allows more exchanges, complex but healthy for the economy. David I. Lehn: I agree - we should support alternative currencies. Manu Sporny: Ok, we should add a use case for that. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarm Developer Tools and Demo Released http://digitalbazaar.com/2011/05/05/payswarm-sandbox/
Received on Friday, 23 September 2011 18:54:36 UTC