- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Thu, 12 Jan 2012 14:32:53 -0500
- To: public-webpayments@w3.org
- Message-ID: <4F0F3565.2000201@digitalbazaar.com>
On 01/12/2012 02:27 PM, Pelle Braendgaard wrote: > Thanks Dave, > > That clears that up. I just realized it didn't support that. > > Obviously we believe this is an important feature. It opens the > standard up to many different kinds of payment devices that we can't > even imagine today. I think two very different things are trying to be standardized here, which makes me hopeful that perhaps both can be standardized. PaySwarm is trying to standardize how payment providers facilitate online commerce (or simple payment) between their customers and the customers of other payment providers. OpenTransact is dealing strictly with standardizing the API for an individual payment provider, largely by using account delegation. A PaySwarm Authority may implement OpenTransact, or some part of it, in order to delegate account access for its customers (it may also choose another method). However, to actually list items for sale and initiate commerce internally or across PaySwarm Authorities, PaySwarm Authorities would use the PaySwarm protocol. > > P > > On Thu, Jan 12, 2012 at 2:02 PM, Dave Longley > <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote: > > On 01/12/2012 01:45 PM, Pelle Braendgaard wrote: >> So how would I: >> >> - create a mobile wallet app with one or more payswarm authorities? >> - give permission to a Mint like system to pull out and analyze >> my data? >> >> There are many different use cases that I can't see solved >> without either sharing my Payswarm Authority password or using OAuth. > > Please keep in mind that the PaySwarm spec doesn't *require* you > to implement OAuth. That doesn't mean that a PaySwarm Authority > can't implement it. The spec doesn't even get into how you > delegate access to your PaySwarm account other than for what is > necessary for transferring funds or engaging in online commerce. > Anything else is between you and your PaySwarm Authority of > choice. As you say, "it is out of scope". Different PaySwarm > Authorities might want to implement various ways of granting other > applications access to your financial information -- or none at all. > > All that is needed for the protocol to establish interoperability > (to actually send money or to allow merchants to automatically > spend money), is a combination of digital signatures (which are > also used for non-repudiation on receipts and listings), > encryption, and budget IDs. These are based on existing standards > PKCS, AES, and TLS, just like Oauth2 relies upon. > > Again, PaySwarm is silent on how you handle delegating access to > your PaySwarm Authority as this is between you and your PaySwarm > Authority. The interoperability question is about how PaySwarm > Authorities and their associated merchants and customers interact. > The PaySwarm spec is about enabling payments and commerce on the > web in a standard way. This does not cover delegating access to > financial analysis systems and the like, as this is out of scope; > forcing individual PaySwarm Authorities to pick a particular > method of general account access delegation has little to do with > their ability to interoperate with each other or to facilitate > online commerce between merchants and customers. > > >> >> P >> >> >> On Thu, Jan 12, 2012 at 1:21 PM, Dave Longley >> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> >> wrote: >> >> On 01/12/2012 01:00 PM, Pelle Braendgaard wrote: >> >> Unless I'm missing it the single most important part of >> OAuth2 that has not been implemented in PaySwarm is >> delegation. How do I connect to a PaySwarm authority from >> a mobile app or a new kind of application such as crowd >> funding without handing them my private key? >> >> >> Clients (customers) do not have to digitally sign transfers >> or contracts. They can use their PA (PaySwarm Authority) as a >> delegate for this. All you need is a web browser to connect >> to your PA's website in order to authorize a purchase. >> Merchant software redirects you to your PA using your web >> browser. >> >> If you want to authorize merchant software to automatically >> purchase on your behalf, you create what is called a "budget" >> on your PA for that merchant. The merchant's ID is stored >> with the budget and the receipt of your purchase includes the >> budget ID so that the merchant may post future purchase >> requests using that budget ID to your PA. The budget may >> contain limits on the total amount spent, total amount that >> can be spent on a single purchase, expiration dates, or >> whatever other creative features can be provided to you by >> your specific PA. The only part that is in the standard is >> the ability to use budget IDs (IRIs) to do automated >> purchases. They function in a similar way to oauth tokens but >> without the extra token negotiation complexity -- and they >> are encrypted with the merchant's public key so they can be >> passed over plain HTTP, enabling merchant websites to forgo >> the yearly cost of an SSL certificate. >> >> Again, only the merchant software has to do any digital >> signing, the customer software (a web browser) can delegate >> signing to their PA's software. It is possible for customer >> (the "source" of the funds) applications to be written that >> do use digital signatures, but it is not a requirement, >> certainly not for the simplest functions like sending money >> through your PA as a vanilla transfer or in return for an >> asset that you are purchasing from a merchant. >> >> -- >> Dave Longley >> CTO >> Digital Bazaar, Inc. >> >> >> >> >> >> -- >> http://picomoney.com - Like money, just smaller >> http://stakeventures.com - My blog about startups and agile banking > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > > > > > -- > http://picomoney.com - Like money, just smaller > http://stakeventures.com - My blog about startups and agile banking -- Dave Longley CTO Digital Bazaar, Inc.
Received on Thursday, 12 January 2012 19:33:34 UTC