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

Web Payments Telecon Minutes for 2012-04-17

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 17 Apr 2012 20:31:05 -0400
Message-ID: <4F8E0B49.3030506@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing! The minutes for today's telecon are
available here:

http://payswarm.com/minutes/2012-04-17/

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

--------------

Web Payments Community Group Telecon Minutes for 2012-04-17

Agenda:
    http://lists.w3.org/Archives/Public/public-webpayments/2012Apr/0008.html
Topics:
    1. IFEX proposal by Payward
    2. MintChip by the Royal Canadian Mint
    3. Potential security vulnerability via HTTPS
    4. PaySwarm Vocabulary
Facilitator:
    Manu Sporny
Scribe:
    Dave Longley
Present:
    Dave Longley, Manu Sporny, David I. Lehn, Jeff Sayre

Dave Longley is scribing.
Manu Sporny:  on the agenda today -  talk about IFEX, Mintchip,
    potential security vulnerabilities, vocabs, RDFa and JSON-LD
    updates.
Manu Sporny:  no updates to the agenda? ... ok, let's start with
    IFEX.

Topic: IFEX proposal by Payward

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-webpayments/2012Apr/0006.html
Manu Sporny:  I had a long discussion with Walter Stanish who
    works for Payward, they are trying to create a system to do
    payment settlement, which is different from PaySwarm where
    PaySwarm is focused on e-commerce and doing transactions from
    point A to point B, they are concerned with actually moving the
    money (backend transfer), PaySwarm only keeps track of where the
    money *should* be, IFEX moves the money.
Manu Sporny:  IFEX creates an open and decentralized network,
    sort of a parallel to ACH, but more prone to competition, it is
    an open network vs. closed banking network.
Manu Sporny:  the way it works is, say, I need to transfer $100
    to British pounds and put that money into someone else's account
    ... the way I think IFEX works is that you put a bid out there to
    do the transfer and people would compete to complete the transfer
    for you.
Manu Sporny:  you pick the winner, providers compete ... could be
    used on stock exchanges and they could be done in subseconds -
    very quickly instead of it taking seconds, hours, days, weeks.
Manu Sporny:  it seemed like what Walter was going towards with
    IFEX and what we were doing with webpayments here ... made it
    seem like we can work together, they are trying to do
    settlements, PaySwarm is dealing with e-commerce, sort of the
    front end and tracking money/transfers, and IFEX provides the
    backend for moving the physical money around.
Manu Sporny:  PaySwarm could use a backend of IFEX or ACH
    (whichever works best for customers) to move the actual money in
    the background.
Manu Sporny:  Walter is also talking to some other currency
    folks, but wants to really work with fiat currencies
Manu Sporny:  so that's what we know about IFEX now ... any
    questions about how we work with Walter in the future?
David I. Lehn:  sure, how do we integrate that into what we have
    now?
Manu Sporny:  Walter said IFEX would be built into an open source
    server that you install
Manu Sporny:  it would function just like a payment gateway (with
    a merchant account ,etc).
Manu Sporny:  like we would call out to a payment gateway, we
    would similarly call out to the IFEX server instead.
Manu Sporny:  I think they are going to have a software release
    sometime in the near future and we'd deal with the currently
    muddy details at that point.
David I. Lehn:  ok.

Topic: MintChip by the Royal Canadian Mint

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-webpayments/2012Apr/0003.html
Manu Sporny:  Next up is MintChip, the Royal Canadian Mint
    launched this project
Manu Sporny:  so a gov't is getting into more advanced payment
    systems, which is great.
Manu Sporny:  There's a good analysis of MintChip by Pelle here:
    http://payglo.be/2012/04/05/mintchip/
David I. Lehn: he has an update too:
    http://payglo.be/2012/04/17/mintchip-roundup/
Manu Sporny:  He says it may be difficult to scale and there are
    security issues with the physical card.
Manu Sporny:  You always worry about the security and whether or
    not it can survive security attacks once you put it into hardware
    ... always a concern that hardware will be stolen/hacked, etc.
