Re: [jose] JOSE and signed REST requests

[Carsten Bormann <[e-mail]>]

> [...] 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