Web Payments Telecon Minutes for 2011-11-04

The minutes for today's call are now available here, thanks to Dave Lehn
for scribing:

http://payswarm.com/minutes/2011-11-04/

Full text of the discussion follows, as well as a link to the complete
audio transcript:

Web Payments Community Group Telecon Minutes for 2011-11-04

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2011Nov/0006.html
Facilitator:
   Manu Sporny
Scribe:
   David I. Lehn
Present:
   David I. Lehn, Manu Sporny, Pelle Braendgaard, Mike Johnson,
   Jeff Sayre

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: http://finance.data.gov/pelleb/accounts/primary
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: http://json-ld.org/playground/
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:
{
"@context": "http://json-ld.org/contexts/Person",
"homepage": "http://manu.sporny.org/",
"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

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/

Received on Friday, 4 November 2011 18:53:49 UTC