- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 03 Jul 2014 22:20:56 -0400
- To: public-webpayments@w3.org
On 07/03/2014 02:58 PM, Adrian Hope-Bailie wrote: > Am I missing something or is this HTTP-Signatures with a small > twist? If you're missing something, I'm missing it too. It seems like a really restricted subset of HTTP-Signatures with a lock-in to the crypto algorithm and "things that you can sign" with a few major security holes thrown in. Features that are missing from the solution that HTTP Signatures has: * Ability to digitally sign HTTP headers (because you can do a lot of nasty things by modifying important headers... like 'Location:' ). * Ability to not sign the body if that doesn't make sense (like when you're streaming GBs of data or using trailers or ...) * Ability to sign the HTTP method, which is really important: GET /me/accounts/life-savings DELETE /me/accounts/life-savings * Ability to identify keys in a greater variety of ways (URL, fingerprint, etc.) * The server can specify when it expects a digital signature when accessing a resource. * Easy to share keys between clusters of clients. * HMAC support, because there are legitimate uses of it even though it's bad in general. * Ability to select the key format and signing algorithm I'm going to stop there, but the solution seems questionable. There's nothing in there that I can see that the HTTP Signatures spec doesn't already do. > The only thing that makes it similar in any way to BitCoin is the > use of a ECDSA secp256k1 keypair Bitcoin is great so this must be great if it even uses a fraction of Bitcoin technology, right? Marketing, marketing, marketing! :P -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Friday, 4 July 2014 02:21:25 UTC