W3C home > Mailing lists > Public > public-webpayments@w3.org > February 2012

Web Payments Telecon Minutes for 2012-02-10

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 24 Feb 2012 22:14:04 -0500
Message-ID: <4F4851FC.8020203@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
Sorry for the delay... the minutes from the last call are now available
here:

http://payswarm.com/minutes/2012-02-10/

Full text of the discussion follows for archival purposes at the W3C.

---------------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2012-02-10

Agenda:
    http://lists.w3.org/Archives/Public/public-webpayments/2012Feb/0009.html
Topics:
    1. JSON-LD Standardization Updates
    2. Linked Data and Payment Technologies
    3. Web Payments 1.0
Facilitator:
    Manu Sporny
Scribe:
    David I. Lehn, Manu Sporny
Present:
    David I. Lehn, Manu Sporny, Pelle Braendgaard
Audio:
    http://payswarm.com/minutes/2012-02-10/audio.ogg

David I. Lehn is scribing.
Manu Sporny:  JSON-LD Standardization updates and spec split on
    the agenda today. Trying to figure out focus for next few months.
    Any changes or updates?
Manu Sporny:  Potential call time change? 4pm EST Friday? 4pm
    other days? I'll setup a poll.
Pelle Braendgaard:  12pm would be best for me.
Manu Sporny:  We'll put up a poll and see what times works for
    everyone.

Topic: JSON-LD Standardization Updates

Manu Sporny:  Talking with w3c about standardization. Work on
    JSON-LD started 2 years ago, built it for PaySwarm. Building it
    in Linked JSON Commuity Group. RDF WG has JSON for RDF in its
    charter. JSON-LD can be transformed to RDF, but it's primarily
    meant for Web developers.
Manu Sporny:  RDF WG may pick up work for JSON-LD... it is
    getting stable enough for standardization, maybe in next 4-6
    months we will start official standardization on it. [scribe
    assist by Manu Sporny]

Topic: Linked Data and Payment Technologies

Manu Sporny:  David Nicol sent some questions to the mailing
    lists. Asked if or how linked data should be a part of these
    standards. How does Linked Data work for payment technologies?
Manu Sporny:  David had an issue with the use of JSON-LD in
    payswarm... but not clear exactly what his issue was.
Manu Sporny:  We may want more documentation about why linked
    data and IRIs are needed in a payment standard. Melvin Carvalho,
    Web Credits, has been having same issues. We should write
    something up explaining why Linked Data is used in payment tech.
    Pelle, any thoughts on this?
Pelle Braendgaard:  No push back on the aspect of using IRIs as
    identifiers... it is pretty accepted as a best practice for REST
    stuff. [scribe assist by Manu Sporny]
Manu Sporny:  Pelle, have you had any issues with use of linked
    data in OpenTranact?
Manu Sporny is scribing.
Pelle Braendgaard:  Dave Nicols largest concern is that it can be
    hard to understand what is in a message - it can be derefrenced
    in many different ways - this is what I understood - it could be
    dangerous with novice programmers.
Pelle Braendgaard:  In the XML digital signatures standard - huge
    standard designed to do everything - novice programmer would
    think that XML document is the signature - they would pass the
    document in and the library would say the signature was okay.
Pelle Braendgaard:  Except, the signature wasn't okay - big
    security risk.
Pelle Braendgaard:  You could imagine that there could be things
    referenced elsewhere and a novice programmer would use regular
    JSON library to "verify" the document.
Pelle Braendgaard:  It's a legitimate security issue - bad
    implementations.
Pelle Braendgaard:  There are a lot of the language of Linked
    Data and RDF that makes many average developers switch off.
Manu Sporny:  Yes, it's certainly an issue.
Pelle Braendgaard:  All of a sudden you can't understand
    everything in the document - they're all aesthetic concerns.
Pelle Braendgaard:  The normal workflow for Ruby and JavaScript
    is that when you parse JSON, the fields become symbols - having
    namespace or @ signs in there make it weird for a Ruby
    programmer.
Pelle Braendgaard:  Dot-notation is used more than dictionary
    notation.
David I. Lehn:  Yes, we've run into that issue as well. The
    dot-notation one - there are issues.
Pelle Braendgaard:  I think David Nicol's security concern is a
    bigger issue.
Manu Sporny:  Yeah, we've tried very hard to try to make JSON-LD
    simple... avoid the nasty Semantic Web terminology for the most
    part. Unfortunately, this is lost on people that look at the
    JSON-LD spec for the first time. It's a balancing act - difficult
    to find something that wouldn't conflict w/ existing JSON, would
    merge with it easily, but also have something simple and
    expressive. I think we need to explain Linked Data a bit better.
