- From: Pelle Braendgaard <pelle@stakeventures.com>
- Date: Thu, 12 Jan 2012 13:45:38 -0500
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: public-webpayments@w3.org, opentransact@googlegroups.com
- Message-ID: <CAHtLsUXc2432WvryPvc8XbqrVF6P7z9jsGpUsm=dnaWm_ntjyQ@mail.gmail.com>
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. P On Thu, Jan 12, 2012 at 1:21 PM, Dave Longley <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
Received on Thursday, 12 January 2012 18:46:16 UTC