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
Chair
Manu Sporny
Scribe
Dave Longley
Present
Dave Longley, Manu Sporny, David I. Lehn, Jeff Sayre
Audio Log
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: 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: 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.
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.
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.
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: 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: 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: 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: 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.

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