Manu Sporny:  It's difficult to take a novice developer from JSON
    to JSON-LD... in the end, our hope is that the data structures
    will look very familiar to JSON developers. Take colons out of
    the names? Instead of 'foaf:homepage', we use 'homepage'. That
    was your preference, right Pelle? The difficult part in the Web
    Commerce spec - decentralized assets/listings - difficult to
    solve the problem w/o using Linked Data. We tried to solve the
    problem w/ regular JSON - it was a mess. We speak from experience
    - we tried regular JSON... it was a mess. David Nicol's issue was
    mostly with messaging - "show me why Linked Data is beneficial".
    Maybe we start at URLs and go into JSON-LD aspect of it.
Pelle Braendgaard:  Some suggestions - for example, rdfs:comment
    - com:amount, com:currency - I don't think you need to specify
    the namespace.
Pelle Braendgaard:  I think there is a middle-way - of course use
    URIs/IRIs - URL / URI - people don't know what an IRI is
    (culturally difficult)
Manu Sporny:  Yes, Internationalized languages was a big concern
    at W3C - UTF-8 came out as a result, IRI came out as a result.
Pelle Braendgaard:  I think we should use URL - it's
    colloquial... when we explain it to people. Use IRI in the spec.
Pelle Braendgaard:  Part of the whole Linked Data movement is to
    have strong definitions. In everyday speech, technical
    preciseness confuses people.
Pelle Braendgaard:  Going back to receipts - transfers / receipts
    - yes, use references - you could have an object encapsulated,
    right? Isn't it a security risk to have to go out and derefernce
    an IRI?
Manu Sporny:  Oh, right - we have tried to write the application
    so that dereferencing rarely ever needs to happen.
David I. Lehn: Processors might need to dereference the context.
Manu Sporny:  Yes, but in most cases, they won't becaue the
    context will be hard coded or cached. It is a security risk...
    but a manageable one (look at Web browsers - they have to
    dereference stuff all the time).
Pelle Braendgaard:  That's where there may be a slight danger,
    here. We could have JSON-LD that is dereferenced. Novice
    programmers may have issues with all of this... using libraries
    without understanding everything that is going on. A false sense
    of security. We should protect against that.
Manu Sporny:  Yes, I agree - security issues we need to look out
    for. Addressing each is going to be slightly different. We should
    narrow the envelope of attack.
Pelle Braendgaard:  Most of functionality should be useful w/o
    JSON-LD library. You should be able to use just regular JSON.
Manu Sporny:  The Authorities are the ones that have to check the
    JSON-LD objects. The digital signatures will be able to be
    handled via JSON-LD libraries... but I think those libraries will
    be required for this type of system. Same argument for OAuth -
    use the libraries, don't try to roll your own. This isn't a
    simple problem - it's not going to be easy to address.
Manu Sporny:  The security aspect of this is not going to be
    easy. I'll try to look at what David Nicol is saying - we'll try
    to update the spec language to give a gentler introduction to
    Linked Data. Big mistake of Linked Data is not making the
    concepts very accessible to people.
Manu Sporny:  Maybe the solution to this is to use colloquial
    explanations when writing blog posts and tutorials and use the
    technically correct term in the spec. Writing specs is different
    - we have to use technically correct definition because they are
    W3C specs... so, we will have to use IRI there... URL when
    discussing w/ regular web developer folks.
Pelle Braendgaard:  Yes, we should use colloquial terms when
    communicating to Web developers, use specific terms in spec.
Pelle Braendgaard:  We should have a bit in the spec that
    outlines briefly what an IRI is, for beginner readers.
Manu Sporny:  We've tried to do that in the spec - we go into
    terminology fairly deeply - we should do the same for the
    PaySwarm specs.
Manu Sporny:  Anything else on this topic before we move on?

Topic: Web Payments 1.0

David I. Lehn is scribing.
Manu Sporny:  Over last two weeks we took Pelle's criticisms to
    heart and split the spec up into multiple documents.
Manu Sporny:  Spec split into four major components, along the
    lines that Pelle outlined. Didn't think spec split was going to
    lead to as many arguments as it did.
Manu Sporny:  Web Keys 1.0 - public key infrastructure for the
    Web.
Manu Sporny:  Web Payments 1.0 - with basic transaction support,
    decentralized settlement algorithm, and data portability.
Manu Sporny:  Web Commerce 1.0 - how to sell digital content on
    the web - assets, listings, contracts, receipts, etc.
Manu Sporny:  Payment Intents 1.0 - how to do crowd-funding, etc.
Manu Sporny:  The specs are built on top of each other. They can
    be developed and standardized on their own timeframes - Web Keys,
    Web Payments lead... Web Commerce next... then Payment Intents.
Pelle Braendgaard:  Congratulations on the split, it is the right
    thing to do.
Manu Sporny:  Thank you. I think we started out with fairly rocky
    arguments - glad you stuck it out Pelle and kept fighting for it.
    I think we're all better off for it. I hope it's a clear sign
    that we do listen and want what's best for the Web, payments and
    these specs. Thanks for arguing for that change... I don't think
    we would have made the change this soon had you not argued as
    strongly as you did.
