Re: On reinventing PKI

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.

P

On Thu, Jan 12, 2012 at 2:02 PM, Dave Longley <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>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