Web Payments Telecon Minutes for 2011-09-30

The minutes for today'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-30
Agenda:
    http://lists.w3.org/Archives/Public/public-webpayments/2011Sep/0012.html
Chair:
    Manu Sporny
Scribe:
    Pelle Braendgaard, Mike Johnson
Present:
    Pelle Braendgaard, Manu Sporny, David I. Lehn, Jeff Sayre, Mike
    Johnson, Jose 'Manny' De Loera

Pelle Braendgaard is scribing.
Manu Sporny:  We have Payment Links and use cases on the Agenda
    today, any additions to the Agenda?
Pelle Braendgaard:  I'd like to discuss the base technology
    platform for this work - because it sounds like it is PaySwarm?

Topic: Web Payments Base Technology Platform

Manu Sporny:  We need a base standard to work from, we don't want
    this work to devolve into philosophical discussion.
Manu Sporny:  We are proposing PaySwarm as the base technology
    because it seems to fit the use cases discussed thus far the
    best. However, it is not a fully baked specification, it is
    undergoing heavy change - specifically, the change from OAuth
    1.0a to digitally signed messages.
Manu Sporny:  We need to bring ideas and technical concepts in
    from Bitcoin and Open Transact and Open Transactions. We need to
    support as much as possible without overly complicating the
    specification.
Manu Sporny:  We need to create something simple... and do it
    quickly.
Pelle Braendgaard:  I think that we need to have discussions
    about the basics... use cases are important. [scribe assist by
    Manu Sporny]
Pelle Braendgaard:  However, I do think PaySwarm, as it is is too
    complex - it's too wide - it wants to do too many things. It
    would be easier if we split it into smaller pieces. [scribe
    assist by Manu Sporny]
Pelle Braendgaard:  I find it difficult to see how it could take
    off in its current level of complexity. [scribe assist by Manu
    Sporny]
Manu Sporny:  Typically the way standards associations works is
    that we need to work out the use cases, then settle on
    requirements, then dive into the technical discussion. That's
    what we're attempting to do here.
David I. Lehn: Also, please feel free to send messages to mailing
    list with concerns about the direction of Payswarm.
Manu Sporny: Yes, let's please have this discussion sooner than
    later. On the mailing list would be great because we want to have
    a record of this conversation and the reasons that we are making
    the decisions that we're making.

Topic: Quick update on PaySwarm spec

Manu Sporny:  PaySwarm spec is being simplified. The latest
    release uses digital signatures instead of OAuth 1.0a.
Manu Sporny:  We needed to implement nonces as we moved away from
    OAuth 1.0a, which also uses nonces. The nonce's didn't scale for
    Twitter, Facebook etc, but is needed for small publishers if we
    are not going to use OAuth 1.0a. We found a more elegant solution
    than nonces, but we're still working on it.
Manu Sporny:  We use a form of asymmetric message encryption.
    PaySwarm Authorities that are required to use SSL, which means
    that asynchronous messages coming back can be encrypted in a
    different way and delivered over regular HTTP. This means that
    publishers can use plain HTTP - they don't need to buy an
    expensive security certificate every year to be able to sell
    content via their website. So, we have removed the need for
    nonces, which makes the technology scale, while protecting
    against replay attacks and ensuring that Web Publishers don't
    need an SSL certificate in order to sell things via the Web.

Topic: Standardizing Payment Links

Manu Sporny: http://manu.sporny.org/2011/payment-links/
Manu Sporny:  I wrote this article last week
    http://manu.sporny.org/2011/payment-links/ in response to the
    bitcoin community's desire for a payment link.
Jeff Sayre:  The article questions whether or not we need a
    standard way of expressing payment links on the web? [scribe
    assist by Manu Sporny]
Jeff Sayre:  In the post, Manu suggests how Payment Links could
    be implemented, but questions whether or not they should be
    implemented - what use cases they solve. [scribe assist by Manu
    Sporny]
Manu Sporny:  Just having a payment link without describing what
    is being payed is insufficient - people like paying for refined
    goods, they have more of a problem buying unrefined goods and
    Payment Links seem to be associated with unrefined goods
    (tipjars, donations, etc.). Gregory Rader has a good series of
    posts on this topic
http://onthespiral.com/navigating-four-economies
http://onthespiral.com/abundance-scarcity-four-quadrant-value-universe
Manu Sporny:  You don't know what you are paying for and who you
    are paying - it's not tied in with the purchase process - that's
    problematic for pure Payment Links.
Pelle Braendgaard:  So, I think very differently on this - I
    think a simple payment link is a great idea. [scribe assist by
    Manu Sporny]
Pelle Braendgaard:  We can't model everything out - whatever you
    are buying - it's out of the scope of a Web standard. I think the
    bitcoin standard link is a good idea - but for web-based systems
    - it should be a URL with some parameters on the end of it. It
    really doesn't have to be more complex than that. I think it'll
    be an error if we get more complex than that. [scribe assist by
    Manu Sporny]
