Re: HTTP Signatures specification updated

On 2014-02-04 07:36, Melvin Carvalho wrote:
>
>
>
> On 1 February 2014 19:54, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>
>     In order to make Web Payments (and REST APIs in general) more secure on
>     the Web, this group has been working on extensions to the HTTP protocol
>     so that you can digitally sign HTTP headers and content.
>
>     We just pushed an update to the specification and believe that it's
>     ready for public comment. The specification is already deployed in
>     production at Joyent and Digital Bazaar:
>
>     http://tools.ietf.org/html/draft-cavage-http-signatures-01
>
>     This technology is useful when you just need to make a secure request to
>     your financial provider to transmit money from you to someone else, make
>     a payment, create an invoice, etc. without having to perform a login
>     handshake (OAuth, user+pass, etc.).
>
>     This is what a payment request looks like using this specification:
>
>     POST /transactions HTTP/1.1
>     Host: payments.example.com <http://payments.example.com>
>     Date: Sat, 01 Feb 2014 21:31:40 GMT
>     Content-type: application/ld+json
>     Digest: SHA-256=ZjQ1MjU1ZWNhNWUwZWM4N2...yAqdGVzdAo=
>     Content-length: 525
>     Authorization: Signature
>       keyId="http://bluebank.com/people/john/keys/5",
>       algorithm="rsa-sha256",
>       headers="request-line host date content-type digest content-length",
>       signature="jgSqYK0yKc...ZZItOuhIs78w="
>
>     {
>       "@context": "https://w3id.org/payswarm/v1",
>       "type": "Transaction"
>       "transfer": {
>         "type": "Transfer",
>         "amount": "7.50",
>         "currency": "USD",
>         "source": "https://bluebank.com/people/john/accounts/party-funds",
>         "destination": "https://redbank.com/people/jane/accounts/hosting",
>         "comment": "Chipping in for the Pizza Party tomorrow."
>       },
>       "signature": {
>         "type": "GraphSignature2013",
>         "created": "2011-09-23T20:21:34Z",
>         "signer": "http://bluebank.com/people/john/keys/5",
>         "signatureValue": "ExMgoDIyOGQzNGVkMzVmmM...yZTkZDYMI="
>       }
>     }
>     Question: How are duplicates handled? 
>

Melvin,
This is a generic problem.  In a system developed by the EU for dealing with e-passports
over the border they "forgot" to say to the implementers how to deal with duplicates which have
created a nightmare of non-interoperability.

If I were to rule, duplicates should be tolerated but of course not generate a new
transaction.   This requires that each message carries a (for the sender) unique ID but that
is pretty much standard.  Date doesn't IMO suffice.

Anders

>     An astute reader might recognize that there are two signatures in this
>     request. The first one is on the HTTP message, the second one is on the
>     transaction. This is done because the first signature is designed to
>     authenticate the client (person or organization making the call). The
>     second signature is designed to authenticate the request (which may have
>     been made by a different person or organization than the entity making
>     the request). This dual-signature approach allows agents to relay
>     financial requests on behalf of other people or organizations. One
>     optimization would be to remove the signature in the message so that
>     only one signature is necessary for this type of transaction.
>
>     The HTTP Signatures specification is utilized by the Web Payments
>     specification, the Secure Messaging specification, and the Web Identity
>     specification, which are then used by most every other specification
>     that this group is working on that requires REST API authentication.
>
>
> Is there a possible replay attack where the same transaction may be actioned more than the intended number of times?
>  
>
>
>     -- manu
>
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: The Worlds First Web Payments Workshop
>     http://www.w3.org/2013/10/payments/
>
>