Manu Sporny:  It's a neat way to do offline payments
Manu Sporny:  Different from PaySwarm in that PaySwarm focuses on
    online payments, though PaySwarm can do offline payments by
    deferring a transfer by digitally signing it and then uploading
    later.
Manu Sporny:  MintChip is supposed to be fairly anonymous which
    is good news, like cash.
Manu Sporny:  bad news is that if you lose your card it's just
    like losing cash, it's gone.
Manu Sporny:  it's meant for smaller amounts on cards, several
    hundred dollars at a time at most.
Manu Sporny:  any questions on MintChip, etc?
David I. Lehn:  how would we begin to integrate with them?
Manu Sporny:  we could contact the Royal Canadian Mint and talk
    to them ... we could have MintChip tied in as just another
    currency, it is supposedly a virtual currency
David I. Lehn:  actually I think it is in Canadian Dollars.
David I. Lehn:  they have currencies that are listed in Canadian
    dollars.
Manu Sporny:  Pelle came to the same conclusion that it is its
    own currency, I remember reading that as well.
David I. Lehn: http://payglo.be/2012/04/05/mintchip/#comment-3
Manu Sporny:  in any case, if it is its own currency we could use
    it like that.
Manu Sporny:  we would need to talk to them to figure out how we
    could integrate or charge in that currency over PaySwarm.
Manu Sporny:  I think you have to have an official hardware
    device to add money to it.
Jeff Sayre:
    http://www.canadafreepress.com/index.php/article/46008
Manu Sporny:  there is an online version of it that maybe we
    could work with.
Manu Sporny:  but now you need hardware devices, merchants would
    need them along side credit card readers etc, and that is
    problematic for integration.
Manu Sporny:  I don't really know how we'd integrate cleanly.
Jeff Sayre: See link above: " The Royal Canadian Mint is pleased
    to announce that it has launched a program for developers from
    across North America to test and challenge a digital currency
    technology and to determine its applicability to the current
    marketplace."
Manu Sporny:  I can only think of the online version integration
    working.
David I. Lehn:  at one level we could accept money that way, if
    we had the hardware.
David I. Lehn:  it could just be another way to deposit or
    withdraw funds.
Jeff Sayre:  there's a link that was released just two days ago
Jeff Sayre:  the Royal Canadian Mint is challenging devs to test
    their new technology
Jeff Sayre:  they are asking for devs to get involved so they are
    clearly interested in developer input, so we should investigate
David I. Lehn:  the roundup link from Pelle's blog has pictures
    of the devkit.
Manu Sporny: "MintChip™ uses innovative technology, for which
    the Mint has prototypes and five patents pending."
Manu Sporny:  there's one other issue which is that MintChip
    looks to be a patent-encumbered technology which is always a
    concern.
Jeff Sayre: http://mintchipchallenge.com/
Manu Sporny:  they probably did that just to prevent other
    companies from patenting it
    ...conversation about patent licenses...
Manu Sporny:  PaySwarm needs to be patent and royalty-free
Manu Sporny:  we should try and get them to be readily available
    in the webpayments group
Jeff Sayre:  in the MintChip challenge there is a cash prize,
    which they are issuing in physical gold not their currency. =)
Manu Sporny:  Jeff, you are right we should try and contact them,
    would you like to do that if you're interested?
Jeff Sayre:  sure!
Manu Sporny:  it would be great to see if they are interested in
    what we're doing and get them involved
Manu Sporny:  Thanks Jeff
Manu Sporny:  anything else on MintChip before we move on?

Topic: Potential security vulnerability via HTTPS

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-webpayments/2012Apr/0007.html
Manu Sporny:  this was brought up on the mailing list ...
Manu Sporny:  there was a discussion about PaySwarm on a closed
    facebook group and how it does automatic payments over HTTPS...
Manu Sporny:  Specifically the issue raised by a "crypto expert"
    was that we use HTTPS to protect transaction integrity
Manu Sporny:  I wrote a response to Fabio to ask for more
    information
Manu Sporny:  it seems like the person misread the intent of the
    spec - perhaps the spec needs to be more clear
Manu Sporny:  about what we're depending on HTTPS to prevent and
    what we're depending on digital signatures to prevent
