Web Payments Community Group Telecon

Minutes for 2011-11-04

Agenda
http://lists.w3.org/Archives/Public/public-webpayments/2011Nov/0006.html
Topics
  1. Customer Digital Signatures
  2. Requirements Discussion
  3. Requirements - Payment for Digital Products
  4. Requirements - Delayed Payment / Escrow
  5. Requirements - Time-based payments
  6. Requirements - Decentralized Payment Processors
  7. Contributor License Agreement
  8. Review of New OpenTransact Draft
  9. JSON-LD Relevance to Web Payments
Chair
Manu Sporny
Scribe
David I. Lehn
Present
David I. Lehn, Manu Sporny, Pelle Braendgaard, Mike Johnson, Jeff Sayre
Audio Log
David I. Lehn is scribing.

Topic: Customer Digital Signatures

Manu Sporny: Hi Pelle, I think we're miscommunicating on the mailing list because our definitions are slightly different. We don't intend for the customers to digitally sign the contracts. I think that addresses your concerns - we're having the PaySwarm Authority sign on behalf of the customer. We also have Vendors digitally sign contracts. Will go into depth on the mailing list. I agree - we don't want external client software in the mix.
Pelle Braendgaard: Good, that was my main worry.
Manu Sporny: Yes, we don't want 3rd party clients in the mix. We do have cases where Certficiate generation and signing can be done via pure JavaScript/WebSockets. We have a full SSL/TLS login working via JS and WebSockets, however - that is very advanced and will not make it into the first spec.
Pelle Braendgaard: Nowadays people use multiple browsers on different devices. All the work in the 90s assumed that people would be using a single browser. I would love to see it happen.
Manu Sporny: Yes, we've replaced the client signatures w/ an Agent on the web that is able to sign on your behalf. That's what a PaySwarm Authority is right now. We have plans to push it into a Node on the Web somewhere... but this isn't for PaySwarm 1.0.

Topic: Requirements Discussion

Manu Sporny: 4 requirements left from original list.. let's go through them.

Topic: Requirements - Payment for Digital Products

Manu Sporny: article, post, file you want to transact on in contract to physical good
Manu Sporny: safer to transact in digital goods than physical goods. You can revoke digital good transactions and things are usually fine when you do that. However, revoking physical good transactions is much more difficult/impossible.
Mike Johnson: +1
Pelle Braendgaard: +1
Manu Sporny: agreement we want to support digital products?
General agreement that we support the sale of digital products.

Topic: Requirements - Delayed Payment / Escrow

Manu Sporny: allow ability for system to put money into and take money out of escrow
Manu Sporny: one use case is crowd funding
Manu Sporny: (some examples) like kickstarter. commit money but the project is only funded if hits a certain level. if it doesn't hit the level, funds are returned.
Mike Johnson: kickstarter is not only use case
Mike Johnson: +1 to support escrow
Pelle Braendgaard: +1
David I. Lehn: +1
Agreement to support delayed payment or escrow in the system.

Topic: Requirements - Time-based payments

Manu Sporny: This is basically scheduled payments. pay $X to someone every month.
Manu Sporny: may not go into spec. authorities can provide as a service, but we should say it's a requirement so that we cover it.
Manu Sporny: important to have requirement but may not effect spec.
Manu Sporny: similar to subscription model
Pelle Braendgaard: I'm for supporting it. perhaps not monthly payment but allow authority to allow merchant to take out certain amount each month. permissions system on spending amounts
Manu Sporny: Our PaySwarm implementation is using the term "budgets" for a particular vendor.
Manu Sporny: prevent vendors from taking out more than certain amount during a time period.
Agreement to support time-based payments and budgets.

Topic: Requirements - Decentralized Payment Processors

Manu Sporny: want system to be decentralized. give people choice on processor to use. Data Portability is part of this requirement - transactions could be exported between processors so that one can download/save/transfer transactions.
Manu Sporny: accounts need to be transfered. if not money at least trnasaction history.
Manu Sporny: core concept is not to have centralized any part of system
Manu Sporny: want competition. people should be able to implement spec and compete on the network.
Manu Sporny: don't want to have to install specific software other than a web browser
Pelle Braendgaard: belive strongly in decentralization. 3rd parties will aggregate transactions. authority stores local txn history. not good idea for them to be responsible for that.
Pelle Braendgaard: should be able to export txns
Pelle Braendgaard: don't see use case of exporting paypal account to dwolla
Pelle Braendgaard: do see use case of exporting history
Jeff Sayre: also for decentralization
Jeff Sayre: exporting history is desireable. if history exported old authority should keep history. unlike exporting from a social network. may be financial regulations to keep copy of txns at original authority.
Manu Sporny: original authority should keep records as long as is required by local regulations
Manu Sporny: http://purl.org/
Manu Sporny: concept of using purl.org for permanent urls. have non profit or similar to provide urls forever for people - a life-time personal id space.
Manu Sporny: could use that to specify personal financial accounts
Manu Sporny: url would be tied to your identity. give authority ability to transact on that account.
Manu Sporny: makes it easier to change between authorities
Manu Sporny: just a thought for now. many details to consider.
Manu Sporny: issue is creating txns that are tied to an authority and don't transfer easily
Pelle Braendgaard: +1
Mike Johnson: +1
David I. Lehn: +1
Agreement to support decentralization of the system.

Topic: Contributor License Agreement

Jeff Sayre: Is there an issue about contributor and license agreements for the group?
Jeff Sayre: seems more like a non issue. W3C looking for lifetime license for content.
Manu Sporny: Typically, the way this works is that W3C holds copyright on the document while also allowing a Creative Commons, Attribution, Share-Alike license (CC-BY-SA). So, there is an official version of the W3C spec published by W3C. They are good stewards of World Wide Web Standards. However, if W3C goes haywire at any point in the future, the spec can be forked and developed via the Creative Commons license. So, I think we'll assign W3C the copyright and then keep the document under CC-BY-SA.

Topic: Review of New OpenTransact Draft

Pelle Braendgaard: http://www.opentransact.org/
Manu Sporny: Pelle, could you give us an overview on the OpenTransact updates and the new draft
Pelle Braendgaard: a lot of people working with open transact
Pelle Braendgaard: want to work through issues and standardize properly for implementors
Pelle Braendgaard: before were two components, simple payments (payments links), but changed to "transfer requests" naming.
Pelle Braendgaard: better name since it's a request for money or other assets
Pelle Braendgaard: core now requires OAuth 2. simplifies things.
Pelle Braendgaard: didn't want to specify it before but OAuth 2 is ready now
Pelle Braendgaard: final building block is transfer authorization
Pelle Braendgaard: looks simpler to request but allows merchant to make request at a later date
Pelle Braendgaard: feel that all the payswarm use cases are covered
Pelle Braendgaard: openid connect replaces openid that is simpler. allows you to combine openid connect and authorization at the same time.
Pelle Braendgaard: covers paypal usability features
Pelle Braendgaard: payswarm deals with things that are higher up. open transact nice at a lower level.
Pelle Braendgaard: not attempting to handle higher level. better in other standards or in apps.
Manu Sporny: room for payswarm to build on top of open transact?
Pelle Braendgaard: absolutely
Pelle Braendgaard: not mutually exclusive, can work together
Pelle Braendgaard: OT could be lower level. PS could be higher level. PS more of an application level. good to standardize everything.
Manu Sporny: looks good and simple. not specifying application level things.
Manu Sporny: need to look at how PS and OT can work together and what can be used in PS spec.
Manu Sporny: concerns with oauth 2 usage. easier to use digital signatures via PKI.
Manu Sporny: might be able to use some of the OT spec in PS.
Pelle Braendgaard: happy to answer questions about integration
Pelle Braendgaard: digital sigs fine for after-the-fact things like receipt. oauth 2 handles delegated responsiblity well. providers on SSL but using people using blog to use it
Pelle Braendgaard: openid connect has same issues payswarm deals with regarding digital sigs. using "claims".
Pelle Braendgaard: (claim example)
Manu Sporny: digital bazaar will look at OpenTransact

Topic: JSON-LD Relevance to Web Payments

Manu Sporny: digital contracts and receipts need to be extensible. can't spec out just a few terms that apply forever. apps have custom requirements that need to be considered.
Manu Sporny: issue with decentralized system. want everyone to be able to process data.
Manu Sporny: plain JSON has issues with how to spec things out - decentralized extensibility is a concern.
Manu Sporny: look towards RDF and their data model
Manu Sporny: http://json-ld.org/
Manu Sporny: want ease of JSON format that represents a RDF graph
Manu Sporny: spec nearing completion. playground give basic examples. Goal is to have it look a great deal like JSON, but to also have it extensible in a way that prevents term/key collisions and to allow the graph of data to be digitally signed:
{
"name": "Manu Sporny"
}
Manu Sporny: basic example of JSON-LD
Manu Sporny: can expand into triples representing a graph
Manu Sporny: allows extensible data structure
Manu Sporny: payswarm messaging is using JSON-LD. easy to understand for developers. but extensible without name clashes.
Pelle Braendgaard: motivation for JSON-LD?
Manu Sporny: wanted way to describe assets that was open-ended. want providers to be able to process contracts without having to go through standards process for custom properites.
Manu Sporny: authority can process assets without having to understand every property
Manu Sporny: when contract used by vendor their app can see and use special properites
Manu Sporny: example: article wants to only allow 5 copies to be printed at a time. specified in asset. authority could process transaction but printer could handle that custom property.
Manu Sporny: probably better examples. want licenses to be machine readable too.
Manu Sporny: innovation possible without involving core payswarm spec.
Manu Sporny: express info on web pages using RDFa. or microdata or microformats in the future. wanted data format that could support all those data representation syntaxes.
Manu Sporny: wanted machine processing of info to be possible
Pelle Braendgaard: likes using JSON. how does it compare to other specs like schema.org and opengraph.
Manu Sporny: opengraph uses rdfa. could use opengraph. still working with schema.org to get rdfa support. they use microdata. trying for better rdfa support, possibly with new "RDFa Lite" spec.
Manu Sporny: any of these specs produce a data graph which can be expressed in JSON-LD.
Manu Sporny: universal graph data format
Manu Sporny: gets into JWT and JWS. JSON-LD has normalization and digital signature mechanisms.
Manu Sporny: JWT doesn't use graphs. makes it unable to use other representations than JSON.
Manu Sporny: good idea to talk to JWT and JOSE lists but they might be solving different problems and not interested in problems JSON-LD solves.
Pelle Braendgaard: good to talk to other groups. could maybe use JSON-LD without external references. might be able to use with normalized JSON-LD format.
Manu Sporny: graph normalization is difficult problem. linked data community pushing JSON-LD and wants to apply normalization algorithm to generalized RDF graphs.
Manu Sporny: many cases don't need graphs. extensible decentralized system requires the extra complexity.
Manu Sporny: (wrap up)
Manu Sporny: thanks for the good discussion today - 2 weeks to next telecon

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