Jeff Sayre:  I agree. We don't want to be in a situation where
    there needs to be a new IRI for every new payment scheme that
    comes up. We need to be sufficiently generalized. There are
    issues with payment links - bitcoin example in Manu's article is
    good. We want something more generalized - that gets around the
    uniqueness of each currency. [scribe assist by Manu Sporny]
Mike Johnson is scribing.
Pelle Braendgaard:  99.9% payments are done without digital sigs,
    fully legal. Legal system does not care about digital signatures
    and RDF. Courts care about email, HTML, and logs. Engineers
    over-complicate, payment links will fail if they turn it into
    something complex.
Pelle Braendgaard:  No need for standard, PayPal just uses https
    links. It can be good to add some details, but there is no need
    for a payer field or bitcoin accounts to draw from.
Pelle Braendgaard:  Link, specify amount, who it is to and some
    other information. Can just be straight HTML.
Manu Sporny:  That argues away the entire need for
    standardization. That link allows people to implement whatever
    they want, but the whole point is to standardize the architecture
    people use to pay each other.
Manu Sporny:  If you take the oversimplification approach, that
    does nothing to standardize the payment process.
Pelle Braendgaard:  Take only one thing to standardize, payment
    link would be a lowest common denominator.
Pelle Braendgaard:  Payment links now have an asset as well.
    Payment provider builds something based off the link information.
Pelle Braendgaard:  I'm worried about over-complicating.
Manu Sporny:  I'm lost as to the direction Pelle wants the group
    to head in... what is actionable from what Pelle is saying?
Pelle Braendgaard:  Payment link is just one of the really basic
    things, a starting point.
Pelle Braendgaard:  Have a link on your homepage with your
    banking details exposed for payment, don't destroy implicitness
    of link. Links should have some parameters that are standardized,
    rest is just the web.
Pelle Braendgaard:  Bitcoins don't need to understand assets.
    Bitcoin just handles the payment part.
Manu Sporny:  Pelle wants just a generic payment link, parameters
    are just standardized.
Pelle Braendgaard:  Just a link, not even attributes. Something
    you could put in an email and someone could follow to do payment.
Manu Sporny:  Why would that need to be standardized at all,
    parameters are part of HTTP - people can do this today.
Pelle Braendgaard:  Parameters should be known to work with any
    payment mechanism - it would be a way of expressing how much you
    want to get paid and where to deposit the money.
Manu Sporny:  Amount and person to pay should be in the link.
Pelle Braendgaard:  Even the amount should be optional.
Manu Sporny:  Too hard to solve with just a link without browser
    (user-agent) knowing what accounts are.
Manu Sporny:  To do that you have to assume that the person has
    to have a specialized account for whatever service you want to
    use.
Pelle Braendgaard:  The person has to have that account, PayPal,
    Bitcoin, etc.
Manu Sporny:  Yes, but then you have the NASCAR problem - sites
    plastered with all sorts of payment buttons.
Pelle Braendgaard:  Yes, but that is a different issue.
Manu Sporny:  Let's discuss this on the mailing list - it would
    be good to understand the exact proposal.
Pelle will write up a proposal and send to mailing list.

Topic: Steven Rowat Use Case Review (continued)

Manu Sporny:
    http://lists.w3.org/Archives/Public/www-tag/2009Sep/0055.html
Manu Sporny:  Most of these use cases are addressed by discussing
    the licenses associated with the asset. That conveys most of the
    information necessary.
Manu Sporny:  We addressed case 1 last week, we will start with
    2.

Topic: Anonymous, Free Content

A journalist in Africa with an ogg or mp4 video of atrocities in
    an ongoing war. She specifies: anonymity; no content
    modification; free; no downstream commercializing.
Manu Sporny:  Probably associate CC no-derivs license with the
    work. Distribute for free, no downstream commercializing.
Manu Sporny:  2 seems not to be a use case we have to cover,
    Creative Commons handles this use case completely.
Mike Johnson: Mike: +1
Group chooses to pass on use case 2 - it is handled by Creative
    Commons

Topic: Conditional Re-Distribution

A writer with a complete novel in pdf, doc, html, and other text
    formats. He specifies: authorship as pseudonym; no content
    modification; payment per download; downstream commercializing
    allowed with constraints of: no advertising (direct sale only);
    payment of 20% of gross per copy re-sold; any additional
    commercial rights for other media must obtain agreement of the
    original author.
Manu Sporny:  Downstream commercialization, direct sale only and
    no advertising.
Manu Sporny:  PaySwarm listings allow a variety of terms to limit
    resale rules.
Manu Sporny:  No other rights are conveyed unless they are
    specified.
Manu Sporny:  Standard copyright practice for no content
    modification and requirement for additional commercial rights to
    be cleared by the author.
Jeff Sayre:  I agree that this falls under payment - it's a use
    case we care about.
Jeff Sayre:  My company, PubPie, would benefit from this.
Jeff Sayre:  Resale would help, gets around copyright and DRM
    issues, has social incentive.
Jose 'Manny' De Loera:  Very benefitial, expands distribution
    ability for authors while maintaining control.
Pelle Braendgaard: +1
Mike Johnson: +1
Group accepts conditional redistribution use case.