Manu Sporny:  they may be misunderstanding how the system
    operates or is intended to operate
Manu Sporny:  they don't think HTTPS is good enough to prevent
    replay attacks, which is confusing because that's exactly what
    one of the things TLS (which HTTPS operates on top of) is meant
    to prevent.
Manu Sporny:  it depends on what their suggested attack is, but
    it's hard to tell from the little text that we received.
Dave Longley:  Yeah, HTTPS has nonces to prevent replay attacks -
    if they get out of order, messages will not validate. HTTPS is
    specifically designed to prevent replay attacks, authentication
    (MITM) - two parts to protocol - don't know which part of the
    protocol they were criticizing/saying we weren't using correctly.
    [scribe assist by Manu Sporny]
Dave Longley:  I'm sure their argument wasn't "HTTPS can't
    prevent replay attacks" - it's unclear from the message what they
    were concerned about. [scribe assist by Manu Sporny]
Manu Sporny:  the only thing I can think of is that they were
    talking about a MiTM related attack to the certificate system...
Manu Sporny:  with regard to network perspectives:
    http://perspectives-project.org/
Manu Sporny:  if China can sign for US websites or vice versa
    then there's a problem - this can happen today, vulnerability for
    all websites.
Manu Sporny:  if a signing authority gets compromised or acts
    nefariously there can be an issue, PaySwarm is no different from
    all other e-commerce sites out there in this respect.
Manu Sporny:  every e-commerce site is susceptible to this attack
    it isn't specific to PaySwarm
Manu Sporny:  you could always narrow down the PaySwarm
    authorities that you trust
to a very specific set
Manu Sporny:  even if that's what the actual complaint what
    about, there is a solution for it
Manu Sporny:  the other issue could be... what happens if a steal
    a private key (nothing we can do about that) other than revoke
    the key ... or what happens if you accidentally make a purchase
    request over HTTP and try to replay it?
Dave Longley:  I don't think we get very specific on transaction
    IDs - how do you deal with transactions at a PaySwarm Authority?
    If we generate transaction IDs, we get rid of many of these
    issues. [scribe assist by Manu Sporny]
Dave Longley:  We really need to find out what the specific
    attack they're talking about is. [scribe assist by Manu Sporny]
Manu Sporny:  anything else on this issue before we move on?

Topic: PaySwarm Vocabulary

Manu Sporny:  next up is the PaySwarm vocab
Manu Sporny: http://payswarm.com/specs/source/vocabs/PaySwarm
Manu Sporny:  Let's finish off the remaining bits that we have in
    here
Manu Sporny:  Let me check the last minutes real quick to figure
    out where we were
Dave Longley:  Yeah, we were discussing contentURL - drop URL,
    maybe just use 'content' [scribe assist by Manu Sporny]
Dave Longley:  We need the definition of what that term is to be
    clear - if it is a general term that covers everything we need,
    then that's fine. [scribe assist by Manu Sporny]
Manu Sporny:  So we decided that contentUrl should just be
    content.
Manu Sporny:  Next up is licenseTemplate
Manu Sporny:
    http://payswarm.com/specs/source/vocabs/payswarm#licenseTemplate
Manu Sporny:  in PaySwarm we have a concept .... you have an
    asset like a webpage (blog/article) and a listing for it that
    tells you the cost,etc ... and there is a license.
Manu Sporny:  the webpage/song is the asset and the license tells
    you if something is free for non-commercial use, or whatever
    other terms there are ... and those two things (asset+license) go
    into the listing.
Manu Sporny:  the license can say things like "the maximum number
    of people can be in a room watching a movie"
Manu Sporny:  and other fairly complex statements.
Manu Sporny:  for 3d-printed goods, you buy a digital file that
    allows you to print a physical item and the license may say the
    number of times you can print the item or there could be serial
    numbers in the license.
Manu Sporny:  the license will be an html file that is a template
    that lets you fill in part sof the license
Dave Longley:  To be clear - the purpose of this is to re-use the
    same license language - so you don't have to mint a new license
    for every asset that you generate. [scribe assist by Manu Sporny]