Manu Sporny: The Web Payments 1.0 spec:
    http://payswarm.com/specs/ED/web-payments/2012-01-30/
Manu Sporny:  Section 4.2 specifies how Transactions happen -
    basic transfer of money from one place to the next. You take a
    JSON transaction and HTTP POST it to a transaction endpoint to
    move money. Pretty simple and straight forward. The decentralized
    settlement process is also there - if source and destination
    account exist on different authorities - how do you make sure
    electronic bookkeeping stays in sync. This is about ensuring that
    the decentralized system does not require human intervention.
Manu Sporny:  How do you make the transaction atomic between
    decentralized systems. The algorithm has to be resistant to
    failure - has to be atomic. The algorithm outlined is a
    decentralized settlement algorithm. Any questions?
Manu Sporny is scribing.
Pelle Braendgaard:  I think eventually, Decentralized Settlement
    would make more sense in a separate specification. It's an
    important aspect, there are a lot of different ways it can be
    done. Does PaySwarm require decentralized settlement for the base
    level spec?
Manu Sporny:  Right now, yes, decentralized settlement is
    required. The concern is that a large payment processor would
    implement the spec such that they don't interoperate with other
    payment providers. Counter-argument is that they wouldn't
    implement PaySwarm if they didn't want to interoperate. The
    counter-counter argument to that is that if PaySwarm is
    successful, implementers would only implement things that would
    benefit them and not the parts that would create competition for
    them. By and large, many corporations believe that
    interoperability in their core business leads to stronger
    competition and corporations don't like that. They tend to favor
    monopolies rather than even playing fields. The short answer is:
    Yes, decentralized settlement is required. We may end up being
    out-voted at W3C - Google, Amazon, PayPal may feel that they
    don't want decentralized settlement in there. Make sense?
Pelle Braendgaard:  My main two objections to having the
    decentralized settlement algorithm in there: 1) There has to be
    some trust relationship between authorities (this is really
    important - it's a complicated issue)
Pelle Braendgaard:  I think Melvin's Web Credits shows how to
    build a Web of Trust, good start to solving this issue. However,
    that is a separate issue to doing just a simple payment. This is
    why we're indifferent to the types of assets we're transferring
    in OpenTransact. It limits us to national currencies or one or
    two alternative currencies - there has to be a trust
    infrastructure for each alternative currency.
Pelle Braendgaard:  So, 2) It limits us to national currencies or
    one or two alternative currencies.
Pelle Braendgaard:  For example - w/ OpenTransact - you could use
    it to transfer Domains, you could use it for Shares, you could
    use it for non-traditional money. It could be a local community
    currency - it wouldn't make any sense to have a decentralized
    settlement process.
Pelle Braendgaard:  So, for example - Coconut Grove Currency -
    whole idea is to be local.
Pelle Braendgaard:  If you require Decentralized Settlement, it
    limits it because (I understand the reasons - we don't want a
    PayPal to just sit and operate as an island) - then we need to
    make that a separate... have people opt-in.
Manu Sporny:  Not enough language in the spec to get this right
    now - we do support alternative currencies - you can use any ISO
    currency code, or you can use an IRI as the currency. If you use
    an IRI, that IRI can mint new units of currency. If one Authority
    wants to use the IRI currency, the other Authority doesn't have
    to accept it. The decentralized algorithm doesn't always have to
    succeed. You would expect it to always succeed for USD, Euro,
    Yuan, etc. However, you wouldn't always expect it to work for
    alternative currencies. Maybe it /would/ work for alternative
    currencies... maybe local currencies stay local if they have a
    flag. What I'm saying is that there is no requirement that every
    authority has to accept every currency. You're right - there are
    some currencies where it doesn't make sense for it to be
    decentralized.
Manu Sporny:  We're out of time for today. I'll send out a link
    to a poll to decide on a time. We'll try to clean up language in
    Web Keys and Web Payments specs. Any other comments before we get
    off of the phone?
Pelle Braendgaard:  One quick comment - are you really married to
    the "source" and "destination" parameter names?
Manu Sporny:  We like them, but not married to them. Everything
    is fairly malleable during the demo period, once we launch a
    commercial system, we would really not like to change those. One
    of the nice things about JSON-LD is that you don't always have to
    use 'source' and 'destination', you could use 'to' and 'from'.
Pelle Braendgaard:  What about "to" and "from"? Make it more
    human. It's shorter. Let's try to keep these things simple. For
    example: memo vs. note. We should try to map between OpenTransact
    and PaySwarm.
Pelle Braendgaard:  We could create some level of compatibility
    between Web Payments and OpenTransact.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Saturday, 25 February 2012 03:14:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC