Re: HTTP Signatures specification updated

On 1 February 2014 19:54, Manu Sporny <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
> 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?
> 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/
>
>