Re: PaySwarm Web API (was: Web Payments Telecon Minutes for 2011-12-16)

On 12/16/11 11:02 PM, Manu Sporny wrote:
> PaySwarm Web API
> http://payswarm.com/specs/ED/web-api/2011-12-14/

On reading Sections 1-3:
I find it easy to understand; reads smoothly. No issues so far. This 
doesn't necessarily mean I disagree with Pelle's point of view (that 
the current PaySwarm track is attempting too much too soon), but to me 
you've made a very strong overall case here for how the PaySwarm 
system *might* work. :-)

Section 4.1:
Minor typo:
"An invalid certificate or TLS error or any kind MUST result..."
I believe should read "...error [of] any kind...", not [or].

Section 4.2:
I'm uncomfortable with the repeated use of "incredibly difficult" 
relating to security practice and ability to forge or break keys. It's 
a minor point, but using it here has the ring of sophistry to me: -- 
of attempting to convince the listener of the value of your statement 
without supplying supporting reasoning. Yet I'm having trouble 
thinking of a better way to say it briefly that gets the message 
across.  Maybe just downgrading a notch to "extremely" would do it? Or 
maybe it's necessary to give a couple of sentences, at once place 
only, to explain how the level of difficulty is such that it would be 
counterproductive, on the margin, for anyone to commit the resources 
necessary to break the code just to get access to a single key? (If 
this is true).

Section 4.3: typo: 4.3 3) 3.1  : 'emtpy' should be 'empty' .
Section 4.7: typo: there's an extra letter on the end of "specificationd"
Sec 6.4: typo: 'bakc' should be 'back'.

I'll also note that the colored setup of the code was delightful; made 
it much easier to understand. And as a person who struggled with HTML 
and CSS for years and then peaked ahead into RDFa, it's very 
gratifying to see them all come together in this way.

One last comment: I had to read through the security and signing 
sections with little comprehension; I have no background in this and 
find it quite complex. There does seem to be a lot of it. This made me 
ruminate on Pelle's comments and also those of Van Jacobson: that the 
levels of different languages that need to communicate are an Achilles 
heel for security of the current web and a reason why they're making 
CCN. So what you're doing here needs to be air-tight; --as you've 
already stated explicitly in section 4.7.

Given the world's interest in siphoning off any freely available 
capital, I guess if it actually isn't possible to do secure 
transactions with this method, that will become apparent soon enough. 
:-) .


Steven Rowat




> 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
>

Received on Saturday, 17 December 2011 23:35:08 UTC