On reinventing PKI
3 views
Skip to first unread message
Pelle Braendgaard
Jan 12, 2012, 1:00:52 PM1/12/12
to Web Payments, opentr...@googlegroups.com
Manu,
You say:
A new form of PKI has not been invented for PaySwarm. It uses the industry standard for both encryption and digital signatures – AES and RSA. The PKI methods are clearly laid out in the specification and have been settled for quite a while, not a single person has mentioned that they want to use a different set of PKI methods or implementations, nor have they raised any technical issues related to the PKI portion of the specification.
Pelle might be referring to how PaySwarm specifies how to register public keys on the Web, but if he is, there is very little difference between that and having to manage OAuth 2 tokens, which is a requirement imposed on developers by the OpenTransact specification.
A PKI is not signing nor encryption. It is the infrastructure used to manage the keys. It is notoriously complex and many different PKI's have been created and attempted.
This is the link to the PaySwarm PKI:
It appears your PKI has:
- registration
- http based public key lookup
If you believe that digital signatures are sacrosanct you need many different things to create an effective PKI:
- Who does the key belong to?
- How can we revoke it?
- How do we auto expire it?
- When we create a new cert are our old receipts still valid?
- I lost the private key what do I do
This does not belong in a payment standard.
I would be willing to help create a new simple web based PKI based on what is in PaySwarm. But it just does not belong in neither PaySwarm nor OpenTransact spec itself.
The oauth2 http mac authentication scheme could easily be extended to use RSA on top of such a simple standard.
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?
Pelle
-- http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Pelle Braendgaard
Jan 12, 2012, 1:45:38 PM1/12/12
to Dave Longley, public-we...@w3.org, opentr...@googlegroups.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 <dlon...@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.
Pelle Braendgaard
Jan 12, 2012, 2:27:50 PM1/12/12
to Dave Longley, Web Payments, opentr...@googlegroups.com
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 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 <dlon...@digitalbazaar.com> wrote:
On 01/12/2012 01:00 PM, Pelle Braendgaard wrote: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.
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?
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.
Reply all
Reply to author
Forward
0 new messages