> [...] 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
I'm don't think that this will help you with your payment project, but, you said REST and didn't specifically ask for HTTP, so here is another standards effort you might want to be aware of: draft-selander-ace-object-security–05 In the Berlin CoRE WG meeting, there was in-room consensus to adopt this as a WG document (to be confirmed on the mailing list), so this should not be too far out. [Sorry about the WG name confusion -- ACE is focusing on how to do OAuth in constrained-node networks, but the protected CoAP exchanges themselves actually are a CoRE WG issue, where we use COSE formats for the actual protection.] > I would rather have dropped REST in favor of transport-independent > schemes using self-contained JSON-encoded signed message objects. [Pet peeve: HTTP is not a transport protocol.] This removes the REST abstraction that is quite useful to the application designer. Having the application designer create the security protocol around signed message objects also has increased potential for mistakes around freshness, context binding etc. You get to verify your whole application-layer message interaction against the security objectives; you need a larger amount of luck with that than with protected REST primitives. Grüße, Carsten _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
