There's also this approach:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02
It's more limited than a general HTTP signing mechanism, but as a
consequence it's more robust for systems that mess with the HTTP message
in transit (which we know happens in the real world).
-- Justin
On 8/2/2016 1:32 AM, Anders Rundgren wrote:
Hi All,
I was recently involved in an inter-bank payment project based on a
REST API.
Since my role was "cryptography" I recommended the following approach
http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
since an operation is defined not only by the message payload, but
also by the HTTP verb, URI, and header parameters.
The only related standards effort I'm aware of is this:
https://tools.ietf.org/html/draft-cavage-http-signatures-05
Unfortunately the methods above get rather awkward if you have a
system where requests are supposed to be embedded in other messages or
just proxied to another server.
I would rather have dropped REST in favor of transport-independent
schemes using self-contained JSON-encoded signed message objects.
WDYT?
Anders
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