Dave Longley:  It also gives people certain boilerplate URLs that
    they can use - the listing contains the license, the asset, and
    the terms for the license. The PaySwarm Authority can look at the
    license and parse that information if it knows what the terms
    mean. [scribe assist by Manu Sporny]
Dave Longley:  This is also there in english prose, you can see
    exactly what the license says and where the terms go and find out
    legally if you're abiding by the license. The license is
    digitally signed. [scribe assist by Manu Sporny]
Manu Sporny:  I don't think we plan to change licenseTemplate or
    licenseTerms [scribe assist by Manu Sporny]
Dave Longley:  Just to be clear - the license itself isn't
    signed, the listing is signed, which contains the license.
    [scribe assist by Manu Sporny]
Dave Longley:  Anybody can publish license - this is important
    for re-use of licenses like Creative Commons licenses. [scribe
    assist by Manu Sporny]
Jeff Sayre:  just to be clear, you can use existing licenses or
    create your own.
Jeff Sayre:  there's nothing holding people back from creating
    their own licenses and terms
Dave Longley:  that's correct
Manu Sporny:  yes, anyone can create those templates and pick the
    terms they want.
Manu Sporny:  hopefully it's fairly easy to create a license
    template
Manu Sporny:  you'll want to get legal help to make sure the
    license you write is legally enforceable.
Manu Sporny:  but that is contract law and out of scope for
    PaySwarm
Manu Sporny:  the assumption is that there is a legal framework
    in your country that will acknowledge the license.
Manu Sporny:  anything else before moving on?
Manu Sporny:  so we're not changing those, they are fine the way
    they are.
Manu Sporny:  identityHash is up next.
Manu Sporny:
    http://PaySwarm.com/specs/source/vocabs/PaySwarm#identityHash
Manu Sporny:  this one is problematic ...
Manu Sporny:  background on identityHash...
Manu Sporny:  we wanted the ability to allow these contracts to
    be fully anonymous - even the vendor
Manu Sporny:  the PaySwarm system was designed so that you could
    be anonymous on the system and make purchases
Manu Sporny:  the downside is verifying a contract if a PaySwarm
    Authority disappears... you still need to prove you have legal
    access to the item
Manu Sporny:  a movie studio might take you to a court of law if
    you started showing a movie to 200-300 people at a time, you have
    to prove that the Movie Studio allowed you to do that.
Dave Longley:  The point of this is to answer the question: What
    happens if the PaySwarm Authority goes out of business and
    disappears? [scribe assist by Manu Sporny]
Dave Longley:  The identity hash is only used for vendors and
    only those providers that are providing an asset other than data.
    If you are providing raw data only then it is assumed that you
    have implicitly given access to that data already anyway -- there
    are no rights involved other than the data access itself and the
    contract is considered fairly temporal. If you are not providing
    data then you are providing rights to an asset where the creator
    of that asset is known. However, the home address of that person
    isn't necessarily known. If that home address is a matter of
    public record then our scheme doesn't care about protecting that
    knowledge -- meaning that person's address can be determined just
    from their name anyway -- even without buying anything from them
    using our system. However, if their address is not a matter of
    public record, our scheme protects that individual's address
    because the set of all addresses where that person has lived are
    not available to do a brute force attack. It is true though, that
    all addresses where that person might have lived within an entire
    state or country might be available. If that's the case, it is
    typically unfeasible to try every possible address in the region
    (high CPU/$ cost). If it isn't unfeasible, then it's likely just
    as easy to check some other public record(s) as it is to look in
    our contracts for that information. [scribe assist by David I.
    Lehn]
Dave Longley:  Since CPU power will continue to improve over
    time... we need to ensure that it is sufficiently difficult to
    test the (sufficiently small) set of addresses that an attacker
    believes a person exists in. In order to do this, we will append
    a random number, in a certain range, to the identity message that
    is digested. This nearly identical to the concept of a salt,
    except that this salt doesn't just protect against dictionary
    attacks, it protects against computational attacks because the
    salt is kept secret (actually, it is thrown away after use).
    [scribe assist by David I. Lehn]