Topic: Publishing with Per-Country Prices

A folk-musician in Siberia who records local throat-singing into
    mp3 or ogg vorbis files. He specifies: authorship; no content
    modification; free streaming of first 10% of content online;
    payment per download at sliding scale proportional to
    user-country's average yearly income per person; no downstream
    commercializing.
Manu Sporny:  This use case basically allows a 10% sample and
    per-capita income price adjustment. No downstream
    commercializing.
Manu Sporny:  Free streaming might make sense if other people
    just stream 10% from their websites.
Manu Sporny:  First and last requirements fall out due to being
    address by standard copyright.
Manu Sporny:  License would have to allow first 10% to be
    streamed without compensation.
Manu Sporny:  Sliding payment scale can be accomplished in two
    ways: Geoloc IP database to serve up different payment licenses
    with the PaySwarm Authority enforcing regions.
Manu Sporny:  technically it can be accomplished, but it is very
    complicated to do on the client-side.
Manu Sporny:  From a PaySwarm perspective the Authority would
    just have to enforce regional licenses.
Jeff Sayre:  Applies to publishing as well. Sliding scale of
    royalties. Net or retail books sold above this many units,
    additional royalty earned.
Jeff Sayre:  What scale and what unit? Books sold, country sold
    in, etc.
Jeff Sayre:  What you are talking about - how are payments split.
Mike Johnson:  This is how the movie industry does things too -
    they have a bunch of different regions - Region 2, Region 1 -
    publishers may still be interested in locking down content to
    different regions. [scribe assist by Manu Sporny]
Jose 'Manny' De Loera:  This happened to me the other day too,
    downloading a Kindle book and was denied because not in US.
Mike Johnson:  We still need to understand whether or not the
    PaySwarm Authority needs to enforce these criteria - maybe this
    should be PA specific - maybe it doesn't need to apply to all
    PAs? [scribe assist by Manu Sporny]
Jose 'Manny' De Loera:  Odd to happen with books.
Jeff Sayre:  Can get around using anonymizer sites, but those are
    often prevented.
Jose 'Manny' De Loera:  In this particular case, how would
    someone using an IP masker be able to prove they are not in a
    specific region.
Manu Sporny:  Do we even want to support this to start, because
    it often works against publishers (and customers!) when people
    cannot access content in their region.
Jeff Sayre:  With a publisher, an author might have US rights
    only contract, or Aussie, etc.
Jeff Sayre:  Most get world rights now, but there might be
    specific cases.
Mike Johnson:  There is a huge legacy to music licensing here as
    well - you can't distribute outside of country it was created
    in... lots of cases where this is applicable. Hard to say if we
    need to address it in PaySwarm 1.0 - do we create a mechanism,
    but don't directly address this use case right now? [scribe
    assist by Manu Sporny]
Jeff Sayre:  Maybe this is something we can push to 2.0?
Jose 'Manny' De Loera:  Yes, this does seem to be very complex.
Manu Sporny:  We do have legacy issues, and some publishers
    without the ability to limit might be in big trouble unless we
    are able to support this.
Manu Sporny:  The standard definitely needs to address this, and
    though we may push it off to 2.0 we need to not limit this from
    happening in the future in the 1.0 spec.
Manu Sporny:  We should add to 1.0, but I do not feel strongly
    about this.
Jeff Sayre:  Larger institutions would probably like this support
    earlier than later.
Manu Sporny:  Allowing the transaction based on the sellers
    country and buyers country.
Mike Johnson:  Is this only applicable to countries? Or is it
    broader? [scribe assist by Manu Sporny]
Manu Sporny:  This use case is complex, not just on country of
    origin, was on GDP and such.
Manu Sporny:  Making listings for every country might be
    wasteful, complex.
Manu Sporny:  Another way to address the issue would be a payment
    formula.
Mike Johnson:  Since each authority may be run by a different
    company, maybe some would allow certain types of transactions and
    others wouldn't. [scribe assist by Manu Sporny]
Pelle Braendgaard:  This is a competitive implementation detail -
    all the standard might need is plain english explaining how to
    apply the general process, but the more specific stuff in an
    external specification. [scribe assist by Manu Sporny]
Manu Sporny:  We may want to address in PaySwarm 1.0, but not
    address all business rules.
Manu Sporny:  Let's push to 2.0, but be willing to address in 1.0
    if we feel we need to have it sooner.
Mike Johnson: +1
Manu Sporny:  We're out of time for this call. Thanks for
    everyone's contributions.
Manu Sporny:  Let's do another call next week, use cases take
    time but we are making good progress.
Jeff Sayre:  I maybe absent next two weeks - traveling.

Topic: Picking a Chair

Manu Sporny:  We might not pick a chair for right now, operating
    fine without one. Need more people in group so it's not just the
    few of us picking from a select few.
Manu Sporny:  We will need the chair more once have more members
    and more paperwork, until then, I can do all the paperwork as I
    have been doing these past several months.
The group agrees to operate without chair for now.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
http://manu.sporny.org/2011/payment-links/

Received on Friday, 30 September 2011 19:53:25 UTC