- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 17 Apr 2012 20:31:05 -0400
- 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