- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 17 Dec 2011 02:02:16 -0500
- To: Web Payments <public-webpayments@w3.org>
The minutes for today's call are now available here, thanks to Mike and
Dave Lehn for scribing:
http://payswarm.com/minutes/2011-12-16/
Full text of the discussion follows:
Web Payments Community Group Telecon Minutes for 2011-12-16
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2011Dec/0027.html
Facilitator:
Manu Sporny
Scribe:
Manu Sporny, David I. Lehn, Mike Johnson
Present:
Manu Sporny, Pelle Braendgaard, David I. Lehn, Mike Johnson
Manu Sporny is scribing.
Topic: Issues with PaySwarm and Simplicity
Pelle Braendgaard: I'd like to start out by discussing how this
group has been operating. I'm going to send out an e-mail to the
mailing list. I'm a bit unhappy about how this process has been
progressing, it doesn't seem to be a W3C standard, it seems as if
people think that PaySwarm is going to be the solution. I think
that OpenTransact is just as good of a solution. I've been very
open about how to integrate, but I don't think that there has
been much in the way of feedback on that. I feel it's very
important that we do things simply. For example, the Agenda today
is quite irrelevant. We should only discuss this if we are going
to follow PaySwarm. I completely disagree with that approach of
having a full, all encompassing standard. I feel like I'm wasting
my time.
Manu Sporny: You raise a valid point, but I think that there
have been no other strong proposals put forward.
Pelle Braendgaard: I believe I have. Out of not wanting to make
this a PaySwarm vs. OpenTransact debate, I haven't proposed that
yet. But that is what I'm going to propose today via e-mail. I'm
going to propose OpenTransact as a basis for the W3C Web Payments
work.
Manu Sporny: I think that would be good, please do that - we
need to thoroughly vet these ideas.
Manu Sporny: Perhaps your reading on it is that we're trying to
"push PaySwarm as the solution" is... well, you could look at it
in two different ways: The whole reason this group started was
because our company decided to place all of this technology into
an open protocol, into an open standard, we led by producing
working code, specifications, Web vocabularies, and then
publishing those to the Web. We are completely open to
modifications on the proposals, we're completely open to
different approaches to the problem as long as it addresses the
use cases. If OpenTransact can do that, we should consider it
strongly. We need to vet these ideas, so please send the proposal
to the list. Does that alleviate some of your concerns?
Pelle Braendgaard: Yes, I'll send a proposal to the list later
on today. I haven't done that because I don't want to step on any
toes... I wanted to guide PaySwarm into what I think is a
realistic standard. Right now, it's too all-encompassing. I feel
like input I've given is not reflected in the Web API.
David I. Lehn: What parts of the PaySwarm spec do you have
issues with? We do understand the need for low-level
functionality, but we're trying to define the whole ecosystem. We
don't want just the low-level stuff. Maybe that's the better
approach, but...
Pelle Braendgaard: Well, I think we need to keep things very low
level. For example, Vendor Registration doesn't need
standardization yet... I don't think. That's something that
different service providers could have their own, from that you
could work out a standard for it. A standard is needed for
payments right now, standard response format, querying whether a
payment went through - that has to be done in a simple, low-level
generic way. People need to use that for a while before we go in
and create the higher-level stuff.
Pelle Braendgaard: For example, I see digital signatures as a
great option for receipts, but for payment, I don't see that.
It's very complex, the PaySwarm spec.
Manu Sporny: The spec is as complex as it needs to be to address
the use cases we've laid out. In principle, I don't disagree with
you, Pelle. However, we need to address the use cases. I think
the issue is that nothing has been proposed that addresses all of
the use cases...
Pelle Braendgaard: I think OpenTransact has been proposed, but
not directly, to be the underlying low-level standard before. I
think we put too much work into the use cases, we spent 2-3
months going through use cases. It's classic waterfall, not a
historically successful model for creating standards. We need to
start with simpler things. We can support all of the use cases
using a combination of HTTP and HTML.
Manu Sporny: ... but that's exactly what we're trying to
standardize here - how /do/ you support all of these use cases?
Pelle Braendgaard: Exactly.
Manu Sporny: We need to understand exactly how each one of those
use cases are addressed, we can't just simply say they can be
addressed and not show how they can be technically addressed.
That's what I'm concerned about. When you get down to the
technical details, some of those use cases cannot be addressed,
for example - decentralization, receipts, cannot be addressed
without getting a bit more complicated with the implementations.
Again, I agree with you in principle... but we have not seen a
technical solution yet that addresses all of the use cases that
we've interested in.
Pelle Braendgaard: I believe OpenTransact does.
Manu Sporny: I do not believe that OpenTransact solves some of
the use cases that have been put forward. However, if you can
make the technical case that it does, I see no reason why we
couldn't also standardize OpenTransact. The end result of this
community group could be two different specs for dealing with
payments on the Web. It might be OpenTransact + PaySwarm. We
shouldn't look at this as an all-or-nothing thing. Maybe
OpenTransact is better at solving a subset of use cases, maybe
PaySwarm is better at another subset.
Pelle Braendgaard: This is why I've been proposing the layered,
step-wise approach. It's how many successful standards have been
created. I think that is important, we do not need to address all
use cases there.
Pelle Braendgaard: I think there are a number of technologies
out there that already solve the distributed use cases. It can
already be done via OAuth. I don't see the need for most of the
PaySwarm standard. It's definitely not following a layered
approach, I thought we agreed it was going to do that?
Manu Sporny: We outlined why we thought OAuth was not a valid
solution. If we implement OAuth, it's not a solution to the
digital receipt problem. OAuth duplicates functionality already
provided by digital signatures. Digital signatures are the
correct technical solution for delegating access and for signing
contracts and receipts.
Pelle Braendgaard: I think OAuth is different from digital
signatures... OAuth provides distributed transactions and
distributed checking of receipts. It provides a good standard for
delegating access. I disagree... yes, OAuth doesn't support
digital signatures, but it doesn't need to. Digital signatures
should be an optional thing for digital receipts.
Pelle Braendgaard: We should really look at OAuth 2 and it seems
to work very well for the majority of people out there, it's a
good standard. But it works for accessing receipts. We should not
require digital signatures. The requirement for digital
signatures should not be the reason that you don't pick OAuth 2,
which is an official Internet standard now. I agree that it
doesn't work for receipts... but it works for /accessing/
receipts.
Manu Sporny: Right... so we actually implemented the latest
PaySwarm demo using OAuth and the finding we came to showed that
the implementations were overly complex by integrating OAuth. You
ended up doing many more HTTP calls than necessary and even after
you implemented OAuth, you still had to implement digital
signatures. We found that in fact, all you needed to implement
was digital signatures and all of a sudden there was a massive
reduction in complexity for the implementations. What OAuth 2
does is effectively replace digital signatures with this token
mechanism... but if you just implement digital signatures, all of
a sudden you have access control for free, because you know who
is making calls to your system and whether or not they're allowed
to perform certain actions on your system. You also get digital
receipts for free because those depend on digital signatures as
well. At the end of the day, all you really need digital
signatures.
Pelle Braendgaard: I completely disagree with your conclusion.
They're two completely different things. We don't want end-users
to deal with digital signatures. We only want servers to deal
with digital signatures. Until you can do digital signatures in
browsers, on cellphones, we don't need to be discussing this.
Digital signatures are a pure server side issue, I'm fine with it
there, but we shouldn't throw out OAuth 2 just because we need
digital signatures.
Editorial note: you can do digital signatures in browsers and
cellphones today: http://digitalbazaar.com/forge/
Pelle Braendgaard: I disagree with the way you guys are pushing
forward with this, I don't fault your company for pushing ahead,
I disagree with this being the W3C Web standard solution. I don't
mind you guys experimenting with it and pushing it out.
OpenTransact is simple and used, this is why I wanted to join in
with W3C discussion, but you are discarding a bunch of standards
that are already Internet standards. I don't want to be nasty or
angry, I just feel that this is going the wrong way. Having these
sorts of things on the Agenda, I just don't think we're there
yet.
Manu Sporny: So, I think the best way to proceed is for you to
put the proposal forward on the mailing list and see how much
uptake that gets. I appreciate your feedback, but I'm still not
hearing a technical argument for how OpenTransact addresses the
use cases that we put forward as a group. Therefore, it's just
not the correct technical solution until it addresses those use
cases. I don't disagree that we should take a layered approach,
and perhaps if there is disagreement on which use cases should be
addressed, then that is a good signal for the requirement of two
different specifications. Maybe we should standardize both.
Typically that is what happens when you have fundamental
disagreements on what the technology should do. If we are headed
into a situation where we believe there are certain use cases
that should be supported and you're not convinced that we need to
support those use cases, then perhaps we need to have two
different standards. We're not trying to plow through and just
standardize PaySwarm - we need to make sure that the use cases
that are important to people must be addressed. Is that a fair
view of the situation?
Pelle Braendgaard: Yes. I think anyone who comes into the group
is going to think that PaySwarm is the W3C standard that is being
worked on. I disagree with that. I don't think that's right.
Manu Sporny: Well, you have commit privileges to everything. You
were given commit privileges at the very beginning, so you have
the power to change the perception if you'd like. I think you
should propose something, I think we should evaluate it, and I
think that we should figure out how we can continue to work
together on this. Does that seem like a fair and reasonable way
forward?
Pelle answers in the affirmative.
Manu Sporny: Ok, based on that any updates or changes to the
agenda that should be made?
Pelle Braendgaard: I'll hear what you have to say on these
things.
Topic: Spec updates
Manu Sporny: We have a number of spec updates that happened last
week. This is the latest implementation info that we have, we're
going to have a live demo launched soon.
Commerce Web Vocabulary (http://purl.org/commerce)
http://payswarm.com/specs/ED/vocabs/commerce/2011-12-13/
PaySwarm Web Vocabulary (http://purl.org/payswarm)
http://payswarm.com/specs/ED/vocabs/payswarm/2011-12-13/
PaySwarm Web API
http://payswarm.com/specs/ED/web-api/2011-12-14/
PaySwarm Web API diff-marked copy to previous version is here:
http://payswarm.com/specs/ED/web-api/2011-12-14/diff-20110926.html
Topic: Vendor Registration
http://payswarm.com/specs/ED/web-api/2011-12-14/#vendor-registration
Manu Sporny: The idea here is that in order to operate on the
network, you have to be able to create digital signatures -
assets, listings, contracts, receipts, requests - all digitally
signed. When you register your public key with the PaySwarm
Authority you get some config info back. The destination
financial account, default license, a whole bunch of preferences
returned by PaySwarm Authority during registration. Vendor
registration is used by a for-profit blog, web app store, etc.
It's how a website registers with their PaySwarm Authority. The
process is outlined in the link above. Two things that happen
during Vendor creation: Identity is created, financial account is
created. Any questions?
David I. Lehn is scribing.
Mike Johnson: I think we're all pretty clear on this, Pelle?
Pelle Braendgaard: Just reading it now. This is where public
key/digital signatures come in. Where does vendor get their key,
how do they sign?
Manu Sporny: The WordPress blog, for example, generates the
public/private keypair. Keeps private key, registers public key
with PaySwarm Authority. Registration works much like how
Twitter/OAuth works, but simpler - you just register a
public/private keypair from your server software. Registers
public key w/ PaySwarm Authority, then all you need to do is make
requests that are signed. You don't need to do the big OAuth
token dance to get a token so that you can make requests, no
nonces need to be tracked, no tokens need to be tracked.
Mike Johnson: Any software written in any Web-capable language
can do this key creation/registration... PHP, Python, Ruby, etc.
Pelle Braendgaard: So, what does this buy us over OAuth 2?
Manu Sporny: You don't have to do the OAuth token dance and you
don't have to implement/use OAuth. You eventually need digital
receipts. Even if you implement OAuth, you still need digital
signatures. So you simplify the system by not implementing OAuth
without reducing what you can do with the system. You still need
digital signatures/crypto for contracts, receipts, assets,
listings, encrypting information over insecure channels (like
HTTP), reduced cost because you don't need to buy an SSL
Certificate for $30-$50/year.
Pelle Braendgaard: None of those things are true, the only
person that needs an SSL certificate is the PaySwarm Authority.
Manu Sporny: If you are going to have a callback from the
PaySwarm Authority back to the WordPress software (for example,
to notify that a purchase is complete), you absolutely need to
have an SSL certificate on the WordPress software otherwise you
open yourself up to a MiTM attack and you leak personal purchase
information to the Web.
Pelle Braendgaard: but for receipts, you just need the PaySwarm
Authority to have SSL.
Manu Sporny: But then you can't do digital signatures for things
like requests.
Pelle Braendgaard: What kind of request?
Manu Sporny: A request to another participant on the network
that needs to verify the origin of a message. To do anything that
you would use OAuth to do. For requesting the processing of a
purchase request. To agree to a bill of sale. To digitally sign
an asset or listing.
Pelle Braendgaard: I hear no reason why a vendor needs to have a
public/private keypair, they can just use OAuth.
Manu Sporny: Then how does a vendor digitally sign anything?
Pelle Braendgaard: They don't have to digitally sign anything.
Digital signatures is just one use case for a small use case. We
increase complexity by incredible amounts for a small use case.
Manu Sporny: It's a use case that's important to us. You can't
make the argument that because a use case isn't important to you
that it's irrelevant. You can't say that OAuth 2 solves all of
the use cases that are "important" and ignores the "unimportant"
ones. That dodges the question. How do you address the many use
cases that we have that require digital signatures? The question
was: How do you use OAuth to address the digital signatures use
cases? and the answer to that question is "You can't. You need a
digital signatures solution for that."
Manu Sporny: Here's an example - purchasing a meal, book or
groceries, using a mobile phone with NFC and no data connection.
The phone reads information from an NFC device proposing a bill,
the phone digitally signs the bill and sends it back over NFC.
Then the restaurant forwards the digitally signed (and possibly
encrypted) bill on to the PaySwarm Authority for processing. You
can only solve that via crypto/digital signatures. If you don't
have that, you can't create these peer-to-peer solutions.
Pelle Braendgaard: So, what you're saying is that until a
purchaser can do digital signatures, then PaySwarm is not valid?
Manu Sporny: No, that is not what I am saying.
Pelle Braendgaard: We've discussed this before, you've confirmed
that end-users are not supposed to be signing anything. I'm
making numbers up now, but everyday in US tens of millions of
electronic contracts happen without digital signatures. They do
not happen in the ideal way. I like digital signatures. When it
comes to end-users, the technology isn't there for it yet.
Mike Johnson: Digital Signatures allow for "intents to purchase"
Mike Johnson: Vending machine may have signed contract but no
internet connection. buyer can use nfc and phones network for
communications, where the transaction is processed via the
cellphone, securely and the vending machine knows that the
contract wasn't modified. This is about having a distributed
payment mechanism, not everyone has a data connection to the
server. This is about being able to trust that your payment
agreement can pass through multiple hostile networks without
being tampered with. This is what a next generation payment
system should be doing in a consistent way.
Manu Sporny: Pelle, you just admitted that things are not done
in the ideal way. Current payment networks are not flexible.
There are no IOUs from customers without incredible risk to
merchants. Regarding you statement about digital signatures being
too complex for customers - they're not going to see anything
even remotely close to "Digitally Sign Contract" button - they're
just going to see a "buy" button and they're going to click it.
We just need to make sure that the technology being provided
allows for flexibility and security. You can't do this with just
OAuth alone.
Mike Johnson is scribing.
Manu Sporny: we need digital signatures and they become a better
replacement for oauth
Manu Sporny: you won't need these multiple layers, you get all
of that through just having vendors/customers digitally sign the
data
Manu Sporny: this allows us to have these use cases we want
whereas with oauth we can't
Manu Sporny: the decisions need to be based on technical
argument, so if the use cases don't match we need to address it
through the use cases
Pelle Braendgaard: I agree with the reasoning
Pelle Braendgaard: but I dont think it should be part of the
core
Pelle Braendgaard: but why does vendor registration need to be
standardized? It doesn't need to be standardized.
Pelle Braendgaard: by focusing on just a few use cases where
digital signatures are necessary you make the other use cases
much harder to address
Pelle Braendgaard: focus should be on the 95% of the use cases
and push harder work onto the fewer use cases where digital
signatures would be a good solution
Pelle Braendgaard: its danger to push for technology that
historically most developers don't understand
Pelle Braendgaard: is it important to standardize things like
vendor registration?
Pelle Braendgaard: Vendor registration shouldn't be in the spec.
How it happens shouldn't be in there.
Manu Sporny: almost all of that stuff is outside the spec. It
says that in the spec, that how the account is created is outside
the spec.
Manu Sporny: only thing in spec is when vendor needs to talk to
payswarm authority, when they register their public key.
Manu Sporny: specifically, vendor account creation is outside
the spec
Manu Sporny: the spec says it is outside the spec
Pelle Braendgaard: it then goes and says how to do it
Manu Sporny: not quite, it specifies how the private/public key
pair is registered with the PaySwarm Authority.
Manu Sporny: This is another reason for digital signatures - the
vendor needs to be able to digitally sign the listing and terms
under which the assets are available.
Manu Sporny: We need to do this because we don't want a
centralized asset mechanism, we want to handle this in a
distributed manner.
Manu Sporny: the emphasis is on the key registration, not vendor
account creation
Pelle Braendgaard: Still does not see it as part of the
implementation details of the payment API
Pelle Braendgaard: I think that section 5.3: Vendor
Registration, including public/private key registration, is
outside the spec. These are just implementation details as far as
I see it.
Manu Sporny: But that's what a spec is about, it's about
implementation details.
Pelle Braendgaard: by saying the key registration is already
part of the vendor registration, you are explaining how to
register a vendor
Pelle Braendgaard: isn't there already a spec for registering
keys?
Manu Sporny: We looked and we haven't found any. No existing
specs for public/private key registration, we were surprised as
well.
Manu Sporny: we'd use it if it exists, but it doesn't as far as
we know.
Pelle Braendgaard: well then it should be renamed to registering
public/private key pairs
Manu Sporny: ok, we can rename
Manu Sporny: sure someone else may want to register a key pair
Manu Sporny: it was set up this way to enable one-click
registration
Manu Sporny: explains wordpress registration
Manu Sporny: other thing that came up was that OAuth doesnt
solve is the problem of decentralized assets and listings
Manu Sporny: how does a website specify that they have a
something for sale in a secure way?
Manu Sporny: they would need SSL certificates if they dont
digitally sign
Manu Sporny: one solution is to centralize assets and pricing,
that's bad
Manu Sporny: more innovation comes from decentralization
Pelle Braendgaard: decentralized is important, but this is the
web and by default it is decentralized...
Pelle Braendgaard: most people would use a third party and don't
need an SSL-cert alternate solution
Pelle Braendgaard: still does not understand the reason for
offers being signed
Manu Sporny: but then they are locked into that site they are
offering their services from
Pelle Braendgaard: don't think that is a problem
Manu Sporny: don't agree, they don't get to pick who their
payment processor or authority is
Pelle Braendgaard: the market decides that
Pelle Braendgaard: right now you pick your payment process and
can switch
Manu Sporny: all of your data is locked into that one payment
processor, then you have a huge cost locked into that processor
Pelle Braendgaard: that's a market issue because a smart
business will offer portability as an advantage
Manu Sporny: but where has that happened in the commercial world
Pelle Braendgaard: maybe the lack of it shows there is no need
Mike Johnson: Two different philosophies here. There has been a
large shift on data portability. People want more control over
how data is stored and moved across systems. With
Diaspora/Facebook/Google+ - examples from social. I think the
idea of distributed design and data portability are very strong
requirements. I don't think we should lock ourselves into the way
traditional payment processors work today. We shouldn't look at
the state of payments today and say that's the best we can do.
We're trying to help people control their data upfront and not
wait for the problem to appear and then fix it at that point. The
Web is distributed, data should be distributed. It's easier to
implement centralized, but the issue is the philosophy: What is
the data that is involved and who should be involved? [scribe
assist by Manu Sporny]
Pelle Braendgaard: I agree that things should not be locked
down, but I still don't understand why product listings should
have a place in a payment standard. I haven't put much thought
into this yet. However, I don't understand why it's a core part
of this. I don't think many small business owners would think of
this as an issue, they'd just move their store.
Manu Sporny: we are out of time, let's continue the discussion
on the mailing list. Pelle we'll wait for your OpenTransact
proposal - thanks for voicing your opinion, important to address
that early on. Let's keep the focus on technical merit. Thanks
for great discussion, no call during the holidays. We'll have
another telecon after the holidays.
-- 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 Saturday, 17 December 2011 07:02:55 UTC