Dave Longley:  This salt can be discarded because, in the event
    of a subpoena, there will be a very small data set (relative to
    the "guess set" a brute force attacker would have to use) that
    will have to processed looking for a hash match. We can just test
    all random numbers (possible salts) along with each address in
    the set. The random number should be sufficiently small that we
    can test identities when subpoena'd but sufficiently large to
    thwart attackers. It can increase with time as CPU power gets
    better. Note that this test only needs to be run if the PaySwarm
    authority involved has gone away (the actual identities are no
    longer stored in an available database). [scribe assist by David
    I. Lehn]
Jeff Sayre:  if identity can be discerned through brute force
    techniques, why would this be considered a desireable feature?
    [scribe assist by David I. Lehn]
Manu Sporny:  An attempt to brute-force the hash would take more
    than 20 years on a large computing cluster - at considerable cost
    (millions of dollars) [scribe assist by David I. Lehn]
Dave Longley:  Right now, there are two different versions of the
    contact - the version of the contract given to the vendor does
    not have the address information for the buyer. The vendor defers
    to the PaySwarm Authority for the address information (it can't
    see it). The buyer gets a version of the contract that contains
    their address information, but possibly not the vendor's address
    information (but the identityHash instead). [scribe assist by
    Manu Sporny]
Jeff Sayre:  Still, if you could brute-force this, then is it a
    desirable feature? [scribe assist by Manu Sporny]
Dave Longley:  You can only brute-force if you know a set of
    potential answers ahead of time. [scribe assist by Manu Sporny]
Jeff Sayre:  If it's only a handful of people that can carry out
    a brute-force attack on this, it still makes me wonder why this
    would be considered useful if this mechanism can be broken.
    [scribe assist by Manu Sporny]
Dave Longley:  I think we should look at the use cases for
    identityHash again - it's been a long time since we've looked at
    this use case. [scribe assist by Manu Sporny]
Jeff Sayre:  You could solve this issue using a form of escrow as
    well. [scribe assist by Manu Sporny]
Dave Longley:  We do already support escrow in PaySwarm - we can
    hold funds for a period of time - the way we plan to deal with
    bad vendors is if you get enough "I didn't get the product"
    complaints - you start getting refused from the system. [scribe
    assist by Manu Sporny]
Jeff Sayre:  You could use escrow until you trust the person
    enough and then lift the need for escrow. [scribe assist by Manu
    Sporny]
Manu Sporny:  so that's identityHash ... the other remaining
    hashes are really necessary
Manu Sporny:  We keep license, licenseHash, listing and
    listingHash [scribe assist by Manu Sporny]
Dave Longley:  Yeah, those are very necessary - we need those.
    The hashes are important to determine that you know what you're
    signing for - that both sides agree that they're signing the same
    text/document. [scribe assist by Manu Sporny]
Manu Sporny:  right, there is no way to switch out the
    asset/license/listing out from underneath you
Manu Sporny:  because the hash of what they signed must match
    what you're looking at as the buyer.
Dave Longley:  There may be other terms for validFrom validUntil,
    but we do need them - sellers need to be able to sign listings
    for a short period of time. For the current demo, the recipes are
    signed for 24 hours (and that way they're valid). You don't say
    you're selling something for all of eternity for $0.05 - you can
    change prices quickly w/o having to contact anybody to do it.
    [scribe assist by Manu Sporny]
Manu Sporny:  that's all the time we have for today for the call
Manu Sporny:  we can talk about more vocab next time and talk
    about rdfa and JSON-LD updates.
Manu Sporny:  we've been doing a lot of RDFa and JSON-LD updates
    lately at DB to get them ready for PaySwarm (and to just get them
    ready for REC, etc).
Manu Sporny:  once those foundational things are done we can
    focus more on higher-level PaySwarm stuff.
Manu Sporny:  Dave Longley has been doing a lot of work on
    digitally signing deterministic graphs
Manu Sporny:  we need these foundational things working before we
    can put much more effort into the PaySwarm specs.

-- 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 Wednesday, 18 April 2012 00:31:44 UTC

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