W3C home > Mailing lists > Public > public-webpayments@w3.org > January 2012

Re: On reinventing PKI

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Thu, 12 Jan 2012 14:02:20 -0500
Message-ID: <4F0F2E3C.7070209@digitalbazaar.com>
To: public-webpayments@w3.org
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.
Received on Thursday, 12 January 2012 19:07:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 January 2012 19:07:46 GMT